@aiwerk/mcp-server-bexio

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation2/5
Multiple tools have overlapping purposes or unclear boundaries, such as the various position types (item_position, discount_position, pagebreak_position, etc.) and the duplicate paystub PDF tools (get_paystub_pdf vs get_pdf_for_employee_in_month). The 'expens' vs 'expense' naming further adds confusion.
Naming Consistency2/5
While many tools follow a verb_noun pattern, there are significant deviations like create_expens, create_file_file, upload_manual_compound_entry_file_file, list_mes, and inconsistent use of 'list' vs 'search'. This mixed convention hurts predictability.
Tool Count1/5
With 310 tools, the server is far too large for a coherent MCP interface. Even for a broad ERP system, this is excessive and likely overwhelms agents, making selection difficult.
Completeness3/5
The tool set covers a wide range of business domains (contacts, invoices, orders, projects, tasks, etc.), but there are gaps (e.g., no update for company_profile, no delete for business_activity) and redundancies that indicate incomplete or uneven coverage.
Average 2.7/5 across 310 of 310 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotation title 'Create Order Repetition' by saying 'Edit'. This is an annotation contradiction, and no additional behavioral information (e.g., side effects, state changes, requirements) is disclosed beyond the bare misleading statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. The single sentence fails to convey essential information and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with nested objects, enums, and no output schema, a one-sentence description is completely inadequate. It lacks any explanation of the repetition formats, constraints, or return behavior, leaving the agent without critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says nothing about the parameters. With a nested 'repetition' object and multiple optional fields (start, end, repetition), the agent receives no guidance beyond raw schema names, which are insufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a repetition' is misleading because the tool name and title indicate 'Create Order Repetition'. The verb 'Edit' contradicts 'create', making the purpose unclear and potentially leading to incorrect invocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus alternatives like 'delete_order_repetition' or 'list_order_repetitions'. No context, prerequisites, or examples are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the tool name. Annotations indicate readOnlyHint=false and openWorldHint=true, but the description does not clarify what side effects might occur, how authentication works, or what the request body is expected to contain. It fails to leverage the body or openWorldHint annotations to explain behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified. Two words do not provide usable information; this is not conciseness but rather a lack of substance. No structure, front-loading of key details, or separation of concerns is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, a required body, no output schema, and a complex domain (bexio API). The description 'Search projects' does not explain how to construct the request, what results are returned, pagination, sorting, or any other essential context. It is wholly inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a basic description. However, the required 'body' parameter is only described as 'Request body as defined by the bexio API', which is vague and offers little semantic value. The tool description adds no extra parameter context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search projects' is a direct tautology of the tool name 'search_projects'. It provides no additional specificity about what the search does, how it filters, or what it returns, and it does not distinguish this tool from siblings like 'list_projects' or 'get_project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. There are many related search/list tools (e.g., search_invoices, search_quotes, list_projects), but the description offers no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits beyond the annotations. While annotations correctly indicate this is a non-read-only, idempotent, non-destructive operation, the description adds no additional context such as side effects, required permissions, or interaction with other bill fields. It does not contradict annotations, but adds no value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, bordering on under-specification. It does not waste words, but one phrase cannot adequately communicate the purpose and usage of a complex tool. It lacks structure and substantive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 21 parameters, 13 required, nested objects, and no output schema. The description is completely inadequate for such complexity, providing no information about return values, field relationships, constraints, or how to correctly structure an update request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains no parameter information at all. With 21 parameters and only 48% schema description coverage, the description was expected to compensate for undocumented parameters, but it does not. The schema itself provides more meaning than the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update Bill' is a direct restatement of the tool name (update_bill), providing no additional specificity about what updating a bill entails or how it differs from related tools like create_bill, get_bill, or update_bill_booking. It is a pure tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives zero guidance on when to use this tool, what prerequisites exist, or how it relates to alternatives such as create_bill or update_bill_booking. There is no mention of scenarios where this tool should or should not be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already convey. It fails to mention side effects, return values, permissions, or any constraints, even though annotations present a baseline. With readOnlyHint=false and destructiveHint=false, the description's 'Create' is consistent, but it contributes nothing extra.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification, not concise writing. A single sentence that simply restates the tool name does not earn its place and provides no useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no output schema, and no behavioral disclosure. A create operation with this complexity requires explanation of return values, dependencies, and potential edge cases, all of which are missing. The description is wholly inadequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (every parameter has a description), so the baseline score is 3. The description itself adds no parameter-related insights, but the schema already documents all fields adequately, including required and optional properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create milestone' is a near-verbatim restatement of the tool name, providing no additional specificity about the resource or context. It does not distinguish the tool from sibling operations like update_milestone or list_milestones, and offers no insight into what a 'milestone' is in this domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, relationships, or situations where a different tool would be more appropriate, leaving the agent to infer applicability solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, but the description adds no behavioral context beyond these flags. It doesn't mention side effects, prerequisites, or what 'title' refers to, so agent learns nothing new from the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but it is under-specified rather than concise. It adds no operational or contextual value and fails to communicate any useful information beyond the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema and no parameter details in the description, the content is completely inadequate. The agent cannot infer the purpose, required data, or result of calling this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'name' (string), but the description has 0% schema coverage and does not mention 'name' at all. The description provides no semantic enhancement, leaving the parameter's meaning entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create title' directly restates the tool name, providing no additional verb-resource detail or differentiation from sibling tools like update_title, delete_title, or list_titles. It is a pure tautology with no scoping or entity clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention contexts, exclusions, or sibling tools, leaving the agent without any decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. However, the description adds no behavioral context beyond annotations, such as pagination, filtering constraints, or return format. It is not contradictory, but contributes nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single word, which is under-specification rather than effective conciseness. It is not front-loaded with key details because there are no details at all.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a detailed schema and annotations, the description gives no indication of what journal entries are, what the tool returns, or how it relates to similar tools like list_manual_entries. With no output schema, the description must fill gaps, and it fails completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all five parameters, providing meaningful descriptions for each. The description adds no value, but per the baseline rule, a 3 is appropriate when the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply 'Journal', which does not state the action or resource. It is not a verb phrase like 'list journal entries' and provides no differentiation from numerous sibling list tools. The tool name itself is more informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any mention of use cases, prerequisites, or exclusions, leaving the agent with zero orientation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. However, the description adds no behavioral context beyond those annotations, such as pagination behavior, ordering semantics, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is severely under-specified rather than concise. 'Task status' is a two-word fragment that provides no actionable information; this is not a case of economy but of omission.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain what the tool returns. It lacks any such detail and fails to contextualize the tool relative to similar list/search tools, making it inadequate for an agent to choose correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for limit, offset, and order_by. The description adds no parameter-level meaning, but the baseline of 3 is appropriate since the schema fully documents each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Task status' is a fragment that restates the noun phrase from the tool name without a verb. It fails to state what the tool does (e.g., list task statuses) and does not distinguish it from siblings like list_task_priorities or list_time_sheet_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no mentions of related tools, exclusions, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate a non-read-only, non-idempotent, non-destructive operation, but the description adds no behavioral context such as required permissions, side effects, or reversibility. It simply repeats the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While brief, the description is under-specification, not conciseness. It doesn't earn its place because it duplicates the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (three entry types, an entries array with undefined structure), yet the description provides no context about how to construct entries or what the response will be. No output schema exists, so the description should fill that gap but is almost empty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics. The schema covers type (with examples), date, and reference_nr, but the essential 'entries' parameter lacks a description. With 75% schema coverage and a truncated type description, the description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology—'Create manual entry' restates the tool name without explaining what a manual entry is or how it differs from other create_* tools. Sibling tools like update_manual_entry and list_manual_entries imply a CRUD resource, but the description offers no specifics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or related tools such as upload_manual_entry_file_file or create_order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating readOnlyHint=false and destructiveHint=false, the description adds no behavioral context such as side effects, required permissions, or document validation rules. It neither enhances nor contradicts the annotation information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise in length but under-specified, providing no more information than the title. It fails to earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's four parameters and the large set of sibling position-related tools, the description lacks essential context about what a text position is, how it fits into documents, and what distinguishes it. It is completely inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, with 'text' and 'show_pos_nr' undocumented. The description provides no parameter semantics, leaving the agent without additional guidance for these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a text position' simply restates the tool name and title, providing no elaboration on what a text position is or how it differs from other position types. It is a tautology, similar to the 'Process' example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like create_item_position or create_subtotal_position. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 safety profile is known. However, the description adds no additional behavioral context such as what happens if the expense is not found or the exact return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this brevity is under-specification rather than concise effectiveness. It contains no useful information beyond the name, so it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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), but the description provides no context about the returned data, when to use this over list_expenses, or any edge cases. Given the large number of sibling tools, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter 'id' is described as 'id of Expense to retrieve'. The description adds no parameter value beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Expense' is a tautology that simply restates the tool name and title. It provides no specific verb+resource beyond what is already evident from the name, and it fails to distinguish this tool from many siblings like get_bill or get_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explanation of when to use get_expens versus related tools such as list_expenses or create_expens. No context, prerequisites, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. It does not explain what 'Show PDF' means—whether it returns a file, a URL, or binary data—or any side effects. Annotations indicate read-only and idempotent behavior, but the description itself contributes nothing enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At only two words, the description is extremely brief, but this is under-specification rather than effective conciseness. A concise description should still convey the tool's purpose and behavior; 'Show PDF' omits critical details and does not earn its place as a standalone description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is severely incomplete for a tool with no output schema. It does not explain what the function returns (e.g., PDF content, base64, file reference), nor does it distinguish this PDF from other document PDFs in the sibling tools. Given the simplicity of the schema, the description should at least clarify the output format and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: order_id is described as 'the id of the order' and logopaper as 'Whether the PDF should be generated using the letterhead, or not.' The tool description adds no additional parameter meaning, but since the schema already provides full descriptions, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show PDF' is essentially a restatement of the tool name 'get_order_pdf' without specifying the resource ('order'). It uses the vague verb 'Show' rather than a more specific verb like 'Retrieve' or 'Generate', and does not distinguish from siblings such as get_invoice_pdf or get_quote_pdf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. The description gives no context about prerequisites, typical scenarios, or alternatives. The only hint comes from the tool name, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond what the annotations already declare (readOnlyHint=false, idempotentHint=true, destructiveHint=false). It does not explain whether the update is partial or full replacement, what happens to associated files, or any validation or side-effect behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but it is under-specified rather than concise. It simply restates the tool name with no detail about the operation, making it an empty shell that fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, 4 required, including a complex 'entries' array, and no output schema, the description is severely inadequate. It provides no explanation of return values, behavior, or edge cases, making the tool nearly impossible to invoke correctly based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), so the schema itself documents most parameters. However, the description itself provides no parameter semantics, and the 'entries' parameter is undocumented. The high coverage sets a baseline of 3, but the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update manual entry' is a direct restatement of the tool name, providing no additional scope or specificity. It conveys the verb+resource but is purely tautological, not distinguishing from sibling tools beyond the 'update' verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 create_manual_entry, delete_manual_entry, or list_manual_entries. It lacks any mention of prerequisites, typical usage scenarios, or alternative tools, leaving the agent with zero context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what annotations already provide. Annotations indicate non-read-only and non-idempotent behavior, but the description does not disclose what happens during a copy (e.g., whether it copies line items, changes invoice number, or requires existing invoice). No additional context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but conciseness here comes at the expense of clarity and completeness. This is under-specification rather than efficient writing, similar to the 'Process' example. The sentence is front-loaded but fails to earn its place by providing useful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description is completely inadequate. It does not explain the tool's role in the invoice lifecycle, how the copy is created, or what the parameters control. The lack of any detail beyond the verb phrase makes it impossible for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, with invoice_id, contact_id, and contact_sub_id having short descriptions. However, the tool description itself does not explain any parameters, and title and is_valid_from remain undocumented. The description adds no value in clarifying parameter meaning, and the existing schema descriptions are sparse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Copy') and resource ('invoice'), which distinguishes it from other invoice tools. However, it is grammatically incorrect and lacks specifics about what 'copy' entails, such as whether it duplicates all fields or creates a new invoice. Compared to descriptions like 'Update shared drive settings including name, color, and restrictions', this is only minimally clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 like create_invoice or update_invoice. The description does not mention use cases, prerequisites, or situations where another tool would be more appropriate. This leaves the agent without any decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutating, non-idempotent operation, but the description adds no behavioral details beyond that. It does not mention side effects, required fields, permissions, failure modes, or return values. Since the description contributes nothing beyond the structured fields, it fails to disclose any additional behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. The single sentence 'Create business activity' merely repeats the tool name and does not earn its place by adding any useful information. It lacks the substance required to be considered well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a create operation with four parameters, no output schema, and minimal annotations, the description is severely incomplete. It offers no context about what data is needed, how the operation behaves, or what the result will be. The agent is left without sufficient information to use the tool correctly, especially with low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only account_id has a description). The tool description does not mention any parameters, so it does not compensate for the missing schema documentation. With three out of four parameters entirely unexplained, the agent cannot infer their semantics from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create business activity' is a direct restatement of the tool name. It provides no additional details about what a 'business activity' is or any distinguishing scope beyond the name itself. The verb and resource are present but tautological, offering no new information to differentiate from other create_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to use this tool versus alternatives. Sibling tools like list_business_activities and search_business_activities exist, but no comparison or selection criteria are provided. The description does not mislead, but it also gives no situational context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context such as return behavior, required permissions, or side effects. It neither contradicts nor enriches the annotation information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified rather than concisely complete. It lacks essential context, so the brevity is not a positive attribute; it is closer to the 'process' example than to a well-structured tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 5 required fields and an enum-based document type, the description is grossly inadequate. It does not explain what a comment is, where it applies, or what inputs are necessary, leaving the agent without critical guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters with only 43% description coverage, and the description provides zero parameter guidance. Critical fields like text, user_id, and is_public remain inadequately explained, and the description does not compensate for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a comment' simply restates the tool name and title, providing no additional context about the scope or nature of comments. It does not distinguish from sibling tools beyond the obvious verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool or when to prefer alternatives. The description fails to mention that comments are attached to quotes, orders, or invoices, and omits any prerequisites or contextual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the obvious mutation implied by 'create'. Annotations already indicate write behavior (readOnlyHint=false) and non-destructiveness, but the description does not disclose permissions, validation rules, side effects, or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It does not front-load useful information; it simply repeats the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters, a nested address object, no required parameters, and no output schema, this description is severely inadequate. It fails to communicate any meaningful context for correct selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 14 parameters and only 7% schema description coverage, the description must compensate by explaining key fields or relationships, but it says nothing. The name 'employee' only weakly implies the fields; it provides no meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create employee' restates the tool name and title without adding any differentiator. It names a clear action and resource but provides no detail that would distinguish this from sibling tools like update_employee or create_fictional_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as update_employee, list_employees, or create_absence_for_employee. The description offers no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, but the description adds no behavioral context. It does not mention required scopes, side effects, or validation rules, even though fields like is_stock require stock_edit scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The phrase 'Create item' is short but under-specified rather than concise. For a complex 32-parameter mutation tool, this is not appropriately sized and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is severely incomplete for a complex tool with 32 parameters, no output schema, and a large sibling toolset. It omits purpose, prerequisites, return behavior, and any operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 32 parameters and only 41% schema description coverage, the description must compensate for undocumented fields, but it provides zero parameter semantics. It does not explain any of the key fields like width, height, article_type_id, or stock-related properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create item' is a direct tautology of the tool name and title, providing no additional meaning. It does not distinguish this tool from siblings like create_item_position or other create_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as update_item or create_item_position. The description lacks any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds no behavioral context beyond the bare action. It does not disclose side effects, required permissions, relationships between parameters (e.g., user_id, contact_id), or the nature of the created note, so the description adds no value over 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words) but this is under-specification rather than effective conciseness. It lacks structure and does not front-load useful information; every word is essentially a restatement of the name, leaving no room for substantive guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, 3 required, and no output schema, the description is severely incomplete. It fails to explain what a note is, which parameters are essential, how the note relates to users/contacts/projects, or what the response will be. The context is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38% (3 of 8 parameters have descriptions), yet the description offers no parameter explanations. The agent gets no help understanding required fields like event_start or subject, or optional relationships like module_id and pr_project_id, making correct invocation difficult.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create note' directly restates the tool name (create_note) without adding any scope or distinction. It is a tautology, similar to the 'Process' example, and fails to explain what kind of note, what it is associated with, or how it differs from note-related siblings beyond the action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_note, delete_note, or list_notes. There are no exclusions, prerequisites, or contextual hints about typical use cases, leaving the agent without information on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. It does not mention that a create operation persists, that repeated calls create multiple entries (consistent with idempotentHint=false), or any side effects like requiring existing user IDs or business activities. It is not contradictory, but it provides zero additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than effectively concise. Every word restates the tool name, providing no informative content. A concise description should communicate essential information in few words, but this one communicates only what can be inferred from the name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 13 parameters, a nested tracking object, no output schema, and numerous sibling timesheet tools, the description is severely incomplete. It fails to explain the purpose of required fields, the tracking format options, or what a successful creation returns. An agent cannot invoke this tool correctly with only this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains no parameter information. With 13 parameters and only 54% schema description coverage, the description was expected to clarify key fields like tracking format (range vs duration), allowable_bill semantics, or required references. It does not, adding no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create timesheet' is a direct tautology of the tool name and annotation title. It states a clear verb+resource but adds no specificity about what a timesheet is, what it contains, or how it differs from similar operations like update_timesheet or get_timesheet. This fails to distinguish the tool from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus other timesheet-related tools (e.g., update_timesheet, delete_timesheet, search_timesheets). The description does not mention any context, prerequisites, or alternative tools, leaving the agent without criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the safe/destructive profile is known. However, the description adds no behavioral context beyond that—no mention of permanence, cascading effects, or required authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but it is under-specified rather than concise. It omits the key word 'order' and provides no additional structure or context, so it does not earn its place with useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with a single parameter and no output schema, the description should explain how order_id identifies the repetition and whether the operation is permanent. It is incomplete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter order_id with description 'the id of the order', but the tool is for deleting a repetition. The description does not clarify the relationship between order_id and the repetition, creating confusion about what identifier is actually needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a repetition' uses a verb and a noun but omits the resource type 'order', making it ambiguous. It does not distinguish from the many sibling delete tools, and the noun 'repetition' is generic without the context of 'order repetition'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of related tools like create_order_repetition or list_order_repetitions, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide. It does not disclose whether the PDF is returned as a file, URL, or base64, nor any details about authentication, rate limits, or the effect of the logopaper parameter. The description merely repeats the tool's basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Show PDF' is concise, it is under-specified to the point of being unhelpful. It is a fragment rather than a proper description, and it does not structure information in a way that aids the agent. It is not a case of efficient writing but of missing substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should have explained the return value or content of the PDF, but it does not. The description is too minimal to be considered complete even for a simple tool, especially with the logopaper parameter whose effect is only partially explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (quote_id, logopaper) have meaningful descriptions in the schema. The description itself adds no parameter details, but since schema coverage is high, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show PDF' is extremely vague and essentially restates the tool name 'get_quote_pdf' without adding any specificity. It does not clearly state that this fetches a PDF for a quote or what makes it distinct from other PDF-related tools like get_invoice_pdf or get_order_pdf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 or when to use an alternative. It does not mention any prerequisites, context, or exclusions, leaving the agent to guess based solely on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. With readOnlyHint=false and destructiveHint=false being generic, the agent is left without knowing whether this operation changes the quote status, requires special permissions, or is reversible. No side effects or state changes are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but under-specified. 'Revert issue a quote' is a vague fragment, not a concise summary of a fuller explanation. It fails to front-load any actionable information and wastes the opportunity to provide clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema, but the description still leaves critical gaps. It does not explain the effect of reverting an issued quote, the expected outcome, or how the operation fits into the quote lifecycle. This is insufficient for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with quote_id described as 'the id of the quote,' so the baseline of 3 applies. However, the tool description adds no additional meaning to the parameter, leaving the agent to infer that quote_id identifies the quote to be reverted. No mention of edge cases or required formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Revert issue a quote' essentially restates the tool name without explaining what 'revert issue' actually does. It does not distinguish this tool from siblings like issue_quote, create_reissue_quote, or revert_issue_invoice. The phrasing is grammatically ambiguous and fails to specify the action taken on the quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool, what conditions warrant a revert, or how it relates to alternatives such as issue_quote or create_reissue_quote. There is no mention of prerequisites, side effects, or business context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=false, and openWorldHint=true, but the description adds no behavioral context. It does not disclose whether the update is partial or full, whether missing fields are cleared, or any side effects, leaving the agent without crucial mutation semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single uninformative phrase 'Update employee'. This is under-specification rather than conciseness, as it fails to provide any substantive content that would justify its minimalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 15 parameters, a nested address object, three enums, and no output schema, this description is completely inadequate. It provides zero information about required fields, partial-update behavior, or interaction with the nested structure, making it nearly impossible for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13% (few properties have descriptions), yet the description text mentions no parameters at all. With 15 parameters, the description completely fails to compensate for the schema gaps, leaving the agent without meaning for most fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update employee' verbatim restates the tool name and annotation title, providing no additional information. It is a tautology that fails to specify scope, fields, or distinguish from other update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like create_employee or update_absence. The description only states the action 'Update' without any context, preconditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint: false, destructiveHint: false, idempotentHint: true, and openWorldHint: true. The description adds no behavioral context beyond what the annotations supply. It does not mention that an existing expense ID is required, that updates are idempotent, or any side effects. No value beyond annotations is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. A single uninformative phrase does not effectively convey the tool's purpose, parameters, or behavior. Every word should add value, but here the words add none.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex schema with 14 parameters, nested objects, and no output schema. The description must explain return values, prerequisites, and operational context, but it does none of this. It is completely inadequate for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 14 parameters and only 43% schema description coverage, the description must compensate for the lack of parameter details. However, 'Update Expense' provides zero information about any parameter. The agent is left entirely to the schema, which has many properties with no description. This is a critical deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update Expense' is essentially a restatement of the tool name 'update_expens' with no additional detail. It fails to distinguish this tool from sibling tools like 'update_expense_booking' or 'create_expens', and provides no information about what an 'Expense' is or what updating entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions no prerequisites, no exclusions, and no alternative tools. An agent would have no idea whether to choose 'update_expens' over 'update_expense_booking' or other related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations indicate readOnlyHint=false and destructiveHint=false, so the agent knows it's a mutation, but the description doesn't explain side effects, required permissions, or what happens on creation. It doesn't contradict annotations, but it also doesn't add value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single phrase with no expansion or context does not earn its place as a meaningful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 28 parameters, no output schema, and minimal annotations, the description is wholly inadequate. It gives no context about what a contact is, the required fields, the expected outcome, or any constraints, making it impossible for an agent to invoke the tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description provides zero parameter semantics. While the schema covers 50% of parameters with useful descriptions (e.g., contact_type_id, name_1), the description itself doesn't compensate for the gaps, especially for required fields like owner_id that lack schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create contact' is a tautology—it simply restates the tool name without adding any detail about what 'creating a contact' entails. It fails to distinguish this from sibling tools like bulk_create_contacts or update_contact, so the purpose is clear only at the most basic level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without direction on selecting this over related contact operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, but the description adds no behavioral context. It does not explain what 'executing' the action does (e.g., creates a copy, modifies existing data) or what side effects may occur. The description provides no value 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than conciseness. It contains a vague phrase with no meaningful content. A concise description would pack useful information into a few words; this one achieves brevity at the cost of substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
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 a potentially side-effectful action, this description is severely incomplete. It does not clarify the tool's purpose, usage context, parameter semantics, or expected behavior. Without an output schema, the description needed to provide comprehensive context but failed entirely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only 50% of parameters with descriptions (id is described, action is not). The tool description fails to explain the action parameter's meaning or the DUPLICATE enum value, leaving half of the parameters semantically underdocumented. The description needed to compensate for this gap but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute Expense action' is essentially a restatement of the tool name, replacing 'create' with 'execute'. It does not specify what the action does (e.g., duplicate) and provides no differentiation from sibling tools like create_expens or update_expens. This is a tautological, vague purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives. It does not mention that the action is specifically for duplicating an expense, nor does it reference any sibling tools. There is no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide. Annotations indicate readOnlyHint=false and idempotentHint=false, so it is understood to be a non-idempotent write operation, but the description does not disclose any additional side effects, permission requirements, or constraints. It is minimal and uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is very short, it is under-specified rather than concise. It consists only of the phrase 'Create invoice,' which fails to convey any substantive information. The structure is fine, but the content is not helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
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 no output schema, a two-word description is completely inadequate. It does not explain what the response contains, how to handle edge cases, or how to structure the creation request. The annotations and schema provide some context, but the description itself is nearly empty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-level detail. Schema description coverage is about 65%, leaving several parameters undocumented, but the description does nothing to compensate for the missing fields. Key parameters like positions have schema descriptions, but the tool description itself adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create invoice' is a tautology—it restates the tool name without adding any detail about what the operation actually does or what makes it distinct from sibling tools like create_invoice_from_order or create_invoice_from_quote. It lacks a specific verb+resource beyond the name itself and provides no differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention when an invoice should be created directly versus converted from an order or quote, nor does it specify any prerequisites or exclusions. The schema hints at automatic numbering, but the description itself offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-readonly write operation, but the description adds no behavioral details beyond 'create'. It does not disclose side effects, such as marking an invoice as paid, nor any prerequisites. With annotations present, the description contributes minimal additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but under-specification is not conciseness. It omits necessary information and does not productively use its sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter write tool with no output schema, a one-phrase description is completely inadequate. It leaves the agent unable to understand what the tool does, what inputs are needed, or what the expected result is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 3 of 5 parameters, but 'date' and 'value' lack descriptions. The tool description does not explain any parameters, failing to compensate for the missing semantic coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create payment' is a vague restatement of the tool name, omitting the invoice-specific context that distinguishes this tool from siblings like 'create_payment' and 'create_outgoing_payment'. It does not state that this creates a payment linked to an invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives. The description offers no context about scenarios, prerequisites, or relationships to other payment-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already convey (write operation). It does not mention side effects, validation rules, or that positions are added to quotes/orders/invoices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified to the point of being unhelpful. It is a single phrase that offers no information beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters and complex document relationships, a one-sentence description is completely inadequate. It doesn't explain the item position's role in documents, required fields, or how to structure the request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains no parameter details. The schema covers 64% of parameters, but the description fails to compensate for the missing fields, leaving users to infer semantics from field names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an item position' restates the tool name and title without adding any clarifying information. It does not explain what an item position is or how it differs from sibling tools like create_text_position or create_subposition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool, what document types it applies to, or any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, signaling a write operation, but the description adds no behavioral context. It does not mention side effects, required relationships (e.g., contact_id), or document numbering behavior. It neither contradicts nor supplements 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, which is under-specification rather than effective conciseness. It contains no front-loaded information and does not earn its place, as it provides no useful content for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 23 parameters, no output schema, and a rich domain (Bexio orders). The description is completely inadequate: it explains neither what an order is, nor the significance of key fields like positions or mwst_type, nor the expected behavior. The agent would have to rely entirely on the schema and external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 74% of the parameters with descriptions, so the schema does some heavy lifting. However, the description itself says nothing about any parameters, and it does not help clarify the undocumented ones (e.g., is_valid_from, show_position_taxes). It adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create order' is a tautology that merely restates the tool name. It does not specify the type of order (e.g., sales order vs purchase order) or distinguish it from sibling tools like create_quote, create_invoice, or create_purchase_order. This leaves the purpose vague and ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool, what prerequisites exist, or how it relates to alternatives such as create_invoice_from_order or create_delivery_from_order. This is especially problematic given the large set of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate a write operation (readOnlyHint=false), but the description adds no behavioral context beyond the generic 'create.' It provides no information about side effects, permissions, or return behavior, which is especially important for a complex payment creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The three-word description is under-specified rather than concise. It contains no information that could not be inferred from the tool name, so it fails to earn its place. Effective conciseness would preserve useful guidance without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 13 parameters, nested objects, and type-specific payment variants, yet the description provides no context. It does not explain the difference between payment types, which fields are conditional, or how this tool relates to sibling payment creation tools. The description is severely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 77% of parameters with descriptions, but the tool description contributes nothing to parameter understanding. It does not highlight the critical type-dependent fields, such as 'type' or 'qr_reference_nr', nor explain their relationships. The description adds zero value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a payment' is a direct restatement of the tool's name and adds no distinguishing information. It fails to differentiate from sibling tools like create_outgoing_payment or create_invoice_payment, making it tautological rather than clarifying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or when to prefer an alternative. It does not mention required fields, payment type differences (iban vs qr), or any context that would help an agent decide to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds no behavioral context beyond the word 'create'. It does not mention side effects, required document existence, or relationship to offers/orders/invoices, nor does it contradict 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which could be concise, but it is under-specified rather than efficiently structured. It lacks essential information that should be front-loaded, making it inadequate as a standalone explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, two required, no output schema, and a domain-specific concept, the description is wholly incomplete. It fails to define what a subposition is, how it attaches to documents, or any contextual constraints, making it nearly impossible to use correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents only two of four parameters (kb_document_type and document_id), leaving text and show_pos_nr with no explanation. The description mentions no parameters and does nothing to compensate for the 50% schema coverage gap, providing zero additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a sub position' is a direct restatement of the tool name, offering only a verb and resource without explaining what a subposition is or how it differs from sibling position-creation tools like create_item_position or create_discount_position. This qualifies as a tautology rather than a clear, distinguishing purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, which document types are applicable, or how it compares to alternatives. It lacks any context about prerequisites or exclusions, leaving the agent to infer usage solely from the schema and tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false), but the description adds no behavioral context beyond the name itself. No information about permissions, required relationships, or side effects is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Create task' is concise to the point of being minimal, it is under-specified rather than appropriately concise. It provides no value beyond the tool name and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 15 parameters, no output schema, and no explanation of return values or relationships to other entities, this description is severely inadequate. It lacks any contextual information that would help an agent invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 15 parameters with only 40% description coverage, and the description 'Create task' does not clarify any parameter meanings. It fails to compensate for the gaps in schema descriptions, leaving agents to guess at most fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create task' merely restates the tool name and title, providing no differentiation from sibling tools like update_task, delete_task, or list_tasks. It is a tautology rather than a meaningful purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, expected context, or exclusions such as when to use update_task instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already convey. Annotations indicate it is a non-read-only, non-idempotent, non-destructive action, and the description merely says 'Create unit' without mentioning side effects, prerequisites, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than concise effectiveness. 'Create unit' does not earn its place because it adds no information beyond the tool name and lacks the detail needed for a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with one parameter and no output schema. It fails to explain what a unit is, what the name parameter does, or any operational details, making it nearly impossible for an agent to use the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'name' with 0% description coverage, and the tool description does not compensate by explaining what 'name' represents or its format. While the parameter name is intuitive, the description fails to add any semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create unit' is a tautology—it merely restates the tool name and title without elaboration. It does convey a basic verb+resource but lacks any detail that would distinguish it from sibling tools like update_unit or delete_unit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, what a 'unit' is, or how it relates to get_unit, list_units, update_unit, or delete_unit. The description provides no context for choosing this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, which already disclose the safety profile. However, the description adds no behavioral context beyond the bare 'Get' – no mention of pagination, result structure, availability of filters, or any operational quirks. With annotations present, the bar is lower, but the description contributes nothing; hence a below-average score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, which is extremely concise, but it is under-specification rather than efficient communication. It fails to earn its place by providing any useful information beyond the tool name. For a tool with 18 parameters and no output schema, this is inappropriately sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 18 parameters, no output schema, and a wide array of sibling tools, the description is severely incomplete. It does not explain return value shape, pagination semantics, date handling, or any filtering capabilities. The annotations mitigate some safety concerns, but the description alone leaves the agent with almost no operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the 18 parameters with per-field descriptions. The description itself does not explain any parameters, but it is not required to do so given the thorough schema. Baseline of 3 is appropriate because the schema carries the full semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Expenses' is essentially a synonym for the tool name (list_expenses) and title (List Expenses). It conveys the basic action and resource but offers no distinguishing scope (e.g., paginated list, all expenses) and does not differentiate it from numerous other list_* tools. This is a near-tautology, lacking specific verb+resource detail beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. No mention of filters, sorting, or related tools like search_expenses (if it exists). The description provides zero context for selecting this tool, forcing the agent to rely solely on the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states a search operation (implying read-only) while annotations set readOnlyHint to false, creating a contradiction. This misleads the agent about the tool's side effects and fails to disclose any behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, bordering on tautology, and does not constitute a meaningful explanation. It lacks structure and substance, providing only a bare phrase that does not help the agent beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and no output schema, the description provides no information about request/response behavior, the 'body' array, filtering capabilities, or return format. The tool is severely under-described for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all parameters. The description adds no additional parameter semantics, but the baseline of 3 applies when the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search additional addresses' directly restates the tool name, providing no additional specificity. While it identifies a search operation, it fails to distinguish it from sibling tools like list_additional_addresses or get_additional_address beyond the verb itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as list_additional_addresses or search_contacts. No context about its intended use case or criteria for choosing it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Search'), but annotations set readOnlyHint=false, indicating potential state modification. This is a direct contradiction. Additionally, no side effects, auth needs, or other behavioral details are disclosed beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence but conveys no information beyond the tool name. It is under-specified rather than concise, as every word is redundant and no value is added.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a required 'body' parameter that is completely opaque ('as defined by the bexio API'), no output schema, and no explanation of what searching calendar years entails, how results are returned, or how it differs from listing. The description is wholly inadequate for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (body, limit, offset), so the schema carries this burden. The description adds nothing about parameters, which is acceptable given the baseline, but it also does not clarify the opaque 'body' parameter beyond the generic API reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search calendar years' is a verbatim restatement of the tool name, offering no additional detail or differentiation from sibling tools like 'list_calendar_years' or 'get_calendar_year'. It identifies a verb and resource but is essentially tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool instead of alternatives. It does not mention search criteria, relationship to list/get operations, or any context in which this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits beyond what the annotations already convey. It does not mention search scope, matching behavior, pagination, or response format. Since readOnlyHint is false, the description could clarify mutability, but it remains silent, providing zero additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but conciseness requires that every word earns its place. Here, the two words merely restate the tool name, providing no informative content. This is under-specification, not efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and no output schema, so the description should explain what the body array does, how search differs from list, and what the response contains. It does none of these, making the description completely inadequate for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not reference any parameters, but the input schema provides complete descriptions for all four parameters (body, limit, offset, order_by), including enum details and constraints. With 100% schema coverage, a baseline of 3 is appropriate; the description adds no value beyond the schema but does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search orders' simply restates the tool name, adding no detail about what constitutes a search, which fields can be searched, or how this differs from list_orders. It is effectively a tautology, providing only a vague verb+resource without any scope or differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus sibling tools like list_orders, get_order, or search_quotes. There is no mention of appropriate contexts, exclusions, or alternatives, leaving the agent without decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses nothing about behavior beyond the name. Annotations show readOnlyHint=false, but the description does not clarify whether the tool modifies data, how results are paginated, or what the output structure is. With no added context, an agent cannot anticipate side effects or return formats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only a single phrase, which is concise but under-specified. It provides no meaningful information beyond what the name already conveys, making it more of a lack of content than an efficiently structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no explanation of pagination or filtering, and a vague body parameter, this description is entirely inadequate for an agent to understand how to construct a valid request or interpret the response. The presence of annotations does not compensate for the complete lack of contextual detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema itself documents all parameters. However, the body parameter is described only as 'Request body as defined by the bexio API', which is vague and does not explain its structure. Since the schema carries the burden, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search stock locations' is a direct restatement of the tool name, providing no additional detail about what the search does or what makes it distinct from the sibling 'list_stock_locations'. It is essentially a tautology rather than a clear explanation of the tool's specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'list_stock_locations' or 'search_stock_areas'. No context is provided about typical use cases or situations where this search is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits. Despite annotations indicating readOnlyHint=false, the description does not clarify whether the operation has side effects, what permissions are needed, or what the response contains. It provides zero transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. It consists of only two words but fails to convey essential information, making it inadequate for an agent to understand the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and many sibling tools like list_tasks and get_task, the description is completely inadequate. It does not explain search criteria, pagination, or how it differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions, so the baseline is 3. The description adds no information about parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search tasks' merely restates the tool name, providing no additional specificity about what kind of search is performed or how it differs from list_tasks. It is essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use search_tasks versus list_tasks or other search_* tools. No context, use cases, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits beyond the annotations. It does not mention pagination, required body parameters, or the nature of the operation (read vs. write). While annotations indicate readOnlyHint=false, the description adds no context about safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than conciseness. It does not provide any structured information or front-loaded value; it merely repeats the tool name in a readable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a required 'body' parameter that is an array of objects, but the description gives no hint of what the body should contain or how the search works. With no output schema and limited annotations, the description is wholly inadequate for an agent to understand how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all three parameters (body, limit, offset). The description 'Search units' adds no meaning beyond the schema, which is a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search units' is an exact restatement of the tool name and annotation title, adding no additional specificity or scope. It fails to distinguish this tool from sibling tools like list_units or get_unit, both of which also relate to retrieving units.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of search criteria, filtering, or how it differs from listing all units (list_units) or fetching a single unit (get_unit).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=false, so the agent knows this is a mutating, non-idempotent operation. The description adds no behavioral context beyond that—no information about whether fields are overwritten entirely, whether permissions are needed, or what the API response looks like. It doesn't contradict annotations but is unhelpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('Edit a timesheet'), but conciseness is not the same as under-specification. While there is no wasted wording, the description fails to convey any actionable information. It is more an empty placeholder than a useful, front-loaded definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters, 5 required, a nested tracking object, and no output schema, the description is grossly incomplete. An agent cannot determine how to construct a valid call, what the tracking object requires, or how to interpret the response. This description provides no orientation and is completely inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 14 parameters with only 57% description coverage. The description itself mentions none of the parameters, required fields, or the two tracking formats (range vs duration). This is particularly inadequate given the nested tracking object and complex relations to users, clients, and activities. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a timesheet' is essentially a restatement of the tool name 'update_timesheet' and title 'Update Timesheet', using a synonymous verb. It does not specify what fields or aspects of a timesheet can be edited, nor does it distinguish this tool from siblings like create_timesheet or delete_timesheet. This borders on tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites (e.g., existing timesheet), the difference between partial and full updates, or how it relates to create/get/delete timesheet operations. There is zero usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read, non-destructive, non-idempotent operation, but the description adds no additional behavioral context. It does not mention what executing the action does, side effects, permissions, or whether it creates a new bill.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal but under-specified. It is too terse to be useful, sacrificing clarity for brevity, and does not earn its place as the sole textual guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description should explain the operation's effects (e.g., duplicating a bill) and any important context. It provides none, leaving the agent to guess from the enum and tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'id' but leaves 'action' as an enum with no explanation. The description does not explain the meaning of action values or how they affect the operation, so it fails to compensate for the 50% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute Bill action' is vague and largely restates the tool name. It does not specify that the action is to duplicate a bill, nor does it distinguish this tool from siblings like create_bill or update_bill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative bill-related tools. The enum value DUPLICATE implies a use case, but the description offers no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations; it only confirms a write operation, which is already indicated by readOnlyHint=false. It does not disclose the effect of creating a relation, validation rules, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified; it is a single tautological phrase that fails to convey useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema, the description is grossly inadequate, offering no context, no usage guidance, and no behavioral detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the parameters. Schema covers 67% (two of three params have descriptions referencing a contact object), but the description adds nothing about how contact_id and contact_sub_id relate, or what the description field means.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create contact relation' is a tautology, restating the tool name without elaborating on what a contact relation is or how it differs from other operations. It offers no distinction from sibling tools like update_contact_relation or delete_contact_relation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no mention of alternatives. The description lacks context about when a contact relation should be created or how it differs from similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details such as side effects, return values, or required context. While annotations indicate readOnlyHint=false and destructiveHint=false, the description itself provides no additional transparency about what 'creating a default position' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one short sentence, but this is under-specification rather than effective brevity. A tool with 13 parameters and multiple sibling tools requires more upfront explanation to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the schema and absence of an output schema, the description is severely incomplete. It doesn't explain what a default position is, which document types are valid (leaving that to the schema), what the operation does, or what the response will be, so the agent lacks essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, and the schema covers only 62% of parameters. Several parameters like 'text', 'amount', 'amount_open', 'amount_reserved', and 'amount_completed' lack descriptions, and the tool description does nothing to clarify their meaning or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a default position' is essentially a direct restatement of the tool name, providing no definition or scope. It doesn't explain what a default position is or how it differs from other position-creating tools like create_item_position or create_discount_position, so the agent cannot determine when this specific tool is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, document types, or relationship to other position tools, leaving the agent without a decision framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotations. Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description does not disclose any additional traits such as return format, pagination, or filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which is concise, but it is under-specified. 'Project status' is more of a label than a structured description. It is not verbose, but it lacks the content needed to be effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite annotations covering safety, the description fails to explain the core function or expected return value. Since there is no output schema, the description should at least state what the tool returns (e.g., a list of statuses). It does not, leaving the tool's behavior largely ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully documents the parameter space. The description need not add parameter details; baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Project status' is a noun phrase that essentially restates the tool name without a verb. It does not clearly state what the tool does (e.g., 'List project statuses'). This is a tautology rather than a clear purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_projects or list_task_status. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, but the description adds no behavioral context such as email delivery, status updates, or external side effects. It merely restates the action without explaining consequences, leaving the agent to infer behavior from the schema and name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is too minimal to be considered appropriately concise; it is under-specified. It consists of only three words and fails to provide a structured explanation that would help an agent understand the tool's operation or parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, a send action, and no output schema, the description is grossly incomplete. It omits how sending works, what happens to the quote, and any prerequisite or side-effect information. The schema and annotations provide some context but cannot compensate for the absence of a meaningful description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 67% of parameters with descriptions, but the tool description contributes no parameter meaning. Two parameters (subject, mark_as_open) lack schema descriptions and are not explained by the description, so the agent receives no help for those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send a quote' is essentially a tautology of the tool name 'send_quote'. It provides a verb and object but no details that distinguish it from sibling tools like 'issue_quote' or 'mark_as_sent_quote'. The purpose is not clarified beyond what the name already implies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention emailing, status changes, or contrast with similar quote tools. An agent would have no basis for selecting this over issue_quote or mark_as_sent_quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. It doesn't mention that all nine fields are required (implying a full update), what happens to unspecified fields (additionalProperties false), or any side effects. With readOnlyHint=false and idempotentHint=true, the description could have explained the idempotent nature or the requirement to supply all fields, but it remains silent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. A single participial phrase "Updating existing absence" is not a complete sentence and provides no structured information. It is too short to be useful, similar to the "Process" example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 required parameters, no output schema, and sparse annotations, the description is severely inadequate. It fails to explain the update semantics, required fields, return values, or any operational context. This is a completely insufficient description for a complex write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description names no parameters at all. It does not compensate for the missing parameter documentation in the schema. The agent is left without any explanation of start_date, end_date, half_day, disability, paid_hours, or continued_pay beyond raw names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Updating existing absence" states the action (updating) and the resource (absence), but it is essentially a rephrasing of the tool name and provides no details about what aspects can be updated. It vaguely distinguishes from delete/create siblings but lacks scope, so it falls between a tautology and a clear statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives. It does not mention prerequisites, such as having an existing absence ID, nor does it contrast with create_absence_for_employee or delete_absence. There is no context to help an agent decide between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true, but the description doesn't explain what updating entails—whether missing fields are reset, side effects, or permission needs. With openWorldHint=true, more disclosure is expected, but none is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three words, which is concise in length, but it's under-specified—it sacrifices necessary context. Effective conciseness would front-load key information while still covering essential details; this description fails to do that.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 32 parameters, no output schema, and relatively sparse annotations, a one-line description is severely inadequate. It doesn't explain the update workflow, dependencies, or typical use cases, leaving the agent without enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 32 parameters and only 41% schema description coverage, the description should compensate, but it mentions no parameters at all. It doesn't highlight that article_id is required, nor does it clarify any of the many optional fields, leaving the agent to rely on the sparse schema descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit an item' specifies the verb and resource, but it is vague—'item' is a generic domain object, and it doesn't clarify which aspects of the item can be edited or how this differs from other item-related tools. It distinguishes from siblings like update_item_position only at a high resource level, not through detailed scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_item, delete_item, or search_items. It doesn't mention prerequisites like the item existing, nor does it explain the context in which updating an item is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false), but the description adds no behavioral context beyond the word 'create'. It does not disclose any side effects, requirements, or ordering behavior, which are relevant for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification rather than appropriate conciseness. It provides no structural breakdown or detail, consisting only of a single tautological phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool lacks an output schema and has only a one-line description. There is no explanation of what a subtotal position is, how it fits into a document, or any preconditions. An agent would not have enough information to use this tool correctly or know when it is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for the required parameters (document_id and kb_document_type), covering the main semantics. The optional 'text' parameter is undocumented but self-explanatory. The description itself adds no parameter information, but the schema does most of the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a subtotal position' merely restates the tool name and provides no additional meaning. It fails to explain what a subtotal position is or how it differs from sibling position creation tools like create_item_position, create_discount_position, or create_text_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention which document types it applies to (though the schema enum shows quotes, orders, invoices) or any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, so safety is covered. However, the description does not clarify what a 'preview' entails (e.g., thumbnails, truncated content) or how it differs from a full download. The name/description mismatch adds confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it is under-specified to the point of being unhelpful. It conveys minimal information without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a vague description, the tool's return format and semantics are unclear. The annotations don't explain what a preview is, leaving a significant gap for a simple but ambiguous tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter file_id as 'File ID to get preview file'. The description adds no additional parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get file preview' uses a verb and resource, but the tool name is 'list_preview_files' which implies a list operation, creating ambiguity. It does not differentiate from sibling file tools like download_file or get_read_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are many file-related siblings, and the description does not mention any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what annotations already provide. It does not disclose whether the operation is read-only, how results are returned, or any side effects. The annotations themselves are ambiguous (readOnlyHint=false for a search operation), but the description neither clarifies nor contradicts them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At only two words, the description is under-specified rather than concise. It does not constitute a meaningful sentence and fails to convey any useful information, making it ineffective even though it is short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a search tool with a complex 'body' parameter and no output schema, yet the description provides no information about search capabilities, return format, pagination behavior, or error handling. Sibling tools like search_contacts and search_orders have similarly terse descriptions, but given the opaque API-specific body parameter, the description is entirely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all three parameters (body, limit, offset) with 100% coverage, so the baseline is 3. However, the tool description adds no additional meaning about how to construct the body or interpret the search criteria, leaving the opaque 'body' parameter without practical clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search Accounts' is a direct restatement of the tool name, providing no additional specificity about what accounts are searched, what the search entails, or how it differs from related tools like list_accounts or search_additional_addresses. It is a tautology that fails to distinguish the tool from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention list_accounts, other search tools, or any context for when a search is appropriate. There is no implied usage because the description is entirely generic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers no behavioral information beyond the annotations. It does not disclose whether the search is read-only, how pagination works, or what happens with archived contacts, leaving the agent to rely solely on schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but not appropriately concise—it omits essential information about the tool's behavior and parameters. It is under-specified rather than economically complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, a complex body array, and no output schema, the description is grossly inadequate. It fails to explain the request body structure, search semantics, or return format, making it insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters have descriptions in the schema (100% coverage), so the schema carries the parameter semantics. The description adds no parameter context, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search contacts' essentially restates the tool name without adding specificity. It does not distinguish from sibling tools like list_contacts or clarify what 'search' entails (filters, output shape).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives such as list_contacts or search_contact_groups. The description gives no context about the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, destructiveHint=false) and the description adds no behavioral context. It does not mention pagination, filtering semantics, request body expectations, or any side effects, leaving the agent without critical operational insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but under-specified. It lacks any explanatory structure or details, so while it is concise in word count, it sacrifices all informative content and fails its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no output schema, and sparse annotations, the description must provide substantial guidance. Instead it is entirely inadequate, offering no information about the request body, search semantics, or how to use the pagination parameters, making the tool effectively unusable without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters (body, limit, offset, order_by) with descriptions, so the baseline is 3. The tool description adds no additional meaning to the parameters, and the body description is vague ('as defined by the bexio API'), but the schema itself provides reasonable context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search countries' is nearly a tautology of the tool name, providing no specific verb, resource details, or scope. It does not distinguish from siblings like 'list_countries' or 'get_country', leaving the agent uncertain about what 'search' uniquely offers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Sibling tools such as 'list_countries' and 'search_countries' overlap, but the description lacks any comparison, exclusions, or context to help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits. Annotations show readOnlyHint: false, but the description does not clarify whether the search has side effects or requires special permissions. It adds no context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is technically concise but severely under-specified. It is a single phrase that does not provide enough information for an agent to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters including a complex body array, no output schema, and numerous similar search tools, the description is completely inadequate. It gives no hint about query structure, supported search syntax, or expected return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all four parameters, meeting the baseline. The description adds no extra meaning about how the body, limit, offset, or archived_state parameters work together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search files' is a direct tautology of the tool name and title. It restates the name without specifying the domain, criteria, or what differentiates it from other search_* tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other search tools like search_accounts or search_contacts. There is no mention of alternatives, suitable contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral aspects beyond what annotations already provide. It does not mention that the tool accepts a complex request body, how results are returned, or any side effects. Given the annotations (readOnlyHint=false, destructiveHint=false), the description adds no additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief at two words, which is under-specification rather than effective conciseness. It lacks any structural elements like examples or explanatory sentences, making it too terse to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to compensate for the complex body parameter and the lack of an output schema. The body is an array of objects with no defined structure in the schema, and the description offers no clue about how to formulate a search query. This is completely inadequate for an API search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all parameters, reaching 100% coverage. The description adds no parameter-level information, so the baseline score of 3 is appropriate. The body parameter remains opaque ('as defined by the bexio API'), but the schema already handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search items' is a direct restatement of the tool name, adding no new information about scope, search criteria, or what constitutes an item. It is essentially tautological, providing no more clarity than the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternative search or list tools. No context distinguishes it from the many sibling tools like 'search_contacts' or 'list_items', and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations provide limited info (readOnlyHint=false, openWorldHint=true), but the description does not clarify return format, side effects, or filtering behavior, which is especially important given the misleading readOnlyHint=false for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified, not efficiently concise. 'Search languages' is a minimal phrase that omits essential details, making it insufficient rather than appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, no output schema, and vague annotations, yet the description provides virtually no context. It fails to explain the search functionality, body requirements, or relationship to sibling tools, making it completely inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no parameter-specific meaning, but the baseline of 3 applies since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search languages' merely restates the tool name, providing no additional scope or differentiation. It fails to distinguish from the sibling 'list_languages' tool, making the specific purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_languages'. The description gives no context about search criteria, body usage, or specific use cases, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as non-read-only and non-idempotent, but the description adds no behavioral details. It does not disclose side effects like sending an email, updating reminder status, or triggering notifications, nor does it mention any authorization or trial-period constraints not in 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is short, but this is under-specification rather than conciseness. The phrase "Send a reminder" adds no value beyond the tool name and lacks the necessary detail to guide correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-required-parameter write action with no output schema and many closely related sibling tools, this description is completely inadequate. It provides no information about return values, side effects, or relationship to other reminder/invoice operations, making it nearly useless for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero parameter explanation, but the input schema already covers 80% of parameters with meaningful descriptions (invoice_id, reminder_id, recipient_email, message). The missing subject parameter is not addressed, and the description does not compensate for any schema gaps, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description "Send a reminder" is a tautology of the tool name send_invoice_reminder, providing no additional specificity. It fails to mention the invoice context or distinguish itself from siblings like send_invoice or mark_as_sent_invoice_reminder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool, what prerequisites exist (e.g., invoice and reminder must exist), or how it differs from alternative reminder-related actions. The description offers no context for selection among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, but the description adds no behavioral context beyond the fact that an update occurs. It does not disclose side effects, permission requirements, reversibility, or any consequences of modifying a currency. Since the description adds nothing beyond the annotations, it fails to enrich the agent's understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It lacks any useful elaboration and does not earn its place by adding value beyond the tool name. A good description would provide at least one sentence of meaningful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with two parameters, no output schema, and minimal annotations, the description is completely inadequate. It does not explain what the update does, what fields can be changed, what the response might look like, or any constraints. The agent would have to rely solely on the schema and tool name, which is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters. Both currency_id and round_factor have descriptive text in the schema, including an example for round_factor. The description itself contributes no additional parameter semantics, but the schema already provides sufficient meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Update a currency" is a tautology that simply restates the tool name and title. It provides no additional detail about what updating a currency entails, how it differs from related tools like create_currency or get_currency, or what specific aspects of a currency can be modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention scenarios where updating a currency is appropriate, any prerequisites such as the currency already existing, or when to prefer create_currency or other currency-related operations. No exclusions or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutating operation (readOnlyHint=false), but the description adds no behavioral context such as what state the quote transitions to, whether it creates a related record, or any side effects. The description fails to add value beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified at only three words. While it is brief, it fails to include any operational detail, making it more of a lack of specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool, the description is critically incomplete. It does not explain the effect of accepting a quote, any valid preconditions, or what the API returns. This leaves substantial gaps in the agent's understanding of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the quote_id parameter described as 'the id of the quote.' The description adds no new meaning, but the schema already fully documents the parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Accept a quote' is essentially a restatement of the tool name 'create_accept_quote' and provides no additional detail about what acceptance does. It does not distinguish this from sibling tools like create_decline_quote or create_invoice_from_quote, so it fails to clarify the specific action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention prerequisites (e.g., quote must be issued) or exclusions (e.g., not for declining), leaving the agent without context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-read-only, non-idempotent, non-destructive operation. The description adds no behavioral context beyond the annotation, such as required existing contact, response behavior, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it concise and front-loaded. However, it is so brief that it borders on under-specification, though that is more a completeness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and only a one-line description, the tool is severely under-explained. An agent would not know what an additional address is, what the required contact relationship is, or what happens on success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 45% with 11 parameters. The description provides no parameter information or relationships (e.g., street_name required if house_number is set), failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Create') and resource ('additional address'), but 'additional address' is vague without context such as being associated with a contact. It differentiates from sibling update/delete operations by its verb, but doesn't provide additional scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like update_additional_address or search_additional_addresses. There are no prerequisites, exclusions, or context for when to create an additional address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-destructive operation, but the description adds no behavioral detail. It does not explain what 'create reminder' entails (e.g., scheduling, notification, persistence), side effects, or how it relates to the invoice lifecycle. No contradiction with annotations, but no added value either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, which is under-specification rather than effective conciseness. It does not earn its place by providing useful distinguishing information; it merely abbreviates the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a single parameter and annotations, the description lacks essential context for a mutation tool. It fails to state the purpose of an invoice reminder, when to create one, or what happens after creation. The agent is left to infer behavior from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (invoice_id well-documented), so the baseline is 3. The description provides no additional parameter semantics, but none are needed given the single simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create reminder' is essentially a tautology of the tool name 'create_invoice_reminder', but it omits the crucial 'invoice' context. It neither specifies the resource precisely nor distinguishes the tool from many sibling invoice-related tools (e.g., create_invoice, create_invoice_payment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like send_invoice_reminder or mark_as_sent_invoice_reminder. No prerequisites, conditions, or exclusions are mentioned, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and idempotentHint=false, suggesting a non-idempotent mutation, but the description adds no behavioral context. It does not disclose the effects of reissuing (e.g., whether a new quote is created, status changes, or external communication occurs), thus offering no value 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. Unlike efficient single-sentence descriptions that convey key information, 'Reissue a quote' simply restates the tool name and lacks substance, making it more a case of under-specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and a single parameter, the description should at least clarify the effect of reissuing a quote and when it is appropriate. It is incomplete and fails to differentiate from siblings, leaving critical gaps in the agent's ability to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter quote_id with a description 'the id of the quote', so the description adds no additional semantics. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reissue a quote' is essentially a restatement of the tool name 'create_reissue_quote' and the title, making it tautological. It does not explain what reissuing involves or how it differs from similar tools like copy_quote, issue_quote, or create_quote, leaving the agent without a clear understanding of the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the large sibling list containing multiple quote-related operations (e.g., copy_quote, issue_quote, send_quote), the agent cannot determine the appropriate context for reissue without additional direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), but the description adds no behavioral context beyond that. It does not explain side effects, permissions, idempotency implications, or what happens after creation (e.g., whether it returns the created entity).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse but not concise in a helpful way—it is redundant with the tool name and provides zero information. This is under-specification rather than effective brevity, similar to the 'Process' example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, this description is severely incomplete. It does not explain what a work package is, how it relates to projects, or what the caller should expect as a return value. The schema descriptions help, but the tool description itself fails to provide essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 per the rubric. The tool description itself adds no parameter meaning, but all properties already have adequate descriptions in the schema, so no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create work package' is a tautology—it simply restates the tool name with a space inserted. It provides no additional detail about what a work package is or how this tool differs from siblings like update_work_package or create_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or required parameters (e.g., project_id). There is no context about the intended workflow or constraints such as 'must be associated with an existing project.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already declare (destructiveHint=true, readOnlyHint=false). It does not mention irreversibility, side effects, or any conditions that might prevent deletion, relying entirely on 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than genuine conciseness. It merely repeats the tool name without providing useful structural information, so it fails to earn its place as a valuable description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool, the description is too sparse to be complete. It lacks information about return values, behavior on non-existent IDs, and any constraints. While annotations cover destructive intent, the description itself does not enrich the context enough for an agent to confidently invoke the tool without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'id' parameter described as 'Outgoing Payment id'. The description adds no additional meaning about the parameter, so the baseline score of 3 is appropriate given the schema already fully documents it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete Outgoing Payment' is essentially a restatement of the tool name and title, providing no additional specificity. It identifies a verb and resource but does not distinguish from sibling tools beyond the obvious action, nor does it clarify scope or effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like update_outgoing_payment or get_outgoing_payment. No use cases, prerequisites, or exclusion criteria are provided, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds no further behavioral context such as whether deletion is permanent, whether related records are affected, or what happens if the task ID does not exist. No contradiction, but no added value 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is short but under-specified. It does not earn its place because it only restates the tool name, providing no additional information. This is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While annotations and schema cover the destructive, idempotent nature and the single parameter, the description lacks usage guidance and any clarification of deletion semantics (e.g., hard vs soft delete). Without an output schema or behavioral notes, the description is insufficient for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the task_id parameter fully documented as an integer with a description. The tool description adds no additional parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a task' is essentially a sentence-form restatement of the tool name and title, adding no new information. It does state the action and object, but it fails to differentiate from the many sibling delete_* tools or provide any detail about what deleting a task entails beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like update_task, get_task, or search_tasks. It lacks any preconditions, exclusions, or mentions of alternative operations, leaving the agent with no context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as destructive and non-read-only. The description adds no additional behavioral context such as cascading effects, whether the delete is permanent, or required permissions. It does not contradict annotations, but it also discloses nothing beyond what the annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It omits essential usage details and provides no structure to guide the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and the lack of an output schema, the description should at least indicate what the response will be or what conditions must be met. It does neither, leaving the agent under-informed for a sensitive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema contains a single required parameter timesheet_id with a clear description, so schema coverage is 100%. The description adds no parameter-specific semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a timesheet' restates the tool name almost verbatim (delete_timesheet) without providing additional context about scope, what constitutes a timesheet, or what happens upon deletion. It is a tautological restatement rather than a meaningful description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when this tool should be used versus other delete_* tools, nor does it mention prerequisites, consequences, or alternatives. There is no guidance on selecting 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the basic action. While annotations (readOnlyHint, idempotentHint, destructiveHint) cover safety aspects, the description does not disclose important behaviors such as response format (e.g., binary stream), potential errors, or the semantics of 'download' vs 'read'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, bordering on under-specification rather than effective conciseness. A well-structured description would include a few clarifying details, but this lacks substance and does not earn its place as a meaningful sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and a very minimal description. It fails to explain what 'download' entails (e.g., returns raw file content, supports streaming), nor does it differentiate from numerous sibling file tools. This is insufficient for an agent to confidently use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage for the single parameter file_id with a description ('File ID to show'). The description adds no parameter-level detail, but the high schema coverage justifies a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Download file' is essentially a restatement of the tool name, providing no additional specificity about what file is downloaded or how this differs from similar tools like get_read_file or list_read_files. It lacks distinguishing details such as the source, format, or scope of the download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternative file-related tools. The description gives no context about prerequisites, intended scenarios, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context—it doesn't mention what happens if the ID is not found, what data the response contains, or any other runtime behavior. It contributes zero value 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is severely under-specified, consisting of only two words. While it is not verbose, the extreme brevity omits necessary context and fails to be appropriately sized. It provides no useful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with no output schema, the description should at least mention that it retrieves a bill resource, but it doesn't. The combination of name, schema, and annotations provides minimal context, but the description itself fails to be complete enough to help an agent understand the return value or distinguish it from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the only parameter, 'id', is described as 'id of Bill to retrieve'. The tool description adds no additional parameter semantics, but the baseline is set at 3 for high schema coverage, so this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Get Bill" is a tautology—it restates the tool name (get_bill) verbatim without adding a specific verb+resource context. It does not distinguish from sibling get_* tools like get_invoice or get_order, offering no clarity on what a 'bill' is or how this operation differs from list_bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus alternatives, lacks any mention of prerequisites or filtering, and omits mention that it retrieves a single bill by ID. There is no context to help an agent choose this over list_bills or search-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond what annotations already provide. It does not disclose that the tool returns a PDF file, any authentication requirements, or the effect of the logopaper parameter. However, the annotations clearly mark this as a read-only, idempotent operation with no destructive side effects, so there is 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, which is too short to convey necessary information. This is under-specification rather than effective conciseness, as it omits critical context about the tool's purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose and the lack of an output schema, the description should explain that the tool returns a PDF for the specified invoice and mention the logopaper option. It provides none of this, so an agent cannot know what to expect from the tool call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (invoice_id and logopaper) are fully described in the input schema with 100% coverage, so the schema carries the burden of parameter semantics. The description adds no additional meaning, but since the baseline is 3 for high schema coverage, this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show PDF' is extremely vague and does not specify that this tool retrieves the PDF for an invoice. It fails to distinguish from sibling tools like get_order_pdf or get_quote_pdf. The description essentially restates the tool's name in generic terms, offering no specific resource or action clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_invoice_reminder_pdf or get_order_pdf. The description lacks any context about prerequisites, use cases, or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool's safety profile is covered. However, the description adds no extra behavioral context like what the return value contains or any access requirements. For a read operation with no output schema, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('Get a payment'), which is under-specification rather than effective conciseness. It does not earn its place by adding meaningful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what is returned or provide context about the payment entity. It does neither, making the tool's usage unclear. Even for a simple get operation, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes a required payment_id string, but the description does not mention it (schema description coverage is 0%). The parameter name is self-explanatory, but the description fails to compensate for the lack of explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('get') and resource ('payment'), but it is vague because there are sibling tools like get_invoice_payment and get_outgoing_payment that refer to different payment types. It does not distinguish this tool from those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as get_invoice_payment or get_outgoing_payment. The description provides no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read, non-idempotent, non-destructive operation, but the description adds nothing about the actual behavior of issuing a delivery. It does not mention side effects, state changes, permissions, or return values, so the agent only has annotations to rely on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no unnecessary words, but it is under-specified rather than appropriately concise. It lacks the detail needed for a useful tool description, so while there is no fluff, the structure does not effectively communicate the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an action tool with one parameter, no output schema, and no description of what 'issuing' does or returns. The description gives almost no context about the operation's effects, prerequisites, or results, making it completely inadequate for an agent to predict the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter (delivery_id) as 'the id of the delivery', covering 100% of the schema. The description does not add extra parameter context, so the baseline score of 3 applies because the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Issue a delivery' names an action and resource but does not explain what 'issue' means in this context. It is not a tautology, but it is vague and does not distinguish this tool from siblings like create_delivery_from_order or update_delivery, leaving the agent guessing about the operation's effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention prerequisites, relationships to other delivery-related operations, or when the action should be performed, so the agent lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-idempotency. However, the description adds no behavioral context, such as whether the quote is sent to the customer, whether it can be reverted (though a sibling tool exists), or what side effects occur. It relies entirely on annotations and provides no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is not effective conciseness—it is under-specification. 'Issue a quote' is the minimum verbiage with no informative content, similar to the 'Process' example where brevity detracts from clarity rather than enhancing it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool is simple (one parameter, no output schema), the description fails to provide essential context about what 'issuing' entails. It does not explain the outcome, the required state of the quote, or how it relates to sibling actions like mark_as_sent or revert_issue. This is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the only parameter (quote_id) with a description ('the id of the quote'), achieving 100% coverage. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Issue a quote' is a verb+noun phrase, but 'issue' is ambiguous in this business context—it could mean send, finalize, or mark as issued. It does not distinguish from sibling tools like send_quote, mark_as_sent_quote, or revert_issue_quote, leaving the agent without a clear sense of what this specific operation does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, status transitions, or exclusions. The agent is left to guess when to call issue_quote compared to the many related quote-handling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only and idempotent. The description adds no behavioral context such as what the tool returns, whether it can return empty results, or any filtering behavior. It merely repeats the name, contributing no value beyond structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two words, but this is under-specification rather than appropriate conciseness. It is not front-loaded with useful information and does not earn its place—it only restates the tool's name in a less precise way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns and what a 'repetition' is in this context. It does neither. The tool appears to list repetitions for an order, but the description is far too skeletal to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (order_id with description 'the id of the order'). The description adds nothing about the parameter, but the schema already fully documents it. Baseline of 3 is appropriate since no additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show repetition' is a vague restatement of the tool name. It lacks a clear verb+resource combination and does not distinguish from siblings like create_order_repetition or delete_order_repetition. The name already implies 'list', so this adds no clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that it lists repetitions for a given order or contrast with other repetition-related tools. The agent is left to infer usage from the parameter and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds no behavioral context beyond the phrase. It does not describe what data is returned, whether all project types are included, or any default ordering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than genuine conciseness. The phrase "Project types" contains no useful information beyond what the name already conveys, so it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not even explicitly state that it returns a list of project types. Given the large set of sibling tools, this description is incomplete and leaves the agent without essential context about the tool's function and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single order_by parameter has 100% schema description coverage, including available enum values and sorting syntax. Since the schema handles parameter semantics, the description's lack of parameter detail does not lower the score, but it also adds no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply "Project types," a noun phrase that lacks a verb and essentially restates the tool's name/title. It does not explicitly say the tool lists or retrieves project types, making it a tautology rather than a functional statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling list_* tools, such as list_project_status or list_projects. There is no mention of use cases, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds no behavioral information beyond these annotations, such as pagination behavior, ordering, or typical use cases. It does not contradict 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words) but this brevity is under-specification rather than conciseness. It lacks a verb or any context, so it does not earn its place as a helpful sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a list operation with no output schema, the description should at least state what is returned or how results are scoped. The current description leaves too much to inference, even though annotations and schema are solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (limit, offset, order_by) with 100% coverage. The description contributes no additional parameter meaning, but the schema suffices; baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Task priorities' is a bare noun phrase that simply restates the tool's name without expressing an action. It does not clarify that this is a list/read operation, nor does it distinguish it from related list tools like list_task_status or list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to choose this tool over alternatives, such as list_task_status, or mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 safety profile is covered. However, the description adds no behavioral context beyond these annotations—no mention of response shape, pagination behavior, or any special constraints. It earns minimal credit for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two words, the description is short but this is under-specification, not conciseness. It fails to convey the tool's purpose or behavior and is more of a label than an explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and the schema/annotations are rich, there is no output schema and the description does not even state that it returns a list of time sheet statuses. Given the ambiguity among sibling tools, this is inadequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: limit, offset, and order_by are all described in the schema. The description adds no parameter information, but the schema fully handles this dimension, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just 'Timesheet status' — a noun fragment without a verb or action. It does not explicitly say what the tool does (e.g., 'List time sheet statuses'). The title provides the action, but the description itself is tautological and vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, what distinguishes it from sibling status-list tools like list_project_status or list_task_status, or any context or prerequisites. The description offers zero usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. The annotations indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, but the description does not elaborate on implications such as required permissions, pagination, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it under-specifies the tool's purpose and usage. A single tautological sentence does not earn its place; it provides no value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the complexity of a search API with a body parameter, the description is inadequate. It does not explain what a search operation entails, the structure of the request body, or the shape of the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 limit, offset, and order_by parameters are well documented in the schema, but the required 'body' parameter is vaguely described as 'Request body as defined by the bexio API,' and the description adds no further clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search contact relations' is a tautology of the tool name, restating the verb and resource without adding any scope or differentiation. It does not distinguish itself from sibling tools like 'list_contact_relations' or 'get_contact_relation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not explain how 'search' differs from 'list' or what kind of queries the body parameter supports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the annotations. It does not explain how the search behaves, what the request body does, whether it supports full-text or structured search, or any side effects. Annotations include openWorldHint: true and readOnlyHint: false, but the description neither contradicts nor enriches these signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but not in a way that is efficient—it simply restates the tool name without providing useful information. The one-word phrase does not earn its place, as every piece of content is redundant with the tool's name and title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with three parameters and no output schema, the description is inadequate. It omits any explanation of return values, pagination behavior, how the body parameter affects search results, or how it differs from listing. The sparse schema descriptions for limit/offset help, but the body requirement is left entirely ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with 'limit' and 'offset' well-described. The 'body' parameter is vaguely described as 'Request body as defined by the bexio API', which is not very informative. Since the schema already covers parameters, the description's lack of additional parameter detail is acceptable, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search salutations' is essentially a verbatim restatement of the tool name 'search_salutations', offering no additional meaning. It fails to distinguish this tool from siblings such as 'list_salutations' or 'get_salutation', which is a critical gap given the many salutation-related tools available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'list_salutations' or other search tools. No context is provided on typical use cases, prerequisites, or criteria for when searching is appropriate, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the annotations. It doesn't mention side effects, authentication requirements, rate limits, or return behavior, leaving the agent without insight into how the search behaves or what it returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. However, it is essentially a tautology of the tool name, making it minimally useful; it is short enough but lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, a required body, no output schema, and nearby siblings (list_stock_areas, search_stock_locations), the description is completely inadequate. It doesn't explain what a search entails, what the body should contain, what results look like, or how it differs from listing stock areas.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description does not add any parameter-specific context; the schema's parameter descriptions are the only source of meaning, and the required 'body' parameter remains vaguely defined as 'as defined by the bexio API'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search stock areas' is a direct restatement of the tool name, adding no new information. It fails to distinguish from siblings like list_stock_areas or search_stock_locations, as it doesn't clarify any specific filtering or matching semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to prefer this tool over alternatives such as list_stock_areas or search_stock_locations, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotations. Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not clarify side effects, the uniqueness constraint (which is only noted in the schema's email parameter), or the effect of omitting optional parameters. It fails to indicate that this is a non-destructive write operation that requires an existing user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short at five words, but it is under-specified rather than concise. It repeats the tool name and provides no meaningful content, so it does not earn its place as an informative description. The low information density makes it inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update operation with 6 parameters and no output schema, the description should at least indicate that it modifies an existing fictional user and that required fields must be provided. It does not mention the email uniqueness constraint, the need for fictional_user_id, or any behavioral expectations. The description is too sparse to be contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83% (5 of 6 parameters documented in the schema). The tool description does not elaborate on any parameters, so it adds no value beyond the schema. Per the baseline for high schema coverage, a score of 3 is appropriate, but the description itself is unhelpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a fictional User' simply restates the tool name, making it a tautology. It does not provide any additional specification or distinguish this update tool from the many other update_* siblings beyond the resource name. This offers no new information to an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_fictional_user or delete_fictional_user. It does not mention that the fictional user must already exist, nor any prerequisites or exclusions. There is no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint=false) and not destructive, but the description adds no behavioral context. It does not explain that copying creates a new quote, what fields are duplicated, or any side effects. The burden falls entirely on the annotations, which are not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is so sparse that it reads like a label. It is front-loaded but lacks any structural breakdown or additional useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with 6 parameters and no output schema, the description is critically inadequate. It does not explain the return value, required parameters' purpose, or the overall behavior of the copy operation, making it impossible to invoke correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so baseline is not high, and the description does not compensate. It fails to explain how optional parameters like contact_id, pr_project_id, is_valid_from, or contact_sub_id affect the copy operation. The undocumented title and is_valid_from parameters remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('copy') and resource ('quote'), so the basic action is understandable. However, it does not differentiate from sibling tools such as create_reissue_quote or create_invoice_from_quote, and it repeats the title without adding scope or detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use copy_quote versus the many related quote operations (create_quote, reissue_quote, accept/decilne, etc.). No alternatives, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations already indicate a non-read-only, non-destructive, non-idempotent operation, but the description doesn't explain side effects, required relationships, or any operational nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than effective conciseness. It essentially restates the tool name without elaboration, offering no value beyond the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 20 parameters, 11 required fields, nested objects, and no output schema, the one-line description is grossly insufficient. It lacks context on the bill creation workflow, relationships between fields, and operational behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains no parameter information. With schema description coverage at only 35%, the description should compensate, but it fails to mention any of the 20 parameters, required fields, or the critical manual_amount vs amount_calc distinction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Create' and resource 'Bill', stating the core action. It distinguishes from sibling tools like create_invoice or create_purchase_order by naming the specific resource, though it provides no additional scoping or detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 update_bill or create_purchase_order. There is no mention of prerequisites, workflows, or scenarios where creating a bill is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what the annotations already convey. Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the agent knows it is a non-read, non-destructive write operation. But the description does not disclose any additional behavioral traits such as duplicate handling, required permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It conveys no useful information beyond the tool name, so the brevity does not serve a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no parameter descriptions, and a minimal description, the tool is severely under-documented. An agent cannot determine what data is required, what the response will be, or how to use the tool correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for its three parameters (name, name_short, iso3166_alpha2), and the description 'Create country' provides no explanation of what these parameters mean, their format, or requirements. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create country' clearly identifies the action (create) and the resource (country). It distinguishes from sibling tools like delete_country, get_country, and list_countries through the verb. However, it lacks any additional context about what a country is or specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, when creating a country is appropriate, or reference related tools like update_country or search_countries. The usage context is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral transparency beyond the annotations. Annotations indicate a non-read-only, non-destructive write operation, but the description does not explain side effects, required permissions, or what kind of data is created. It simply labels the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, which is not a waste of words but is under-specified. It lacks the necessary detail to be considered appropriately sized for a tool with 14 parameters and no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, 5 required, no output schema), the description is highly inadequate. It does not mention return values, required fields, or any operational context, leaving the agent with almost no guidance beyond the schema itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for about 71% of parameters, but the description itself offers no parameter information. It does not compensate for the undocumented required 'name' and other fields, leaving a gap that the description could have filled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create project' clearly states the action and resource, but it essentially restates the tool name without adding any specific context or distinguishing details. It does not differentiate from sibling tools like update_project or create_milestone beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description provides no context about prerequisites, related tools, or typical use cases, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, open-world, and idempotent behavior. The description adds nothing beyond repeating the fetch action—no mention of error conditions, return format, or any domain-specific caveats, so it provides no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and has no filler, which is concise in structure. However, it is under-specified to the point of being unhelpful; the brevity sacrifices the clarity needed for effective tool selection. It strikes a poor balance between conciseness and informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter, the description is still incomplete: it doesn't mention that both IDs are required, that it returns reminder details, or that it operates specifically on invoice reminders. Without the tool name and sibling context, an agent would be guessing at its behavior. The lack of output schema further increases the need for a richer description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both invoice_id and reminder_id have clear descriptions in the schema. The tool description doesn't add or enhance parameter meaning, but the schema fully documents them, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a reminder' has a clear verb and a generic resource, but it doesn't specify that this is for invoice reminders or distinguish it from sibling tools like get_invoice_reminder_pdf or list_invoice_reminders. It's not a tautology, but it's vague about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 such as list_invoice_reminders or search_reminders. The description provides no context for when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. However, the description adds no additional behavioral context, such as whether the number is consumed, what 'next' means, or the return format. It provides no value 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is extremely brief, but this is under-specification rather than effective conciseness. It omits critical details and is misleadingly vague, so brevity hurts rather than helps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must explain what the return value is. It fails to define 'next reference number', and the singular/plural mismatch between the name ('list_next_reference_numbers') and description ('Get next reference number') adds confusion. Overall, the information is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema fully covers the parameter set (100% coverage). The description does not need to explain any parameters; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get next reference number' is a near-tautology of the tool name 'list_next_reference_numbers' and does not clarify what type of reference numbers are involved or whether it returns a single number or a list. It also fails to distinguish the tool from siblings like list_purchase_document_numbers or list_expense_document_numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of specific scenarios, prerequisites, or exclusions, leaving the agent without context to select it appropriately among many similar list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, which cover safety. The description adds that the tool validates availability but does not explain what 'available' means, what the output looks like, or any edge-case behavior, providing minimal extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is structurally concise, but it is under-specified and lacks detail. It is not an example of efficient clarity because brevity comes at the expense of essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns or how availability is presented, but it does not. For a validation-like tool, this is a significant gap, making the description incomplete for an agent to invoke it with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'document_no' described as 'document number to validate'. The description's phrase 'document number' echoes this without adding new meaning, so it meets the baseline for high schema coverage but contributes no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Validate whether document number is available or not' is vague and misaligned with the tool name 'list_purchase_document_numbers', which implies listing purchase document numbers. It does not specify the resource (purchase documents) or the primary listing action, and it fails to distinguish the tool from siblings like list_expense_document_numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_expense_document_numbers or list_next_reference_numbers. It only states a generic validation purpose without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond annotations. It does not disclose what happens to invoice status, whether an email is actually sent, or potential side effects. However, it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The three-word fragment is under-specified, not concise. It lacks sufficient content to inform the agent, making it closer to a placeholder than a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 params and no output schema, a one-line description is inadequate. It does not cover return values, possible errors, or side effects, despite the tool's modesty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers 4/6 params with descriptions, but 2 params (subject, mark_as_open) are undocumented. The description adds no parameter information, leaving the agent to infer the meaning of 'subject' and the boolean flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'send' and resource 'invoice', but it is generic and does not specify the actual behavior (e.g., email dispatch vs. status update). It does not differentiate from siblings like send_invoice_reminder or mark_as_sent_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. It does not disclose that this is a write operation (though readOnlyHint=false already indicates that), nor does it explain effects on existing data, validation, or required permissions. No contradiction with annotations, but no additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concisely complete. It omits essential information about required fields and editable properties, making it closer to the 'Process' anti-example than to a well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, 3 required fields, and no output schema, a one-line description is insufficient. There is no explanation of how discount positions relate to quotes/orders/invoices, what fields are editable, or what the tool returns. The description is far from minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters. The schema covers only 50% of parameters (document_id, position_id, kb_document_type have descriptions; text, value, is_percentual do not). The description fails to compensate for the low schema coverage, leaving unclear semantics for key fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a discount position' uses a clear verb and specific resource, distinguishing it from sibling tools like create_discount_position and delete_discount_position. However, it lacks any detail about what editable fields or document types are involved, so it is clear but not exceptionally rich.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention the requirement to specify kb_document_type, document_id, and position_id, nor does it explain scenarios such as creating a new discount position instead of editing an existing one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=false and destructiveHint=false. The description adds no additional behavioral context such as partial update semantics, permission requirements, or side effects. It merely restates the action implied by the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but being short is not the same as being concise. 'Edit a note' is under-specified and does not earn its place as a helpful description. It provides no structure or meaningful content beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, update operation, no output schema), the description is wholly inadequate. It does not explain what 'edit' entails, which fields are eligible, or any constraints. The agent cannot correctly invoke this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 44%, and the description provides no information about any parameters. The description does not compensate for the low schema coverage, leaving agents without adequate understanding of what the parameters mean or how they should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (edit) and the resource (note). It does not, however, distinguish this tool from sibling tools like create_note or delete_note beyond the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_note or delete_note. The description only says 'Edit a note' without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already declare (readOnlyHint=false, destructiveHint=false). It doesn't disclose side effects, required permissions, or that partial updates are supported. The phrase 'Edit a task' merely restates the title and annotation, providing no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words), but this is under-specification for a tool with 16 parameters, not conciseness. A good description should be brief while still providing essential context; here, the brevity comes at the cost of clarity and utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, no output schema, and minimal annotations), the description is completely inadequate. It fails to explain what a task is, what fields are commonly edited, or any behavioral nuances. The agent has insufficient information to determine correct usage, making this description nearly useless for contextual decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 44% schema description coverage, the description should compensate by explaining the roles of key parameters, but it provides no parameter information whatsoever. The schema itself has descriptions for some fields like task_id and user_id, but the many undocumented fields (module_id, have_remember, todo_status_id, etc.) are left entirely unexplained, leaving the agent without sufficient semantics to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a task' clearly indicates a verb and resource, distinguishing it from siblings like create_task, get_task, and delete_task. However, it is minimal and doesn't specify the scope of editing (e.g., partial vs. full updates), leaving some ambiguity about the operation's exact nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, whether create_task should be used for new tasks, or any scenarios where update_task is preferred. The description simply states the action without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint: false) and non-destructive (destructiveHint: false). The description adds no behavioral context, such as whether the bulk creation is atomic, how partial failures are handled, or what the response contains. It merely repeats the implication of the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase with no redundant words. It is concise and to the point, though it sacrifices substance for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk creation tool with a complex request body array and no output schema, the description is inadequate. It does not explain return values, error behavior, or any constraints that the 'bexio API' body might impose, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, 'body', with 100% description coverage ('Request body as defined by the bexio API'). The tool description does not add any further parameter information, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bulk create contacts' is essentially a restatement of the tool name with underscores replaced by spaces. It does not add any further information about the operation's scope or differentiate it from sibling tools like create_contact, which presumably creates a single contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as create_contact, update_contact, or list_contacts. The description does not mention any specific use cases, exclusions, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already imply. While annotations indicate this is a write operation (readOnlyHint=false) and not destructive, the description does not disclose side effects, numbering behavior, or document lifecycle details. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specification rather than concise efficiency. It merely restates the tool name and does not earn its place with any additional information that aids the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 26 parameters and no output schema, this description is severely inadequate. It provides no indication of how to construct a valid request, what the response contains, or what side effects occur. An agent cannot reliably invoke this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters. With schema coverage at 65%, some fields have their own descriptions, but the remaining 35% and critical guidance about required fields, relationships, or positions are absent. The description fails to add any value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create quote' clearly states the action (create) and the resource (quote), providing a basic understanding of the tool's purpose. However, it does not differentiate from sibling tools like create_invoice, create_order, or copy_quote, so it lacks the specificity required for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use create_quote versus alternatives such as copy_quote, update_quote, or create_invoice_from_quote. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-idempotent write operation, so the description does not contradict them. However, it adds no extra behavioral context, such as what the tool returns, whether it can overwrite existing records, or any side effects. The description solely repeats the basic action already evident from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, earning some credit for efficiency. However, it is under-specified; it omits essential information like parameter meaning and return behavior, so the brevity is not effective structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple CRUD create tool with one parameter and no output schema, the description should at least explain what a salutation is and what the 'name' parameter represents. It does neither, leaving the agent without enough context to correctly invoke the tool. The lack of output schema also means the description should mention return value, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining the 'name' parameter, but it mentions no parameters at all. The single required parameter 'name' remains completely undocumented in both the schema and the description, leaving the agent without guidance on what value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('salutation'), making the purpose immediately understandable. However, it does not explicitly distinguish itself from sibling CRUD tools like update_salutation or delete_salutation beyond the verb, so it misses the full distinction criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The verb 'Create' implies usage for adding a new salutation, but there is no mention of prerequisites, alternatives, or context where this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds no behavioral information beyond that, such as side effects, soft vs hard delete, or consequences for related data. It does not contradict annotations, but provides zero additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. However, it is redundant with the tool name and title, offering no extra value, which limits its effectiveness as a standalone description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the minimal description, the combination of a fully documented schema (both params described) and comprehensive annotations (destructive, idempotent, openWorld) provides sufficient context for an agent to select and invoke the tool. The description itself adds little, but the overall context is complete for a simple delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters (contact_id and additional_address_id). The description adds no parameter-related meaning, so the baseline of 3 applies since the schema fully documents requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an additional address' is nearly identical to the tool name and title, effectively restating them without adding new information. It does not differentiate from sibling delete tools or provide any distinguishing context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It merely states the operation without any context of appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the destructive nature is covered. However, the description adds no additional behavioral context such as cascading effects, permissions, or reversibility. It merely repeats the action without enriching the agent's understanding 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is terse and avoids fluff. However, it is under-specified and lacks any supporting details. While it is not verbose, its brevity borders on underspecification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple (one parameter, no output schema), the surrounding context includes numerous payment-related tools, especially delete_invoice_payment, delete_outgoing_payment, and cancel_payment. The description fails to disambiguate or provide necessary context for correct selection and invocation, making it incomplete for the full operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'payment_id' with no description, and schema description coverage is 0%. The tool description does not explain what payment_id refers to, its expected format, or how to obtain it. Since the description must compensate for the lack of schema documentation but does not, it fails this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a payment' clearly states the action (delete) and resource (payment), which is sufficient for basic purpose. However, it does not distinguish from sibling tools like delete_invoice_payment, delete_outgoing_payment, or cancel_payment, so it earns a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 compared to related tools like delete_invoice_payment, delete_outgoing_payment, or cancel_payment. No prerequisites, side effects, or alternative recommendations are mentioned. The description provides no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true, but the description itself adds no behavioral context such as permanence, side effects, or permission requirements. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it is under-specified rather than efficiently informative. It does not provide enough substance to be considered well-structured; it simply restates the tool's purpose in a sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter delete tool, the description is minimally viable, but it relies entirely on annotations for safety context. It fails to explain what a salutation is, any deletion consequences, or whether the action is reversible, leaving the agent without sufficient context for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'salutation_id' is fully described in the schema as 'the id of the salutation', so schema coverage is 100%. The description adds no additional parameter meaning, but the baseline of 3 applies since the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a salutation' clearly states a delete operation on a salutation, distinguishing it from other delete tools by resource type. However, it adds no scope or detail beyond the tool name itself, making it barely more informative than a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, prerequisites, or alternatives. It does not mention any context or exclusions, leaving the agent without usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. However, the description adds no extra context beyond the annotations, such as error behavior, permission requirements, or what 'read file' specifically means. It contributes minimal value beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('Get single file') but this is under-specification rather than genuine conciseness. It omits crucial context about the file type and use cases, so the brevity is not justified by completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a single parameter, the tool is simple, but the description is insufficient for an agent to distinguish it from many file-related siblings. The lack of usage guidance and the ambiguity around 'read file' make the overall context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'file_id' is described as 'File ID to show', which is clear. The description 'Get single file' adds slight clarity that only one file is retrieved, but it does not provide additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get single file' clearly indicates a read operation but lacks specificity about what a 'read file' is, especially with sibling tools like 'get_file' and 'list_read_files'. It does not distinguish itself from the generic 'get_file', making the purpose ambiguous despite a clear verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_file', 'download_file', or 'list_read_files'. The description gives no context for selection, failing to clarify which file type is meant or when to prefer this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is essentially a tautology of the tool name and adds no behavioral context beyond what the annotations already supply. It does not disclose side effects, return format, or how the search criteria are applied. The annotation readOnlyHint=false is not contradicted, but the description itself provides zero additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three words long, which is concise but severely under-specified. It omits crucial details about the search operation, making it insufficient for an agent to understand how to invoke the tool correctly. This is under-specification, not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, a required body parameter, and no explanation of how search filters work or how it differs from list_communication_types. Given the moderate complexity of the body parameter and pagination options, the description is materially incomplete for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description (body, limit, offset, order_by). The tool description adds no extra meaning about these parameters, so the baseline of 3 is appropriate. The body parameter's description is vague, but the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search communication types' clearly states the verb and resource. However, it does not distinguish itself from the sibling tool 'list_communication_types', which is also present in the API. The lack of differentiation prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus list_communication_types, nor any context about the required 'body' parameter. It offers no explicit alternatives or usage scenarios, leaving the agent to infer when a search is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond the bare action. It does not mention the required body parameter, the response format, or any side effects. Moreover, the annotations state readOnlyHint and idempotentHint are false, which conflicts with the read-only and repeatable nature implied by 'search', creating an annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, consisting of two words that merely restate the tool's name. While it is not verbose, it is under-specified, which does not earn high marks for conciseness as defined in the rubric.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no parameter semantics explained, and a vague body parameter, the description is insufficient for an agent to correctly invoke the tool. It provides no information about how to construct the request body, pagination, or what response to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (body, limit, offset) with 100% coverage. The description adds no additional meaning to the parameters, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Search') and resource ('notes') in two words. However, it doesn't specify what kind of search (by ID, by criteria) or what results are returned, and it fails to distinguish itself from sibling tools like list_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use search_notes versus list_notes or get_note. The description is too brief to convey any context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations already indicate a mutating, non-idempotent operation (readOnlyHint=false, idempotentHint=false), but the description does not disclose whether the update is partial or full-replacement, what happens to omitted fields, or any side effects. It fails to leverage the annotation context to provide useful behavioral specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), but this is under-specification rather than efficient conciseness. For a tool with 29 parameters and no output schema, the description should provide at least a sentence or two of context. It does not earn its place as a helpful summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is highly complex (29 parameters, 5 required, no output schema), yet the description offers no information about return values, update semantics, error conditions, or interaction with the required fields. It is completely inadequate for an agent to understand the full scope of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 52%, the description does not compensate for the gap in parameter documentation. It provides no information about how parameters relate to the edit operation, which fields are commonly updated, or what the required fields represent beyond their schema descriptions. The description adds zero value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Edit') and resource ('a contact'), making the primary purpose unambiguous. It distinguishes from sibling tools that target other resources (e.g., update_contact_group, update_contact_relation), though it does not add any detail about the specific contact attributes or behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to alternatives like create_contact, delete_contact, search_contacts, or update_contact_group. There is no mention of prerequisites, required fields, or typical scenarios, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, but the description adds no behavioral context beyond the obvious 'edit' action. It does not clarify whether the update is partial or full, how missing records are handled, or what side effects occur. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At just four words, the description is concise but severely under-specified. It lacks structure and substance for a tool with four required parameters, making it more of a stub than an efficient description. Every word is necessary, but no meaningful detail is conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter update tool with no output schema, this description is severely incomplete. It does not mention required inputs, how the country is identified, what the update affects, or what the response contains. The annotations cover only safety hints, so the description carries no contextual load.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only country_id having a description. The description 'Edit a country' does not clarify the meaning of name, name_short, or iso3166_alpha2, leaving three parameters entirely unexplained. It adds zero semantic value for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a country' clearly identifies the action (edit) and the resource (country), distinguishing it from country creation, retrieval, and deletion. However, it lacks detail on which fields can be updated or how the country is identified, so it is clear but not fully informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_country, get_country, or search_countries. It does not mention prerequisites, exclusion conditions, or any context for choosing update_country.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is a mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds no additional behavioral context, such as whether it performs a partial update or requires specific prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no unnecessary words. It is appropriately concise, though this brevity comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with annotations and a minimal schema, the description is inadequate. It does not explain what fields are editable, whether it's a partial or full update, or the effect on the unit. This is insufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes unit_id as 'the id of the unit' but leaves name completely undocumented. The description does not explain that 'name' is the new value to set, so it fails to compensate for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool edits a unit, clearly indicating a modification operation. However, it is essentially a synonym for the tool name/title 'Update Unit' and provides no specifics about what aspects of a unit can be edited, making it minimally informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus other unit-related tools like create_unit, delete_unit, get_unit, or list_units. There are no context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds no additional behavioral context such as side effects, permissions, or how the pagebreak position affects documents. It merely restates the action without enriching the annotation-provided information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified rather than concise. A single sentence without any additional structure or detail does not earn its place for a tool with 3 parameters and domain-specific concepts. It borders on being a tautology of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and moderate parameter complexity, but the description provides no information about return values, side effects, or how the parameters interact. It lacks essential context about what a pagebreak position is and how it is used in documents, leaving the agent to infer almost everything from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the parameters. Schema coverage is 67%, so document_id and kb_document_type are documented, but the 'pagebreak' boolean parameter has no description in the schema and none in the text. The description fails to compensate for this gap or add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and the resource 'pagebreak position', clearly distinguishing it from sibling tools like update/delete/get/list. However, it does not explain what a pagebreak position is or mention document scope, which would make it fully clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context about the intended use case (e.g., adding pagebreaks to quotes/orders/invoices). The only implied usage is that the tool creates a pagebreak position, but there is no elaboration on the circumstances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds no extra behavior details—it simply restates the name without mentioning return format, error handling, archived behavior, or any other operational nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but under-specification is not conciseness. The sentence restates the tool name and does not earn its place by providing useful information, making it more of a label than a helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple get-by-id operation with good annotations and schema coverage, but the description is too minimal to be complete. Since there is no output schema, the description should at least imply the return type or clarify the uniqueness of the ID lookup, but it does neither.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (contact_id and show_archived), so the baseline is 3. The description 'Fetch a contact' adds no additional meaning beyond the schema and does not even mention the required contact_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and a clear resource 'contact', indicating it retrieves a single contact. However, it does not differentiate from sibling tools like search_contacts or list_contacts, though the schema's required contact_id implies one-by-ID retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_contacts, list_contacts, or get_contact_group. There are no context cues, 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.
Behavior2/5
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 known. The description adds no behavioral detail beyond the basic fetch action, leaving ambiguity about the response format (e.g., whether it returns binary content or a file URL). There is 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—a single fragment—which makes it easy to scan. However, it is under-specified and grammatically awkward ('Fetch file of manual compound entry'), so it doesn't earn full marks for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter fetch tool with no output schema, the description is incomplete. It does not explain what the returned file looks like, how to use the two IDs, or when to prefer this over sibling tools like get_manual_entry_file. The openWorldHint and idempotent annotations add some context, but the description itself is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage), so the description need not add parameter details. It does not add any extra meaning or relationship between manual_entry_id and file_id, but the baseline of 3 is appropriate given complete schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Fetch' and identifies the resource as 'file of manual compound entry', which is clear at a basic level. However, it does not clarify whether the tool returns file metadata or binary content, and it does not distinguish from sibling tools like get_manual_entry_file or list_manual_compound_entry_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is provided. The description gives no context on when to use this tool versus related file tools such as get_manual_entry_file or download_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 known. The description adds no additional behavioral context, such as pagination behavior, ordering, or that it only returns payments associated with the given invoice. It is a bare 'Fetch' without any details beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (5 words) and front-loaded, but under-specification is a concern. It lacks critical context about the invoice scope, making it less useful than a concise yet informative description. It is not a tautology like 'Process', but it barely adds beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema) and strong sibling context, the description is incomplete. It does not explain that the invoice_id is required to filter payments, nor does it mention pagination or the return format. The schema provides parameter details, but the overall purpose and usage context are underministered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (limit, offset, invoice_id) described in the input schema. The description adds no extra meaning or context, so it does not compensate or enhance beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fetch a list of payments', which identifies the verb and resource but is vague. It fails to mention that the list is specifically for a given invoice, despite the tool name and required invoice_id parameter. The description does not distinguish it from sibling tools like list_payments or list_all_payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as list_payments or list_all_payments. The description does not state that it is for invoice-specific payments or exclude other payment list tools. No context or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction. However, the description adds no behavioral details beyond the name—it doesn't mention pagination, response structure, or any operational caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with no wasted words, but it sacrifices clarity for brevity. 'manual entry line' is cryptic, so the sentence is not efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With simple schema and rich annotations, some context is covered externally, but the description fails to explain what 'files' are, how they relate to manual entries, or how to choose this over similar list tools. Contextual completeness is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description does not add extra parameter context, and the baseline of 3 applies since no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch files of manual entry line' names a verb and resource but 'manual entry line' is vague and doesn't clearly convey what the tool lists. It does not differentiate from sibling tools like get_manual_entry_file or list_manual_compound_entry_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as get_manual_entry_file, list_manual_compound_entry_files, or upload_manual_entry_file_file. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. While readOnlyHint=false and destructiveHint=false are given, the description doesn't explain what mutation occurs, any permission requirements, or side effects. It's purely restating the verb 'edit'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise with a single phrase, but it under-specifies. It's not a tautology, yet it provides minimal value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter mutation tool with no output schema and minimal annotations, a one-line description is grossly insufficient. It gives no information about required inputs, field constraints, or expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only 50% of parameters, and the description provides no parameter-level details. It mentions no fields, required parameters, or constraints, so it fails to compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit an additional address' clearly identifies the action (edit) and resource (additional address), distinguishing it from sibling create/delete/get/list operations. However, it lacks any scope or detail about what 'edit' entails, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_additional_address or list_additional_addresses. There are no prerequisites, context, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, but the description adds no additional behavioral context beyond the verb 'edit'. It does not disclose side effects, permission requirements, failure conditions, or whether the operation is idempotent (though annotations say it is not).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concisely informative. A single sentence that essentially restates the tool name provides no added value, although it is not verbose. It is more of a placeholder than a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 required parameters and no output schema, a minimal description might be acceptable, but this one leaves out any mention of constraints, prerequisites, return values, or typical usage scenarios. It is incomplete for an agent to invoke confidently without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only contact_group_id has a description). The description does not clarify the semantics of the 'name' parameter, nor does it state that name is the only editable field. It fails to compensate for the partial schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (edit) and the resource (contact group), making it distinct from sibling operations like create, delete, get, and list. However, it could be more specific about what exactly is edited (e.g., the name), though the schema provides that detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention the need for an existing contact group ID or contrast with create_contact_group or delete_contact_group, leaving the agent without explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits beyond what the annotations already indicate. Annotations show readOnlyHint=false and destructiveHint=false, which align with 'Edit', but the description adds no context about side effects, partial updates, validation errors, or any special behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one short sentence, which is positively no wasted words. However, it is under-specified for a tool with 14 parameters and 3 required parameters. The conciseness sacrifices useful detail about what 'editing' entails.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the complexity of 14 parameters, and the need to understand what a default position is, this description is severely inadequate. It provides no explanation of the resource, the editing semantics, or the relationship among required parameters, making it impossible for an agent to correctly use the tool without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the 14 parameters. Although the schema provides descriptions for 64% of parameters, the description itself does not compensate for the undocumented ones. It fails to explain the meaning of required fields like kb_document_type, document_id, or position_id, leaving the agent to rely entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Edit') and the resource ('default position'), which distinguishes it from sibling tools like create_default_position, delete_default_position, and get_default_position. It is not merely a restatement of the tool name, though it lacks details on what fields can be edited.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, such as when creating a new position or deleting one. There is no mention of prerequisites or recommended context. It merely states the action, leaving the agent to infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds nothing beyond the annotations. readOnlyHint=false already indicates mutation, but the description does not disclose side effects (e.g., recalculating document totals), required permissions, or constraints. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified, not concise. 'Edit an item position' basically restates the tool name and offers no additional structural value. It is too terse to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, no output schema, and a mutating operation, this single sentence is grossly incomplete. It does not explain required fields, what can be updated, or update semantics, making it insufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero parameter-level meaning. While the schema covers many parameters (tax_id, unit_id, document_id, etc.), several like text, amount, amount_open, and amount_reserved remain undocumented. The description fails to compensate for this 67% coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit an item position' clearly identifies the action (edit/update) and resource (item position), but it does not distinguish from sibling position-update tools like update_subposition or update_discount_position. It is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention the relevant document types (quotes, orders, invoices) or contrast with update_subposition/update_text_position, leaving the agent to infer usage from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already declare. It does not disclose side effects, permissions, reversibility, or impact on related data, even though annotations are sparse (e.g., openWorldHint=true, destructiveHint=false) and the tool is complex with 15 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, at one sentence with no wasted words, but this under-specification is not appropriate for a tool with 15 parameters and complex behavior. It is front-loaded but lacks the detail needed to be genuinely useful, so it falls short of 'appropriately sized'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, 6 required ones, no output schema, and a complex domain, the description 'Edit a project' is grossly incomplete. It provides no information about required fields, return values, or operational behavior, making it inadequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description 'Edit a project' contributes nothing to parameter understanding, while the input schema covers 73% of parameters with descriptions. Since schema coverage is below 80%, the description should compensate, but it does not mention any parameter or convey additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a project' clearly identifies the action (edit) and resource (project), and distinguishes this tool from sibling CRUD operations like create_project, delete_project, and get_project. However, it is generic and does not specify what properties or aspects of the project can be edited, relying on the schema for that detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_project or update_work_package. There is no mention of prerequisites, target use cases, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already convey (read-write, non-destructive). It does not disclose side effects, update semantics (e.g., partial vs. full replacement), or any prerequisites like required permissions. Annotations are present but the description fails to enrich them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than appropriately concise. For a tool with 26 parameters and complex behaviors, a two-word description is inadequate and fails to convey essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the rich schema, the description is minimal and leaves the agent to infer behavior. It does not explain the effect of the update, whether partial updates are allowed, or what the response contains. Given the tool's complexity and the absence of an output schema, the description is not complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 26 parameters and schema description coverage at 65%, the description should compensate for undocumented fields, but it does not. It mentions no parameters at all, leaving the schema as the only source of information. The required quote_id is not highlighted in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a quote' clearly states the verb (edit) and resource (quote), making it obvious what the tool does. However, it does not differentiate this from sibling tools like issue_quote, copy_quote, or update_invoice by explaining scope or specific capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that it is the primary method for modifying quote fields, nor does it reference related commands like create_quote or issue_quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive mutation, but the description adds no behavioral detail such as whether this is a partial or full update, required permissions, or side effects. It provides no transparency beyond the name and existing annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At four words, the description is under-specified, not concise. It essentially restates the tool name ('Edit a text position' vs update_text_position) without adding useful context or structure, and it fails to earn its place as an informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no output schema, and a crowded set of sibling position-update tools, the description is far from complete. It omits usage scenarios, parameter semantics, and behavioral expectations, making it insufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes three of five parameters (document_id, position_id, kb_document_type), but text and show_pos_nr remain undocumented. The description does not mention any parameters, so it fails to add meaning for the undocumented fields and does not compensate for the 60% schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a text position' uses a specific verb and resource, clearly indicating a mutation on a text position. However, it does not distinguish this from many sibling position-update tools like update_item_position or update_subposition, so it fails to differentiate within the broader toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any context about appropriate scenarios, prerequisites, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a write operation. The description adds no further behavioral context such as required permissions, side effects, or rate limits, offering no value beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, making it technically concise. However, it is under-specified to the point of resembling a title rather than a useful description, lacking any structural detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, a nested address object, and no output schema, a one-sentence description is drastically insufficient. It does not explain required inputs, field relationships, or what happens after creation, leaving the agent with very little actionable guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 42%, leaving many parameters undocumented. The description provides no explanation for any of the 12 parameters, including required fields like paid_on and currency_code, so it fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create new Expense' clearly identifies the action (create) and the resource (Expense), distinguishing it from sibling tools like update_expens, delete_expens, and create_expense_action. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_expense_action or update_expens. There is no context about prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. It does not disclose what happens upon creation (e.g., document generation, numbering, required fields) or any side effects. Annotations already signal non-read-only and non-idempotent behavior, but the description fails to enrich that with useful specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly stated sentence with no extraneous fluff, and it front-loads the core action. However, its extreme brevity veers toward under-specification, so it does not fully earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—40 parameters, nested objects, and no output schema—a one-sentence description is grossly inadequate. It lacks essential context about what constitutes a valid purchase order, required associations, or typical use cases, leaving the agent with insufficient information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains no parameter information. With only 57% schema description coverage, the description does not compensate for the undocumented parameters, nor does it highlight key fields like contact_id, positions, mwst_type, or currency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Create') and a specific resource ('purchase order'), making the tool's primary function unambiguous. It does not explicitly distinguish from sibling document-creation tools like create_order or create_quote, but the unique resource name provides inherent differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., create_order, create_quote), nor does it mention any prerequisites or exclusions. The sole sentence offers no contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description 'Delete a payment' adds no extra behavioral context such as irreversibility, cascading effects, or prerequisites beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and to the point, which is efficient. However, it sacrifices specificity that would help with sibling differentiation, but for a simple delete operation, minimalism is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with clear schema, but the description fails to explain the relationship between invoice_id and payment_id, nor does it clarify whether the operation is idempotent (although annotations hint at it). It lacks enough context to be fully usable without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (invoice_id and payment_id) have descriptions in the schema, providing 100% coverage. The description adds no additional parameter semantics, but the baseline is 3 because the schema already documents the parameters sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (Delete) and the object (a payment), which is clear. However, it does not specify that this is a payment attached to an invoice, making it hard to distinguish from sibling tools like delete_payment or delete_outgoing_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Given the many payment-related delete tools in the sibling list, the description should clarify the specific scenario (e.g., deleting a payment from an invoice) but does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, etc., so the safety profile is known. However, the description adds no context about what 'file usage' means, what the response looks like, or any limitations. It doesn't contradict annotations but fails to enrich them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three words—with no wasted words. It is easy to parse. However, it is so brief that it borders on under-specification, which slightly reduces the score from a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is still incomplete. It fails to explain what 'file usage' means or what the user should expect in the response. This is too thin to be considered a fully contextual description, especially given the potential ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter file_id described as 'File ID to show'. The description adds nothing beyond what the schema already provides, so the baseline of 3 is appropriate. No additional semantic value is introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Show' and resource 'file usage', which gives a basic idea of the action. However, 'file usage' is ambiguous—it could mean disk usage, references, or something else—and it doesn't clearly distinguish from sibling tools like get_file or download_file. A more specific term like 'file references' would be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No mention of scenarios, exclusions, or related tools. The user must infer from the name, which is insufficient for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, non-destructive, idempotent, and open-world. The description adds no behavioral context beyond those hints, such as pagination behavior, defaults, limits, or return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and free of filler. It is concise, though somewhat under-specified; the brevity itself is not a problem.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal description, the agent has no way to know what fields the returned titles contain, whether pagination is supported beyond the schema, or what 'titles' refers to in this domain. The description is too thin to be fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: limit, offset, and order_by each have descriptions explaining max limit, skipping, and ordering syntax. The description itself adds no parameter information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of titles' clearly states an operation and resource, but it is essentially a restatement of the tool name and does not define what a 'title' is or how this list is scoped. It does not explicitly distinguish itself from sibling tools like search_titles or get_title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as search_titles for filtered lookup or get_title for a single record. The description is a bare statement with no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations present (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), the description adds no behavioral context. It does not explain what the search does with the 'body' parameter, how results are ordered, or what visibility scope applies, so the agent has no idea what to expect 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief—two words—but this is under-specification rather than effective conciseness. It lacks a complete sentence and fails to structure any useful information for a tool with a complex body parameter and multiple options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (required array body, pagination, ordering, and sibling tools for listing/retrieving), the description is grossly incomplete. It does not explain what 'search' means here, how the body shapes the query, or how results are returned, making it inadequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters (body, limit, offset, order_by), so the description does not need to repeat parameter details. The description itself adds no parameter-level meaning beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and resource 'titles', indicating a search operation over title entities. However, it does not differentiate from sibling tools like 'list_titles' or 'get_title', so it lacks scope or distinguishing details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list_titles' or 'get_title'. No context, prerequisites, or exclusions are mentioned, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits beyond what annotations already provide (readOnlyHint=false, destructiveHint=false). It does not explain whether the update is a partial patch or full replacement, whether validation occurs, any side effects on invoice status, or required permissions. For a mutation tool with a large schema, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence 'Edit an invoice'. It is front-loaded and not verbose, but it lacks structure and depth. It is under-specified to the point of being minimally helpful, similar to a placeholder rather than a properly scoped description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 23 parameters, no output schema, and many sibling invoice operations, this description is incomplete. It fails to explain the scope of editable fields, behavioral semantics, or how it fits into the invoice lifecycle. The agent must rely entirely on the schema and annotations, which do not provide sufficient contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the 23 parameters. Schema coverage is 65%, leaving several fields undocumented (e.g., title, header, footer, is_valid_from, show_position_taxes). The description does not compensate for these gaps or clarify which fields can be edited, so it provides no value beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit an invoice' clearly specifies a verb (edit) and resource (invoice), indicating an update operation. It does not explicitly differentiate from sibling tools like create_invoice, delete_invoice, or issue_invoice, but the verb and the tool name make the action reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention that it modifies an existing invoice, nor does it contrast with related operations like create_invoice, issue_invoice, or cancel_invoice. There is no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds no extra behavioral context such as side effects, reversibility, or authorization requirements. It simply restates the action without elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise three-word sentence with no filler, and it is front-loaded with the verb and object. However, it may be under-specified, which slightly reduces the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema, so the absolute need for detail is low. However, the description does not clarify what 'cancel' entails (e.g., status change vs. deletion), especially in contrast to the sibling delete_payment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 0%, the description does not explain the payment_id parameter beyond its name. The parameter name is self-explanatory, but the description adds no additional meaning or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Cancel') on a specific resource ('a payment'), which makes the primary purpose understandable. However, it does not differentiate 'cancel' from the sibling tool 'delete_payment', which is a close alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use cancel_payment versus alternatives like delete_payment or update_payment. There are no usage contexts, prerequisites, or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral information beyond what the name implies. Annotations indicate readOnlyHint=false and idempotentHint=false, but the description does not mention important behaviors such as auto-generating intermediate future years or relying on previous year's tax ID, which are only found in 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief—a single sentence that essentially restates the tool's name. It is under-specified for a tool with 7 parameters and lacks any additional structure or context that would earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema), the one-line description is inadequate. It omits return values, side effects, prerequisites, and the auto-generation behavior for future years, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already fully documents all 7 parameters. The description adds no parameter-level information, but the baseline score of 3 applies because the schema carries the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'calendar year', distinguishing it from sibling tools like get_calendar_year or list_calendar_years. However, it does not add any extra scope or differentiate from create_business_year, which is also a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no exclusions. The description simply repeats the tool's name without any contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, but the description does not elaborate on potential side effects, permission requirements, or expected behavior after creation. For a write operation, agents would benefit from knowing what changes are made and what invariants hold.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('Create a currency'), which is concise but under-specified. It does not earn its place by adding meaningful guidance or context. The one-sentence format is clear, but the lack of substance makes it less useful than a more complete but still efficient description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with two parameters and no output schema, the description should explain what is returned or how to confirm success. It does not mention return values, error cases, or the openWorldHint implication of side effects. The schema and annotations cover basic constraints, but the description leaves significant gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema provides detailed descriptions for both 'name' (including format and uniqueness) and 'round_factor' (including an example). The description itself does not add any parameter information beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a currency' clearly identifies the action (create) and resource (currency). While it does not provide additional scope or differentiate from sibling tools like update_currency or delete_currency, the verb alone makes the primary purpose unambiguous. It is a step above a tautology because it conveys a specific operation, but it lacks the detail seen in higher-scoring examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No context, prerequisites, or exclusion criteria are provided. The description implies only that it is used to create a currency, but it does not mention related tools like list_currencies or update_currency for lookups or modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is a read-write operation (readOnlyHint=false), but the description adds no behavioral context beyond the literal action. It does not disclose side effects, required existing entities, or any constraints, leaving the annotation and schema to carry the full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information, and it is front-loaded with the verb and object. It is appropriately short for the statement of purpose, though it lacks detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and only partial parameter descriptions, the description is far from complete. It does not explain the document relationship, the meaning of a discount position, or how the parameters interact, making it insufficient for reliable invocation without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40% (only document_id and kb_document_type are described), leaving text, value, and is_percentual undocumented. The description does not clarify these parameters or how they should be set for a discount position, providing no additional semantics beyond the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (create) on a specific resource (discount position), which distinguishes it from sibling tools for other position types. However, it is essentially a restatement of the tool name and does not explain what a discount position is or how it differs from other position types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update_discount_position or create_item_position. There is no mention of prerequisites, document context, or scenarios where this should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. However, the description adds no behavioral context beyond the name—it does not disclose what happens if the position is not found, whether it returns null or errors, or any other runtime behavior. Since the description is merely a restatement of the tool name, it adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. While it has no wasted words, it also provides no useful information beyond the tool's name, essentially repeating the name. This is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a description that only says 'Fetch an item position', the description is not complete enough to prepare the agent for what the tool does, what it returns, or the relevance of the document type parameter. The schema covers parameter meanings, but the overall purpose and expected behavior remain underexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds no additional semantic nuance beyond what is already in the schema, which is acceptable for a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch an item position' uses a specific verb and resource, clearly distinguishing it from sibling tools like get_discount_position or get_text_position. However, it does not elaborate on what an item position is or that it belongs to quotes, orders, or invoices, which would add clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_item_positions or get_discount_position. The description does not mention that it retrieves a single specific position by ID or any context about the document type, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context such as return format, errors, or special conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to add any value beyond the tool name. It is under-specified rather than appropriately concise, providing no useful information for tool selection or invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While this is a simple get-by-id tool, the description lacks context about the purpose of outgoing payments, how they relate to other payment types, or what distinguishes this operation from similar siblings. The bare description is insufficient for an agent to confidently choose this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'id' parameter, and its description is clear. The tool description adds no parameter information beyond the schema, which is acceptable given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Outgoing Payment' clearly identifies the action (get) and resource (outgoing payment). However, it simply restates the tool name and doesn't differentiate from other payment-related tools like get_payment or list_outgoing_payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of appropriate contexts, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds no further behavioral context, such as pagination behavior, default return of all bills, or the effect of filter parameters, which would be valuable 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, which is extremely concise but under-specified for a tool with 24 parameters. It lacks any structural elements or additional context; this is under-specification rather than good conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the rich schema and safety annotations, the description fails to mention that this is a list endpoint with pagination and filters. With no output schema, the description should clarify the return type and typical usage, making the current two-word description inadequate for such a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, all 24 parameters have detailed descriptions. The tool description itself does not add any parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Bills' uses a specific verb and resource, clearly indicating it retrieves bill data. It distinguishes from the sibling get_bill (singular) through the plural form, but lacks detail about the list/pagination nature or filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_bill or other list_ endpoints. No context is given about typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. However, the description adds no behavioral context beyond the bare 'Fetch a list', missing details like pagination behavior, ordering, or the dependence on document_type/document_id that the schema implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it essentially restates the tool name and provides no additional information. It is under-specified rather than efficiently concise; the sentence does not earn its place with valuable content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should account for return behavior. It does not mention that the operation requires a document type and document ID, nor what kind of data is returned. Combined with minimal behavioral context, the description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the four parameters (limit, offset, document_id, kb_document_type) are fully documented in the schema. The description adds no extra parameter meaning, but given high coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Fetch a list') and a specific resource ('sub positions'), which is consistent with the tool name. It is distinguishable from 'get_subposition' by the list vs. single-item verb, but it does not explicitly mention document scope or alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not provide context about required document types, filtering, or scenarios where other list tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply restates the action without explaining side effects, such as whether it resets the sent date or triggers any related updates. Annotations declare it is non-readonly, non-destructive, and non-idempotent, but the description adds no further context about the operation's consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief—a fragment that essentially mirrors the tool name. It is not verbose, but it is under-specified and lacks any context or structure, so it doesn't earn high marks for being appropriately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters, no output schema, and no usage guidance, the description is minimal. It doesn't specify the return value or the effects of the operation, and it fails to position the tool among its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (`invoice_id` and `reminder_id`), and the description adds no additional meaning beyond what is in the schema. Since schema coverage is 100%, this meets the baseline for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Mark' with the object 'reminder' and target state 'unsent', clearly indicating a status change. It distinguishes itself from the sibling tool `mark_as_sent_invoice_reminder` by specifying the opposite state. However, it doesn't explicitly mention 'invoice' in the noun, but the tool name does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this action, such as prerequisites (e.g., reminder must exist and be currently marked as sent) or alternatives (e.g., use `send_invoice_reminder` to actually send). There is no mention of scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond the word 'search'. Annotations exist but are minimal, and the description adds no context about side effects, permissions, or API behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, but it is under-specified. It fails to provide useful information beyond the tool name, making it less effectively informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a required 'body' parameter that is an array of arbitrary objects, yet the description provides no hints about its structure or usage. With no output schema and no explanation of search behavior or return format, an agent cannot correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema adequately explains each parameter. The description adds no additional meaning beyond the action, yielding a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (search) and the resource (business activities). However, it does not distinguish this from the sibling tool 'list_business_activities', so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'list_business_activities' or how to structure the search query. The description offers no context for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. The readOnlyHint is false, which is ambiguous for a search operation, but the description does not clarify side effects, return format, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase that simply restates the tool name, providing no additional information. It is under-specified rather than efficiently concise, as there is no substantive content to evaluate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with a required free-form body parameter and no output schema, the description is severely incomplete. It does not explain what the body accepts, what results are returned, or how pagination and ordering interact with the search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter semantics; the required 'body' parameter remains vague ('as defined by the bexio API'), and the description does not explain how to construct search criteria.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource pattern ('Search contact groups'), making the primary action evident. However, it does not differentiate from sibling tools such as list_contact_groups or get_contact_group, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 search tool versus list_contact_groups, get_contact_group, or other alternatives. The description provides no context, exclusions, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, but the description adds no behavioral context beyond the tool's basic action. There is no mention of authentication requirements, rate limits, response structure, or side effects, so the description contributes nothing 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, extremely brief phrase that essentially restates the tool name. While concise, the brevity is due to under-specification rather than efficient communication of key details, leaving the agent with insufficient information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no output schema, and a sibling that lists contact sectors, the description is inadequate. It lacks details on search criteria, pagination, filtering, or how it differs from the list variant, making it incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all four parameters (body, limit, offset, order_by) documented. The tool description itself adds no information about parameter usage or semantics, so it meets the baseline of 3 without enhancing the schema's explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Search contact sectors' with a clear verb and resource, indicating it searches for contact sectors. However, it fails to differentiate from the sibling tool 'list_contact_sectors', which likely serves a similar listing purpose, so it lacks scope differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 search tool versus the alternative 'list_contact_sectors' or other search tools. The description provides no context on typical use cases, prerequisites, or exclusions, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (readOnlyHint false, destructiveHint false, idempotentHint false, openWorldHint true) and do not clarify the behavior. The description adds no details about return values, pagination, or the effect of the 'body' parameter. It carries the burden but fails to disclose behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it essentially restates the tool name (search_payment_types) without adding meaningful detail. It is under-specification rather than effective conciseness, nearly a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal annotations, the description is incomplete. It does not explain how to use the required 'body' parameter, what the search returns, or how it differs from a simple list operation. The tool needs more contextual information to be usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters including 'body' as 'Request body as defined by the bexio API.' The description itself adds no additional parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Search' and the resource 'payment types', which clearly indicates the tool searches payment types. However, it does not distinguish from the sibling tool 'list_payment_types', so it lacks differentiation between searching and listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of alternatives like list_payment_types or other search tools. It lacks context on search criteria, required body structure, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, yet the description gives no behavioral details, such as whether search is read-only despite the hint, what side effects might occur, or what results contain. With no additional context, the agent cannot anticipate the tool's behavior beyond the minimal name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words), but it under-specifies the tool's functionality. Conciseness should not come at the cost of missing critical information; this is under-specification rather than efficient brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex 'body' parameter defined as an array of objects with no detailed schema, and no output schema exists. The description does nothing to explain how to construct the body or interpret the response, leaving a significant knowledge gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for all parameters, including body, limit, offset, and order_by, so the baseline is 3. The description adds no extra meaning about parameter usage, but the schema already handles this adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Search timesheets'), making the core action clear. However, it does not differentiate from sibling tools like list_timesheets or get_timesheet, leaving ambiguity about what 'search' adds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of list_timesheets or get_timesheet. The description lacks context about intended use cases, filters, or exclusions, so an agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already convey (non-read-only, non-destructive). It doesn't disclose side effects, handling of missing relations, or response behavior, leaving the agent to infer from the schema and the tool name without added insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only four words with no filler. While brevity is generally good, the text is so minimal that it omits necessary details, yet as a standalone phrase it is well-structured and easy to read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for an update tool. It doesn't explain what a contact relation is, what updating entails, which fields are valid, or what the outcome will be. The schema and annotations provide some structural context, but the description's one-liner leaves critical gaps for an agent trying to make an informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description makes no contribution to parameter understanding. The schema already describes three of four parameters (contact_id, contact_sub_id, contact_relation_id), but the 'description' field remains undocumented, and the tool description adds no examples, constraints, or explanations to bridge that gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a contact relation' clearly identifies the action (edit) and resource (contact relation), making it easy to distinguish from siblings like create or delete. However, it lacks specific scope, such as which attributes can be modified, and doesn't explicitly differentiate from the tool name 'update_contact_relation' beyond using a synonym.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_contact_relation or delete_contact_relation. There is no mention of prerequisites, typical scenarios, or exclusions, so the agent has no directional support for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the write-but-not-destructive nature is captured. The description 'Edit a salutation' adds no additional behavioral context such as permission requirements, side effects, or return behavior. It is largely redundant with the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words. It is front-loaded with the verb and object. While extremely brief, it is not verbose or poorly structured; it simply lacks information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with two parameters and annotations, the description is thin. It doesn't mention what happens when editing, whether the name is the only updateable field, or any success/error implications. The context provided is barely more than the tool name itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'salutation_id' but not 'name'. The description fails to explain what 'name' represents or how it relates to a salutation. With 50% schema description coverage, the description should compensate but does not add any parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Edit' and the resource 'a salutation', making the purpose unambiguous. It distinguishes itself from create/delete/get/list/search siblings by the verb, but doesn't explicitly call out the distinction. It's specific and understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like create_salutation or update_title. There is no mention of prerequisites, exclusions, or appropriate contexts. The agent must infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already communicate that this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), but the description adds no further behavioral context—it doesn't state whether editing is limited to certain fields, if prior existence is required, or what happens to linked data. With no output schema, the agent gains no insight into the operation's effects or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence and free of redundancy, which is efficient. However, it is so brief that it borders on under-specification, though conciseness itself is achieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters and no output schema, this description is insufficiently informative. It fails to explain what a subposition is, what fields can be edited, or any constraints implied by the document type, making the tool hard to use without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for kb_document_type, document_id, and position_id, but the parameters text and show_pos_nr are unexplained. The description 'Edit a sub position' offers no clarification of these parameters, and with 60% schema coverage, the missing parameter semantics are not compensated for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Edit') and a specific resource ('a sub position'), which distinguishes it from sibling tools like create_subposition, delete_subposition, and get_subposition. However, it lacks any scope or qualification about which aspects of the sub position can be edited, so it is not as rich as a top-tier description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives, such as whether it is the sole way to modify a subposition or if there are prerequisites like the document type. It also doesn't mention any conditions that must be met before editing, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is terse and adds no behavioral context beyond what the annotations already provide. It doesn't disclose that the update modifies only the text field, whether the document total is recalculated, or any permission requirements. Since annotations already indicate readOnlyHint=false and destructiveHint=false, the description contributes no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 4-word sentence, extremely concise with no filler. However, it is so minimal that it sacrifices necessary information, but that is a completeness concern, not a conciseness one. For its length, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 a mutation behavior, yet the description only says 'Edit a subtotal position'. It lacks context about the document types, the meaning of a subtotal position, how to obtain position_id, and what effect the edit has. This is inadequate for an agent to use the tool correctly without relying on schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 3 of 4 parameters with descriptions, but the 'text' parameter lacks any description. The tool description does not explain that document_id, position_id, and kb_document_type are identifiers and that text is the editable content. It adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Edit' with a specific resource 'subtotal position', clearly indicating a mutation of an existing subtotal position. However, it doesn't differentiate from sibling tools like update_subposition or other position update tools, and the name itself does most of the work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention that subtotal positions are found on quotes, orders, or invoices, nor does it distinguish editing from creating/deleting subtotal positions. The openWorldHint annotation suggests the tool may accept open-world inputs, but the description offers no situational advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context beyond what the name implies. It does not disclose side effects, required permissions, return values, or failure modes, so the agent is left without additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At only three words, the description is extremely short but lacks necessary detail. This is under-specification rather than efficient conciseness, leaving the agent without meaningful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description does not mention what the response contains, and there is no output schema to fill that gap. Given no annotations about response format, the agent cannot know whether the create operation returns the created group, an ID, or nothing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'name' with zero description coverage, and the description does not explain what this parameter expects. While the parameter name is self-explanatory, the description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'create' and the resource 'contact group', clearly distinguishing it from sibling tools like list, get, search, update, and delete contact groups. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no mention of related operations such as updating or deleting contact groups. The description simply restates the tool's name without offering any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, so the agent knows it's a write operation. However, the description adds no behavioral context—no mention of side effects on the quote, whether positions are copied, or what the response contains. It merely restates the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, but it sacrifices substance for brevity. It is front-loaded and wastes no words, but the under-specification makes it less helpful than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A write operation with side effects is described in only four words. The schema covers positions behavior, but the overall context—what happens to the source quote, expected outcome, and workflow—is missing. No output schema exists to clarify the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters (quote_id and positions) with descriptions, including the optionality and behavior of positions. The tool description itself adds no parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create order from quote' with a specific verb and resource, and the 'from quote' qualifier distinguishes it from the sibling tool 'create_order'. It precisely communicates the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create_invoice_from_quote' or 'create_order'. The description lacks any context about workflow or prerequisites, offering zero decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond what the annotations already declare. Annotations clearly set destructiveHint=true and idempotentHint=true, so the agent knows it is destructive and repeatable. The description simply restates the action without adding context like permanent deletion, authorization requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It is efficient for a simple delete operation, though it is arguably too sparse to provide meaningful value. Still, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one required parameter and annotations covering destructive behavior, the description is minimally sufficient. However, it omits any context about consequences (e.g., fail if referenced) or confirmation steps, which would be helpful in real-world usage. The presence of complete schema and annotations lifts it from a 2, but it still lacks proactive clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: country_id is described as 'the id of the country'. The description adds no additional parameter information. Baseline is 3 for high schema coverage; the description neither enhances nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a country' clearly states the action (delete) and the resource (country), matching the tool name. It is unambiguous, though it does not provide additional context to distinguish from other delete_* tools beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 such as update_country or search_countries. It does not indicate prerequisites (e.g., country not in use) or situations where deletion is appropriate. This is a minimal placeholder with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already flag the operation as destructive and idempotent, and the description simply repeats 'Delete' without adding anything about consequences, irreversibility, or impacts on related documents. No additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, consisting of a single clause, but it is under-specified and adds little value beyond the tool name. While there is no verbosity, the lack of substance makes it not a model of effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and the existence of many similar position-deletion tools, the description is too terse to provide a complete understanding. It does not explain what a discount position is, how deletion affects the parent document, or when it is appropriate, relying entirely on schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters with descriptions and an enum for kb_document_type, so the 100% schema coverage meets the baseline. The description itself contributes no parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a discount position, using a specific verb and resource. It distinguishes itself from other delete tools by specifying 'discount position' rather than other position types, though it provides no additional context beyond the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as delete_item_position or delete_subtotal_position. It lacks any mention of document types, prerequisites, or when deletion is appropriate, leaving the agent to infer from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds no extra behavioral context, such as whether deletion is permanent, what happens to the associated invoice, or any side effects. It lacks information beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words. It is appropriately sized for a simple delete operation and front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain the relationship between invoice_id and reminder_id, or any constraints or outcomes. With no output schema, the description does not mention return values or behavior when the reminder does not exist. Given the destructive nature, more context is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'invoice_id' and 'reminder_id' having descriptions in the input schema. The description adds no additional meaning or context about the parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a reminder' clearly states a delete action on a reminder resource. It is clear in meaning, but it does not specify that it is an invoice reminder, relying on the tool name to disambiguate. It does not explicitly differentiate from other delete tools, but the verb+resource is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives. There is no mention of prerequisites, conditions (e.g., only unsent reminders), or comparison to related tools like mark_as_sent_invoice_reminder or delete_invoice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what annotations already convey. Annotations include destructiveHint=true and readOnlyHint=false, so the description's 'Delete an item' is consistent but redundant. It does not disclose additional details such as irreversibility, cascading effects, or authorization requirements, which would add value beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three words) and avoids verbosity, but it is under-specified to the point of being almost identical to the tool name. It does not waste words, but it also does not earn its place by adding meaningful information. This is acceptable but not exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description is incomplete. It does not explain what happens on deletion (e.g., permanent removal, return values, side effects). Annotations provide the destructiveHint, but the description lacks contextual details that would help the agent understand the full impact. Given the low complexity, a bit more explanation would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter 'article_id' with a description ('the id of the item'), so schema coverage is 100%. The description itself adds no parameter information, but the baseline for full schema coverage is 3; the description does not compensate with any additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an item' clearly states the action (delete) and the resource (item), which is understandable and distinct from sibling tools like delete_item_position or create_item. However, it lacks any additional scope or specificity, such as what 'item' refers to or any qualifying conditions, so it does not fully distinguish beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, use cases, or exclusions. For example, it does not say whether this tool should be used instead of delete_item_position or if it is the correct tool for deleting articles. This leaves the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, but the description adds no additional behavioral context beyond the word 'delete'. It does not mention irreversibility, cascading effects, or required permissions, providing no extra value over 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is ultra-concise at just four words, and it is not a tautology. However, it is under-specified, providing no useful information beyond the tool name and thus not earning its place as a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate complexity with three required parameters including an enum for document types, and no output schema. The description does not explain what a text position is, when deletion is valid, or any consequences, leaving the agent without essential context. Sibling tools like delete_subposition and delete_pagebreak_position further highlight the lack of distinguishing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, and all three parameters (kb_document_type, document_id, position_id) are fully described in the input schema. The description itself adds no parameter-level meaning, but the baseline of 3 applies due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('text position'), which is a straightforward verb+resource combination. However, it does not distinguish from sibling tools like delete_item_position or delete_subposition, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or how it compares to alternatives such as delete_item_position or delete_subposition. The description simply states the action without any contextual cues about document types or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the basic safety profile. The description adds no additional behavioral context such as error handling, return format, or requirements like the comment existing before retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded, but it is so sparse that it carries minimal information. It does not expand on the tool's scope or parameters, making it under-specified for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should at least hint at the return value or clarify the document–comment relationship. It provides neither, relying entirely on the schema and annotations. The tool is not complex, but the description adds no contextual value beyond the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all three parameters (100% coverage), so the description does not need to add much. The description 'Fetch a comment' adds no extra meaning beyond the schema's parameter descriptions, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a comment' uses a specific verb and resource, making the core action clear. However, it does not differentiate this tool from other get_* sibling tools (e.g., get_note, get_task), or mention that comments are tied to documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_comments or create_comment. There are no context cues, prerequisites, or exclusions beyond what is implicitly understood from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds no further behavioral context, such as return value formats, authentication needs, or edge cases. It merely restates the basic action without going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Fetch a payment'), which is efficient but under-specified. It avoids verbosity but barely adds value beyond the tool name. While not as severe as 'Process', it lacks the substance expected for a resource-specific tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool appears to fetch a payment associated with an invoice, but the description does not explicitly state this relationship. Given the absence of an output schema and the presence of a similar get_payment tool, the description should provide more context about what constitutes an invoice payment and what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (invoice_id and payment_id) with types and descriptions, achieving 100% coverage. The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a payment' clearly indicates a read operation on a payment resource. However, it does not distinguish this from the sibling tool get_payment, which also fetches a payment. The tool name suggests invoice-specific payments, but the description lacks that qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_payment or list_invoice_payments. It does not mention context, prerequisites, or the relationship between invoice_id and payment_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety expectations. However, the description adds no behavioral context beyond the tool name—it does not disclose what 'show' entails (e.g., generating a file, returning a URL, downloading), any authentication requirements, or response format. This is essentially a tautology of the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short at only three words, which is concise but under-specified. It is front-loaded but has no informational substance beyond what the tool name conveys. Adequate in length but not appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should at least hint at the return value (presumably a PDF file), but it does not. It also fails to mention the required combination of invoice_id and reminder_id or any behavior like letterhead generation. The annotations cover safety but not functional completeness. For a 3-parameter tool with no output schema, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, with invoice_id and reminder_id clearly defined as IDs and logopaper explaining the letterhead option. The description adds no parameter information, but since the schema is comprehensive, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show reminder PDF' clearly indicates the tool retrieves or displays a reminder PDF. The verb 'show' and resource 'reminder PDF' are specific enough, but it does not explicitly distinguish from other PDF-related tools like get_invoice_pdf or get_order_pdf beyond the 'reminder' qualifier, relying on the tool name for full context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives. Sibling tools such as get_invoice_reminder (non-PDF) and get_invoice_pdf exist, but the description does not mention them or clarify that this is the PDF-specific variant for reminders. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. Annotations state readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is known. However, there is no extra disclosure about return format, error behavior, or the fact that it operates on a specific tax_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('Fetch a tax') and wastes no words, but it is under-specified. It conveys the basic action but lacks necessary detail like 'by ID', making it borderline between concise and incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description is minimal but still leaves gaps. It does not explain what a 'tax' represents in the domain, what fields are returned, or how this relates to list_taxes. The annotations and schema do not compensate for this lack of context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter semantics: tax_id is required and described as 'the id of the tax'. The description adds nothing about the parameter, so with high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and identifies the resource 'a tax', which clearly indicates retrieving a single tax object. It is distinct from sibling tools like list_taxes (plural) and delete_tax (destructive), though it does not explicitly mention retrieval by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives. It does not mention that this is for fetching a single tax by ID and that list_taxes should be used for multiple taxes, nor does it provide any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral context such as error handling, authentication needs, rate limits, or return format. It is consistent with annotations but contributes no extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in length, but it essentially restates the tool name without adding informative value. It is under-specified rather than efficiently scoped, resembling the 'Process' example in that it provides minimal insight beyond the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only fetch tool with strong annotations and full schema coverage. However, the description omits important context about the relationship between project_id and package_id, and what a work package represents. It is minimally viable but leaves gaps that could lead to incorrect usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%—both package_id and project_id have clear descriptions. The tool description does not add extra parameter semantics, but the schema already carries the full burden. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a work package' clearly indicates a retrieval operation for a specific work package resource. It differentiates from list_work_packages and create/update/delete counterparts by using 'Fetch' and singular 'a work package', though it does not explicitly contrast with sibling get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like list_work_packages or get_project. The required project_id and package_id imply the need for specific identifiers, but the description does not state this or provide any contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the operation is not read-only and not destructive, but the description adds no extra behavioral context. It does not state what changes occur (e.g., invoice status updated), any side effects, or that it is reversible via revert_issue_invoice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, which is concise, but it essentially repeats the tool's title and does not add explanatory value. It is under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description is too sparse. It fails to explain the invoice lifecycle position, what 'issuing' entails, or how it differs from the many adjacent invoice tools, making it inadequate for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter invoice_id is fully documented in the schema with 100% coverage. The description provides no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as 'Issue an invoice', using a specific verb and resource. However, it does not explain what 'issue' means operationally or differentiate it from sibling tools like send_invoice, create_invoice, or mark_as_sent_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No mention of prerequisites, typical workflow position (e.g., after creation), or that this is distinct from sending or creating an invoice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context—it doesn't mention that comments are scoped to a document, pagination via limit/offset, or what the returned list contains. It merely restates the tool's name, providing no value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence with no fluff, and the information is front-loaded. However, it is so brief that it borders on under-specification rather than being appropriately concise. It's not verbose, but it also doesn't earn its place by being informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns, but it doesn't. It also fails to mention that comments are tied to a specific document type and ID, which are required parameters. The annotations are good, but the description is incomplete for a tool that requires a document context and returns a paginated list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters (kb_document_type, document_id, limit, offset) having meaningful descriptions in the schema. The description itself adds no parameter information, but the schema already carries the full semantic load, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'comments', which is specific enough to indicate a list operation. It doesn't differentiate from sibling tools, but no other comment-list tool exists in the sibling set, and 'comments' is a distinct resource. However, it lacks the context that comments are attached to specific documents, which would make the purpose clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no exclusions. The schema implies it requires a document type and ID, but the description doesn't explain this. In a large sibling set of list_* tools, this lack of usage context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond the literal action, such as pagination behavior, default limits, ordering, or any constraints on the list result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise. However, it essentially restates the tool name ('list_item_positions' -> 'Fetch a list of item positions') without adding new information, so it earns its place only minimally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and many closely related sibling tools, the description is incomplete. It fails to explain what item positions are, which document types are supported, or how the required parameters constrain the request, leaving the agent to rely heavily on schema and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented. The description adds no additional meaning beyond the schema, but the baseline of 3 is appropriate because the schema carries the load and the description does not contradict it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('item positions'), making the base purpose clear. However, it does not distinguish from sibling position-related tools like list_discount_positions or list_subposition_positions, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternative position listing tools. There is no mention of required document context (kb_document_type, document_id) or exclusions, leaving the agent to infer usage solely from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 safety profile is covered. However, the description adds no behavioral context beyond that—no mention of pagination, default limits, ordering, or what qualifies as a manual entry. It essentially restates the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence, which is structurally concise. However, it borders on a tautology and lacks useful detail, so it does not earn a higher score for conciseness; under-specification prevents it from being truly helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is contextually sparse: no explanation of what manual entries are, no output schema to compensate, and no guidance on when to choose this over sibling tools like list_manual_entry_files or list_journal_entries. The openWorldHint suggests unfiltered results, but pagination and domain specifics are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for both parameters (limit and offset) with clear descriptions. The tool description adds no parameter information, but the baseline of 3 applies because the schema fully documents parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Fetch' and specifies the resource 'manual entries', giving a clear high-level purpose. It does not explicitly differentiate from siblings like list_manual_entry_files or list_journal_entries, but the naming is distinct enough to infer the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any mention of context, prerequisites, or exclusions, and does not reference related search or list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral traits beyond the annotations. Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. But the description does not mention pagination, filtering by bill, or return characteristics, providing no 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it essentially restates the tool name and title. It is concise but lacks substantive information, making it minimally acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description is incomplete. It fails to explain that bill_id is required, what the returned list contains, or how it relates to other payment listing tools. The schema provides parameter names but not the overall purpose or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters have detailed descriptions. The description does not add any extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves outgoing payments, which is specific to the resource. However, it does not differentiate from similar sibling tools like list_all_payments or list_invoice_payments, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that bill_id is required, nor when to choose this over list_all_payments or list_invoice_payments. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond the trivial 'Fetch a list', such as pagination defaults or whether the list is complete. It contributes no value beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it essentially restates the tool name ('list_tasks' → 'Fetch a list of tasks'). This is under-specification rather than concise efficiency, offering no new information to the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with well-documented parameters and strong annotations, the description is minimally adequate. However, it lacks guidance on when to use list_tasks vs. search_tasks, and the absence of an output schema leaves the return structure unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all three parameters (limit, offset, order_by), achieving 100% coverage. The description does not discuss parameters, but the baseline of 3 applies because the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('list of tasks'), clearly identifying the operation. However, it does not differentiate from sibling tools like search_tasks or get_task, so it misses the level-5 distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that search_tasks should be used for filtered queries, or clarify the scope of 'list' (e.g., all tasks vs. filtered).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the annotations. It does not mention return format, search semantics, performance characteristics, or side effects. The annotations (readOnlyHint=false) are surprisingly not read-only for a search tool, but the description itself does not clarify this potential inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, which is efficient but lacks any structure or additional context. It is arguably under-specified for a tool with a complex request body and sorting options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are 4 parameters, no output schema, and the search operation is non-trivial, the description is far from complete. It fails to explain how search criteria are specified in the body, how results are ordered, or what the response contains. An agent would not know how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for all parameters, so the baseline is 3. The description adds no additional meaning about parameters, such as how 'body' is structured or how 'limit' behaves. It relies entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search invoices' provides a clear verb and resource, indicating the tool searches for invoices. However, it does not differentiate from the sibling tool 'list_invoices', which likely serves a similar purpose, so it lacks distinguishing scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_invoices' or 'search_quotes'. The description does not mention filters, pagination, or any context where search is preferred over list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what annotations already provide. It does not disclose whether the operation is safe, what side effects might occur, or any important constraints. The annotations include readOnlyHint: false, which is ambiguous for a search tool, and the description fails to clarify this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 'Search quotes' — extremely concise with no wasted words. However, it is under-specified to the point of being nearly tautological, which the rubric treats as under-specification rather than good conciseness. It lacks any structural elements like examples or clarifications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no output schema, and annotations that don't clarify behavior, the description is insufficient. It doesn't explain what the search filters are, what the response looks like, or how the body parameter should be structured. This makes the tool hard to use correctly without external API knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds nothing about the parameters, and the 'body' parameter remains vague ('Request body as defined by the bexio API'), but since the schema already documents each parameter, the description does not need to compensate much.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action 'Search' on the resource 'quotes', which is a specific verb+resource pairing. However, it does not distinguish itself from the sibling 'list_quotes' tool, so it isn't fully differentiating but remains clear in its core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of alternatives like 'list_quotes' or how it differs from other quote-related tools. There are no exclusions, prerequisites, or examples of appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only, not idempotent, and not destructive, but the description adds no additional behavioral context such as partial update semantics, field validation, or side effects. Both annotations and description are consistent, but the description contributes nothing beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at only three words, which is good for front-loading, but it is under-specified for a tool with 23 parameters. It reads more like a summary than a standalone description, and while not verbose, it could benefit from additional structured context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex mutation tool with 23 parameters, no output schema, and no behavioral notes, a three-word description is insufficient. It does not explain return values, editing semantics, or the intended usage context, leaving the agent to rely entirely on the schema and sibling tool names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for 74% of the 23 parameters, including detailed notes for fields like mwst_type, document_nr, and mwst_is_net. The description 'Edit an order' adds no parameter information, but the schema largely covers that need, so the baseline of 3 is appropriate given the high-ish coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit an order' uses a specific verb ('Edit') and resource ('an order'), clearly distinguishing it from sibling tools like create_order, delete_order, or get_order. It is concise and unambiguous, though it does not elaborate on the scope or fields involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_order or delete_order. It does not state prerequisites, exclusions, or context, leaving the agent to infer usage solely from the name and resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal that this is a mutating (readOnlyHint=false), idempotent, and non-destructive operation. The description adds no additional behavioral context, such as side effects on related bills, approval workflows, or constraints beyond the schema. The rich parameter constraints are present in the schema but not in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words) and front-loaded, but it is under-specified rather than efficiently concise. It is a fragment, not a full sentence, and provides no additional explanation, which limits its usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters, 4 required fields, and complex business rules (e.g., amount limits, execution date constraints), a three-word description is grossly inadequate. While the schema covers parameter details, the description lacks an overview of the operation's purpose, high-level behavior, or exceptional cases, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has detailed descriptions for 86% of parameters, meeting the high-coverage baseline. The description itself says nothing about parameters, but the schema compensates well, so no additional compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit Outgoing Payment' clearly identifies the action (edit) and resource (outgoing payment), which distinguishes it from sibling tools like create, delete, get, and list. However, it lacks detail on what specific aspects can be edited, making it clear but minimally informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or comparisons to similar actions such as create_outgoing_payment or update_payment. An agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is a non-read-only, idempotent, non-destructive operation. The description adds no extra behavioral context, such as whether payments in certain states are editable, permission requirements, or side effects. It simply restates the action without augmenting the annotation information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it is minimal to the point of being almost vague; it conveys only the basic verb+resource and omits useful details. It is appropriately sized but under-specified for a tool with 11 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has a complex input schema (11 parameters, nested object) and no output schema. The description does not explain what happens on success, error conditions, or any special update constraints. It is insufficient for an agent to fully understand the tool's behavior or expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (82%), with most parameters having detailed descriptions. The tool description provides no additional parameter meaning beyond what the schema already offers, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a payment' uses a specific verb and resource, clearly indicating the action of modifying an existing payment. It is distinct from siblings like 'update_outgoing_payment' and 'create_payment', though it does not elaborate on the scope or fields involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'create_payment', 'update_outgoing_payment', or 'cancel_payment'. The description does not mention any prerequisites or context that would help an agent choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already indicate (readOnlyHint=false, destructiveHint=false). It doesn't disclose permissions, side effects, or idempotency considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified. It provides minimal information without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no usage guidance, the description is incomplete. It does not explain what 'edit' encompasses or what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have descriptions in the schema (100% coverage), so the description need not explain them. The description adds no additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Edit' and the resource 'work package', clearly distinguishing it from create/delete/get/list siblings. However, it lacks any specificity about which fields or scope of editing, so it is clear but not detailed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_work_package or update_project. There is no mention of prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. It does not explain what archiving entails, whether it is reversible, or what side effects may occur despite openWorldHint=true and destructiveHint=false providing only partial hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise and free of fluff. It is appropriately front-loaded, though it is sparse enough that it does not fully leverage the opportunity to convey additional useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool performs an action on a project with no output schema, the description leaves out crucial context: what happens to the project when archived, whether it can be reversed, and how it relates to unarchive_project or delete_project. This is a state-changing tool, and the minimal description is insufficient for an agent to fully understand implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter project_id with the description 'the id of the project', so schema coverage is 100%. The tool description adds no additional parameter meaning, but the baseline of 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Archive a project' clearly identifies the action and resource, using a specific verb. It distinguishes from obvious siblings like unarchive_project and delete_project, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The presence of unarchive_project and delete_project in sibling tools makes this gap notable, as an agent receives no advice on choosing among these related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, implying a state change that is not destructive. The description adds no extra context about reversibility, required invoice status, side effects on payments or reminders, or whether cancellation is permanent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single clear sentence with no wasted words. While it is under-specified, that is a completeness issue rather than a conciseness problem.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the low complexity (one parameter, no output schema), the description is too terse to be complete. It fails to clarify the semantics of cancellation versus deletion, any preconditions, or the outcome, leaving the agent unsure about the tool's effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter invoice_id is fully documented in the schema with a description ('the id of the invoice'). The tool description adds no additional meaning, but with 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Cancel') and the resource ('an invoice') clearly. However, it does not differentiate from the sibling tool delete_invoice, leaving ambiguity about whether cancellation is a status change or a deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as delete_invoice, update_invoice, or issue_invoice. There are no scenarios, preconditions, or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already convey (readOnly=false, destructive=false). It does not disclose side effects such as whether the delivery is drafted or issued, whether the order status changes, or what happens to existing positions. Since annotations already indicate it is a write operation, the description contributes minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary wording. It is appropriately sized for such a simple tool, though it lacks detail. The structure is easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too terse to be fully complete. With no output schema, it does not explain return values, and it omits information about the creation process or side effects. The schema and annotations cover parameters and safety hints, but contextual details like what happens after creation are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for both parameters, including a useful note about omitting positions to use all order positions. The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create delivery from order' uses a specific verb ('create') and names both the resource ('delivery') and source ('order'), making the core purpose unambiguous. However, it does not explicitly distinguish itself from sibling tools like issue_delivery or create_invoice_from_order, limiting differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. Users are left to infer that it is for converting an order into a delivery, but no explicit context or comparison with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already convey (readOnlyHint=false, idempotentHint=false). It does not mention side effects, validation rules, uniqueness constraints, or what happens on duplicate emails, despite the schema hinting at such behavior in the email parameter description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the verb and object. However, it is so minimal that it does not contribute much beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and sibling CRUD operations, the description is under-specified. It does not explain what a fictional user is, mention the unique email constraint, or describe the return value. The agent would need to rely on the parameter schemas and annotations for essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself does not elaborate on any parameters, so it adds no value beyond the input schema. Since schema description coverage is 80% and most properties have meaningful descriptions, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a fictional user'), which distinguishes it from sibling tools like get_fictional_user, update_fictional_user, and delete_fictional_user. However, it is essentially a restatement of the tool name and title, adding no additional contextual detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or how it differs from creating regular users. The description simply states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the action without adding any behavioral context. Annotations already flag destructiveHint and idempotentHint, but the description adds no extra details such as cascading effects, permission requirements, or irreversibility beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, it is under-specified and adds little value over the tool name, making it borderline between appropriate minimalism and under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description is minimally sufficient. It does not mention irreversible consequences, effects on associated contacts, or return values (no output schema exists), so some additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter contact_group_id with a description, achieving 100% schema coverage. The description itself adds no additional semantic meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a contact group' clearly states the verb (delete) and the resource (contact group). It is specific but does not differentiate from other delete tools, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other contact-related operations, nor any mention of prerequisites (e.g., whether the group must be empty) or alternatives. The description provides no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what annotations already provide. Annotations clearly mark it as destructive (destructiveHint=true) and non-read-only, so the agent already knows it is a destructive operation. The description does not disclose permanence, side effects, or any additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or repetition. It is extremely concise and front-loaded, which is appropriate for a simple delete operation. However, it is so terse that it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with strong annotations (destructiveHint, idempotentHint), the minimal description is adequate but not comprehensive. It lacks any mention of return values, error conditions, or whether the note is permanently removed. The annotations cover the safety profile, so the spareness is less critical than it would be without them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (note_id) with the description 'the id of the note'. The tool description adds no extra parameter meaning. Since schema coverage is 100%, the baseline is 3, and the description does not enhance it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a note' clearly states the action and resource, distinguishing it from sibling tools like delete_currency or delete_item. However, it is almost identical to the tool name and offers no additional nuance about the type of note or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when deletion might be inappropriate, or any exclusions. The sibling list includes update_note and other delete_* tools, but the description does not help differentiate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description adds no behavioral context beyond what annotations provide. It does not disclose consequences, irreversibility, permissions, or any other behavioral traits, offering zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose without waste. It lacks structure (e.g., bullet points), but for a simple delete operation, the brevity is acceptable and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal description, lack of output schema, and annotations that only indicate safety profile, the description is incomplete. It does not explain what happens on success, error conditions, or any caveats. For a destructive operation, more context would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all three parameters with clear descriptions, achieving 100% coverage. The description adds no additional parameter semantics, so the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a sub position' clearly states the action (delete) and the resource (sub position), making the tool's purpose obvious. It distinguishes from sibling delete tools by the specific resource type, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or specific contexts. It merely states the action without mentioning scenarios, prerequisites, or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive operation. The description adds no additional context beyond the verb 'delete', such as irreversibility, cascading effects, or permission requirements, so it contributes little beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, and easily parseable sentence. It is not a tautology and effectively communicates the core action, though it could be slightly expanded with usage context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with a complete schema and clear annotations, the description provides the essential purpose. However, it lacks usage context such as which document types it applies to and how it relates to other position deletion tools, making it minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself provides clear explanations for each parameter, including the relationship between kb_document_type and document_id. The description adds no parameter-level information, so it meets the baseline but does not elevate the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a subtotal position'), which differentiates it from sibling tools like delete_subposition or delete_item_position. However, it does not explicitly mention the supported document types (offer, order, invoice), which are only found in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or context such as that it applies to specific document types. With many sibling delete tools, this lack of direction makes it hard for an agent to select it confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds no additional behavioral context such as irreversibility, cascade effects, or permission requirements. It relies entirely on annotations for safety disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is appropriately concise for a simple delete operation. It is not bloated, though it lacks detail that could be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with one parameter and no output schema, the description is minimal but omits context about the title entity, potential side effects, and usage scenarios. The combination of schema and annotations covers invocation, but the description itself provides insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with title_id documented. The tool description adds no parameter-level information beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a title' clearly states a delete operation on a title resource, with a specific verb and object. It distinguishes itself from other delete_* siblings by naming the resource, though it doesn't clarify what 'title' refers to in the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or conditions mentioned. The description gives no context for selection among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds no additional context about consequences, such as whether deletion is permanent, if related records are affected, or if there is any recovery option. The openWorldHint suggests possible side effects, but the description does not address them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one short sentence with no filler. It is a complete verb+resource statement, but it lacks any additional structure or explanation that could be considered valuable for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of annotations, and a fully described parameter, the description provides the basic function. However, it omits behavioral details like permanence and side effects, which are especially relevant for a destructive operation. The description is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter, unit_id, with a description. The tool description adds no extra meaning beyond what the schema provides. Since schema coverage is 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a unit' clearly states the action (delete) and the resource (unit), making it distinguishable from sibling tools like get_unit and update_unit by the verb. However, it does not elaborate on what a unit is in this domain, which would help an agent fully understand the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mention of prerequisites, exclusions, or edge cases. For a destructive action, it would be helpful to say something like 'Use when a unit is no longer needed' or 'Permanently removes the unit and associated data.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds no behavioral context beyond restating the read operation. It does not disclose what happens if the absence is not found, any permission requirements, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and contains no fluff. Minor grammatical awkwardness ('Retrieving absence for employee with given absence id') prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complexity is low and the schema/annotations are sufficient for a basic safe read, but the description is minimal. With no output schema, it does not clarify what the returned absence record contains or edge-case behavior, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions, so the baseline is 3. The description adds a little semantic linkage by indicating the absence belongs to an employee, but it does not explain parameter formats, dependencies, or validation beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Retrieving' and identifies the resource 'absence' with the scope 'for employee with given absence id', making the operation clear. It distinguishes from sibling create/update/delete absence tools, though it does not explicitly state it returns a single record or contrast with list_employee_absence_in_years.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_absence_for_employee, update_absence, or list_employee_absence_in_years. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint, idempotentHint, and non-destructive behavior, the description adds no extra behavioral context. It simply states 'Fetch an additional address', repeating the tool's name without disclosing anything about return values, error handling, or authorization beyond what annotations already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, effectively front-loaded with no fluff. However, it is essentially a tautology of the tool name and title, providing minimal informational value despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with complete schema coverage and reassuring annotations, the description is minimally sufficient. Yet it lacks any mention of the relationship between the additional address and the contact, or what the response should contain, which would be helpful given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both required parameters with simple but clear descriptions, giving 100% schema coverage. The description adds no additional meaning to the parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and the resource 'an additional address', clearly indicating a read operation for a single address. However, it does not explicitly distinguish itself from siblings like list_additional_addresses or search_additional_addresses, though the name and required ID parameters imply a single-record get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives. There is no mention that list_additional_addresses or search_additional_addresses should be used for retrieving multiple addresses, nor any context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 known. The description adds no additional behavioral context beyond the annotations, such as what happens if the business year is not found or what the returned data represents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It is front-loaded, but it is minimal to the point of under-specification, which slightly reduces the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks context on the business year concept, return value, and relationship to list_business_years. Since there is no output schema, the description should compensate by explaining what is returned, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a clear description for business_year_id. The description adds no extra semantic detail beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a business year' uses a specific verb and resource, clearly indicating a retrieval operation. However, it does not differentiate from the sibling tool list_business_years or explain what a business year is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list_business_years exists, but the description does not mention it or any other selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description 'Show company profile' is consistent with the annotations (readOnlyHint=true, destructiveHint=false), but it adds no extra behavioral context such as expected return format, pagination, or auth requirements. With annotations already covering the safety profile, the description contributes nothing beyond what is already declared.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single short phrase 'Show company profile'. It is front-loaded and free of unnecessary words, which is good, but it may be too terse to convey full purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and clear annotations, but the description lacks context about when to use this tool instead of the sibling 'list_company_profiles'. It does not mention that it retrieves a single profile by ID, nor does it describe any behavior beyond the basic operation. This omission leaves a gap for users unfamiliar with the API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'profile_id' with a description ('the id of the company profile'), and schema description coverage is 100%. The tool description does not add any further parameter semantics; it merely says 'Show company profile' without referencing the parameter. The schema already provides the necessary meaning, so this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show company profile' uses a clear verb and resource, indicating a read operation to fetch a company profile. However, it does not differentiate itself from the sibling tool 'list_company_profiles', which likely lists multiple profiles, so it lacks explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of 'list_company_profiles' for retrieving all profiles, nor any prerequisites or context for using this tool. The user must infer from the tool name that it retrieves a single profile by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 need not restate safety. The description adds no behavioral context beyond what the annotations provide, such as return format or error conditions. It is consistent with annotations, so no contradiction, but it adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short at four words, which is concise but lacks any structuring. It is not verbose, but the brevity borders on under-specification rather than effective conciseness, as it provides no additional useful details beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the availability of sibling tools like list_contact_groups and search_contact_groups, the description does not explain when to use this tool for a single group by ID versus listing or searching. Without an output schema, the description also fails to mention what a successful fetch returns, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, with contact_group_id described as 'the id of the contact group'. The description adds no additional parameter meaning, so the baseline of 3 is appropriate because the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a contact group' clearly states the action and resource. It is not a tautology because 'fetch' adds a verb to the noun 'contact group', and the resource is distinct from siblings like get_contact or get_contact_relation. However, it does not differentiate itself from list_contact_groups or search_contact_groups, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like list_contact_groups or search_contact_groups. The description is a single sentence with no context about appropriate invocation, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide (readOnlyHint=true, idempotentHint=true, destructiveHint=false). It does not disclose return format, error behavior, or any side effects. It is consistent with the annotations but adds no value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is structurally simple and front-loaded, but it is also terse and could include a bit more context (e.g., what the return value is) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and strong annotations, the description is minimally adequate. However, it doesn't explain what a 'contact relation' is or what the response will contain, and since there is no output schema, the description carries more burden than it fulfills.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of the single parameter (contact_relation_id) with a clear description. The tool description adds no additional parameter semantics beyond what the schema already documents, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and resource ('contact relation'), making the purpose immediately obvious. It doesn't explicitly differentiate from sibling tools like get_contact or get_contact_group, but the resource name itself provides distinction. Lacks additional scoping context that would warrant a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_contact_relations or search_contact_relations. There is no mention of prerequisites, exclusions, or typical use cases, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond what the annotations already state (readOnlyHint=true, destructiveHint=false, idempotentHint=true). It simply restates the tool's name in sentence form without providing any additional context such as return behavior, error handling, or data format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words, making it efficient and easy to parse. It does not waste space, though it could include a bit more context without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and strong annotations, the description is minimally adequate. However, it does not mention what the response contains (e.g., country details) or what happens if the country_id does not exist, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter, country_id, with the description 'the id of the country'. The tool description adds no further semantic meaning, so the score is at baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a country' clearly states the action (fetch) and resource (country), making the tool's purpose immediately apparent. It distinguishes get_country from sibling tools like create_country, update_country, delete_country, list_countries, and search_countries, though it does not explicitly mention retrieval by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_countries or search_countries. It does not explain that this is for retrieving a single country by ID, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read nature is covered. The description adds no behavioral context such as error behavior or scope constraints, merely restating the action without enriching understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short, direct sentence with no filler words, making it efficient. However, its brevity sacrifices useful context, so it earns a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool requires three IDs and has a moderately specific purpose. While the schema and annotations provide structural context, the description leaves the concept of a 'default position' undefined and offers no return-value information. Still, for a simple getter with rich annotations, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptive schema entries with 100% coverage, so the schema carries the meaning. The description adds no additional parameter semantics beyond the schema, keeping the baseline at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'fetch' and identifies the resource as 'a default position', making the basic operation clear. However, it doesn't differentiate from sibling tools like list_default_positions or other position getters (e.g., get_discount_position), so it is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It doesn't mention that this retrieves a single position by ID, nor does it reference list_default_positions for multiple positions, offering no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint=false) already declare the safety profile, but the description adds no behavioral context beyond the basic fetch action. It does not mention return format, error behavior, or any side effects, so it adds no value beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and to the point, though it is terse enough that it could be mistaken for a tautology if not for the specific noun 'delivery'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter getter, the description is minimally viable. However, without an output schema, the agent might expect more detail about what the response contains or potential errors. The presence of annotations and the self-explanatory param mitigate the absence, but the description leaves gaps in return value and edge-case handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter semantics, with a clear description for 'delivery_id' ('the id of the delivery'). The description adds nothing about the parameter, so the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a delivery' states a clear verb and resource, indicating a retrieval operation for a single delivery. However, it does not explicitly differentiate itself from the sibling tool 'list_deliveries', which would provide the contrast between fetching one versus multiple records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_deliveries' or 'issue_delivery'. The description lacks any contextual cues about scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint=true and destructiveHint=false, the description itself adds no behavioral information beyond the basic action. It does not disclose what is returned, how errors are handled (e.g., if the position does not exist), or any side effects. The description carries no extra weight, so with the low bar set by annotations, this is still a minimal pass but lacks meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words, with no unnecessary padding. However, its brevity borders on under-specification, and adding a few words about the document context could improve clarity without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool requires three parameters and has no output schema, the description is far too sparse. It does not contextualize discount positions within quotes, orders, or invoices, nor does it explain that the tool depends on identifying a document. The agent would need to infer the purpose from the parameter names, which is risky, especially for a relatively specialized concept like a discount position.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all three parameters (kb_document_type, document_id, position_id) having descriptive text. The tool description itself adds no parameter-related meaning, but since the schema already explains the parameters, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and identifies the resource as 'a discount position', clearly indicating this tool retrieves a single discount position. However, it does not explicitly contrast with the sibling tool 'list_discount_positions', so the distinction between getting one vs many is implied by the name rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of alternatives like 'list_discount_positions' or other position getters. It does not state that it requires a document type, document ID, and position ID, nor does it mention any prerequisites or use cases. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no further behavioral context, such as what happens when no employee exists on the given date, whether historical data is returned, or any limitations. It simply restates the read-only nature already indicated by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words or repetition. It is efficient and front-loaded, though it could benefit from a slightly clearer phrasing to convey the historical-state nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two well-documented parameters and strong annotations covering safety. However, the description lacks an explicit statement about returning the employee state as of the date, and there is no output schema, so an agent might not fully understand the result semantics. The schema's date description partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described ('Id of an employee' and 'Date of employee's state'). The tool description does not add any extra meaning beyond the schema, but because the schema already provides adequate descriptions, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('a single employee') with a qualifier ('on a specific date'), which clearly distinguishes it from generic employee tools like get_employee. However, it does not explicitly explain that the date represents the employee's state as of that date, which is a key nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 get_employee or list_employees. The description neither mentions prerequisites nor excludes cases where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 safety profile is clear. However, the description adds no additional behavioral context, such as what the response contains, error behavior, or any side effects. It does not contradict annotations, but it also doesn't enrich them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
'Fetch an item' is extremely concise and front-loaded, with no wasted words. However, it is under-specified to the point of being terse, but since conciseness is about efficiency rather than completeness, it earns a high score for structure while lacking descriptive richness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 nested objects) and annotations cover safety, but there is no output schema. The description does not indicate what the fetch returns (e.g., full item details) or clarify what 'item' means in this domain. Given the large sibling list, the description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for article_id, stating 'the id of the item,' so the schema fully documents the parameter. The description 'Fetch an item' adds no further meaning beyond what the schema provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch an item' uses a clear verb ('fetch') and a resource ('item'), but the resource is generic and doesn't specify what kind of item. It does not distinguish itself from related tools like get_item_position or list_items, and is almost a restatement of the tool name 'get_item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that it fetches a single item by ID, nor does it reference sibling tools like search_items or list_items for other use cases. The context is entirely implied by the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. However, the description adds almost no behavioral detail beyond the verb 'fetch'—it does not clarify whether the tool returns file content, metadata, or a URL, nor does it explain how it differs from sibling download/get file operations. With openWorldHint=true, more context about how the file is referenced would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single phrase 'Fetch file of manual entry line'. Every word contributes to the core purpose, and there is no fluff. While it is terse, for a simple fetch operation with well-defined parameters, this level of brevity is acceptable, though slightly more specificity would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three required parameters and no output schema, so the description carries the burden of explaining return behavior. It does not state whether the result is the file binary, a download link, or metadata, nor does it differentiate from related file-retrieval tools in the sibling list. Given the existence of download_file and get_read_file, this lack of clarification leaves the agent guessing about the actual response and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (manual_entry_id, entry_id, file_id) having descriptions in the schema. The tool description itself adds no parameter-level detail, but since the schema fully documents each parameter, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch file of manual entry line' uses a specific verb (fetch) and names the resource (file of manual entry line), giving a clear idea of what the tool does. It is not a tautology and is distinguishable from immediate siblings like get_manual_compound_entry_file by the 'manual entry' scope, though the term 'manual entry line' is slightly unusual and could benefit from clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as download_file, get_read_file, or get_manual_compound_entry_file. The description gives no context about prerequisites, intended use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral traits beyond the annotations, which already declare readOnly, openWorld, idempotent, and non-destructive hints. It does not add context about return values, error behavior, or side effects. The annotations cover safety but the description adds no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, with no wasted content. It is front-loaded and easy to parse, though it is minimal to the point of being telegraphic. It earns a 4 because it avoids verbosity while still conveying the basic action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description should explain what is returned, but it does not. It also lacks context about how this differs from list_notes or search_notes, and does not mention error conditions or the nature of the fetched note. Given the simplicity, more context is needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter note_id with a clear description 'the id of the note'. The tool description itself does not add any additional semantic meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a note' clearly states a specific verb (fetch) and resource (note), making the tool's basic purpose evident. However, it does not include any scoping details or differentiate itself from sibling tools like get_task or get_bill, which follow the same pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as list_notes or search_notes. The description simply states what it does, not when it should be preferred or any exclusions. This leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint), the description adds no behavioral context. It does not disclose return format, error behavior (e.g., 404 if order not found), or that it fetches by ID. Annotations cover safety, but the description is purely explicit without additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded and appropriate for a simple get tool, but could include a bit more context (e.g., 'by ID') without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and existing annotations, the description is minimally adequate. However, there is no output schema and the description does not mention that the tool returns an order object or that it uniquely identifies the order via order_id. This leaves some context gaps, though the schema helps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with order_id described as 'the id of the order'. The description 'Fetch an order' adds no further meaning to the parameter, so it does not exceed the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch an order' clearly states the action (fetch) and resource (order), making the tool's purpose understandable. However, it does not differentiate from sibling tools like get_order_pdf or list_orders, as it lacks specifics about fetching a single order by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this retrieves a single order by ID, nor does it contrast with list_orders or search_orders. No usage context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds no additional behavioral context—such as return format (binary vs. URL), error handling, or generation behavior—so it barely adds value 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded. It states the action and scope efficiently, though it could be slightly more informative without becoming verbose, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 3 parameters and read-only annotations, so the schema handles much of the context. However, the absence of an output schema means the description should clarify whether the result is a file download, a link, or something else; it does not, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptive entries in the schema (year, month, employeeId), so schema coverage is 100%. The description adds no further meaning beyond what the schema already provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Retrieving' and specifies the resource 'pdf' with a clear scope ('for employee for given month'), making the core action unambiguous. However, it does not differentiate from other PDF retrieval tools like get_paystub_pdf or get_invoice_pdf, so it loses the sibling distinction point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or when to choose a different PDF retrieval tool, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds no extra behavioral context such as return format, authentication requirements, or potential edge cases, so it provides no value 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, but it is under-specified. While there is no wasted wording, it lacks substance and could easily be mistaken for a tautology, making it minimally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity with a single simple parameter and no output schema, and annotations cover safety. However, the description doesn't explain what a quote represents in this domain or what the response contains, leaving the agent to rely on schema and sibling names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter quote_id, which is sufficiently described. The description adds no further meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('quote'), making the action clear. It doesn't differentiate from siblings like get_quote_pdf or list_quotes, but it's a clear statement of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_quotes or search_quotes. There is no mention of prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context beyond the verb 'Fetch', such as the required document type, how the position is identified, or any side effects. Since it contributes nothing beyond the annotations, it falls short of the baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of only four words, with no filler. It front-loads the verb and resource. However, it is slightly too terse to be fully informative, which is why it doesn't earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with all parameters thoroughly described in the schema and annotations covering the operation's safety. There is no output schema, so the description could clarify the return value, but 'Fetch a sub position' reasonably implies the subposition object is returned. Missing context like the document type dependency is already in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; all three parameters (document_id, position_id, kb_document_type) have descriptive text explaining their meaning. The description itself provides no parameter information, but the schema fully documents them, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and identifies the resource 'a sub position', clearly indicating a read operation. It distinguishes from sibling tools like create_subposition, update_subposition, delete_subposition, and list_subposition_positions by implying a single-item fetch. However, it does not explicitly mention that subpositions are scoped to a quote, order, or invoice, which is essential context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention the existence of list_subposition_positions for fetching multiple subpositions, nor does it explain that this tool retrieves a single subposition by ID. There are no usage scenarios or exclusions given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds no behavioral context beyond the bare action. It does not describe return behavior, error handling, or permissions, and while it doesn't contradict annotations, it provides zero additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, front-loaded and free of fluff. However, it is borderline under-specified, which costs it a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite rich annotations and a simple schema, there is no output schema, and the description doesn't explain what a successful response contains or any error conditions. For a getter tool, more context about return structure or relationship to list/search would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage for the single task_id parameter, so the schema itself documents the parameter. The description adds no extra meaning beyond the schema, aligning with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Fetch a task'), clearly indicating a single-task retrieval operation. It doesn't explicitly mention 'by ID', but the required task_id parameter and name distinguish it from list_tasks and search_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives like list_tasks or search_tasks. The description gives no context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is a read-only, idempotent, non-destructive operation, and the description does not add any behavioral context beyond that. It does not disclose what the return payload looks like, whether any document-level qualification is needed, or any edge cases, so the description adds no transparency value 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at only four words, front-loading the core purpose without wasted sentences. While it lacks structural elements like examples or additional clauses, it is appropriately sized for a simple getter and earns its place, though it might be too terse to be fully helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns, but it does not. It also fails to provide any usage context beyond the schema. The tool seems relatively simple, but for a complete description, it should mention the return structure or how the position relates to documents, which is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have detailed descriptions in the input schema, covering the document type, document ID, and position ID. With 100% schema coverage, the description need not repeat parameter details, and it does not add any additional meaning. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a text position' clearly states the action (fetch) and the resource (text position), distinguishing it from other position-related tools like get_discount_position or get_item_position. However, it is quite minimal and does not elaborate on what a text position is, though the schema provides some context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as list_text_positions or other get_position tools. The description does not mention context, prerequisites, or when a user should prefer this tool, leaving the agent with no direction beyond the schema's required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide (readOnly, idempotent, non-destructive). It does not describe return values, error handling, or any other runtime behavior, though annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three words—with no wasted text. It is front-loaded and appropriately sized for a simple getter, though it sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with one parameter and full schema coverage, the description might be too minimal. It fails to clarify what a 'title' is (e.g., salutation, document title) and provides no context about the return value or typical use case, leaving ambiguity among many similar get_* tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter title_id with a description, so schema coverage is 100%. The description adds no additional parameter semantics, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a title' uses a specific verb ('fetch') and resource ('title'), clearly indicating this is a retrieval operation. However, it does not differentiate from the many sibling get_* tools (e.g., get_task, get_unit) and leaves 'title' ambiguous without context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention that it retrieves a single title by ID, nor does it reference any sibling tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context but is consistent with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and free of fluff, but it is so minimal that it barely contributes beyond the tool name. It is appropriately structured for a simple get, but could have added slightly more useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only operation, the annotations and schema cover much of the essential information. However, the description does not clarify what is returned or distinguish this user entity from related tools like get_fictional_user, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents user_id with 100% coverage, so the baseline of 3 applies. The description does not add any parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
"Fetch a user" states a clear action and resource, but lacks specifics about user type or scope. It does not differentiate from sibling tools like get_fictional_user or get_task, making the purpose only minimally clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_users or get_fictional_user. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral information beyond restating the tool's name, lacking details on pagination behavior, result ordering, or any special list semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words. It is concise, though it is also under-specified in terms of useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a simple paginated list tool, the description, schema, and annotations together are minimally adequate. However, there is no output schema and no description of return values, ordering, or list-specific behavior, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (limit and offset), so the schema fully documents their meaning. The description itself adds nothing about parameters, but the baseline of 3 applies since the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of calendar years' is a specific verb+resource phrase that clearly states the tool's function. However, it does not distinguish itself from sibling tools like 'search_calendar_years' or 'get_calendar_year', so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'search_calendar_years' or 'list_business_years'. There is no mention of exclusions, preconditions, or context where this specific listing tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so safety is covered. However, the description adds no behavioral context beyond the annotations—no mention of pagination, ordering, or that it returns all sectors. It is essentially a restatement of the tool name without additional insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and easy to parse, earning a high score for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with good annotations and schema, the description is minimal. Critically, it fails to mention that it returns all contact sectors without filtering, nor does it relate to the sibling 'search_contact_sectors'. This lack of context makes it incomplete for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters (limit, offset, order_by) with full descriptions, achieving 100% schema coverage. The description adds no parameter information, but the schema already handles this, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('contact sectors'), clearly indicating it returns a list. However, it does not differentiate from the sibling tool 'search_contact_sectors', which likely serves a similar but more filtered purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like search_contact_sectors. It neither states that this is for unfiltered listing nor excludes search scenarios, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already declare (readOnlyHint, idempotentHint). It does not mention pagination via limit/offset, the date filtering parameter, or any response shape, leaving agents without additional insight into how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It is appropriately terse, though this short length contributes to under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a very terse description, agents have no indication of what the returned list contains, how optional parameters affect results, or what distinguishes this listing from similar sibling tools. The presence of four optional parameters makes this lack of context particularly limiting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (date, embed, limit, offset) are already documented in the schema. The tool description adds no extra parameter semantics, which is acceptable given the high schema coverage, but no additional value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and resource ('a list of currencies'), making the core purpose understandable. However, it does not differentiate this tool from sibling tools like list_currencies_codes or list_exchange_rates_for_currencies, which may lead to confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many currency-related siblings. No mention of alternatives, exclusions, or specific scenarios where this list is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and destructiveHint false, so the description adds no further behavioral context. The description is redundant with the tool name and provides no additional details about what the list contains, ordering, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the main action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief to fully contextualize the tool. It does not mention that it lists reminders for a specific invoice, nor does it distinguish from similar list/search tools, and there is no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter invoice_id, so the description does not need to add parameter semantics. The description does not mention the parameter, but the schema covers it completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of reminders' clearly indicates a list operation, and the tool name specifies invoice reminders. However, it does not differentiate from sibling tools like search_reminders or get_invoice_reminder, and omits the invoice context in the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_reminders or get_invoice_reminder. There are no exclusions, prerequisites, or context about filtering by invoice_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds no extra behavioral context such as pagination behavior, ordering, authentication needs, or what data is returned. It relies entirely on structured fields for safety and operational information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is efficient, though minimal; a bit more detail would improve utility without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with only two optional pagination parameters and no output schema, the description is minimally sufficient. However, it doesn't clarify whether all notes are returned, what a 'note' includes, or default ordering, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has complete descriptions for both limit and offset parameters, achieving 100% coverage. The description doesn't add additional parameter semantics, so it remains at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Fetch' and the resource 'a list of notes', identifying it as a read operation. However, it doesn't distinguish this from sibling tools like search_notes or other list_* tools, lacking explicit scope such as 'all' or 'filtered'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use list_notes versus search_notes or get_note. The description provides no context about typical use cases, prerequisites, or alternatives, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, but the description adds no additional behavioral detail such as whether it returns all records, pagination behavior, or filtering limitations. It merely restates the action without enriching the agent's understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks crucial context: it does not clarify the distinction between list_payment_types and the sibling search_payment_types, nor does it explain the return value or typical use case. While the schema and annotations are thorough, the description leaves the agent without enough information to choose this tool confidently among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (limit, offset, order_by), so the baseline is 3. The description itself does not add any additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a list of payment types, which is a specific verb and resource. However, it does not distinguish this from the sibling tool search_payment_types, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like search_payment_types or other list tools. No context is given for selecting this over a search or filtering approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is known. The description adds no further behavioral context, such as pagination behavior, default ordering, or that it returns a list in chunks, and therefore adds no value beyond the annotations and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is easy to parse and front-loaded. It is appropriately concise for a simple list operation, though it could include a bit more substance without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a minimal description, the tool is only minimally complete. The schema covers parameters and annotations cover safety, but the description does not state what the response contains or that it supports pagination, which would be helpful for a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for limit, offset, and order_by with clear descriptions, including the max limit of 2000 and sort syntax. The tool description itself adds no additional parameter meaning, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Fetch' and identifies the resource 'purchase orders', which clearly aligns with the tool's name and distinguishes it from single-record operations like get_purchase_order. However, it lacks any scope qualifier (e.g., 'all', 'paginated') that would further clarify what kind of list is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is the sole listing tool for purchase orders, nor does it suggest using get_purchase_order for individual records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. However, the description adds no behavioral context such as whether default ordering or archived files are included, and it does not clarify what 'read files' means. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence with no wasted words. It is front-loaded and efficient, though it errs on the side of under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and three parameters, the description is too brief to be contextually complete. It fails to explain the return value, pagination behavior, or the specific meaning of 'read files' compared to other file-listing tools, leaving an agent uncertain about its suitability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter (offset, order_by, archived_state) clearly documented. The description itself adds no parameter semantics, but the baseline for high schema coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of files' clearly indicates a list operation with the verb 'fetch' and resource 'files', but it does not specify what distinguishes 'read files' from other file-related siblings like list_preview_files or search_files, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool over alternatives, no exclusions, and no context about the scope of 'read files'. With three file-related sibling tools, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent operation, so the description adds no behavioral context beyond what structured data provides. There is no mention of pagination, default limits, or what 'text positions' represent, offering no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundancy, which is efficient and front-loaded. However, it is so terse that it borders on under-specification, though conciseness itself is not penalized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good schema coverage and annotations, the description omits critical context: it doesn't mention that the tool requires a document type and ID, nor what 'text positions' are or how they relate to other position types. An agent must rely entirely on the schema to understand the tool's scope, making the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema comprehensively describes all parameters (100% coverage), including limit, offset, document_id, and kb_document_type. The description adds no parameter-level detail, but the schema fully carries the semantic load, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Fetch') and a resource ('text positions'), making the primary function understandable. However, it doesn't differentiate from sibling position-listing tools like list_discount_positions or list_item_positions, leaving 'text positions' vaguely defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, no mention of alternatives, and no context about document-specific scoping. It is a bare instruction without any decision-making support for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. However, the description adds no behavioral context beyond that—no mention of pagination behavior, default sorting, or what data is actually returned. It merely rephrases the tool name without revealing any additional behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence with no wasted words, which is good. However, it essentially restates the tool name ('list_timesheets' -> 'Fetch a list of timesheets') and adds no additional value, making it borderline under-specified. It is not verbose, but it also doesn't enrich the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with a well-documented schema, the description is minimally adequate. It lacks information about the default scope (e.g., all timesheets or only those in a certain status), which could matter for an agent. Given the tool's low complexity and the schema's thoroughness, a score of 3 reflects that it is sufficient but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all three parameters (limit, offset, order_by), so the schema carries the full burden of parameter semantics. The description adds no extra parameter context, but the baseline of 3 is appropriate when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and resource ('list of timesheets'), making the tool's core purpose unambiguous. However, it does not explicitly differentiate from the sibling tool 'search_timesheets', which could cause confusion about when to use a plain list versus a search. The verb 'Fetch' is specific enough to establish it returns a collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'search_timesheets' or 'get_timesheet'. The description simply states what the tool does, with no mention of use cases, prerequisites, or exclusions. An agent would have no contextual basis to choose this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the agent knows it's a safe read. The description offers no additional details on pagination, return format, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is efficient, but it's so minimal that it provides little beyond the tool name. It's concise but at the expense of useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with good annotations and full schema coverage, the description is adequate but incomplete. It does not describe the return value, and with no output schema, that information is missing. However, given the tool's simplicity, the gaps are not severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters with descriptions (limit max 2000, offset for skipping). The description does not add any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of vat periods' clearly states the tool retrieves multiple VAT periods. It distinguishes from the sibling 'get_vat_period' by using 'list', but does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like get_vat_period. The description only states what it does, without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotations. Annotations already declare the operation as read-only, open-world, idempotent, and non-destructive. The description does not mention pagination behavior, default limits, or any other side effects, missing an opportunity to add value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and directly stated in one sentence. It contains no redundant words or fluff, earning a solid score for efficiency, though it could add slightly more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal description, the agent is left without information about the return shape or content. The lack of usage guidance and behavioral details makes the description insufficient for a complete understanding, especially in a large sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters (limit, offset, project_id) with descriptions, so schema coverage is 100%. The tool description provides no additional parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Fetch') and resource ('list of work packages'). It clearly indicates what the tool does, though it does not explicitly distinguish itself from sibling tools like get_work_package or list_projects, which are also list/get operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to alternatives. There is no mention of exclusions, preconditions, or a preference over related tools such as get_work_package or search tools. This leaves the selection criteria entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond what annotations already convey. It does not disclose whether this operation triggers side effects like email dispatch, modifies timestamps, or requires specific permissions. Given the annotations indicate a non-read-only, non-idempotent operation, the agent has to guess the exact semantics of 'mark as sent'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single phrase with no filler. It is front-loaded and easy to parse, but it is so brief that it risks being under-informative, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simple interface (one parameter, no output schema), the surrounding context is complex with multiple invoice-related tools. The description does not clarify the difference between 'marking' and 'sending', nor the potential downstream effects, making it insufficient for confident invocation in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the only parameter, 'invoice_id', with a straightforward description. The tool description adds no additional parameter-level meaning, so the baseline score of 3 applies because the schema already carries the necessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark invoice as sent' uses a specific verb ('mark') and resource ('invoice') with the resulting state ('as sent'), making the core purpose clear. However, it does not differentiate this from sibling tools like 'send_invoice', 'issue_invoice', or 'mark_as_sent_invoice_reminder', which could have similar state-change effects on invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'send_invoice' or 'issue_invoice'. The description does not provide any context about the expected workflow or prerequisites, leaving the selection decision entirely to the model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint=false) and non-destructive, but the description adds no extra behavioral context. It does not mention the effect of marking, reversibility, or whether any notification is sent. It adds nothing 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded and efficient, though slightly under-specified for the reasons noted in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description is adequate but incomplete. It does not mention the return value, how it relates to sibling tools, or what 'sent' means in terms of side effects. Given no output schema and the presence of similar tools, more context is needed to fully understand the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for invoice_id and reminder_id, so the baseline is 3. The description adds no additional meaning beyond the schema, but it does not need to since the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark reminder as sent' clearly states the action and target resource. It distinguishes the 'mark as sent' operation from 'send' or 'unsend' actions, though it does not explicitly reference sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'send_invoice_reminder' or 'mark_as_unsent_invoice_reminder'. The description fails to specify whether this tool only updates status or also triggers sending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include readOnlyHint=false, destructiveHint=false, and idempotentHint=false, but the description adds no behavioral context about side effects, permissions, or what the operation does beyond the word 'Search'. It does not contradict the annotations but also does not disclose anything helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, front-loading the essential purpose. It could be slightly more detailed, but it is appropriately short and clear, earning a strong score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This 2-parameter tool lacks an output schema, and the description does not explain what the search returns, how the body parameter works with invoice_id, or what search criteria are supported. The description is too minimal to be contextually complete for an implementation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameters are already documented (invoice_id as 'the id of the invoice' and body as 'Request body as defined by the bexio API'). The description itself adds no extra parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search invoice reminders' states a clear verb and resource, indicating the tool's core purpose. However, it does not differentiate from sibling tools like list_invoice_reminders or get_invoice_reminder, which also deal with invoice reminders, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as list_invoice_reminders or search_invoices. The description does not mention any context, prerequisites, or the appropriate use case, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is a write operation (readOnlyHint=false), idempotent, and non-destructive, but the description adds no additional behavioral context. It does not explain what happens when status changes (e.g., locking effects of BOOKED) or any business rules, leaving the agent with incomplete information about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it merely restates the tool's purpose without adding meaningful information. It is not overlong, but the sentence does little to earn its place beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with a clear schema and annotations, the description is minimally sufficient. However, it lacks guidance on when to use this tool and any context about the bill booking workflow, leaving gaps for an agent to infer correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'id' and 'status' have descriptions, and the enum for status is provided. The description adds no param information beyond the schema, so it stays at the baseline of 3 for fully documented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('Bill status'), making it evident what the tool does. However, it does not distinguish itself from the sibling tool 'update_bill', which might also update bill fields, so it is specific but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like 'update_bill' or 'create_bill_action'. The schema implies usage (to change a bill's status to DRAFT or BOOKED), but no clear context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the agent knows it is a non-destructive write. The description adds no additional behavioral context, such as partial versus full update, required fields, or outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At six words, the description is highly concise and front-loaded. It wastes no words, though it may be too brief to be maximally useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sparse annotations, the description is under-specified. It does not mention return behavior, error conditions, or update semantics, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are documented in the schema. The description adds no parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update existing file' clearly identifies the action (update) and resource (file), distinguishing it from create/delete/get/list siblings. However, it lacks detail on which fields or scope, so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of related file tools (create_file_file, delete_file, etc.) or any prerequisites. The single sentence offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context beyond 'edit'. It does not disclose whether the tool performs a partial update (only changing provided fields) or a full replacement, what happens to omitted optional fields, or whether the milestone must already exist. The description carries no extra value over 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, 'Edit a milestone', which is extremely concise and free of unnecessary words. It earns its place as a clear purpose statement, though it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, a missing output schema, and limited annotations, the description is insufficient. It does not clarify update semantics such as whether the 'name' field is always required, whether omitted optional fields are retained or cleared, or what the tool returns. The schema covers parameter meanings but not the behavioral context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter semantics, but the schema already provides clear descriptions for each field (e.g., 'name' is the name, 'end_date' is the end date). No additional meaning is needed beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a milestone' clearly states the verb (edit) and resource (milestone), distinguishing it from sibling tools like create_milestone, delete_milestone, get_milestone, and list_milestones. It is concise and unambiguous, though it lacks additional scope details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., milestone must exist), nor does it reference create_milestone for new milestones or get_milestone for reading before updating. No exclusions or contextual hints are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. It does not mention side effects, preconditions (e.g., position must exist), what happens if the pagebreak field is omitted, or any return value. Annotations indicate readOnlyHint=false and destructiveHint=false, but the description itself is silent on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence with no wasted words. It is front-loaded but adds little beyond the tool name. It earns a decent score for conciseness, though it is somewhat under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool without an output schema, this description is too sparse. It fails to explain what 'edit' changes, what response to expect, or any prerequisites. Given the complexity of the domain (pagebreak positions on documents), the description is not complete enough for an agent to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes 3 of 4 parameters (75% coverage). The description itself provides no parameter information. Since schema coverage is reasonably high and the one undocumented parameter (pagebreak) is optional, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a pagebreak position' uses a specific verb (Edit) and resource (pagebreak position), clearly indicating an update operation. This distinguishes it from sibling tools like create_pagebreak_position, delete_pagebreak_position, get_pagebreak_position, and list_pagebreak_positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The verb 'Edit' implies modifying an existing pagebreak position, but this is only implicit and no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds no additional behavioral context, such as whether unspecified fields are preserved, required permissions, or return value. It just restates the obvious 'update' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant information. It front-loads the action and resource, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 40 parameters, nested objects, and no output schema, the one-sentence description is severely lacking. It gives no operational context, no common use cases, and no indication of input expectations beyond the schema itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 40 parameters and 57% schema coverage, the description provides no additional meaning for any parameter. It does not mention which fields are updatable, how to identify the purchase order, or any relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Update' and the resource 'purchase order', distinguishing it from create, delete, get, and list sibling tools. 'Single' clarifies that it operates on one purchase order at a time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_purchase_order or update_quote. It simply states the operation without any context on prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this is a write operation (readOnlyHint=false) and non-destructive. The description adds no further behavioral context, such as which fields are modified or whether an existing title is required, so it provides no value 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient. However, it is under-specified and nearly duplicates the annotation title 'Update Title', so it does not add enough informational value to fully justify its presence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with two parameters and no output schema, the description still lacks essential context such as return value, prerequisites (e.g., existing title), or side effects. Annotations provide some transparency, but the description is too minimal to give a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 50% (only title_id is described), the description could have clarified the 'name' parameter but does not. It offers no parameter-level explanation, leaving the semantics of 'name' and 'title_id' to be inferred from the schema and tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit a title' clearly specifies the action (edit) and resource (title), distinguishing it from sibling tools like create_title, delete_title, get_title, list_titles, and search_titles. It is not a tautology because it uses a specific verb rather than repeating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as the title existing, or contrast with create_title or delete_title, leaving the usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide (readOnlyHint: false, destructiveHint: false). It does not mention file replacement behavior, upload constraints, or any side effects, leaving the agent to infer the tool's behavior solely from the name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and target. It contains no filler, but it is minimal to the point of being terse, which keeps it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter upload tool, the description covers the core purpose, but it lacks context about the relationship between manual compound entries and manual entries, file constraints, or how the fileName array should be used. The absence of an output schema reduces the need for return-value documentation, but the missing usage nuances leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions for both fileName (array of strings) and manual_entry_id (integer). The tool description adds no additional parameter semantics, so it meets the baseline for high schema coverage without enriching meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add file to manual compound entry' uses a specific verb (Add) and resource (file) with a clear target (manual compound entry), which is distinct from the sibling 'upload_manual_entry_file_file'. However, it does not explicitly contrast with alternatives, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like upload_manual_entry_file_file, nor any prerequisites or conditions. The only implied usage is from the description itself, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. It does not disclose whether the file is attached to the header or line item, whether existing files are replaced, how uploads are processed, or any side effects. The annotations (readOnlyHint=false, destructiveHint=false) already indicate a non-read, non-destructive mutation, but the description contributes nothing further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. However, it is slightly under-specified, so while concise, it could be improved by adding a few words to clarify the operation without becoming wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema, the description is too sparse to be contextually complete. It does not explain what the endpoint returns, how the manual_entry_id and entry_id relate to the 'manual entry line', or what the expected behavior is after adding the file. The schema covers parameters but the overall operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its three parameters, so the heavy lifting is done there. The description does not add any parameter-level meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add file to manual entry line' uses a specific verb (Add) and resource (file) and identifies the target (manual entry line). It is clear but does not differentiate from the similarly named sibling tool 'upload_manual_compound_entry_file_file', which suggests a related but distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention when to prefer this over upload_manual_compound_entry_file_file or create_file_file, nor does it provide context on prerequisites or expected usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide (readOnlyHint=false, destructiveHint=false). It doesn't disclose side effects like whether the quote is marked as invoiced, or any permission requirements. With such a minimal description, the agent learns nothing new about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, essentially restating the tool name. While there is no wasted text, it also provides no additional structure or detail, making it minimally acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates an invoice from a quote, the description is incomplete. It doesn't explain the relationship with the quote, any prerequisites (e.g., quote must be in a certain state), or the resulting invoice behavior. The openWorldHint and lack of output schema increase the need for richer context, which is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters (quote_id and positions), including a note about omitting positions to copy all from the source. Since schema coverage is 100%, the description doesn't need to add parameter details, and it correctly doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create') and the resource ('invoice from quote'), making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like create_invoice and create_invoice_from_order by specifying the source as a quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_invoice or create_invoice_from_order. The description fails to mention any context, prerequisites, or exclusions that would help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates the tool's purpose and adds no behavioral context beyond annotations. While annotations declare destructiveHint=true and readOnlyHint=false, the description does not disclose whether deletion is permanent, cascading, or has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is perfectly concise for the simple action it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of destructiveHint and openWorldHint, the description is minimal but lacks critical context about the deletion's impact, such as whether it is reversible, if related items are affected, or any restrictions. The tool is too thin to be fully complete for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the sole parameter invoice_id, achieving 100% coverage. The description contributes no additional parameter meaning, so it meets the baseline for schema-rich tools without raising the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('an invoice'), clearly distinguishing it from sibling tools like create_invoice, get_invoice, or update_invoice. It precisely states the action performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as cancel_invoice or issue_invoice. It does not mention acceptable use cases, prerequisites, or scenarios where deletion is not recommended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-destructive operation, and the description confirms the write action. However, it discloses no additional behavioral details such as required permissions, validation rules, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that is front-loaded and contains no irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters and no output schema, the description is insufficient. It provides no context on parameter semantics, expected inputs, or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25%, with descriptions for only reason and employeeId. The tool description does not explain any of the parameters, especially the optional fields like end_date, half_day, disability, paid_hours, and continued_pay, nor the required start_date.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('create') and resource ('absence') and clearly differentiates from sibling tools like delete_absence, update_absence, and get_absence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any context on prerequisites or exceptions. The action is self-evident but there is no explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds no extra behavioral context. It does not mention permissions, potential file system side effects, or return behavior, leaving the agent without additional insight beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Create new file'), with no wasted words and the key information front-loaded. It earns its place by stating the essential operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description could be minimal. However, it lacks clarification on whether parent directories are created, whether existing files are overwritten, or what success/error responses look like, leaving moderate gaps for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the only parameter 'file' as 'Input path to file', which is clear and covers 100% of parameters. The description adds no semantic detail beyond the schema, but the high schema coverage justifies the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action 'Create' and the resource 'new file', which is clear and specific. It does not differentiate from sibling file operations like update_file or upload_manual_entry_file_file, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update_file, delete_file, or upload_manual_entry_file_file. The intended usage is implied only by the verb 'create', with no exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the action itself. It doesn't mention side effects on the source order, whether the invoice is created as draft or issued, or any other consequences. Annotations only indicate it's a non-read-only, non-idempotent operation, so the description carries the burden for transparency but doesn't fulfill it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. However, it is somewhat under-specified for the complexity of the operation, so it doesn't earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Creating an invoice from an order is a workflow with significant context (e.g., order status, position copying, invoice numbering). The description provides none of this and there is no output schema. It is too minimal for an agent to understand the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both order_id and positions. The description adds no additional parameter meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an invoice sourced from an order. It distinguishes from siblings like create_invoice (standalone) and create_invoice_from_quote (from quote) by specifying the source document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_invoice or create_invoice_from_quote. The description lacks any context about prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds no further behavioral context beyond confirming a create operation, which is consistent with the annotations. There is no contradiction, but also no added disclosure about permissions, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short, front-loaded single sentence with no wasted words. It is appropriately concise for a title-like summary, though it adds little beyond what the tool name already implies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 34 parameters and no output schema, the description is insufficient. It does not explain the overall purpose in the payment workflow, what the response looks like, or how it differs from related tools like create_payment. The rich schema helps with parameter selection but cannot replace missing high-level context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, providing detailed descriptions for all 34 parameters. The tool description itself contributes no additional parameter-level meaning, so the baseline of 3 is appropriate because the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create') on a specific resource ('Outgoing Payment'), which is clear and direct. However, it does not explicitly distinguish this from sibling tools like create_payment or update_outgoing_payment, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no preconditions, and no exclusion criteria. The schema provides parameter constraints, but that does not constitute usage guidelines for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. However, the description adds no extra behavioral context such as whether deletion is permanent, cascading, or if there are restrictions on which bills can be deleted. The openWorldHint suggests potential side effects, but the description does not explain them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, minimal sentence that conveys the purpose without any fluff. It is appropriately sized for a simple tool, front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and clear annotations, so the description plus schema cover the basics. However, the openWorldHint and destructive nature could benefit from additional context about side effects or constraints, which is absent. It is adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains a description for the 'id' parameter ('id of Bill to delete'), giving 100% schema description coverage. The description adds nothing beyond this, so a baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete Bill' clearly states the verb 'Delete' and the resource 'Bill', which is specific enough to understand the tool's function. It distinguishes from sibling tools by naming the resource type, though it does not add any additional nuance beyond the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as cancel_invoice or delete_purchase_order. No context, prerequisites, or exclusions are provided, leaving the agent to infer usage only from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. Annotations already declare destructiveHint=true, but the description does not elaborate on consequences such as irreversible deletion, cascade effects, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose. It does not waste words, though it could potentially add a brief note on usage or side effects without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation, the description is extremely minimal. While the schema and annotations cover the basic parameter and safety profile, there is no explanation of what happens when a currency is deleted, such as effects on dependent records or whether the action can be undone. More context would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the only parameter, currency_id, with its own description. The tool description adds nothing extra about parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Delete a currency" uses a specific verb and resource, clearly distinguishing it from sibling tools like update_currency, get_currency, and list_currencies. It states exactly what the tool does with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites, restrictions, or conditions for deletion. The description does not mention potential dependencies or scenarios where deletion would be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description aligns with that. The description adds no extra detail about side effects, permanence, or constraints. Since annotations cover the safety profile, there is no contradiction, but no added behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with the action verb, but it is grammatically awkward ('a item') and lacks any supporting detail. It is concise but under-specified for a destructive operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with rich schema and annotations, the description is minimally sufficient. However, it lacks any explanation of what an item position is or the document types it applies to (which the schema provides), and no output/return behavior is noted, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, including a helpful example for document_id and an enum explanation for kb_document_type. The description itself adds no parameter-specific meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Delete' and clearly identifies the resource as 'item position', making the core action unambiguous. It does not, however, distinguish this from sibling position-deletion tools like delete_subposition or delete_default_position, nor does it specify the document context beyond the schema enum.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention that item positions belong to quotes/orders/invoices (that's only in the schema) or when a delete_subposition would be more appropriate. There are no usage contextual cues in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds that only the connection is deleted, not the file or entry, which is useful. However, it does not mention idempotence or any side effects, leaving the idempotentHint=true unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the action. It contains no redundant words and conveys the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple deletion tool with no output schema, the description is adequate but leaves gaps. It does not disambiguate from the nearly identical sibling 'delete_manual_entry_file', nor does it address the schema's file_id description error. The context around compound vs regular entries is undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters, but the description for file_id is erroneous ('the id of the currency'), and the tool description does not correct this or clarify that manual_entry_id refers to a compound entry. The simple names are self-explanatory, but the misleading schema text and lack of clarification reduce the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource as the 'connection between file and manual compound entry'. This distinguishes it from deleting the entry or file themselves, though the potential confusion with the sibling tool 'delete_manual_entry_file' is not fully resolved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'delete_manual_entry_file' or 'delete_manual_entry'. There are no exclusions, prerequisites, or context about the difference between manual entry files and manual compound entry files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write operation. The description adds no additional behavioral context, such as irreversibility, permission requirements, or side effects like cascading deletes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it borders on under-specification. While it is concise, it does not offer any added value beyond the tool name, making it minimally adequate rather than well-crafted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description is technically sufficient, but it lacks any usage context or elaboration on consequences. Given the destructive nature, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description ('the id of the manual_entry'). The description adds no extra parameter information beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the specific resource 'manual entry', distinguishing it from sibling tools like delete_manual_entry_file or delete_absence. It is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool vs alternatives, such as updating a manual entry or deleting related files. The description only states the action with no context about prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. However, the description adds no extra behavioral context, such as whether the deletion is permanent, what happens to related data, or any authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence, 'Delete an order', that is immediately understandable and contains no filler. It is appropriately sized for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, annotations covering destructive behavior), the description is minimally sufficient. However, it lacks explicit details about the consequences of deletion and does not clarify the exact type of 'order', which could be ambiguous alongside similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter order_id with a clear description ('the id of the order'), and schema description coverage is 100%. The description does not add additional parameter semantics, but none are necessary given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Delete') and a resource ('an order'), making the tool's purpose evident. However, it does not differentiate among the many order-related tools in the sibling list (e.g., delete_purchase_order, delete_order_repetition), so it is not fully distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, conditions, or alternative tools such as delete_order_repetition or delete_purchase_order, which leaves the agent without decision-support information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description 'Delete a quote' adds no additional behavioral context beyond the literal action, such as permanence, cascading effects, or error conditions. It neither contradicts nor enriches 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of four words with no unnecessary wording. It is front-loaded and efficient, though it may be under-specified, it earns its place as a clear summary for a simple one-parameter delete tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive action, the description lacks information about side effects, required preconditions (e.g., quote status), or consequences for related documents. It relies entirely on annotations for safety context, leaving significant gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the sole parameter quote_id as 'the id of the quote' with 100% coverage. The description adds nothing about the parameter's semantics, constraints, or usage, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a quote' uses a specific verb and resource, clearly distinguishing it from other quote-related tools like create_quote, update_quote, or list_quotes. It is unambiguous and immediately conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as updating a quote's status instead of deleting it. There is no mention of prerequisites, contexts, or exclusions, leaving the selection criteria entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotations. Annotations already declare destructiveHint=true and readOnlyHint=false, but the description does not add context about irreversibility, potential errors, or whether deletion cascades. It simply restates the action without enhancing the agent's understanding of consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Delete a tax'. It contains no filler or redundancy and is front-loaded with the action and object. For such a simple tool, this level of brevity is appropriate and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the annotations covering destructive behavior, the description is minimally viable. However, it lacks any mention of return value, failure conditions, or side effects beyond what annotations imply, leaving some gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the only parameter (tax_id as 'the id of the tax'), giving 100% schema description coverage. The description adds no additional semantic nuance about the parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a tax' clearly states the action (delete) and the resource (tax), distinguishing it from sibling delete tools by resource name. However, it does not add any scoping or additional qualifiers, so it lacks the extra differentiation seen in higher-scoring examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or exclusions. The description does not mention any context such as 'use to remove a tax that is no longer needed' or direct users to get_tax/list_taxes for reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint and idempotentHint, but the description adds no additional behavioral context such as permanence, side effects on related data, or permission requirements. It simply restates the action with no extra nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly and fully states the tool's purpose. There is zero wasted wording, and it is appropriately brief for a straightforward delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two clear parameters and annotations covering destructiveness, the description is minimally sufficient. However, it omits any mention of effects on associated records, return values, or whether deletion is permanent beyond what annotations imply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both package_id and project_id clearly described in the schema. The tool description adds no extra meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a work package' explicitly states the action and target resource, making the tool's purpose clear. It distinguishes from siblings by naming 'work package' as the object, though it does not explicitly contrast with other delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, any prerequisites, or conditions under which deletion should be applied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds no additional behavioral context, such as the structure of the returned position, error conditions, or document-type handling. It simply restates the fetch action without disclosing any traits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant phrasing. It front-loads the action and object, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the concise description, the tool's purpose is reasonably inferable from the name and schema. However, the description lacks any exposition about return values or the relationship between the three required parameters beyond what the schema already provides. With no output schema, a bit more context about what a subtotal position represents would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (kb_document_type, document_id, position_id) are fully described in the schema with examples and domain-specific notes. The description itself adds no parameter-level details, but since the schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' with the resource 'a subtotal position', clearly identifying the operation as a read of a single subtotal position. It distinguishes itself from list_subtotal_positions by singular scope, but does not explicitly contrast with other position getters like get_subposition, leaving some ambiguity about the exact entity type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as list_subtotal_positions or get_item_position. There are no usage contexts, exclusions, or references to related tools, leaving the agent to infer applicability solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints, so the safety profile is covered. However, the description adds no further behavioral context such as error handling, return format, or authorization requirements, which are not provided elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no redundant words or information. It is appropriately sized for a simple get-by-ID operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema plus annotations cover the essential details. However, without an output schema or any description of what a timesheet entails, the return value and typical use remain somewhat opaque. The description is adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with timesheet_id described as 'the id of the timesheet'. The description adds no additional meaning beyond this, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a timesheet' clearly indicates a single-resource retrieval operation, distinguishing it from list/search alternatives. However, it doesn't explicitly differentiate itself from sibling get_* tools or state that it operates by ID, though the schema implies this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus list_timesheets or search_timesheets. The description is purely imperative and offers no context about use cases, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation safe (readOnlyHint, idempotentHint, openWorldHint, non-destructive). The description adds no extra behavioral context beyond these annotations, such as pagination behavior, ordering, or whether it returns all accounts by default. It is a minimal statement that doesn't enhance understanding of side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the action and resource with no redundant or unnecessary information. It is well-structured and direct, maximizing clarity with minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with full schema coverage and safety annotations, the description is adequate. However, it lacks any mention of return format, whether pagination is required, or when a search might be more appropriate. Given no output schema exists, some additional context would help, but the tool is straightforward enough that this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (limit and offset) with descriptive text, providing 100% coverage. The description doesn't add any parameter semantics beyond what the schema already offers, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Fetch') and resource ('accounts'), making the operation unambiguous. However, it doesn't explicitly differentiate from sibling tools like search_accounts or list_account_groups, though the use of 'list' implies a full collection rather than a filtered search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as search_accounts or list_account_groups. The description gives no usage context or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds no behavioral context beyond a literal restatement of the tool's name and title; it does not disclose pagination behavior, filter semantics, or response format. Consequently, it offers no additional value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is immediately understandable and contains no filler. It is appropriately sized for a straightforward list operation, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the schema captures parameter details. However, without an output schema and with a minimal description, there is little explanation of what 'all payments' includes or how it relates to other payment list tools. The description is sufficient for a basic understanding but lacks context to fully disambiguate from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (page, per-page, filter-by) are fully described in the schema, so schema coverage is 100%. The description does not mention or elaborate on any parameters, so it adds nothing 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of all payments' uses a clear verb 'Fetch' and identifies the resource 'all payments', making the basic purpose obvious. However, it does not explicitly distinguish this from sibling tools like list_invoice_payments or list_outgoing_payments, leaving some ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given the presence of sibling tools such as list_invoice_payments and list_outgoing_payments, the description does not explain which situations call for list_all_payments. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide (readOnlyHint, idempotentHint, destructiveHint). It does not mention whether the list is scoped to the current user, how pagination works, or any ordering/filtering behavior, which would be useful for invoking the tool correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It front-loads the action and resource, making it easy to parse, though it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with optional limit/offset, the description is minimally adequate, but it lacks information about how it differs from similar tools and does not mention pagination behavior or the scope of the list. Given that the annotations and schema are rich, the description satisfies the basic requirement but leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (limit and offset) with clear descriptions, and the description itself does not add any additional meaning. With 100% schema coverage, the baseline of 3 applies, and the description offers no extra parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and identifies the resource 'a list of bank accounts', clearly stating the tool's function. However, it does not distinguish itself from sibling tools like list_accounts or search_accounts, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 search_accounts or list_accounts. The description provides no context about use cases, prerequisites, or exclusions, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, which cover the safety profile. The description adds no extra behavioral context beyond stating it fetches a list, so it does not conflict with annotations. Without annotations this would be insufficient, but here the structured data carries most of the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately front-loaded. However, it is slightly underwhelming in content, though conciseness itself is not compromised.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 optional params) and rich annotations/schema, the description is too thin to be fully complete. It does not explain what a business activity is, how to iterate over large result sets, or how this differs from `search_business_activities`. The openWorldHint is also unexplained, leaving the agent without critical context for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters (limit, offset, order_by) are well-documented in the schema. The description does not add any additional meaning or context about these parameters. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool fetches a list of business activities using a specific verb and resource. However, it does not differentiate from the sibling tool `search_business_activities`, which likely serves a similar listing purpose with filtering. The name helps, but the description alone could be more explicit about scope (e.g., 'all business activities').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus `search_business_activities` or other list/search variants. There is no mention of alternatives, prerequisites, or typical use cases. The agent is left to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond 'Fetch a list', such as pagination behavior, result format, or any side effects. It does not contradict the annotations, but it fails to add value beyond what annotations and schema already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. It contains no unnecessary words and is appropriately sized for a simple list endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three optional parameters and strong annotations. However, the description does not mention what a 'communication type' is, whether the result is paginated, or how it differs from the search variant. Given no output schema, a bit more context would be helpful, but the current description is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage of the three parameters (limit, offset, order_by) with clear descriptions. The tool description adds no parameter-specific information beyond what the schema already provides. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('list of communication types'), clearly stating what the tool does. However, it does not differentiate from the sibling tool 'search_communication_types', which could perform a similar function. The name itself hints at the distinction, but the description does not explicitly clarify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the alternative 'search_communication_types' or other list tools. The description only states the basic action without any context about typical use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 safety profile is covered. However, the description adds no behavioral context beyond 'fetching a list'—no mention of pagination defaults, archive inclusion behavior, or ordering specifics. It fails to disclose any traits beyond what the annotations and schema already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the action and object. It contains no unnecessary words or filler, making it highly succinct and perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the schema documents all parameters and the annotations cover safety, making the tool usable. However, the description omits differentiating context from search_contacts, and with no output schema, it does not explain the return structure or default pagination. The definition is adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters (limit, offset, order_by, show_archived) have detailed schema descriptions covering their semantics, giving 100% schema coverage. The description 'Fetch a list of contacts' adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of contacts' clearly specifies a verb and resource, indicating the tool retrieves a collection of contacts. However, it does not distinguish this from the sibling 'search_contacts' tool, which likely also returns contacts, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'search_contacts' or 'get_contact'. There is no mention of scenarios like listing all contacts versus searching with filters, leaving the agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no behavioral details such as pagination behavior, filtering, or return format, offering nothing beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant information. It is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, the schema and annotations cover most needs. However, the description lacks guidance on usage context and return value expectations, making it viable but not fully complete for an agent deciding between sibling position tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema (100% coverage), so the description need not repeat them. The description does not add any parameter context, but the schema already explains that document_id is tied to the selected kb_document_type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch a list') and resource ('default positions'), clearly distinguishing it from sibling list tools like list_discount_positions or list_item_positions by the resource type. However, it doesn't define what a default position is, relying on the schema to explain the document context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not state when to use this tool versus list_discount_positions or other position list tools, nor does it mention the requirement to specify a document type and ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive, but the description adds no additional behavioral context such as pagination behavior or result scope. It essentially restates the tool's name without enriching 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero redundancy. It is appropriately sized for a straightforward list operation, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with optional parameters and strong annotations, the description is minimally adequate. However, it lacks any mention of return shape, filtering scope, or relationship to other delivery tools, leaving some context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters with descriptions, so the schema carries the burden. The description adds no parameter-specific meaning, maintaining the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fetch a list of deliveries' with a specific verb and resource. It clearly indicates the tool lists delivery entities, but it does not explicitly differentiate from siblings like get_delivery, relying on the name for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_delivery for a single delivery or other list tools. The description only states the basic action without context on appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already declare (readOnlyHint=true, destructiveHint=false, idempotentHint=true). It does not disclose that the list is filtered by a specific document or that pagination parameters (limit/offset) control the result size. With annotations covering the safety profile, the description offers minimal additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no redundant words or fluff. It is appropriately sized for a simple list operation, and it is immediately front-loaded with the action and object. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but functional. The schema provides detailed parameter contexts (e.g., document types, ID usage) and annotations declare safe read behavior, so those are covered. However, the description alone does not convey that the list is scoped to a document or that required parameters are necessary, which could lead to confusion if the schema is not consulted. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully described in the schema (100% coverage), so the description need not repeat them. The description itself adds no parameter-level meaning, but the baseline of 3 is appropriate since the schema does the heavy lifting. No explicit parameter insight is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('a list of discount positions'), clearly identifying the tool's function. It distinguishes from sibling position tools (e.g., list_item_positions, list_subtotal_positions) through the 'discount' qualifier, though it does not explicitly mention the document-scoped nature (required by the schema).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of required parameters (kb_document_type, document_id), nor any comparison to get_discount_position or other list tools. The description is purely a statement of function without contextual usage directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, informing the agent of the safe read-only nature. The description adds no extra behavioral context beyond the annotations, such as return format or rate limits, which is acceptable given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is shorter than ideal but still effectively communicates the core purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal description, the agent is left uninformed about the return value structure, whether the result is a list of rates or a single rate, and how the 'date' parameter affects the output. The annotations cover safety but not functional completeness, so the description is inadequate for a tool with two parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as both 'date' and 'currency_id' have descriptions in the input schema. The description adds no additional meaning about the parameters, so it does not compensate beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch exchange rates for currencies' clearly states the action and resource. It distinguishes itself from sibling tools like 'list_currencies' and 'get_currency' by focusing on exchange rates, though it doesn't mention the required currency_id parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention that it requires a currency_id and optional date, nor does it exclude use cases or suggest sibling tools. This falls short of implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description adds no behavioral details beyond what is structurally available. It does not mention pagination defaults, return format, or any scoping constraints, failing to provide extra 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and direct sentence with no wasted words. It conveys the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with comprehensive annotations and parameter schema, the description is minimally sufficient. However, given the existence of 'search_invoices', a note about when to use this tool versus the search alternative would have improved completeness. The lack of such context holds it back from a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of the parameters (limit, offset, order_by) with detailed explanations, including the max limit and sort syntax. The description itself adds no parameter-specific meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and names the resource 'invoices', clearly indicating the tool retrieves a list of invoices. However, it does not differentiate from the sibling 'search_invoices', which also returns invoice lists, so it misses the 5-point criterion of distinguishing from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_invoices' or other list operations. It lacks any context for selection, exclusions, or prerequisites, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 known. The description adds no additional behavioral context, such as pagination behavior or result scope, beyond what the schema already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is appropriately front-loaded and wastes no words, though it is under-specified in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with schema and annotations covering parameters and safety, the description is minimal but not entirely inadequate. However, it fails to mention alternative tools or the scope of the list, so it's not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (limit, offset, order_by) having descriptions. The description itself adds no additional parameter information, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' with resource 'languages', clearly indicating a read operation that retrieves languages. However, it doesn't distinguish from sibling 'search_languages', so it's clear but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search_languages. The description does not mention pagination, filtering, or any context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context such as pagination implications or project-scoping, but it also does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. However, it is slightly under-specified given that project_id is required and pagination parameters exist, so it is not maximally effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with rich annotations and full schema coverage, the description is adequate but not complete. It does not mention that milestones are scoped to a project or describe the return value, though these are somewhat implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters (limit, offset, project_id) described in the schema. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('fetch') and specific resource ('list of milestones'), making its purpose evident. It subtly distinguishes from the sibling 'get_milestone' (single vs. list), but does not mention the required project scope, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description simply states what it does without indicating that it is for listing milestones in a project or that 'get_milestone' should be used for a single milestone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds no additional behavioral context. It only restates the read-only nature ('fetch') and provides no details about pagination behavior, result ordering, or any other runtime characteristics beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence 'Fetch a list of orders' with no unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to quickly parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with an empty required-parameter set and a clear schema. However, the description lacks any mention of when to use 'list' over 'search' (given the sibling 'search_orders'), and it does not explain the scope of the listing (e.g., all orders vs. filtered). This leaves a notable gap in context for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (limit, offset, order_by) have descriptions in the schema, providing 100% coverage. The description itself does not add any parameter semantics, but the schema already fully documents the parameters, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of orders' clearly states the action (fetch) and resource (orders), making it a specific verb+resource combination. However, it does not differentiate from the sibling tool 'search_orders', which likely serves a similar purpose with more filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'search_orders'. The description does not mention pagination, recommended use cases, or any exclusions. This leaves the agent without context for selecting the correct tool among many list/search siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds no additional behavioral context such as pagination behavior, default limit, or relationship to other outputs; it simply restates the list action without enriching the agent's understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no unnecessary text. It is appropriately sized for a simple list operation and front-loads the essential verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with good annotations and schema coverage, the description is minimally adequate. However, it lacks any usage guidance, such as distinguishing when to use this vs 'search_salutations', and does not mention any caveats about the returned data. This is a clear gap for a tool that could potentially be confused with a search variant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, with clear descriptions for 'limit' (max 2000) and 'offset' (skip over elements). The tool description does not add any extra meaning about parameters beyond the schema, so it meets the baseline expected for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of salutations' clearly identifies the action (fetch) and resource (salutations), making the tool's purpose obvious. However, it does not differentiate from sibling tools like 'search_salutations' or provide any scope details such as whether it returns all salutations or paginated results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_salutations' or 'get_salutation'. There is no mention of use cases, exclusions, prerequisites, or scenarios where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context (e.g., pagination behavior, default ordering, or constraints) beyond restating the action 'Fetch'. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, clearly front-loaded with the action and resource. It is appropriately concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with three optional parameters, the description is adequate but thin. Since there is no output schema, it does not explain the return structure, and it does not distinguish from search_stock_areas. However, the core purpose is clear enough for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes all three parameters (limit, offset, order_by) with 100% coverage. The description adds no extra meaning to these parameters, so it meets the baseline without enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and clearly identifies the resource ('list of stock areas'). It is straightforward but does not explicitly differentiate from sibling tools like 'search_stock_areas' or 'list_stock_locations'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_stock_areas. It only states what it does, not when it should be preferred or what scenarios it is for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no additional behavioral context such as pagination behavior, result ordering, or that the list is scoped to a specific document, making it essentially a restatement of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of eight words, with no filler or repetition. It earns its place by stating the action and object clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, 2 required, and no output schema. The schema and annotations cover parameters and safety, but the description lacks usage scenarios and distinction from similar position-listing tools. It is minimally adequate but leaves room for helpful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions for limit, offset, document_id, and kb_document_type. The tool description adds no parameter information, but the schema fully documents the parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of subtotal positions' clearly states the verb and resource, making the tool's core function unambiguous. However, it does not explicitly differentiate from sibling tools like list_subposition_positions or list_item_positions, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. The schema's parameter descriptions mention that subtotal positions can be added to quotes, orders, and invoices, but that is embedded in the schema, not the tool description. There are no exclusions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only and idempotent behavior, but the description adds no additional behavioral context. It does not mention pagination, filtering, sorting, or the possibility of a large result set. The description adds zero value beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized for a simple list operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the schema covers pagination, but the description leaves ambiguity about what constitutes a 'user' (e.g., real vs fictional) and does not mention that the list may be paginated or what the return structure resembles. It is adequate but could be more complete given the sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the limit and offset parameters are already well-documented in the input schema. The tool description does not add any parameter semantics, but the baseline of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of users' clearly states the action (fetch) and the resource (list of users). It distinguishes from 'get_user' (single user) and 'list_fictional_users' (fictional users), though it could be more explicit about what 'users' encompasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of using 'get_user' for individual users or 'list_fictional_users' for fictional users, nor any context about default behavior or limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the description adds no new behavioral context. It does not explain side effects (e.g., whether the quote becomes immutable, triggers notifications, or can be reverted) or any prerequisites. The wording merely restates the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no wasted words. However, it is arguably too terse, lacking even a brief note on when to use it, so it only narrowly misses a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the presence of closely related siblings (send_quote, issue_quote, mark_as_sent_invoice) requires contextual disambiguation. The description does not clarify the precise scenario for marking a quote as sent, making it incomplete for an agent to select correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (quote_id is described as 'the id of the quote'). The description adds no further meaning to the parameter, but since the schema fully documents it, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark quote as sent' uses a specific verb ('mark') and resource ('quote') with a clear state change. It distinguishes itself from siblings like 'send_quote' and 'issue_quote' by focusing on updating the status rather than performing an external action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'send_quote' or 'mark_as_sent_invoice'. Given the large number of quote-related sibling tools, explicit differentiation is necessary but entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds no additional behavioral context such as side effects, permissions, or state-transition implications, making it purely redundant beyond the action statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's action. There is no unnecessary elaboration or redundancy, making it highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required parameters, clear schema, and informative annotations), the description is minimally sufficient but lacks usage context, potential side effects, or return-value expectations. It is adequate for an agent to understand the basic function but not rich enough for a complex decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both 'id' and 'status' have descriptions), so the description text adds no extra meaning to the parameters. The baseline of 3 is appropriate because the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update Expense status' clearly states the action (update) and the resource (Expense status), making the primary purpose understandable. However, it does not distinguish this tool from sibling tools like 'update_expens' or 'update_expense_action', so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusion criteria, and no prerequisites. It is a bare statement with no contextual direction for an agent deciding which tool to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the action name. Annotations already indicate readOnlyHint=false, but the description fails to disclose side effects, irreversibility, required quote state, or outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with no wasted words. It is slightly under-specified, but for a single-verb tool it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and annotations, the description is minimally viable. However, it lacks any mention of quote status prerequisites, consequences, or relationship to sibling quote tools, leaving some ambiguity in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter quote_id is fully described in the schema (100% coverage). The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Decline') and a specific resource ('quote'), clearly conveying its function. It distinguishes from sibling tools like create_accept_quote and create_reissue_quote by naming the decline action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many quote-related siblings (accept, reissue, issue, send). There are no exclusions, prerequisites, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the agent knows this is a destructive operation. The description's 'Deleting' is consistent with these annotations but adds no extra behavioral context such as whether the deletion is permanent, what side effects occur, or if any authorization is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words. It starts with the verb 'Deleting' to immediately communicate the action, but the phrase 'with given id' is redundant and could be replaced with more specific parameter information, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of a delete operation, the explicit parameter schema (100% coverage), and annotations indicating destructive and idempotent behavior, the description provides adequate baseline context. However, it lacks any information about return values, success/failure behavior, or consequences if the absence doesn't exist, which would help complete the picture for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for absenceId ('Id of an absence') and employeeId ('Id of an employee'), so the description doesn't need to explain them. The phrase 'with given id' adds no clarification about the distinct roles of the two parameters, so it contributes nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Deleting) and the resource (employee absence), making it unambiguous that this tool removes an absence record. However, 'with given id' is vague about which id (absenceId vs employeeId) is the primary identifier, and it doesn't explicitly differentiate from update_absence or get_absence, though the verb 'Deleting' does distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like update_absence or create_absence_for_employee. There are no prerequisites, exclusions, or contextual hints beyond the verb 'Deleting', which implies removal but doesn't clarify scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating a mutating, destructive operation. The description adds nothing beyond the tool name, such as side effects, permanence, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. However, it is terse to the point of providing minimal value beyond the tool name, so it is concise but slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema and annotations are strong (all params documented, destructive and non-read-only hints present), but the description fails to explain what a 'default position' is or any operational context. For a low-complexity tool, the definition is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptive text for all three parameters, including an example for document_id and an enumerated list for kb_document_type. The description does not add any parameter-specific meaning, so the baseline 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a default position' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_default_position, get_default_position, list_default_positions, and update_default_position. The action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, no mention of prerequisites, consequences, or alternatives. It is a bare statement of the action with no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description 'Delete Expense' adds no behavioral context beyond what annotations already provide (destructiveHint=true, idempotentHint=true). It does not mention permanence, cascade effects, permissions, or error scenarios, so it fails to add value beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just two words—and free of fluff. It is appropriately sized for a simple delete operation, though it is slightly under-specified in terms of informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description combined with annotations (destructiveHint, idempotentHint) provides basic completeness. However, it lacks details on return values, failure modes, or prerequisites, making it minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter 'id' with a clear description, so schema coverage is 100%. The description adds no direct parameter information, but the baseline of 3 is appropriate since the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete Expense' clearly states the action (delete) and the resource (expense), distinguishing it from sibling tools like create_expens, get_expens, and update_expens. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_expense_action or other delete operations. The description only states the action without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide. Annotations indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=true, but the description does not disclose consequences, reversibility, or side effects. It simply restates the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, but it is perhaps too sparse to provide any structural benefit like lists or caveats. For a simple delete operation, it is appropriately sized, but could include a bit more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool with annotations indicating destructiveness and open-world side effects, the description is minimally viable. It doesn't mention what happens after deletion, whether it's permanent, or how it relates to related objects. With openWorldHint=true and no output schema, more context would aid the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (purchase_order_id is described as 'the id of the purchase order'). The description adds no additional semantic value beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (delete) and the resource (purchase order), using a specific verb+resource structure. It is unambiguous and distinguishes this tool from sibling tools like update_purchase_order or get_purchase_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or compare with update_purchase_order or other delete_* tools. Usage is only implied by the verb 'delete'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is clear. The description adds no extra behavioral context, such as behavior when the ID is not found or the shape of the returned object, but it does not contradict 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and free of fluff, consisting of a single sentence. However, it borders on being a near-tautology of the tool name, providing only a slight readability improvement without additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool, the description is adequate but minimal. No output schema exists, so the description could have been more explicit about the return value or error behavior, but the basic purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers the single parameter, describing 'fictional_user_id' as an integer with a clear description. The description adds no additional meaning beyond the schema, so the baseline of 3 for high schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a fictional User' clearly identifies the action (fetch) and the resource (fictional User). The qualifier 'fictional' distinguishes it from other getters like get_user, but it doesn't elaborate on what a fictional user is or explicitly differentiate from sibling tools beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_user or other getter tools. There are no exclusions, prerequisites, or context hints, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context such as return format, error handling, or data scope, so it contributes no value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence ('Fetch a salutation') with no extraneous information. It is appropriately sized for such a simple tool and front-loads the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one well-documented parameter, strong annotations, no nested objects), the description is sufficient even though it doesn't explicitly state the return value. The implied return of a salutation is clear from the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter salutation_id, which is fully explained as 'the id of the salutation'. The description adds no additional parameter semantics, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch') and resource ('a salutation'), which clearly identifies the action. It distinguishes from sibling tools like list_salutations and search_salutations by implying direct retrieval, though it doesn't explicitly mention 'by ID' to fully differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_salutations or search_salutations. There is no mention of prerequisites or context, leaving the agent to infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already declare (readOnly, idempotent, non-destructive). It does not mention return format, error behavior, or any special handling, though annotations mitigate safety concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that is concise and directly states the tool's function. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and strong annotations, the description is adequate. It does not explain return values, but the lack of an output schema and the straightforward nature of the operation make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter (vat_period_id) with a clear description. The tool description adds no further semantic meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a vat period' clearly states the action (fetch) and resource (vat period). It is distinct from list_vat_periods by implying a single record, though it does not explicitly contrast with listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_vat_periods. It does not state prerequisites or typical scenarios, leaving the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds no behavioral information beyond this—it simply restates the read-only nature with 'Fetch'. No additional context about pagination limits, rate limits, or response structure is provided, so the description adds minimal transparency value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately communicates the tool's purpose without any filler or redundancy. It is appropriately front-loaded and minimal, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with three optional pagination parameters and no output schema, the description plus the schema annotations are largely sufficient. The tool's function and parameters are clearly documented. It would benefit from a note about what a 'contact group' is or how it differs from contacts, but this is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptive text for limit, offset, and order_by. The description itself provides no parameter semantics, but the schema does the heavy lifting, meriting the baseline score of 3. No extra value is added by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of contact groups' clearly states the action (fetch) and the resource (contact groups), leaving no ambiguity about the tool's basic function. However, it does not explicitly differentiate this from the sibling tool 'search_contact_groups', so it misses an opportunity to distinguish between list-all and search semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when to prefer 'list_contact_groups' over 'search_contact_groups' or other list tools, nor any note on pagination or use cases. The description offers zero usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context, but given the strong annotation coverage, the bar is lower and a 3 is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple list resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simple parameters and good annotations, the description lacks essential context such as whether it lists all items or supports filtering, and it doesn't mention pagination behavior or return format. Without output schema, more explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the input schema fully describing limit, offset, and order_by. The description adds no extra parameter information, so it meets the baseline but doesn't enhance clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Fetch' and resource 'items', identifying the tool's core action. However, it doesn't distinguish from sibling tools like search_items or get_item, and 'items' is a generic term without scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as search_items or get_item. There is no mention of prerequisites, typical use cases, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description adds no behavioral context beyond these annotations, such as pagination behavior, result scope, or anything else, so it provides no extra transparency value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's purpose. It is concise with no unnecessary words, achieving maximum clarity in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with comprehensive annotations and schema coverage, the description is mostly complete. However, it lacks any mention of pagination or differentiation from search_stock_locations, which would make it more complete for an agent evaluating context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter clearly documented (limit, offset, order_by). The description does not add any further meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a list of stock locations, using a specific verb and resource. However, it does not explicitly distinguish from sibling tools like search_stock_locations or list_stock_areas, so it lacks full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the alternative search_stock_locations. The description does not mention any context, prerequisites, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds no behavioral details. It doesn't disclose that the result set can be paginated via offset/limit, that date filters active taxes, or that scope/types filter the results. While annotations cover the safety profile, the description contributes no additional context about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the purpose immediately and earns its place, though it is minimal. This is appropriate conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description is too terse. It doesn't mention pagination, filtering, or what a tax object contains. With no output schema, the description should provide more context about the returned data, but it only states the obvious. The annotations help with safety, but not with functional completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 5 parameters with full descriptions (100% coverage), so the description doesn't need to add parameter details. It doesn't, and the baseline 3 applies because the schema already provides the heavy lifting. The description adds no extra meaning beyond the parameter names/descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of taxes' uses a specific verb ('Fetch') and resource ('list of taxes'), clearly distinguishing it from sibling tools like get_tax (fetch a single tax) and delete_tax (delete a tax). The plural 'list' signals a collection operation, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any filtering, pagination, or contrast with search_taxes (which doesn't exist but there are search_* tools). The only usage context is implied by the name, so there is no explicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, but the description adds no further behavioral detail beyond the word 'restore'. It does not explain whether the operation reverses a deletion, what side effects occur, or if special permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It front-loads the core purpose effectively and earns its place without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity and full schema coverage, the description is too sparse. It does not specify what 'restore' entails (e.g., undeleting a contact), what the outcome looks like, or whether it is the inverse of delete_contact. Without an output schema, more context would be needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes contact_id as 'the id of the contact' with 100% coverage. The description adds no additional meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Restore a contact' uses a specific verb ('restore') and resource ('contact'), clearly distinguishing this tool from siblings like create_contact, update_contact, and delete_contact. The action is unambiguous and directly tied to the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about scenarios such as restoring a previously deleted contact or prerequisites, and it does not mention related tools like delete_contact.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive, non-idempotent mutation. The description 'Unarchive a project' adds no behavioral context beyond that, such as side effects, permission requirements, or what state changes occur. It does not contradict annotations, but also does not enrich them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with zero wasted words. It states the action and resource efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has only one parameter and output schema is absent, the description lacks essential context: it does not clarify that the project must be archived, what the effect of unarchiving is, or any side effects (especially given the openWorldHint annotation). The agent receives minimal actionable information beyond the tool's name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'project_id', which has a clear description. The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pair ('Unarchive a project') that clearly distinguishes it from the sibling tool 'archive_project'. It unambiguously states the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is the inverse of archive_project, nor does it specify prerequisites such as the project needing to be archived first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply restates the action 'delete' without adding behavioral context beyond what annotations already declare. Annotations provide destructiveHint=true, readOnlyHint=false, idempotentHint=true, but the description does not add information about permanence, side effects, or related data. It adds no value over the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is as concise as possible while still being clear, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and annotations covering destructive behavior, the description is minimally complete. However, it lacks usage context and does not mention what happens after deletion or any side effects (beyond destructiveHint). The absence of an output schema and lack of guidance make it adequate but not rich, so a score of 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter contact_id has a description 'the id of the contact'. The tool description itself does not elaborate on the parameter, but the schema already fully covers its semantics, satisfying the baseline for a fully-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a contact' uses an explicit verb and resource, making it immediately clear what the tool does. It distinguishes from sibling tools like delete_contact_group and delete_contact_relation by specifically targeting a contact, so there is no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like update_contact or restore_contact, nor does it mention any prerequisites or contexts where deletion is appropriate. The annotations include destructiveHint but no practical guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only repeats that the tool deletes, which is already conveyed by the destructiveHint annotation. It adds no additional behavioral context such as whether deletion is permanent, cascading, or requires special permissions. The openWorldHint is not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is appropriately concise for a simple delete operation, every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 annotations provide destructiveness and idempotency hints. However, the description does not clarify potential side effects, prerequisites, or permanent nature, leaving some ambiguity for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (fictional_user_id) with a clear description. Since schema coverage is 100%, the baseline is 3, and the tool description itself adds no extra parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a fictional user' uses the specific verb 'Delete' and clearly identifies the resource (fictional user), distinguishing it from other delete_* tools in the sibling list. It precisely states what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or any exclusions. It does not mention other fictional user operations (create, update, get, list) or related delete tools, so the agent receives no explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, readOnlyHint=false, idempotentHint=true, and openWorldHint=true. The description adds no additional behavioral context beyond the explicit action, such as whether deletion is permanent, cascades to related data, or has side effects. Since it contributes nothing beyond the annotations, it fails to enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It is front-loaded with the action and resource, making it highly scannable and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 required params) and the presence of annotations covering destructive and idempotent behavior, the description is minimally adequate. However, it lacks any contextual detail about the operation's effects, such as permanence or impact on related data, which would be valuable for an agent deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter given a basic description ('the id of the project' and 'the id of the milestone'). The tool description does not add any meaning about how these parameters relate or behave. Baseline for high coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a milestone' uses a specific verb (delete) and resource (milestone), making the tool's purpose immediately clear. It distinguishes itself from sibling tools like get_milestone, list_milestones, and update_milestone, which operate on the same resource but with different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any conditions, prerequisites, or exclusions. There is no mention of situations where deletion might be inappropriate (e.g., milestones with associated work packages or dependencies).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds no additional behavioral context (e.g., permanence, cascading effects, idempotency). It does not contradict the annotations but also does not enrich them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence 'Delete a project' is maximally concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with strong annotations, the description is minimally adequate. However, it omits any mention of irreversible consequences or related data behavior, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the sole parameter project_id with a clear description, so the baseline is 3. The tool description adds no extra semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Delete' and the resource 'project', making it clear what the tool does. It also distinguishes from numerous sibling delete_* tools by naming the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use delete_project versus alternatives like archive_project, nor any prerequisites or exclusions. It simply states the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds no extra behavioral context (e.g., error handling, return format) beyond the simple fetch action. It is consistent with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four words: 'Fetch a calendar year'. Every word is meaningful and there is zero wasted text, making it maximally concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and clear annotations. However, the description does not mention return value details, potential errors, or how this get operation differs from list/search. It is adequate but minimal for a basic getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the only parameter 'calendar_year_id' clearly described as 'the id of the calendar_year'. The description does not add further parameter semantics, but the schema already carries the full meaning, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and resource 'calendar year', clearly indicating a retrieval operation. However, it does not distinguish itself from sibling tools like list_calendar_years or search_calendar_years beyond the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description merely states what it does without contextualizing against list/search operations or specifying intended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 safety profile is covered. The description adds no additional behavioral context, such as what is returned or how errors are handled. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is appropriately front-loaded and perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 annotations provide strong safety hints. However, the description does not explicitly state what is returned, leaving ambiguity given get_invoice_pdf exists. It is minimally adequate but lacks a clear statement of return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since the single parameter invoice_id is described as 'the id of the invoice'. The description does not add extra meaning beyond the schema. Baseline of 3 is appropriate when the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch an invoice' clearly states the action (fetch) and resource (invoice), so it is not a tautology. However, it does not differentiate between returning invoice data versus related resources like invoice PDFs or payments, which are separate sibling tools. It is specific enough to be understood but lacks distinguishing details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_invoices, search_invoices, or get_invoice_pdf. The description simply states the action without context for decision-making. Given the large number of sibling tools, this is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 safety profile is clear. The description adds no extra behavioral context (e.g., not-found behavior, response shape). This is acceptable but not enhanced by the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It earns its place by stating the core purpose without redundancy. For a one-parameter get tool, this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with strong annotations and a fully documented parameter, the description is minimally sufficient. However, without an output schema, it does not state the return format or error cases, leaving some gaps. Given the simplicity, a 3 is reasonable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with project_id described as 'the id of the project' in the schema. The description 'Fetch a project' adds no additional semantics beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a project' clearly identifies the action (fetch) and resource (project), which distinguishes it from sibling tools like list_projects or search_projects. It lacks additional scope details, but the verb and resource are specific enough for a simple get-by-id tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_projects or search_projects. The description does not mention that it fetches a single project by ID, nor does it draw contrasts with list/search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, establishing the safety profile. The description adds no additional behavioral context such as pagination behavior, result scope (all vs filtered), or data shape, but it does not contradict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the verb and resource, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no output schema, and annotations cover safety. However, the description lacks explicit context about the scope of the list (e.g., all contact relations vs filtered) and does not point to the sibling search tool for filtered queries, so it is marginally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (limit, offset, order_by) have descriptions in the schema, covering 100% of param semantics. The description itself offers no additional parameter guidance, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('list of contact relations'), clearly indicating a read operation. However, it does not differentiate between this list and the sibling search_contact_relations tool, which may also return contact relations with filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus search_contact_relations or get_contact_relation. The description merely states the action without specifying scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, open-world, idempotent, and non-destructive. The description adds no further behavioral details beyond the simple fetch operation, which is consistent. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler or redundancy. It is appropriately sized for such a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema and annotations are rich, the description lacks mention of whether this is the unfiltered list (versus search_countries) or any details about response shape. Given the existence of a sibling search_countries tool, the description is minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions for limit, offset, and order_by. The description adds no parameter-specific meaning, but the schema is self-sufficient, so a baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and resource ('a list of countries'), distinguishing it from single-resource get_country. However, it doesn't differentiate from the sibling search_countries, which likely also returns countries with filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use list_countries versus search_countries or other list tools. The description only states the operation without context on when to choose this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat safety info. The description itself adds no extra behavioral context, such as pagination, ordering defaults, or the meaning of 'document settings' beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence front-loaded with the verb 'Fetch'. It contains no filler or repetition, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with annotations and a well-documented parameter, the description is minimally adequate. However, it doesn't explain what 'document settings' are, potential response shape, or any edge cases, leaving some ambiguity for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, order_by, has a thorough description in the schema covering sorting behavior and enum values. The tool description adds nothing beyond that, so the schema carries the load as expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a list of document settings, using a specific verb and resource. However, it doesn't explicitly distinguish this from sibling tools like list_document_templates, leaving the exact scope of 'document settings' slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, and the sibling list is large, so an agent has no indication of when to choose this over other list_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already declare. Annotations thoroughly cover safety (readOnlyHint, idempotentHint, destructiveHint false), but the description fails to add value such as noting there are no filters, no pagination, or that it returns all templates. It merely restates the title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no filler. It is front-loaded and every word is meaningful. While terse, it is appropriately sized for a tool with no parameters and a straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's extreme simplicity (no parameters, no output schema, simple list operation), the description is nearly complete. It clearly states what the tool does. However, it omits any detail about return values or scope, though for a no-param list with openWorldHint, this is largely implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema fully covers everything needed. The baseline for 0 params is 4, and the description does not need to compensate for missing parameter explanations. It correctly focuses on the action rather than params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('document templates'), making the tool's purpose evident. However, it does not explicitly differentiate this from other list_* tools with similar naming patterns, such as list_document_settings or list_company_profiles, so it stops short of full sibling discrimination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of typical use cases, prerequisites, or exclusions. The openWorldHint annotation implies it lists all templates, but this is not stated in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, read-only, idempotent operation, so the description does not need to repeat that. It adds minimal context by identifying the resource as 'files of manual compound entry', but it does not disclose any additional behavioral traits like pagination behavior, response format, or whether file metadata vs. content is returned. The description is consistent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. It efficiently conveys the core purpose without wasting words, though it could be slightly clearer with proper grammar ('files of the manual compound entry'). This is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the operation, the presence of robust annotations and a fully described schema, the description is minimally sufficient. However, it lacks details about the response structure (no output schema) and does not clarify the difference between manual compound entries and regular manual entries, which is relevant given sibling tools. These gaps prevent higher completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all three parameters (limit, offset, manual_entry_id) with clear descriptions. The tool description itself adds nothing about parameter meanings or usage, only indirectly implying that manual_entry_id is the target identifier. Since the schema fully documents the parameters, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('files of manual compound entry'), which distinguishes it from related tools like 'get_manual_compound_entry_file' and 'list_manual_entry_files'. However, it does not explicitly differentiate itself from all sibling tools, and the phrase 'manual compound entry' is not defined, leaving some ambiguity about the exact entity type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_manual_compound_entry_file' for fetching a single file or 'list_manual_entry_files' for regular manual entries. There is no mention of prerequisites, exclusions, or context for choosing this list operation over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, establishing the tool as a safe read-only operation. The description adds no further behavioral details beyond the name itself, such as pagination behavior or return structure. Since annotations cover the safety profile, a score of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundancy. It is appropriately sized for the tool's simplicity, conveying the essential purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with well-documented optional parameters and annotations indicating a safe read-only operation. However, it lacks any mention of when to use list_projects versus search_projects, and there is no output schema to clarify return structure. Given the sibling context, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (limit, offset, order_by) have descriptions in the input schema, covering 100% of parameters. The description itself adds no additional parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Fetch' with the resource 'projects', clearly indicating a read operation to retrieve a list. It is distinct from get_project (single project) and search_projects (search-based), but it does not explicitly contrast with siblings, so it gets a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like search_projects. It does not mention that list_projects may be used for unfiltered lists or that search_projects is better for filtered queries. No usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no further behavioral context (e.g., pagination behavior, default ordering, or return format), but it is consistent with the annotations and does not introduce ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded and contains no unnecessary words. It is appropriately sized for a simple list tool, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the rich schema/annotations, the description is minimally acceptable. However, it lacks context about how this listing function differs from the sibling search_quotes tool, and it does not describe the return value or pagination behavior (though the schema contributes some of this). The description is not complete for an agent trying to decide between list and search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for all three parameters (limit, offset, order_by), so the description does not need to repeat them. The description itself adds no parameter-level information, but the schema fully covers semantics, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Fetch') and resource ('a list of quotes'), making the tool's purpose immediately understandable. However, it does not differentiate from the sibling tool 'search_quotes', which may also retrieve quotes but likely with different semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool vs alternatives like search_quotes. The description gives no context on whether to prefer listing over searching, nor does it mention any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety and idempotency profile. The description 'Fetch a list of units' adds no additional behavioral context such as pagination defaults or filtering behavior. It does not contradict the annotations, so the score is acceptable but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It is front-loaded with the action 'Fetch' and the resource 'units', making it instantly scannable. Every word earns its place, and there is no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 2 optional parameters and no output schema, the description is minimally adequate. However, it lacks any mention of the tool's scope (e.g., all units vs. filtered) or how it differs from search_units. The absence of an output schema is not compensated by the description, leaving some ambiguity about return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters (limit and offset) are fully described in the input schema, so the schema coverage is 100%. The description does not add any parameter-specific meaning beyond what the schema provides, which is the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of units' clearly states a specific verb and resource, making the tool's primary purpose obvious. However, it does not differentiate from sibling tools like search_units, which also deals with units. The title 'List Units' aligns with the description, but no distinguishing details are provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as search_units or get_unit. The description implies a general listing operation but lacks explicit context, prerequisites, or exclusions. This is a clear gap for an agent deciding between multiple unit-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds no additional behavioral context beyond a restatement of the action, such as irreversibility, cascading effects, or failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with zero filler. It efficiently states the operation without unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple one-parameter tool with full schema coverage and safety annotations, the description is adequate. It could mention that the deletion is permanent, but that is already implied by destructiveHint. No output schema exists, so no return value expectations are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter fully described. The description does not add param details, but the schema handles the burden, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('contact relation'), clearly distinguishing it from sibling tools like create/update/get/list/search. No ambiguity about what action is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information on when to use this tool or alternatives. There are no exclusions, prerequisites, or context about when deletion is appropriate vs. using other contact relation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description 'Fetch a milestone' is consistent with the annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true). It adds no behavioral context beyond what annotations already provide, such as error behavior or return format. However, the annotations cover the safety profile, so this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant information. It is appropriately front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read operation with rich annotations and complete schema descriptions, the description is adequate. It does not detail the return shape, but the tool name and context imply a milestone object. No output schema exists, but the minimal description still fills its purpose for a straightforward getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both project_id and milestone_id described as 'the id of the project' and 'the id of the milestone'. The description 'Fetch a milestone' does not add any additional parameter semantics beyond what the schema already provides. Baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a milestone' clearly uses a specific verb and resource, indicating a single milestone retrieval. It does not explicitly distinguish from list_milestones, but 'a milestone' implies a single resource. Overall, purpose is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_milestones. There is no mention of when not to use it, prerequisites, or context. The description is purely declarative and offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply restates the tool's action ('Fetch') and adds no behavioral details beyond the annotations. Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description does not mention return value, error behavior, or any edge cases, contributing no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single five-word sentence with the verb 'Fetch' front-loaded. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of fetching a single pagebreak position and the comprehensive schema and annotations, the minimal description is mostly sufficient. However, it does not explicitly state the return value, which could be inferred but is not clearly disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions for document_id, position_id, and kb_document_type. The description adds no additional meaning to the parameters, so it relies entirely on the schema to convey parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('pagebreak position'), clearly distinguishing this tool from sibling tools like list_pagebreak_positions, create_pagebreak_position, update_pagebreak_position, and delete_pagebreak_position. It unambiguously indicates a single-record retrieval operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_pagebreak_positions. The description lacks any context about prerequisites, selection criteria, or scenarios where this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool downloads a PDF, which is useful behavioral context, but doesn't mention response format or any required permissions. With annotations present, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (8 words) with no wasted words. It clearly states the action, resource, and qualifying details, making it well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple download tool with full schema coverage and annotations, the description adequately covers the essentials: what (paystub pdf), who (employee), and when (given month). No output schema is present, so return values need not be explained. Minor gap: it doesn't explicitly note that the output is the PDF file itself, but this is implied by 'Download'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters (employeeId, year, month) with descriptions, achieving 100% schema_description_coverage. The description adds little beyond what the schema already provides, merely echoing 'employee' and 'month'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (Download), the resource (paystub pdf), and the target (employee, given month). However, it does not distinguish this tool from the sibling 'get_pdf_for_employee_in_month', which appears to perform a similar function. This is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. Given the presence of a similarly named sibling tool, the lack of usage context is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. However, the description adds no behavioral context beyond a restatement of the purpose, such as pagination behavior, return format, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, front-loaded with the core action. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with only two well-described parameters and read-only annotations, the description is mostly sufficient. It doesn't explicitly state that it returns all account groups, but the lack of filter parameters and the pagination schema make this clear. No output schema is present, so the description need not explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (limit, offset) having descriptions. The description does not add any additional parameter semantics, so the baseline score of 3 applies since the schema already handles the documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and resource 'account groups', clearly identifying the tool's function. The resource name distinguishes it from siblings like list_accounts and search_accounts, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of conditions, exclusions, or context that would help an agent decide between this and related list/search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the operative word 'Fetch'. Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered, but the description does not disclose additional behaviors like pagination (limit/offset) or that results are tied to a contact. It is essentially a restatement of the tool name with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no superfluous words. It is front-loaded and directly communicates the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the rich annotations (read-only, idempotent, non-destructive), and full parameter schema, the description is nearly sufficient. It lacks an explicit statement of return value or the relationship between contact_id and 'additional addresses', but the schema and tool name fill most gaps. A short note on when to use list vs search would elevate it, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter documented. The description does not add any parameter-specific meaning, but the schema already fully explains limit, offset, order_by, and contact_id. Baseline 3 is appropriate as the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch a list') and the resource ('additional addresses'). It distinguishes from sibling tools like get_additional_address (singular) and search_additional_addresses (search-based), 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_additional_addresses or get_additional_address. There is no mention of context, exclusions, or prerequisites, leaving the agent to infer usage solely from the name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that validation checks availability, implying a boolean-like result, but does not disclose return format, edge cases, or behavior beyond that. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that communicates the tool's function without any wasted words. It is appropriately concise for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only validation tool, the description is adequate but leaves ambiguity about the return format (e.g., boolean vs. list). The tool name suggests 'list' while the description says 'validate', and with no output schema, a bit more detail on the response would make this more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a somewhat tautological description for the only parameter ('document number to validate'), but the tool description adds the key semantic that the validation checks 'availability'. This clarifies what 'validate' actually means, going beyond the schema's wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'validate' and references document number availability, clearly stating the tool's core purpose. However, it does not mention 'expense' or distinguish this from the sibling tool list_purchase_document_numbers, so differentiation is left to the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it reference the similar sibling list_purchase_document_numbers. The agent must infer usage context solely from the name and general validation semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond the annotations, such as pagination, defaults, or return format, so it provides minimal additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is front-loaded and efficient, but lacks any structure beyond the basic statement, which keeps it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with two optional parameters and no output schema, the description is minimally adequate. However, it doesn't convey any behavioral nuance or clarify what a 'fictional user' is, so it's not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% coverage with descriptions for both limit and offset. The description doesn't add any parameter-specific meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Fetch' and resource 'list of fictional users', clearly distinguishing from siblings like list_users (real users) and get_fictional_user (singular). It precisely states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the list semantics, but no explicit guidance is given on when to use this tool versus alternatives. There is no search_fictional_users sibling, so it's clearly the listing tool, but the description doesn't state this or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the destructive and idempotent nature. The description adds that it removes a 'connection' rather than deleting the underlying file or entry, which is useful. However, it doesn't clarify effects on the linked entities 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, direct, front-loaded verb, and no redundant words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete-link tool, the description plus annotations cover the basics. However, it lacks details about whether the file itself remains intact, what happens if the connection doesn't exist, and how entry_id differs from manual_entry_id. The misleading schema description for file_id is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not explain the roles of manual_entry_id, entry_id, and file_id, and notably file_id's schema description incorrectly says 'the id of the currency', which the description fails to correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Delete connection') and resource ('file and manual entry line'), clearly distinguishing it from sibling tools like delete_manual_entry or delete_manual_compound_entry_file. It unambiguously targets the relationship, not the entities themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs. alternatives (e.g., delete_manual_entry, delete_manual_compound_entry_file), nor are prerequisites or consequences mentioned. The only hint is implicit in the name and description, which is not enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the operation without adding behavioral context such as not-found handling, response shape, or required permissions. The annotations already declare readOnlyHint=true and destructiveHint=false, so this adds little beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the purpose with no unnecessary words. It is perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with one parameter and no output schema, the description is adequate but minimal. It doesn't mention return value format, error behavior, or permissions, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage (100%) for the only parameter bank_account_id with a clear description, so the baseline of 3 applies. The description adds no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fetch', the resource 'bank account', and the scope 'single', which distinguishes it from list_bank_accounts and search_accounts. It is concise and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching one bank account by ID but does not explicitly say when to use it instead of list_bank_accounts or search_accounts. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds no further behavioral context, such as return format or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, with zero redundant content. It is front-loaded and immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description combined with schema and annotations is largely sufficient. However, it does not mention the return value or any error conditions, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter 'currency_id' with type and description. The description adds no additional meaning beyond what the schema provides, so baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a currency' clearly states the tool action and resource with a specific verb. It distinguishes from sibling tools like list_currencies by indicating singular retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or when to prefer alternatives. The description lacks any context about prerequisites, exclusions, or comparison to list_currencies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds no additional behavioral context such as error behavior, authentication, or return format. While there is no contradiction, the description contributes nothing beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single four-word sentence is maximally concise and front-loaded. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the one-parameter schema and rich annotations, the description is adequate but terse. It doesn't state what a 'unit' is or what is returned, but the name and schema cover the essentials. For a simple get-by-ID tool, this may be sufficient; however, no output schema means a bit more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter with a clear description ('the id of the unit'), so the description does not need to add parameter details. Baseline 3 is appropriate; 'Fetch a unit' adds no extra semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a unit' uses a specific verb and resource, clearly indicating a retrieval operation for a single unit. It distinguishes itself from sibling tools like list_units (plural collection) and search_units (query-based) by implying direct fetch by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus list_units or search_units, nor does it mention exclusions. Usage is only implied by the name and the required unit_id parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds no behavioral context beyond the basic function, such as pagination behavior or document scoping, which are left to 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no unnecessary words, front-loaded with the verb and object. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with complete schema descriptions and safety annotations, the description is minimally sufficient. However, it doesn't describe the return payload or any nuances like ordering or filtering, making it slightly incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all four parameters. The description adds no parameter-level information, so the baseline of 3 applies as the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and the resource 'pagebreak positions', clearly indicating a list operation. It distinguishes from sibling get_pagebreak_position by using 'list/fetch a list' versus 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a list operation but provides no explicit guidance on when to use this tool versus alternatives like get_pagebreak_position. It doesn't name alternatives or exclusions, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the core state transition (issued → draft) but adds no further behavioral context. Annotations already indicate readOnlyHint=false, so the write nature is known. The description does not disclose potential side effects (e.g., impact on payments, invoice numbering, or reminders), but given the simplicity and existing annotation coverage, this is acceptable though 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the function with no filler or unnecessary information. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (one parameter, no output schema) and annotations are present, the description is mostly sufficient. However, it lacks contextual guidance about when to revert an issued invoice vs using cancellation or other invoice-related actions, which is relevant given the large sibling set. It is not incomplete to the point of confusion but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full coverage of the sole parameter (invoice_id), including a clear description. The tool description does not need to add parameter details. Baseline of 3 is appropriate since the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sets issued invoice to draft' uses a specific verb ('sets'), names the resource ('issued invoice'), and specifies the resulting state ('draft'). This clearly distinguishes it from sibling tools like issue_invoice (which presumably does the opposite) and cancel_invoice (which implies a different outcome).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as cancel_invoice, update_invoice, or mark_as_sent_invoice. There is no mention of prerequisites, typical scenarios, or situations where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and idempotentHint=true, which cover the key behavioral traits. The description simply says 'Delete' which is consistent, but it does not add extra context beyond what annotations already provide, such as potential side effects or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and directly communicates the tool's purpose. There is zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple delete tool, and the annotations cover the destructive nature while the schema fully documents the required parameters. The description, while minimal, adequately indicates the operation. No output schema exists, but for a delete action this is not a critical gap given the other structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the schema already explains document_id, position_id, and kb_document_type. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and the resource (pagebreak position). It is a specific verb+resource construction that directly distinguishes this tool from sibling tools like get_pagebreak_position, list_pagebreak_positions, update_pagebreak_position, and create_pagebreak_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, what prerequisites are needed (e.g., obtaining a position_id), or how it compares to alternatives. There is no mention of context such as needing to reference a document type or that this permanently removes a pagebreak.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 scoping detail that it returns a single purchase order, but doesn't describe response shape, error behavior, or any other behavioral traits. It is consistent with annotations, adding minimal but non-contradictory context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence of five words, with no filler or redundancy. It is front-loaded with the action and resource, and every word contributes to meaning. For a simple get-by-id tool, this level of conciseness is ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, strong annotations, no output schema), the description is largely complete. It clearly communicates the core function. However, it lacks any mention of return value expectations or when to use alternatives, leaving a small gap in overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the parameter 'purchase_order_id', which is described as 'the id of the purchase order'. The tool description does not add additional meaning to the parameter, so the baseline score of 3 applies since the schema already carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Fetch a single purchase order" clearly states the action (fetch), the resource (purchase order), and the scope (single), distinguishing it from list_purchase_orders and other CRUD operations. The verb is specific and aligns with the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like list_purchase_orders or search tools. It does not mention prerequisites, exclusions, or alternative selection criteria. The word 'single' only implies a singular result, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 safety profile is clear. The description adds no extra behavioral context such as pagination behavior, open-world semantics, or response format, but it does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, immediately stating the action and resource. It contains no fluff or redundant information, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and read-only annotations, the description provides a sufficient minimal description. It could optionally mention that it returns all business years or that pagination is supported, but the schema already covers this. The description is complete enough for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents both 'limit' and 'offset' with complete descriptions, giving 100% schema description coverage. The tool description does not mention parameters, which is acceptable since the schema fully covers them. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a list of business years' uses a specific verb ('fetch') and resource ('business years'), clearly distinguishing it from sibling tools like 'get_business_year' (singular) and 'list_calendar_years' (different resource). It directly states the operation and object, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or related tools such as 'get_business_year' or 'search_calendar_years'. There is no context about use cases or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the destructive nature but adds no new behavioral details beyond what annotations already provide. Annotations include destructiveHint=true and readOnlyHint=false, which cover the safety profile. The description does not elaborate on irreversibility, side effects, or idempotency behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and economical, but it contains a grammatical error ('a existing' instead of 'an existing'). It earns its place without padding, though polish is needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required parameter) and the rich annotations (destructiveHint, idempotentHint), the description is adequate for a simple delete operation. It omits edge-case behavior or return details, but the annotations and schema cover the essential aspects sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's verb 'Delete' clarifies that file_id identifies the file to delete, which is valuable because the schema's parameter description says 'File ID to show'—a mismatch. The tool description implicitly corrects this and adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (file), making the purpose unambiguous. It distinguishes itself from sibling delete tools like delete_item or delete_absence by explicitly naming 'file' as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mention of prerequisites, exclusions, or scenarios to avoid. The description simply states the action without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description's 'Retrieving' aligns with the read-only annotation but adds no further behavioral detail, such as pagination, sort order, or return format. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that front-loads the verb 'Retrieving' and the resource. It is concise, direct, and avoids redundancy with annotations or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read/list operation with only two fully-documented parameters, strong annotations, and no output schema, the description is complete. It clearly specifies what is retrieved and the required scope, leaving no critical gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both employeeId and businessYear have clear descriptions. The description's 'for given year' essentially restates the businessYear property and adds no new semantics. Since schema fully documents the parameters, this meets the baseline but adds nothing extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieving absences of employee for given year' clearly states the action (retrieving), the resource (absences of employee), and the scope (given year). It distinguishes the tool from siblings like get_absence (single absence), create_absence_for_employee, update_absence, and delete_absence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to list all absences for a specific employee in a business year) but does not explicitly mention alternatives or exclusions, such as 'use get_absence for a single absence.' The usage context is clear but lacks explicit guidance against using other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 safety profile is clear. The description adds context that this fetches the authenticated user rather than any user, which is useful since there is no parameter to specify a user. It does not add additional behavioral details like return format or auth requirements, but does not need to given 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Fetch the authenticated user.' It is extremely concise with no irrelevant details or filler, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, a read-only operation, and no output schema, the description is complete. It conveys the core behavior (fetching the authenticated user) and given the annotations, no additional context is necessary. The simplicity of the tool means the description covers all needed information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is trivially fully described. The baseline for zero parameters is 4, and the description does not need to explain parameter meanings since there are none. It correctly focuses on what the tool does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch the authenticated user' uses a specific verb and resource, clearly indicating this tool returns the currently authenticated user. This distinguishes it from siblings like 'get_user' (which fetches a user by ID) and 'list_users' (which lists all users), 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention alternatives such as 'get_user' or 'list_users', nor does it clarify contexts where this should be preferred. The usage is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral traits beyond the obvious 'fetch a list', but there is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence 'Fetch a list of company profiles' is concise, front-loaded, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool with strong annotations, the description states the core purpose adequately. However, it does not specify whether the list includes all profiles or any default ordering, and there is no output schema to clarify the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered by default. The description does not need to add parameter meaning, and the 0-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' with a clear resource 'a list of company profiles', which distinguishes it from the sibling get_company_profile (singular). It accurately conveys the list semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance or alternatives are mentioned. The usage is implied by the name and description, but it does not clarify when to use this over get_company_profile or any filtering options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, making the safety profile clear. The description adds only scope ('logged in user') but does not disclose additional behavioral details such as return format or required authentication, which is not needed given 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, strong annotations, no output schema), the description covers the essential purpose. However, 'access information' is somewhat vague about what exactly is returned, but this is a minor gap for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so baseline 4 is appropriate. The description does not need to explain parameters, and it does not add irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get access information of logged in user' uses a specific verb and resource, clearly distinguishing it from sibling list_* tools by focusing on the authenticated user's permissions. It states both the action and the scope (logged in user).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are mentioned, but the purpose is self-evident enough that an agent can infer usage. It does not state exclusions or when not to use, so it falls at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds the 'all possible' scope, indicating an unbounded result set, but does not mention return format, pagination, or rate limits. For a parameterless read-only tool, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It uses a clear verb and direct object, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete enough to convey its purpose and scope. It fully informs the agent that this is a read-only enumeration of all possible currency codes, sufficient for selecting it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so the description does not need to explain any. The empty input schema is fully covered by the description's indication that it fetches all possible codes, meeting the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' with the resource 'currency codes' and the scope 'all possible', clearly distinguishing it from sibling tools like list_currencies that likely return more detailed currency objects. It is immediately clear 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a simple enumeration use case for retrieving all currency code values, but it does not explicitly state when to use this tool versus list_currencies or other currency-related tools. No alternatives or exclusions are mentioned, relying on the name and wording to convey intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, establishing the safety profile. The description adds the behavioral detail that only 'active' employees are returned, which is non-trivial and not present in annotations. It does not contradict any hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource. Every word adds value—'all' and 'active' are essential qualifiers. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and annotations covering safety, the description is sufficient to understand the tool's behavior. It clearly states the scope ('active') and the operation ('retrieves all'), leaving no critical gaps for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema is trivially fully covered. The description does not need to explain parameter semantics. The baseline of 4 applies as no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieves' and clearly identifies the resource 'all active employees', distinguishing it from sibling tools like 'list_users' or 'get_employee_on_date'. The qualifier 'active' provides additional scoping beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing active employees, but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternatives. For a simple list tool, the context is clear from the purpose, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server-bexio MCP server](https://glama.ai/mcp/servers/AIWerk/mcp-server-bexio/badges/card.svg)](https://glama.ai/mcp/servers/AIWerk/mcp-server-bexio)

Score Badge

Copy to your README.md:

[![mcp-server-bexio MCP server](https://glama.ai/mcp/servers/AIWerk/mcp-server-bexio/badges/score.svg)](https://glama.ai/mcp/servers/AIWerk/mcp-server-bexio)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AIWerk/mcp-server-bexio'

If you have feedback or need assistance with the MCP directory API, please join our Discord server