CrossingKey MCP

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

Beyond the annotations, the description discloses valuable traits: the exact cost ($0.10 USDC on Base via x402), that no funds are spent on this call, and that it returns the PAYMENT-REQUIRED challenge plus the canonical paid execution endpoint. This is meaningful context the annotations do not carry. There is a mild tension with readOnlyHint=false (the call is described as non-spending and challenge-returning), but not a clear contradiction.

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?

Three tight sentences with the price front-loaded and the crucial 'does not spend funds' caveat placed before the mechanics. Efficient overall, though the cost-first opening slightly obscures the tool's actual operation.

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?

An output schema exists, so return-value explanation is unnecessary, and the payment flow is covered. But given 33% parameter coverage and a nested-object param, the description leaves idempotency_key and payment_payload entirely unspecified, which is a real gap for a 3-param tool.

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?

Schema description coverage is only 33%, so the description must compensate, and it largely does not. 'Supplied text artifacts' loosely maps to the artifacts array, but idempotency_key and payment_payload receive no explanation of format, purpose, or when to supply them.

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 gives a specific verb+resource: 'Creates deterministic SHA-256 entries and a root manifest hash for supplied text artifacts.' This clearly distinguishes it from siblings like commerce.quote or result.preview. However, it also muddies the purpose by pairing 'Purchase'/'PAID' framing with 'does not spend funds', leaving some ambiguity about what this call actually does.

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 explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The only contextual cue is that calling it returns a payment challenge, which implies usage but does not state conditions for selecting it over siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context with 'FREE' (no cost incurred), which the annotations do not convey, plus the nature of the returned marketplace data.

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 dense sentence, front-loaded with the 'FREE' signal and then the parameter routing. Nothing is wasted, though the compressed phrasing makes the two modes slightly harder to parse than a short structured list would.

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?

An output schema exists, so return values need not be explained. With zero required parameters, the description adequately signals that either name or capabilityId is the entry point, though it never states outright that at least one must be supplied.

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?

Schema coverage is 100%, so the baseline would be 3. The description adds meaning beyond the schema by characterizing name as 'legacy deterministic' and capabilityId as 'public marketplace' metadata carrying rights and provenance, sharpening the distinction between two nearly identical-looking string parameters.

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?

Names the resource (capability) and distinguishes the two lookup modes clearly: 'legacy deterministic capability metadata' via name versus 'public marketplace metadata, rights and provenance' via capabilityId. It does not explicitly differentiate itself from the sibling capability.search tool, which is the main gap.

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 routes the agent between the two parameters ('use name for X or capabilityId for Y'), which is useful selection guidance. However it gives no when-to-use context relative to alternatives such as capability.search or marketplace.describe, and no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed world, so safety is covered. The description adds genuinely non-obvious behavior: metadata search is free while purchased execution and deliverables are not, and results are limited to active public listings. It stops short of noting pagination limits, which the schema already documents.

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?

Four tight sentences with the scope banner front-loaded and every prohibition paired with a redirect. No filler, and the routing information is placed where an agent will read it first.

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 an output schema present and annotations covering the safety profile, the description only needs to establish scope and routing, which it does completely. Nothing required to call this correctly is missing.

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?

Schema description coverage is 100%, so all eight parameters (query, category, provider, deliveryType, price bounds, limit, offset) are already documented in the schema. The description enumerates the same filter dimensions without adding syntax, units, or format guidance beyond the schema, so baseline 3 is correct.

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?

States a specific verb (search) and resource (active public marketplace capabilities) and immediately constrains the scope to filtered discovery. It explicitly distinguishes itself from catalog.list, offers.list, and capability.get by name, so an agent can route without opening schemas.

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?

Gives explicit when-to-use ('when one or more filters are known') and two explicit when-nots with named alternatives (catalog.list for unfiltered browsing, offers.list for CrossingKey offers), plus a routing note to capability.get for exact IDs. This is the full when/when-not/alternative pattern.

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

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

Annotations already cover the safety profile (readOnly=true, destructive=false, openWorld=false), but the description adds substantive context the annotations cannot: metadata is free while execution, entitlement, delivery, and purchased output remain gated, and only 'active public' entries are returned. It does not describe pagination limits or result ordering, so it falls short of a 5.

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?

Front-loaded with the key scope constraint in caps, then each subsequent sentence handles one concern (usage, gating, exclusions). Dense but every sentence earns its place; the all-caps opening is slightly heavy-handed.

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 read-only paginated list tool with an output schema present, the description covers scope, gating semantics, and sibling routing, so return-value explanation is correctly omitted. Ordering/filtering guarantees on the returned list are the only notable gap.

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?

