Anthid

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly describes the output contents and input flexibility. It does not explicitly say 'read-only,' but a documentation lookup tool with this description is evidently non-mutating, so no contradiction or major gap 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?

The description is three sentences: the first states the core purpose and deliverables, the second gives a usage guideline, and the third specifies accepted input formats. Every sentence adds essential information with no fluff, and important content is front-loaded.

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 two parameters and no output schema, this description is complete. It covers what the tool returns, how to provide input, and when to use it. It does not need to describe output schema because return content is already enumerated, and errors/pagination are not critical for a documentation lookup.

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% with clear descriptions for both parameters, and the tool description adds valuable semantics by explaining that endpoint accepts a path, signature, or operation ID, as well as the optional method's purpose. This enhances the agent's ability to invoke correctly beyond the schema alone.

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 'Return the full reference for one endpoint,' a specific verb and resource that clearly distinguishes it from sibling tools like list_anthid_endpoints. The scope ('one endpoint') and the detailed list of returned content (authentication, parameters, request body, response examples) leave no ambiguity about 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 instruction 'Read this before writing a request rather than inferring the shape' provides a clear when-to-use context. It implies the tool is for pre-request reference, but it does not explicitly name alternative tools like list_anthid_endpoints for broader discovery, though the sibling list makes that connection easy.

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 are provided, so the description carries the burden of disclosure. It reveals a key behavioral trait ('with its references expanded'), but does not mention error behavior, return format, or read-only nature explicitly. For a simple retrieval tool, this is adequate but not rich.

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 action and purpose, with an example embedded naturally. Every sentence earns its place; 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?

The tool is simple (one parameter, no output schema), and the description covers what it does, when to use it, and key behavior (expansion). It could mention the return format more explicitly, but for this complexity, it is largely 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?

Schema coverage is 100%, with the 'name' parameter already well-described as 'The schema name, as it appears in the endpoint description.' The description adds helpful examples but does not significantly extend the parameter's meaning 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?

The description clearly states a specific verb 'Return' and resource 'one named schema from the API reference', and differentiates from siblings by noting references are expanded. Examples like 'SubmitIntentParams' or 'OrdersResponse' further clarify the 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?

The description provides clear usage context: 'Use this when an endpoint description names a schema you need in full.' It does not explicitly name alternatives or exclusions, but the context is sufficient for choosing this tool over 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?

No annotations are provided, so the description carries the full burden. It discloses the output scope (positioning overview containing platform purpose, replacements, audience, and implementation guidance) and the intended use case. It omits return format or side effects, but for a read-only informational tool with no parameters, this is adequate and adds value beyond what the name implies.

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: the first states what it returns and its content areas; the second gives usage guidance. Front-loaded with the action, 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?

For a no-parameter, no-output-schema informational tool, the description provides all necessary context: content type, content areas, and usage guidance, while differentiating from sibling tools.

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, so schema description coverage is vacuous. Baseline 4 applies; further parameter details are unnecessary.

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

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

The description uses a specific verb ('Return') and resource ('positioning overview for Anthid'), enumerates the content areas (what it does, replaces, audience, implementation pointers), and explicitly distinguishes from search via 'before reaching for a search.' This clearly separates it from sibling 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 explicitly instructs using this tool to answer 'what is Anthid' before searching, providing a clear when-to-use directive and implying not to use search first for broad overview questions.

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 available, the description carries the full burden. It clearly states the output is a listing of endpoints with method, path, and summary, grouped by service, and frames it as a pre-search overview. It does not mention side effects, but for a simple read-only listing tool, the transparency is adequate.

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 exactly two sentences: the first states what the tool does, the second gives usage guidance. No filler or redundancy; it is front-loaded and 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?

This is a simple tool with one optional parameter and no output schema. The description covers the purpose, the content of the response, and a usage context. It could be slightly more explicit about the effect of the optional service parameter, but the schema covers that, so it is sufficiently 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 input schema has 100% description coverage for the single 'service' parameter, including an example. The description does not add parameter-level detail beyond the schema, so the baseline of 3 applies. The phrase 'grouped by service' indirectly relates to the parameter but adds no semantic detail.

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 ('List') and resource ('every documented endpoint'), and clearly states the grouping and fields (method, path, summary). It distinguishes itself from sibling tools like search_anthid_api and describe_anthid_endpoint by framing itself as an overview tool to use 'before searching it.'

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 clear context: use this to see the API shape before searching. It implies a workflow and points toward search as a later step, but it does not explicitly name alternative sibling tools or state when not to use 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?

