Anthropic Billing

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

Annotations already convey readOnly, idempotent, and non-destructive behavior. The description adds some return-shape context ('compact totals and daily costs') and normalization, but doesn't disclose aggregation details, date handling, or error behavior. No contradiction with 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?

The description is two short sentences with no filler. The main action and return type are front-loaded, making it highly scannable.

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 6 optional parameters, 0% schema description coverage, and no output schema, the description is too thin to fully support correct invocation. It omits parameter semantics, default behaviors, and output details, leaving significant gaps.

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 description only hints at 'date range' (covering start_date/end_date/days_back). Parameters like account, group_by, and bucket_width are completely unexplained, leaving the agent without enough information to set them correctly.

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 ('Get') and resource ('normalized Anthropic cost report') with date-range scope. It clearly states what the tool does, but doesn't explicitly distinguish it from the sibling tool anthropic_billing_usage, so it misses full sibling differentiation.

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 implies when to use the tool—when a normalized cost report over a date range is needed—but provides no explicit exclusions or alternatives. It doesn't mention why to choose this over anthropic_billing_usage or list_accounts.

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, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the scope ('linked to this install') but does not disclose additional behavioral traits such as whether it returns connection status, whether it requires prior authentication, or any rate limits. With annotations covering the safety profile, a 3 is appropriate.

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, concise sentence that front-loads the purpose. It contains no fluff and is appropriately sized for a simple listing tool.

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 (one optional param, no output schema), the description is mostly adequate, but the lack of parameter semantics and any mention of return format or filtering behavior leaves gaps. The annotations cover safety, but the description does not fully compensate for the undocumented parameter.

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 schema has one optional parameter 'account' with no description, and the description does not explain what 'account' means or how it filters results. Schema description coverage is 0%, so the description must compensate, but it does not. The parameter semantics are entirely unclear, leaving the agent to guess whether 'account' is an ID, name, or filter.

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 clearly states the tool lists Anthropic Billing admin API connections linked to the install. It uses a specific verb ('List') and resource ('Anthropic Billing admin API connections'), and it distinguishes from siblings like anthropic_billing_cost and anthropic_billing_usage, which are about data retrieval rather than connection listing.

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 implies usage for viewing existing billing connections, but it does not explicitly state when to use this tool versus alternatives. It does not mention prerequisites like authentication or whether it should be used before other billing tools. The context is clear but lacks explicit guidance on when not to use it or alternatives.

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 the tool read-only and idempotent, so safety details are covered. The description adds behavioral context beyond annotations by explaining that the output is normalized and that pagination is automatically drained, which is not visible from annotations or the schema.

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 concise and front-loaded with the primary purpose. The second sentence about pagination is valuable, though slightly jargon-heavy, but it still earns its place by letting the caller know pagination is handled internally.

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 six parameters, no output schema, and no per-parameter documentation, the description is too sparse to be fully actionable. It omits the output shape, what 'normalized' means, and how the date parameters relate, so an agent would likely need additional context to call the tool 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?

The schema has six parameters with zero description coverage, and the description does not explain the meaning or interaction of start_date, end_date, days_back, group_by, bucket_width, or account. It only mentions 'date range,' leaving most parameter semantics uninferred.

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 clearly states the tool retrieves normalized Anthropic Messages API usage for a date range. It specifies an action (get), a resource (usage), and a distinguishing qualifier (normalized, Messages API), which separates it from the sibling billing cost and account list 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?

The description implies usage is appropriate for date-bounded Messages API usage queries, but it gives no explicit guidance on when to choose this tool over the similar anthropic_billing_cost or anthropic_billing_list_accounts siblings. There are no stated exclusions or alternative recommendations.

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 include idempotentHint=true and destructiveHint=false. The description adds context by explaining the permanent vs session-only login behaviors and the need for browser login. It does not mention error handling or side effects like overwriting previous tokens, but the core behavior is disclosed.

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 packed with essential information and each sentence contributes value. It is somewhat lengthy but well-structured with clear alternatives; no wasted words.

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 purpose and lack of output schema, the description covers the main usage modes and config options. It could mention the actual return value (e.g., the link or success message) when a token is passed, but it is sufficiently complete for most agents.

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 schema has 0% description coverage, but the description fully explains the 'token' parameter as a JWT for session login, and clarifies that calling with no args produces a link. This adds meaningful semantics beyond the bare schema.

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 clearly states the tool is for authentication, explaining the browser login flow and token usage. It distinguishes from siblings (billing, marketplace, etc.) by focusing on IDE agent authentication.

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?

Provides explicit usage instructions: best to add token to server config for permanent connection, or pass token for session-only login, or call with no args to get the link. It doesn't explicitly say when not to use it, but the context is clear and alternatives are not needed.

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, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds value by disclosing the exact return structure (authenticated, pending, connect_url) and the conditional behavior. This goes beyond annotations and provides useful behavioral context for a read-only, idempotent 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?