Schema description coverage is 100% and both parameters (limit, offset) are fully documented with ranges and defaults, so the schema does the heavy lifting. The description's 'page through' phrase reinforces the pagination intent but adds no format or syntax detail beyond the schema. Baseline 3 applies.

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?

States a specific verb ('page through') and resource ('active public marketplace capabilities'), and explicitly distinguishes itself from three named siblings (capability.search, offers.list, capability.get). An agent can route correctly without opening any schema.

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?

Explicitly states when to use it ('no search filters are needed') and when not to, naming the alternative tool for each exclusion (filtered discovery -> capability.search, CrossingKey offers -> offers.list, exact id -> capability.get). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond them: 'A quote grants no entitlement and performs no execution,' and it names the pricing components returned. It doesn't mention quote validity/expiry or refresh behavior, which would matter for a pricing artifact.

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?

Front-loads the scope in the first clause and is dense with routing information, but the 'Do NOT use ... use cost.estimate' pattern appears twice with the same alternative, which is mildly redundant. Slightly longer than needed but every remaining sentence carries routing value.

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 an output schema covering return values, full annotations, and a single fully documented parameter, the description covers everything an agent needs: the prerequisite (active capabilityId), the safety profile, the boundaries, and the next step for execution.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents capabilityId fully. The description's 'active marketplace capabilityId' phrasing adds no syntax or constraint detail beyond the schema's 'Exact active public marketplace capability identifier.' Baseline 3 is appropriate.

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?

States a specific verb and resource ('return authoritative gross price, CrossingKey fee, provider share, and x402 v1/v2 payment requirements' for a marketplace capabilityId). It explicitly distinguishes itself from cost.estimate and capability.purchase, so an agent can route without opening any schema.

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?

Gives explicit when-to-use ('after selecting an active marketplace capabilityId'), two explicit when-not cases (first-party paid capabilities; generic price lookup) each paired with the alternative to use instead, plus the follow-on tool for execution. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds that the tool is free and explicitly never creates checkout, reserves funds, or contacts a facilitator, which is useful behavioral context beyond the annotations.

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?

Two sentences are efficiently used: the first front-loads the key qualifiers 'FREE read-only', and the second lists explicit negative side effects. No wasted words, and the most important information comes first.

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 a rich output schema and annotations, the description provides adequate safety and cost information. However, it omits when to choose this tool over quote-related siblings, leaving a minor gap for agent selection.

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?

Schema description coverage is 100%, so the single parameter item_id is fully documented in the schema. The description adds no additional parameter meaning, making the baseline score of 3 appropriate.

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 and resource (cost estimate) but essentially restates the tool name; it does not explain what is being estimated or differentiate from siblings like commerce.quote. The added 'FREE read-only' is behavioral context, not purpose clarification.

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 guidance is given on when to use this tool versus alternatives such as commerce.quote or offers.list. The description only offers negative constraints about what the tool does not do, leaving the agent to infer appropriate usage.

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

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

Annotations already declare a write operation (readOnlyHint=false) with destructiveHint=true. The description adds valuable context beyond annotations: 'No ownership transfer' clarifies the scope of the write, and 'AI training defaults false' discloses a privacy default. These are specific behavioral traits that help set expectations, though the description does not explain what exactly gets created or destroyed.

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 extremely concise with no wasted words. However, 'FREE WRITE' is cryptic and the fragmented sentences (sentence fragments) make it slightly less front-loaded and clear, but overall it is efficient.

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?

Given the tool's complexity (write operation, destructive hint, nested object parameter, and an output schema), the description is adequate but minimal. It covers privacy and ownership defaults but leaves the core action ('intake' process) and the meaning of 'capability model' unexplained. The output schema exists, so return values need not be described.

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?

Schema description coverage is 100%, so all parameters are fully documented in the schema. The description does not add any meaning beyond what the schema provides (e.g., it never mentions 'provider' or 'summary'). Baseline 3 is appropriate when the schema does the heavy lifting.

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 presents 'private creator intake' as the purpose but uses a noun phrase rather than a clear verb+resource. It does not distinguish from sibling tools like provider.register or marketplace.describe, and 'capability model' is jargon that isn't defined. The action (submitting an intake) is implied but not stated explicitly.

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 use this tool versus alternatives, nor any prerequisites or context for invocation. The constraints ('No ownership transfer and AI training defaults false') describe behavior but not usage conditions.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful context beyond those annotations: the listing is free, and the tool never starts payment or creates accounts. It does not cover auth requirements or rate limits, but for a no-argument read-only listing tool this is appropriately transparent.

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 three compact sentences, front-loading the primary purpose and then the key behavioral exclusions. Every sentence earns its place, and there is no redundant or filler language.

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?

The tool has no parameters and an output schema, so the description does not need to explain inputs or return values. It fully covers what the tool does and what it does not do. Nothing essential for correct invocation is missing.

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?

There are zero parameters, so there is no parameter semantics to explain. Per the rubric, a zero-parameter tool has a baseline of 4. The description does not need to add parameter meaning.

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 specific verb and resource: listing available prepaid request-credit packs, with identifiers and credit amounts. It also distinguishes this tool from purchasing by saying checkout handles purchases and this tool never starts payment or creates accounts. An agent can clearly tell what this tool does.

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 clearly implies this is for viewing credit-pack options before purchasing, and explicitly excludes payment/account-creation behavior. It routes purchasing to checkout, but does not name a specific sibling tool or give an explicit when-to-use statement. The guidance is clear but not maximally explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description still adds useful context beyond them: it explicitly disclaims authorization, purchase, settlement, execution, and record creation, and names the sole return state. No output details are needed since an output schema exists.

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?

Front-loaded and compact: the defining trait ('FREE read-only') and the return value come first, followed by a tight negation list. The list of five negative verbs is slightly redundant but each forecloses a plausible misreading of 'execution'.

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 annotations covering safety, an output schema covering the return, and full schema coverage on the only parameter, the description is nearly complete for the call mechanics. The remaining gap is ecosystem-level: no routing guidance among many closely related audit/check siblings in a 21-tool set.

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?

Schema description coverage is 100% and the single parameter item_id is fully documented in the schema, including its provenance from offers.list. The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 the tool is a 'read-only execution preflight' that returns READY_FOR_HUMAN_AUTHORIZATION, which conveys the gating/readiness function more than the name alone. However, 'preflight' is abstract and the description never clarifies what the check actually validates, nor distinguishes it from close siblings like requirements.check, result.preview, machine_commerce.readiness_audit, or x402.compatibility_audit.

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?

It never says when to call this vs. any of the ~20 sibling tools, nor what prerequisite state (e.g., a prior offers.list call) is needed before invoking it. The only implicit guidance is 'FREE' implying it is cheap to call, which is weak.

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

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

With readOnlyHint=false and openWorldHint=true, the agent knows this touches external state; the description usefully clarifies the critical nuance that invoking the MCP tool does not itself spend funds and instead returns a payment challenge plus the canonical paid endpoint, plus the $2.00 USDC-on-Base cost. It stops short of describing what the audit covers or returns, but the payment-flow disclosure is substantive.

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?

Two sentences, front-loaded with the most decision-critical fact (the price and payment rail), then the effect on funds and the return shape. Dense and efficient, though x402/PAYMENT-REQUIRED jargon assumes a knowledgeable reader.

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 paid, open-world audit tool, the definition covers cost, the no-funds-spent guarantee, and what the call returns; the output schema exists to describe return structure. The main gap is scope relative to sibling audit tools and what surfaces are actually checked.

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?

Only one parameter ('url'), documented at 100% schema coverage as 'Base URL of the machine-commerce service to audit'. The description adds no format, example, or constraint beyond the schema, so it is the standard baseline when the schema carries the semantics.

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?

States a specific verb+resource: 'Checks machine-commerce discovery and health surfaces', which tells the agent what the audit inspects. However, it does not distinguish itself from closely related siblings such as x402.compatibility_audit, mcp.schema_audit, or openapi.quality_audit, all of which are also 'check/audit' tools.

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?

It clarifies the payment mechanics of the call itself ('does not spend funds; returns the exact PAYMENT-REQUIRED challenge and canonical paid execution endpoint'), which is useful context for deciding to invoke it. But it gives no guidance on when to choose this audit over the many sibling audit/compatibility tools, leaving that to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds non-annotation context: the call is 'FREE' and it is an overview (not a deep query). It does not discuss rate limits or freshness, which is a minor remaining gap.

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?

Two compact sentences, with the scoping and 'use first' cue front-loaded ahead of the alternative-tool routing. Every clause earns its place.

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?

An output schema exists, so return values need not be described. For a zero-parameter read tool with full annotation coverage, the description supplies everything an agent needs: purpose, cost, when to call, and which sibling to prefer instead.

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 there is nothing for the description to disambiguate; the 4 baseline applies. The schema's additionalProperties=false is self-documenting.

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?

States a specific verb and resource ('marketplace overview') and immediately names the sibling it is not ('use provider.describe for the broader CrossingKey provider and legacy offer surface'). An agent can distinguish it from provider.describe and the other 21 siblings without opening a schema.

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?

'Use this first for marketplace-specific capability commerce, fee policy, creator rights, payment rails, and active catalog counts' gives an explicit when-to-use condition, and the second clause names the alternative and its scope. Nothing is left to inference.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, and the description adds the crucial behavior that this call does not spend funds but returns a PAYMENT-REQUIRED challenge plus the canonical paid endpoint. That resolves the apparent tension of a 'paid' tool that is safe to call, and is genuinely beyond structured data. It stops short of stating auth requirements, rate limits, or what happens on the paid follow-up call.

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?

Three sentences, front-loaded with the price and payment rail, then what it scores, then the safety clarification. Every sentence carries information, though the payment sentence is dense enough that the core purpose arrives second.

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?

An output schema exists, so return-value detail is unnecessary, and the description covers the non-obvious pricing/payment semantics an agent must know before calling. The remaining gap is the absence of any when-to-use routing against the many audit siblings.

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?

Only one parameter exists, and schema description coverage is 100% ('MCP tool definitions to audit'), so the schema already carries the parameter meaning. The description restates the audit target but adds no format, size, or shape guidance for the tools array beyond the schema. Baseline 3 is appropriate.

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?

States a specific verb and resource ('Scores supplied MCP tool schemas') and names the dimensions measured (discoverability, descriptions, bounded input contracts). This clearly separates it from siblings like openapi.quality_audit and x402.compatibility_audit, which audit different artifacts.

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 explains the payment model and what a call actually returns, which implicitly tells the agent this is the discovery step before paid execution. However, it never states when to prefer this over sibling audits (openapi.quality_audit, x402.compatibility_audit) or what inputs qualify. Usage is implied rather than directed.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds meaningful context beyond annotations: 'FREE' and 'never starts payment or execution,' which directly informs an agent's safety and cost expectations. It does not cover rate limits or auth requirements, but the core behavioral promise is clear.

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?

Two short sentences, front-loaded with the core purpose and immediately followed by the critical safety guarantee. No filler or redundancy.

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?

Given the tool's simplicity, full schema coverage, existing annotations, and a separate output schema, the description is nearly complete for correct invocation. The only gap is sibling differentiation, which is a usage guideline concern rather than a call-correctness issue.

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?

Schema description coverage is 100%, so the input schema fully documents both parameters (limit, query). The description adds no parameter-level detail beyond what the schema already provides, making a baseline 3 appropriate.

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 specific verb+resource: 'public offer and capability discovery,' and clarifies it is read-only and free. It distinguishes itself from payment/execution tools but does not explicitly differentiate from siblings like capability.search or catalog.list.

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?

Usage is implied: use this for free read-only discovery of public offers and capabilities. However, there is no explicit when-to-use guidance relative to alternatives such as capability.search or catalog.list, and no when-not-to-use conditions.

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

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

Annotations leave readOnlyHint=false, which could mislead an agent into expecting a write; the description resolves this by explaining the tool returns a PAYMENT-REQUIRED challenge rather than spending funds. That is meaningful behavioral context beyond the hints, though the actual execution flow after payment is not spelled out.

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?

Three tight sentences with the cost/payment constraint front-loaded, which is the most decision-relevant fact. No redundant filler.

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?

An output schema exists so return values need not be explained, and the description supplies the payment context that the schema and annotations cannot. Complete enough for an agent to decide and call, with only the post-payment flow left implicit.

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?

Schema coverage is 100% and there is a single parameter ('spec') whose schema description already documents it as the parsed OpenAPI document. The prose adds no format, size, or validation detail beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource ('Evaluates structural quality and required fields in an OpenAPI document') and adds the pricing/payment model up front. It is clear what the tool does, though it never names the closest siblings (mcp.schema_audit, x402.compatibility_audit) to draw the boundary.

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 clarifies the payment mechanics ('Calling this MCP tool does not spend funds') which is a real usage consideration, but it gives no explicit when-to-use versus alternatives among the many audit/preflight siblings. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds one genuinely new fact — that the call is FREE (no cost/credits) — which is not in the annotations. It says nothing about rate limits, auth requirements, or what 'commerce policy' contains.

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?

