One-step fetch: find the best Sugra endpoint for the query and call it. Combines search_endpoints + call_endpoint into a single round trip. Use this when you want data without manually picking an operation_id. The full search_endpoints + describe_endpoint + call_endpoint dance is still available ...
Risk signalsAccepts freeform code/query input (query) · Accepts raw HTML/template content (body)
Part of the Sugra API server.
Free to start. No card required.
AI agents call fetch_data to retrieve information from Sugra API without modifying any data. This is common in research, monitoring, and reporting workflows where the agent needs context before taking action. Because read operations don't change state, they are generally safe to allow without restrictions -- but you may still want rate limits to control API costs.
Even though fetch_data only reads data, uncontrolled read access can leak sensitive information or rack up API costs. An agent caught in a retry loop could make thousands of calls per minute. A rate limit gives you a safety net without blocking legitimate use.
Read-only tools are safe to allow by default. No rate limit needed unless you want to control costs.
{
"version": "1",
"default": "deny",
"tools": {
"fetch_data": {}
}
}See the full Sugra API policy for all 8 tools.
These attack patterns abuse exactly the kind of access fetch_data gives an agent. Each links to the full case and the policy that stops it:
Other read tools across the catalogue. The same approach applies to each: allow, with a rate cap to control cost.
One-step fetch: find the best Sugra endpoint for the query and call it. Combines search_endpoints + call_endpoint into a single round trip. Use this when you want data without manually picking an operation_id. The full search_endpoints + describe_endpoint + call_endpoint dance is still available when you need explicit control, but for most natural-language queries this tool is enough. Behavior: 1. Search the bundled catalog for the query. Top match wins. 2. If the matched endpoint has required parameters and they are all provided in params, call it and return the response. 3. If required parameters are missing, return the candidate endpoints and the missing-params list so the LLM can retry with the correct params dict on the next call. Examples: - fetch_data("US CPI inflation", params={"series_id": "CPIAUCSL"}) → calls /api/v1/fred/series/CPIAUCSL, returns observations. - fetch_data("Bitcoin price", params={"coin_id": "bitcoin"}) → calls /api/v1/crypto/bitcoin/price. - fetch_data("Latest financial news") → news_latest has no required params, returns latest news directly.. It is categorised as a Read tool in the Sugra API MCP Server, which means it retrieves data without modifying state.
Register the Sugra API MCP server in PolicyLayer and add a rule for fetch_data: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Sugra API. Nothing to install.
fetch_data is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the fetch_data rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for fetch_data. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
fetch_data is provided by the Sugra API MCP server (pypi:sugra-api-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 8 Sugra API tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.