MCP OAuth client-interop conformance

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

No annotations are provided, so the description carries the full burden. It usefully discloses the auth requirement (Bearer token required), the POST /trial/claim endpoint, and the one-time, first-server-only eligibility constraints, but says nothing about failure modes (e.g., what happens on a second claim), idempotency, or the response.

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 compact sentence with the core offer front-loaded and technical details (endpoint, auth) relegated to a parenthetical. No wasted words, though the parenthetical packing is slightly dense.

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?

Covers eligibility, auth, and the underlying operation, which is most of what an agent needs, but with an undocumented parameter and no output schema the agent is left guessing what server_name expects and what the claim returns.

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 0% for the single server_name parameter, and the description never names or explains it. The phrase 'for your first server' only loosely gestures at what server_name should contain, and doesn't say whether it is optional (it isn't required), an ID, or a name format.

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?

Specific verb (claim) plus a precise resource (one-time free first Solo month for your first server), which distinguishes it from the paid subscribe_solo sibling by conveying that this is a free trial, not a subscription purchase. The sibling distinction is implied by the offering, not stated as an explicit alternative.

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 'one-time' and 'first server' phrasing implies when this applies, but the description never explicitly says when to use it instead of subscribe_solo or what to do if the trial was already claimed. Usage is inferable 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?

No annotations exist, so the description carries the full burden. It does disclose the pricing/metering model and subscription exemption, which is genuinely useful, but says nothing about whether the call is read-only or state-changing, expected latency for a 'full matrix', failure/partial-result behavior, or what the response contains — a large gap for an unannotated, potentially expensive operation.

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 sentence with the verb front-loaded, and the parentheticals carry real information (endpoint mapping, pricing). Dense but no filler; slightly overloaded by stacking operation mapping and billing in one clause.

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 annotations, no output schema, and 0% parameter coverage including a nested object, the description must do much more than it does. It covers purpose and cost but omits return shape, error behavior, and the meaning of four of five inputs.

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 0% across 5 parameters, including a nested server_config object and an enum idp_shape. The description only gestures at 'client x IdP-shape' and 'full', leaving apply_shims, server_config, and the format of the clients array entries entirely undefined, and it is ambiguous whether 'full' implies the full_matrix flag.

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: 'run one full client x IdP-shape conformance matrix', and anchors it to a concrete backend operation (POST /check). That is distinct enough from the billing/account siblings (claim_trial, subscribe_solo, subscription_status) and run_history, though it never names 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?

The cost clause ('$0.01 per check unless your account has an active Solo subscription/trial') implies the agent should verify entitlement via subscription_status or claim_trial first, but that routing is left to inference. There is no explicit when-to-use/when-not-to-use statement or named alternative.

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 no annotations, the description carries the full burden and usefully discloses that the operation is a GET and that a Bearer token is required. It does not disclose return format, pagination, or rate-limit behavior, which are the remaining behavioral risks for a history-list 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?

One compact sentence with the resource and scope front-loaded, and auth/endpoint details in a parenthetical. Every element 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 simple no-param read tool this covers the essentials: what is listed, whose data, and the auth requirement. Because there is no output schema, the description should ideally say more about what a history record contains or whether results are paginated, so it is adequate rather than complete.

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 baseline for a no-param schema is 4. The description correctly adds no redundant parameter prose.

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 (list), resource (past matrix runs), scope (only your own account), and even the underlying endpoint (GET /history). No sibling could be confused with this, since the other tools cover trials, subscriptions, and conformance.

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 phrase 'list only your own account's past matrix runs' makes the intended use and its account scoping clear. It doesn't spell out when-not-to-use or name alternatives, but the sibling tools are not plausible substitutes, so little 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?

With no annotations, the description must carry the full behavioral burden. It does disclose real, non-obvious traits: a $9 charge, payment through the x402 X-PAYMENT header, and Bearer-token auth. It omits failure/rejection behavior, idempotency of repeated activation, and whether the 'extend' is additive or resets the period.

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 dense sentence with the action and price front-loaded, followed by endpoint and auth in a parenthetical. Efficient, though the parenthetical stacks three separate facts and slightly obscures the auth requirement.

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?

No output schema and no annotations, so the description should be richer. It adequately covers the payment path and auth, but leaves the only parameter undocumented and says nothing about the response, renewal semantics, or error conditions for a money-moving operation.

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 0% and the single parameter server_name is never mentioned in the description. For a paid, state-changing call the agent gets no guidance on what server_name means or whether omitting it (it is optional) is safe.

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 pair (activate/extend) and a specific resource (a Solo month), plus the backing endpoint POST /subscribe. It is clearly distinct from claim_trial and subscription_status, though it never names those siblings as alternatives.

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 by 'activate/extend a Solo month' — call it when a Solo subscription must be started or renewed — and 'Bearer token required' establishes a prerequisite. There is no explicit when-not guidance, no mention of what to do if a subscription already exists, and no reference to the sibling tools.

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 no annotations present, the description does useful work by disclosing the auth requirement ('Bearer token required') and that it is a GET/read operation. It does not state what the status payload contains or whether unsubscribed accounts return an error, which leaves behavioral gaps for a zero-annotation 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?

One front-loaded clause names the resource and the parenthetical adds only endpoint and auth detail, with no filler. The parenthetical phrasing is slightly awkward but every element carries information.

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 simple read operation the security and endpoint context is adequate, but with no output schema the description does not indicate what fields (plan, billing period, status) are returned, which an agent may need to decide whether this call answers its question.

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 no parameters, so there is nothing for the description to disambiguate; the baseline for a 0-parameter tool 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 resource and the concrete backend operation ('the GET /subscription operation'), so the agent knows exactly what is fetched. It does not distinguish itself from siblings such as claim_trial or subscribe_solo, which also relate to subscription state.

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 claim_trial (start a trial) or subscribe_solo (purchase a plan). Usage is only implied by the name and by 'your account's subscription status'.

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