Two compact sentences, no filler, and the key qualifier (FREE read-only) is front-loaded before the routing hint. Every clause earns its place.

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?

An output schema exists, so return values need not be described. But for a zero-param discovery tool the description leaves the domain ambiguous — 'provider' and 'commerce policy' are undefined, and no distinction from provider.get or marketplace.describe is drawn, which is the main thing an agent needs.

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 the baseline is 4 and there is no parameter meaning for the description to supply or omit.

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 names a concrete verb-resource pair ('provider and commerce policy discovery') and states the scope (read-only, free), which is more than a tautology of the title. However, it does not distinguish itself from close siblings like provider.get, marketplace.describe, or capability.search, so an agent cannot route on the text alone.

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?

'Use this before selecting an offer or capability' gives a sequencing cue, implying usage ahead of offers.list/commerce.quote. But it names no alternative tool and gives no when-not-to-use condition, so the guidance is implied rather than explicit.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower, yet the description still adds real behavioral context: the call is free, it returns only active providers, and pending applications gate on owner/administrator authorization. That auth-condition disclosure is genuinely useful for an agent deciding whether the call will succeed.

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?

Three short fragments with zero filler, and the most decision-relevant fact (FREE) is front-loaded. It is arguably too terse given the sibling ambiguity, but nothing in it is wasted.

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 an output schema present, return values need no explanation, and the parameter is fully documented in the schema. The remaining gap is sibling differentiation from provider.describe, which matters given the crowded toolset and is not addressed.

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?

There is a single required parameter with 100% schema description coverage, including a precise regex pattern and the 'CrossingKey marketplace provider identifier' definition, so the schema carries the full burden. The description adds nothing about providerId, so baseline 3 applies.

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 phrase 'Public active provider metadata' identifies the resource and scope (active providers only), which is more informative than the bare tool name. However it never states a retrieval verb and gives no signal distinguishing it from the sibling provider.describe, so an agent cannot tell which of the two to call.

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?

'FREE' tells the agent there is no cost barrier, and the authorization note tells it that pending applications require owner/admin rights, which implicitly routes it toward active providers. But there is no explicit when-to-use versus provider.describe, and no statement of what happens for non-existent IDs.

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

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

The description adds real context beyond annotations: it declares the intake is FREE and enumerates the side effects that do not occur (no credential, approval, payment, ownership transfer, or active capability). That is valuable for a write tool. There is mild tension with destructiveHint=true, since the description frames this as a harmless pending-record intake with no substantive state change, but it does not falsely claim read-only behavior, so this is a nuance rather than a contradiction.

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?

Two sentences, zero filler, and the scope boundary plus the FREE framing are front-loaded before the sibling routing. Every clause earns its place.

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?

An output schema exists, so return values need not be explained, and the safety/mutation profile is covered by annotations plus the description's explicit list of non-effects. The only gap is what happens after intake (review/approval flow, duplicate handling beyond the slug hint), which is desirable but not essential to invoke 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?

Schema description coverage is 100%, so the schema already documents slug, contact, description, displayName, and website with lengths and patterns. The description adds no parameter-level detail, which is acceptable given the schema does the work, so the baseline 3 applies.

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?

States a specific verb and resource ('Submit a pending marketplace provider application') and immediately bounds the scope by naming what it does not create. It also names the sibling creator.apply and the condition that selects it, so an agent can distinguish the two without opening either schema.

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?

Explicit routing: use this tool for provider applications, use creator.apply instead when submitting an asset or body of work needing a capability model. The when-to-use and the alternative are both stated rather than implied.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description still adds two pieces of context beyond them — that the call is FREE (no cost) and that it will never authorize or start payment or execution, drawing an explicit boundary against payment/execution siblings. It stops short of describing latency or result shape, but with annotations present this is solid added value.

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?

Two short, front-loaded sentences with no filler; each carries a distinct fact (cost, negative capability boundary). It is efficient, though the terseness leaves purpose under-explained rather than being wasteful.

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?

An output schema exists, so return values need not be described, and the sole parameter is fully covered. What is missing is the surrounding commerce context: what requirements are being checked and when in a purchase flow this should be called instead of execution.preflight or commerce.quote.

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?

Schema description coverage is 100% and the single item_id parameter is fully documented in the schema, including its source (offers.list). The description adds nothing about the parameter, so the baseline 3 applies.

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?