The description is two sentences, front-loaded with the main purpose, and every word serves a function. It introduces the two possible states without redundancy. Excellent conciseness and structure.

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-parameter, read-only tool with strong annotations, the description fully explains the return values (authenticated, pending, connect_url) and the two scenarios. There is no output schema, so the description carries the burden of return-format clarity, and it meets that directly. Given the low complexity, this is 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 has 0 parameters, so the baseline for parameter semantics is 4. The description adds no parameter-specific meaning because there are none, but it does indirectly clarify the output semantics, which is sufficient. No deficiency here.

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 ('Returns') and resource ('connection status and URLs'), and it distinguishes from sibling tools like 'authenticate' (which performs auth) by clarifying it reports status rather than establishing a connection. The conditional outcomes (connected vs missing credentials) add specificity.

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 when to use this tool: to check connection status and obtain URLs, particularly when credentials are missing. It explains the two states, which gives context, but it does not explicitly name alternatives or exclusions (e.g., 'use authenticate to actually connect'). That would have earned a 5.

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 discloses behavior beyond annotations: invoke returns connect/checkout links on credential/payment gaps, writes require workspace owner/admin, and invoke runs one-off without adding to toolkit. This adds context not present in the annotations (readOnlyHint=false, etc.), with no 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?

The description is a single dense paragraph without structural breaks. While every sentence adds information, the lack of formatting reduces scannability. It is front-loaded with the core purpose but quickly becomes a wall of text.

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 tool with 23 parameters and 14 actions, the description covers the main workflow, auth/payment scenarios, and the prompt library. It omits some parameter-specific details but overall provides a comprehensive understanding of how to use the marketplace, especially given the sparse annotations and no output schema.

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%, so the description must compensate. It explains the key parameters like action (with its enumerated values), mcp_id, tool_id, arguments, and prompt-related parameters. However, it does not detail all 23 parameters (e.g., immediate, tier_slug, conversation) or map each parameter to its relevant action, leaving some ambiguity.

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 clearly states the tool's role: 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It explains the core flow (search→describe→invoke) and distinguishes itself from sibling tools like billing, auth, and reporting by covering the full catalog and runtime capabilities.

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 provides explicit guidance: 'prefer invoke for a single/occasional use' vs 'use install only to make an MCP PERMANENT', and explains when to use list_tools, subscribe/cancel, report_bug, and request_mcp. It also clarifies when to use the prompt library functions (search_prompts, get_prompt, publish_prompt).

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 state readOnlyHint=false and idempotentHint=true, and the description does not contradict them. The description adds no deeper behavioral context such as what happens after submission, rate limits, or authorization needs. It gives only a telegraphed side-effect report-like action, which is consistent but not more informative.

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 one clean sentence, front-loads the purpose, and includes the crucial reproduction tip. There is no filler or repetition, so every word 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?

Although annotations are provided and the tool is simple, the description omits explaining the 'context' parameter and fails to describe what response the agent can expect. The only example of 'conversation' as a 'array' overstrings conflicts with the schema type. Combined with a low schema_description_coverage, the current description leaves gaps for correct invocation.

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%, so the description must carry parameter meanings. It only mentions the 'conversation' variable, instructing to 'include the conversation array', but does not explain that it is a string field (likely JSON) nor mentions the 'context' parameter at all. This leaves the agent without full guidance for all three input fields.

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 opens with 'Report a bug, missing feature, or send feedback', which clearly states the tool's action and resource using a specific verb and scope. It is fully distinct from sibling tools like billing, marketplace, or authentication tools, so no confusion is possible.

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 suggests when to use this tool: for bug reports, missing features, or feedback. It does not explicitly mention alternatives or exclusions, but the sibling tools are semantically so different that the context is sufficiently clear without them.

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 does not contradict annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false). Annotations already cover the safety profile, and the description adds no extra behavioral context beyond the purpose. Since the tool is trivial and annotations are sufficient, a 3 is appropriate.

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, concise sentence that front-loads the action and resource. No wasted words.

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 has no parameters, no output schema, and simple functionality, the description fully explains what it does. Annotations handle safety. Nothing is missing for an agent to correctly select and invoke this 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?

The tool has 0 parameters, and schema description coverage is 100% (empty). Per rubric, baseline for 0 params is 4. The description does not need to elaborate on parameters, and it doesn't.

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 clearly states the tool shows current MCP platform and adapter versions, using a specific verb and resource. It distinguishes itself from sibling tools, none of which seem to focus on version 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?

The description implies usage (to check versions) but does not explicitly state when to use it versus alternatives or when not to use it. Given the simplicity of the tool and clear differentiation from siblings, implied usage is adequate but not strong.

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, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating read operation. The description adds useful behavioral context beyond annotations by enumerating the exact categories of state returned (installed MCPs, connection status, accounts, tool counts), which helps set expectations without unnecessary detail.

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 entire description is a single, well-structured sentence that front-loads the purpose ('Returns the current toolkit state') and uses a colon-plus-list format to efficiently enumerate the included information. Every phrase adds value and there is no redundancy or 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?

For a zero-parameter, no-output-schema tool, the description fully answers what the tool does and what information it returns. It specifies the toolkit's current state, installed MCPs, connection statuses, connected accounts, and catalog tool counts—sufficient for an agent to decide when to call it and what outcome to expect.

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 has zero parameters, making parameter semantics largely irrelevant. The description adds no parameter details, but none are needed because the input schema is empty. Baseline 4 is appropriate for a zero-parameter tool where all behavior is fully explained in the description.

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 ('Returns') and clearly identifies the resource ('current toolkit state'), listing concrete contents: installed MCPs, connection status, connected accounts, and catalog tool counts. This distinguishes it from siblings like show_version or marketplace by focusing on aggregate state rather than version details.

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 implies when to use it: whenever an agent needs the overall toolkit state, connection status, or available capabilities. It does not explicitly compare to alternatives or state exclusions, but the zero-parameter scope and self-explanatory purpose provide clear usage context without needing sibling comparisons.

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