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

With no annotations provided, the description must carry the burden of transparency. It implies a read-only operation (counting) but does not explicitly mention side effects, permissions, or edge cases. For a simple count, this is acceptable, but it could be more explicit about returning a numeric result.

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 well-structured, consisting of two clear sentences with no unnecessary details or fluff. It efficiently conveys the purpose and usage.

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 there is no output schema, the description could benefit from stating the return type (e.g., an integer count). However, the phrase 'Count invoices' strongly implies a numeric result, making the tool's behavior sufficiently clear for typical use cases.

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 description adds minimal value beyond the input schema. It merely restates that client and status are optional filters, without explaining their exact semantics (e.g., how client is matched, whether status accepts multiple values). The schema already provides types and enums, so the description contributes little to parameter understanding.

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 that the tool counts invoices, and it explicitly says to use it when the user asks how many invoices exist. This effectively distinguishes it from sibling tools like search_invoices or get_invoice, which return detailed data rather than a count.

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 on when to use this tool: 'Use when the user asks how many invoices there are.' It also mentions optional filters, implying it can be used with or without them, which clarifies its flexibility.

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. It states the tool fetches one invoice, implying a read operation, but doesn't disclose details like whether it returns full details, error behavior for invalid IDs, or any rate limits. It's minimal but not misleading.

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 action and parameter, and includes a usage hint. 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 simple single-parameter fetch tool with no output schema, the description is sufficient. It covers the purpose, parameter, and usage context. It could mention what happens if the invoice is not found, but that's a minor 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 0%, but the description explains the invoice_id parameter with an example format (INV-0001), which adds value beyond the schema. However, it doesn't specify the expected format beyond the example, so it's adequate but not rich.

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 fetches one invoice by invoice_id, with an example format (INV-0001). It distinguishes from siblings like search_invoices and list_overdue_invoices by specifying it's for a single known invoice.

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 says to use when the user already has the invoice number, which provides clear context. It doesn't explicitly mention alternatives, but the sibling names imply other tools for searching or listing, so the guidance is adequate.

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 of behavioral transparency. It discloses that the tool fetches live data from tools.yaml, including newly added tools, and warns about a frozen connector list. This conveys dynamic, read-only behavior without explicit side effects, which is sufficiently transparent for a list 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?

The description is concise, consisting of two sentences that convey the tool's purpose, a key behavioral nuance, and a practical usage tip. There is no redundant information, and every sentence serves a clear function, making it well-structured and easy to parse.

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 simplicity of the operation (listing tools) and the absence of an output schema, the description provides sufficient context. It explains when to call the tool, what it returns (a live list), and why it matters (frozen connector list). This fully equips the user to understand and invoke 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 tool has no parameters, and the schema coverage is complete (100%). The description does not need to explain any parameters. Since no parameter information is added, the baseline score of 3 applies, indicating no additional semantic value provided beyond the 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 that the tool provides a live list of available tools from the current tools.yaml, including tools added after the chat started. It explicitly distinguishes itself from sibling tools by focusing on enumeration of tools, making the purpose unmistakable.

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 gives explicit guidance on when to use this tool: 'call this before saying a tool is missing, then invoke with run_tool.' It also explains the context of Claude Desktop freezing the connector list, which clarifies why a live refresh is needed. This effectively directs the user to prefer this tool over alternatives in a specific scenario.

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 read-only listing behavior and optional filters, but doesn't mention return format, pagination, or how 'overdue' is defined. For a simple list operation, this is adequate but sparse.

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 the purpose and filters, the second gives the usage trigger. No unnecessary words, well-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?

The tool is simple with 3 optional parameters, but the description only covers two of them, and there is no output schema or annotations. It lacks details about the 'limit' parameter and return structure, making the description incomplete for a fully informed 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 has 0% description coverage. The description mentions 'client' and 'minimum amount' but omits the 'limit' parameter entirely, and provides no additional semantic details about what 'client' refers to or how 'min_amount' is applied.

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?

Description states 'List overdue invoices only' – a specific verb and resource, and 'only' clearly scopes it to overdue invoices. This distinguishes it from siblings like search_invoices and search_paid_invoices by focusing on overdue status.

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?

Concludes with 'Use when the user asks which invoices are overdue or past due.' This provides a clear trigger for when to use the tool, but it doesn't explicitly list alternatives or when not to use 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?