"FREE read-only requirements check" largely restates the tool name (requirements.check); it never says what a "requirement" is, what resource is inspected, or how it differs from siblings like execution.preflight or commerce.quote. The only added content is a cost qualifier and a safety qualifier, not a statement of purpose.

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 and no named alternatives, despite a crowded sibling set (commerce.quote, execution.preflight, cost.estimate, offers.list) that plausibly overlaps. The agent must infer the trigger condition entirely.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety baseline is covered. The description goes further by naming the specific side effects it avoids — no capability execution, no entitlement, no receipt — which tells the agent this call consumes nothing and mutates no account state. It stops short of describing cost, rate limits, or what the preview contains.

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?

Two short sentences, zero filler, with the most decision-relevant fact (FREE, read-only) front-loaded. Nothing is repeated from the structured fields.

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?

An output schema exists, so return values need no explanation, and the single required parameter is fully specified by the schema. For a one-param read-only preview, the description supplies the essential non-side-effect guarantee; only the routing against sibling tools is missing.

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?

Schema description coverage is 100% and the single item_id parameter is fully documented in the schema (including provenance from offers.list), so the description is not obliged to restate it. It adds no format or constraint nuance beyond the schema, so the baseline 3 applies.

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 names a concrete action (preview of a 'result-shape') and asserts a key property ('never executes'), but the object of the preview is left implicit — an agent must infer from the schema that it previews the result shape of the capability referenced by item_id. It does not clearly distinguish itself from execution.preflight or capability.get, which appear to live in the same problem space.

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?

Signaling 'FREE' and 'never executes' implies this is the cheap, safe alternative to actually running a capability, so the usage is implied rather than stated. There is no explicit when-to-use/when-not versus execution.preflight, capability.get, or requirements.check, which are the most plausible siblings an agent would weigh against it.

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

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

With annotations only covering readOnly/openWorld/destructive, the description supplies non-obvious behavioral facts: the $1.00 USDC on Base cost, the x402 payment mechanism, that invocation itself spends nothing, and that it returns the PAYMENT-REQUIRED challenge plus the canonical paid execution endpoint. This is exactly the 'beyond annotations' context that matters for a paid, network-touching tool.

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?

Three short sentences, with the cost and payment method front-loaded before the functional description and the crucial 'does not spend funds' clarification. No filler or repetition.

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 one-parameter paid tool with an output schema and partial annotations, the description covers everything an agent needs: price, payment chain, no-charge invocation, and the nature of the returned challenge/endpoint. Return-value detail is present but need not carry the burden since an output schema exists.

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?

Schema description coverage is 100% and there is a single well-described 'url' parameter, so the schema already carries parameter meaning. The description adds no format, constraint, or example detail beyond what the schema provides, which lands at the baseline for full coverage.

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?

States a specific verb and resource ('Audits an x402 endpoint for v1/v2 compatibility defects'), scoping it to the x402 protocol domain rather than generic audits. It is reasonably distinct from sibling audit tools such as mcp.schema_audit and openapi.quality_audit, though it never names or contrasts with them explicitly.

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 explicit when-to-use/when-not-to-use guidance or named alternative among the many sibling audit tools. The statement that calling it 'does not spend funds' does clarify invocation semantics, and the price line implies intent (you use this before paying for an audit), but the agent still has to infer when this tool is the right pick.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, and the description adds genuinely new behavioral facts: it consumes paid prepaid credit, charges only on verified success, and requires an authenticated ck_ principal. This billing/auth disclosure is exactly the extra context annotations cannot carry.

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?

Three short, front-loaded sentences with no filler; the paid/credit constraint leads. Slightly terse on what 'validation' actually produces, but every sentence earns its place.

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 two-parameter tool with full schema coverage, an output schema, and annotations covering the safety/idempotency profile, the description supplies the missing commercial and auth context. The only real gap is a lack of explicit contrast with the free discovery siblings.

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?

Schema coverage is 100% and both parameters (raw_intake, idempotency_key) are fully documented with constraints in the schema. The description adds nothing about parameter syntax or intent, so the baseline 3 is correct.

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?

States a specific verb (validate) and resource (XKEY intake) plus the commercial nature (PAID prepaid-credit). No sibling tool in the list validates XKEY intake, so the agent can place it, though it never names an alternative to differentiate behaviorally.

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?

'Discovery is free; execution is not' and 'commits one credit only on verified success' imply prerequisites and a cost boundary, but there is no explicit when-to-use versus when-not, nor any named discovery sibling (e.g. capability.get or x402.compatibility_audit) to route the agent.

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