No annotations are provided, so the description carries the full burden. It states that the tool lists 'every public page' and reveals the returned fields (title, description, URL), implying a read-only operation. However, it does not mention response format, pagination, or any potential limitations, leaving some behavioral aspects unspecified.

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: two sentences. The first states the action and output scope, the second states the purpose. There is no redundant or extraneous information, making it efficient and clearly structured.

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 tool with no parameters and no output schema, the description covers the essential context: what it lists (all public pages), what fields are included, and when to use it. It could be more complete by noting any limits or response details, but it is adequate for a basic listing 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?

The tool has zero parameters, so the input schema is trivially complete (100% coverage). The description does not need to add parameter information, and the baseline for zero-parameter tools is 4, which is appropriate 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 clearly states the tool's function: 'List every public page on anthid.com with its title, description, and URL.' This is a specific verb+resource+scope, and it differentiates from sibling tools like list_anthid_endpoints (API endpoints) and search_anthid_site (search) by explicitly listing all pages rather than searching or focusing on endpoints.

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 usage guidance: 'Use this to find the right page to cite or to fetch.' This tells the agent when to invoke the tool (to identify a page for citing or fetching) but does not explicitly contrast with alternatives like search_anthid_site, so it lacks a clear 'when not to use' exclusion.

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 behavioral burden. It discloses the output format (method, path, summary) and implies a search action. It adds context by suggesting the matched endpoints need further lookup via describe_anthid_endpoint. It doesn't cover rate limits or edge cases, but for a straightforward search tool, this is acceptable.

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 output, followed by usage guidance. Every sentence adds value and there is no redundancy. It is well-paced and immediately 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?

For a 2-parameter search tool with no output schema, the description covers the key elements: what it searches, what it returns, and the recommended follow-up. It omits details like result ordering or pagination, but given the simplicity and clear next-step guidance, it is sufficiently 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 schema already documents both parameters fully (100% coverage), so the baseline is 3. The description enriches this with illustrative query examples ('submit an order', 'list positions'), giving the agent a better sense of what natural-language-like input is expected for the 'query' parameter.

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 it searches the 'Anthid REST API reference' and 'return[s] matching endpoints with their method, path, and summary.' This distinguishes it from sibling tools like list_anthid_endpoints (which lists all) and describe_anthid_endpoint (which provides details for one), reinforced by the follow-up instruction to use describe_anthid_endpoint after a match.

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 explicitly tells when to use the tool: 'Use this to find which endpoint does something' with concrete examples. It also directs the agent to follow a match with describe_anthid_endpoint for parameters and examples. While it doesn't list specific 'when not to use' alternatives, the guidance is clear and actionable.

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. It discloses that this is a search operation returning excerpts and URLs, and it explicitly scopes the search to product/pricing/company pages. It does not mention rate limits or authentication, but for a public site search this is less critical. The clear non-mutating behavior and exclusion of API docs add useful context beyond 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?

Two sentences, front-loaded with the main action and scope. The second sentence delivers clear usage boundaries. Every word earns its place; there is no redundancy or fluff.

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?

This simple search tool has two parameters and no output schema, and the description covers purpose, scope, return format, and explicit alternatives. It provides enough context for an agent to decide when to use it and what to expect, without needing additional details.

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 is 3. The description adds value by providing example query formats ('pricing free tier' or 'which brokers') and tying them to the tool's intended use cases. This goes beyond the schema's generic parameter descriptions and helps the agent formulate effective queries.

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 ('Search'), a precise resource ('anthid.com — the product, pricing, and company pages'), and the return format ('matching excerpts with their URLs'). It clearly distinguishes this tool from sibling tools that focus on API endpoints or documentation.

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 lists when to use this tool: 'questions about what Anthid is, what it costs, which brokers it connects, or how to get in touch.' It also names an alternative: 'use the documentation MCP server at https://docs.anthid.com/mcp instead' for API endpoints, payloads, or client code.

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