Since there are no annotations, the description carries the full behavioral disclosure burden. It does well by revealing that arguments are re-validated against the target tool's compiled inputSchema, that hidden static_filters and request tenancy still apply, and explicitly asserting this is not a bypass. This adds valuable behavioral context beyond the schema, even if it does not cover side effects or failure modes.

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 compact—four sentences, each serving a distinct purpose: the essential action, the exact use-case, revalidation and constraints, and a caution against misuse. The most important information ('run by name', 'use for new tools') appears first, and no sentence 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?

The description covers the main use case, tool login source, and revalidation constraints, which is good for a generic dispatcher. However, given there is no output schema or annotations, it does not explain what the returned result looks like or how errors from the target tool are presented, leaving room for the agent to ask follow-up questions.

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 provides strong descriptions for both parameters: 'name' points to list_available_tools, and 'arguments' explains that validation happens against the target tool's inputSchema. The description adds a slight emphasis on re-validation and constraints, but overall the structured schema carries most of the parameter semantics, so a 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?

The description states a clear verb and resource: 'Run any VectorSmith tool by name with its arguments from list_available_tools.' It clearly distinguishes this from the invoice-related sibling tools by presenting it as a generic dispatcher for tools not visible in the Desktop connector list. It is more specific than a tautology and provides enough scope to avoid confusion.

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 explicitly says when to use it: 'for tools added to tools.yaml after Claude connected; Desktop will not show those names in the connector list.' It also adds an important exclusion by stating 'Not a bypass' and noting that hidden filters still apply. However, it does not directly discuss using or avoiding sibling tools, though this generic dispatcher clearly does not conflict with 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 must disclose behavior, side effects, or permissions. It only says 'Search invoices,' implying a read operation, but gives no information about return format, pagination via limit, or any potential side effects. The description adds minimal behavioral context beyond the name and schema hints.

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 concise sentences: the first states the purpose and filters, the second gives usage context. There is no redundancy or fluff, and it is front-loaded with the core action. 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?

Given the tool has 5 optional parameters, no output schema, and no annotations, the description could be more thorough. It covers the main filters and usage context but lacks details on return format, pagination, and edge cases. The mention of 'Search invoices' implies a return, but without an output schema, the description should hint at the result type. It is adequate but not complete for an agent to use it without confusion.

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 coverage is 0% (no parameter descriptions), so the description should compensate. It mentions 'free text' (query), 'client', 'status', and 'amount' (likely min_amount), but omits the 'limit' parameter entirely. The mapping is partial; the description does not explain the exact meaning of min_amount or how the status filter works (e.g., multiple statuses selelectable). It adds some meaning but is incomplete.

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 action: 'Search invoices by free text and filter by client, status, or amount.' It identifies the resource (invoices) and the filtering capabilities, which distinguishes it from siblings like get_invoice (fetching specific) and list_overdue_invoices (specialized status). The verb 'search' plus the resource is unambiguous.

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 provides a clear usage context: 'Use when the user asks about invoices, billing, or payments.' This tells the agent when to invoke it, but it does not explicitly mention when NOT to use it or point to alternatives like list_overdue_invoices or search_paid_invoices, which are more specialized. Thus it lacks explicit exclutions and alternative guidance.

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 provided, the description carries the full burden of behavioral disclosure. It mentions the core function (searching paid invoices) but lacks details on read-only nature, pagination, default limits, or any side effects. The description adds little beyond the tool name itself.

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 concise sentences, front-loading the primary action and usage context. There is no fluff or redundant information, making it efficient and easily 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?

The tool has 4 parameters, no output schema, and no annotations. The description is minimal, explaining only the basic purpose and two of four parameters. It does not mention what the return value looks like, the behavior of the 'query' parameter, or how the 'limit' applies, leaving significant gaps for an agent to correctly invoke the 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 0%, so the description must compensate. It explains the semantics of 'client' (filter by client) and 'amount' (min_amount), but completely omits the 'query' and 'limit' parameters. This partial coverage leaves two parameters unexplained, making the description insufficient for proper usage.

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 searches for paid invoices, using a specific verb and resource. It also distinguishes from sibling tools like search_invoices (which likely searches all invoices) by specifying 'already paid', making the purpose unambiguous.

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 explicitly says 'Use when the user asks about paid invoices or completed payments,' providing a clear context for when to invoke the tool. It does not mention when not to use it or alternatives, but the usage guidance is sufficiently clear.

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