Find paid APIs, check access policy and price, and route x402 requests. No autonomous spending.
Scored across 4 tools
catalog and status heavily overlap — both promise 'free pre-spend' info plus the 'canonical paid execution authority,' making them hard to tell apart. policy and quote are more distinct, but quote oddly only explains how to get pricing rather than returning it.
All four tools use a consistent ghostkey_<noun> pattern (catalog, policy, quote, status), which is predictable and readable.
Four tools is thin for a server whose stated purpose is routing paid APIs; the count is defensible only if this is purely a metadata/discovery layer, but it feels under-scoped.
The domain is executing/routing paid x402 APIs, yet every tool is descriptive metadata (catalog, policy, quote, status) with no tool that actually invokes, quotes, or settles a paid route — a dead end for the core workflow.
List GhostKey's free pre-spend tools and the canonical SML x402 paid execution authority.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld. The description adds no behavioral context beyond what annotations provide — no auth requirements, rate limits, side effects, or return format. It only restates the content category.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately sized for a simple catalog tool, though the dense jargon in the second half slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description must carry the burden of explaining what the tool returns. It states the categories listed but leaves 'SML x402 paid execution authority' undefined, so an agent lacks a complete picture of the return content or how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and schema description coverage is 100%. Per rubric, zero parameters sets a baseline of 4; the description cannot add parameter meaning where none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb (List) and a resource (GhostKey's tools and authority), which is more than a tautology. However, the phrase 'canonical SML x402 paid execution authority' is opaque jargon that an agent cannot easily parse, and there is no differentiation from the sibling tools ghostkey_policy, ghostkey_quote, or ghostkey_status. The core purpose is implied but not fully clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus its siblings. It does not mention prerequisites, exclusions, or alternative tools. Only the content of the catalog is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return GhostKey's free-discovery, payment-authority, and upstream-rights policy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description adds little behavioral detail. It does signal that the response is a policy document rather than a live operation, but doesn't describe freshness, scope, or format of the returned policy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and the three policy areas. No filler and no redundancy relative to the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument, read-only, idempotent retrieval tool with full annotation coverage and no output schema, the description covers the essential scope. It could be stronger by naming the difference from siblings or hinting at the returned structure, but it is sufficient to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so per the rubric baseline is 4. The description correctly implies the tool takes no arguments by enumerating what is returned rather than what must be supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and names three concrete policy domains owned by GhostKey, so an agent knows exactly what it yields. It doesn't explicitly distinguish itself from the sibling tools, but the policy retrieval framing is clearly different from catalog/quote/status by resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no mention of how it relates to ghostkey_catalog, ghostkey_quote, or ghostkey_status. The agent must infer that this tool is for policy questions rather than pricing or inventory. Nothing states when this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain how to obtain authoritative route pricing from a fresh live SqueezeOS x402 402 challenge.
| Name | Required | Description | Default |
|---|---|---|---|
| capability | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, covering the safety profile. The description adds one useful behavioral claim — that the tool explains how to obtain pricing rather than returning pricing directly — but leaves the crucial question of whether it issues a live network challenge or just returns instructions unresolved, and mentions no auth or rate-limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler, which is appropriately brief. But it is dense with undefined proprietary terms rather than front-loading plain-language purpose, so brevity comes at the cost of immediate comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should say what comes back (instructions? a quote object? a challenge payload?), and it does not. Combined with an undocumented parameter, the definition is too thin for an agent to invoke this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'capability' has 0% schema description coverage, so the description carries the full burden and fails: it never mentions the parameter, its accepted values, or what a capability string should look like. The agent is left guessing what to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb is 'explain' and the resource is 'authoritative route pricing', so the intent is at least identifiable. However, the phrasing is heavily jargon-laden ('SqueezeOS x402 402 challenge') and never distinguishes this tool from ghostkey_catalog, ghostkey_policy, or ghostkey_status, leaving the agent to guess which sibling to pick. It also sits ambiguously between documenting a process and performing one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus the sibling tools, no prerequisites, and no exclusions. The only implied usage is 'when you need route pricing', which is not sufficient to route between four ghostkey tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report GhostKey's free pre-spend discovery status and the canonical paid execution authority.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered by structured data and the description does not contradict it. The description adds only a hint about what information is reported; it says nothing about what the two status facets contain, whether values are static or fetched live, or how the paid authority relates to the other tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with no filler or redundancy. It is front-loaded with the verb and the primary subject, though the second clause ('canonical paid execution authority') is dense jargon that could have been stated more plainly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry the return-shape burden, and it does not: an agent cannot tell whether 'status' is a boolean, an enum, or a structured object, nor how the two reported facets are separated. For a zero-parameter introspection tool it is minimally adequate but leaves the caller guessing about the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the baseline the schema carries no semantic burden the description must compensate for. The description introduces no parameter behavior to confuse the caller.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Report' and the pairing of two specific subjects ('pre-spend discovery status' and 'canonical paid execution authority') give the tool a recognizable purpose, but both subjects are domain jargon that an agent cannot interpret without outside knowledge. It also does not distinguish itself from the sibling tools (ghostkey_catalog, ghostkey_policy, ghostkey_quote), which are presumably the adjacent sources of that information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus ghostkey_policy or ghostkey_catalog, no prerequisites, and no stated conditions. The agent is left to infer that this is a general status/introspection call from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ghostkey_catalog2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseghostkey_policy2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseghostkey_quote1 field changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"ghostkey_status2 fields changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseghostkey_catalogghostkey_policyghostkey_quoteghostkey_statusDiscover x402 paid APIs and inspect fresh payment requirements before authorizing spend.
Read-only BUY / WAIT / AVOID spend gate for paid APIs, MCP endpoints, and x402 routes.
Pay-per-call x402 gateway: agent tools, OpenAI-compatible LLM, market data, RPC, security audits.
Advisory context, intent, budget and API-ledger checks with free examples and x402 payments.
Add one secure layer between your agents and this server.
