Skip to main content
Glama
Sign In

fourzerotwo

by si.fourzerotwo
OverviewDiscussionsAdmin

Call a data API

call_api
Read-onlyIdempotent

Run one endpoint by the tool name that search_apis returned, with that endpoint's parameters, and get its data back as JSON (with source and licence attribution). Endpoints with free_tier "free" or "sample" cost nothing within the daily allowance (100 calls/day anonymously, 500 with a free key). Otherwise the result is a payment request: pay in USDC via x402 and retry with _meta["x402/payment"]. Invalid arguments are rejected before any charge, and failed upstream calls are never charged.

Input Schema

NameRequiredDescriptionDefault
toolYesEndpoint tool name from search_apis, e.g. "uk-postcodes__lookup" or "sanctions__screen".
argumentsNoThe endpoint's parameters as listed in search_apis results, e.g. {"postcode": "SW1A 1AA"}.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / arguments / additionalProperties
      Added value: +true
    • changedInput schema / properties / arguments / description
      Previous value: -"The endpoint's parameters"New value: +"The endpoint's parameters as listed in search_apis results, e.g. {\"postcode\": \"SW1A 1AA\"}."
    • changedInput schema / properties / tool / description
      Previous value: -"Tool name from search_apis, e.g. \"uk-police__street-crime\""New value: +"Endpoint tool name from search_apis, e.g. \"uk-postcodes__lookup\" or \"sanctions__screen\"."
    • addedInput schema / properties / tool / pattern
      Added value: +"^[a-z0-9-]+__[a-z0-9-]+$"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The endpoint's JSON response. Proxied sources return {data, source{name, licence, attribution}}; first-party endpoints return their own documented object. List responses are wrapped as {result: [...]}.",
+  "type": "object"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover the read/idempotent/open-world safety profile; the description adds substantial behavioral context beyond them: the daily allowance (100 anonymous, 500 with a free key), the x402 USDC payment flow, and the guarantee that invalid arguments or failed upstream calls are never charged. These are exactly the operational traits an agent must know before invoking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core behavior (run an endpoint, get JSON), then adds cost/payment rules compactly. Three dense sentences with little waste, though the payment detail is packed tightly enough to require re-reading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be enumerated, yet the description still notes attribution content. Combined with cost, payment, and error-charging rules, an agent has everything needed to call this correctly in the intended discovery workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters, and it correctly points to search_apis results for the endpoint-specific arguments. It also surfaces the _meta["x402/payment"] retry field, which is not present in the schema (additionalProperties: false), adding genuine meaning beyond structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (run), resource (one endpoint from search_apis), and return form (JSON with source/licence attribution). It is clearly distinguishable from list_apis and search_apis, which discover rather than invoke endpoints.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly ties invocation to the tool name returned by search_apis, which establishes the required discovery-then-call workflow. It also explains when a call is free versus chargeable and how to retry with payment, but never states exclusions (e.g. do not call with arbitrary tool names).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All fourzerotwo toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources