mcp-office-suite

Server Quality Checklist

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

Latest release: v0.20.0
Disambiguation3/5
Tools are grouped by domain and individually well-specified, but clusters such as pdf_info/pdf_count, pdf_merge/pages/reorder, price_check/watch_add, resume_create/to_markdown/to_html, and convert/convert_time share enough purpose that an agent can easily pick the wrong one. The detailed descriptions help, but the sheer number of similar utilities makes boundaries less crisp than in a smaller, focused server.
Naming Consistency3/5
Most names use the expected snake_case verb_noun pattern with domain prefixes like schedule_, pdf_, sheet_, invoice_, and clause_, which is helpful. However, one-word commands (now, report, forecast, overlap, convert, conflicts, free_busy), mixed creation verbs (add/create/set), and convert/convert_time/convert_many break the pattern and reduce predictability.
Tool Count1/5
117 tools for one server is far beyond a practical selection surface. Even if an office suite covers many subdomains, bundling them into a single MCP server makes every agent scan a huge flat list and massively increases selection cost; this should be split into several focused servers.
Completeness4/5
Each subdomain is well covered: schedules, clauses, PDF operations, time tracking, price watches, spreadsheets, invoices, FX rates, docx, and calendar events all have lifecycle or read/write coverage with few dead ends. Minor gaps remain, such as no proposal/contract get/list/delete and credit notes only being referenced, but they are workable rather than blocking.
Average 3.9/5 across 117 of 117 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
This repository includes a glama.json configuration file.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description vaguely mentions that changes go to a shared profile and affect invoice issuer and default VAT, but it does not clarify persistence, overwrite behavior, validation, or any other meaningful side effects. With no annotations, this is insufficient.
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 short, but the second sentence is confusing and poorly worded, making it less concise and harder to parse than a simple clear statement would 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?
Given 17 parameters, no output schema, and no examples, the description lacks crucial context such as return behavior, required-field implications, or how the shared profile relationship impacts callers.
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 17 parameters, including aliases and defaults, so the description itself adds little parameter-level meaning. This 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Set your business details' is clear, and the description indicates it configures sender/profile information shown on documents. However, the body is garbled ('The SAME profile invoice's business_set writes:') and never plainly states that calling this tool updates the business profile.
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 siblings like profile_set or invoice_business_set, nor are any prerequisites or expected call contexts 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?
With no annotations, the description carries the full burden. It discloses two important behaviors: re-adding the same name updates stored details, and an identical record is refused with the id of the existing record. This gives useful idempotency and duplicate-handling context, but it omits return value, permission requirements, and whether other fields are cleared when updating.
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?
Two sentences with no fluff. The core purpose is front-loaded, and the behavioral nuance about update/duplicate refusal follows naturally. It is appropriately concise for a CRUD operation.
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 no output schema, no annotations, and only 25% parameter coverage, the description is incomplete. It doesn't explain the response structure (e.g., the returned id), how updates affect unspecified fields, or any required permissions. An agent would need to make assumptions or call the tool to learn more.
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% (vat_id has a description). The description adds meaning for the 'name' parameter as the matching key for updates and duplicate detection, but it doesn't explain email, address, or vat_id beyond what the schema provides. Given the low coverage, the description should compensate more than it does.
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 'Store a client' and the purpose 'so invoices can refer to them by name.' It is specific to client_add and distinguishes its upsert behavior from a plain create, though it doesn't explicitly contrast with sibling tools like client_delete or client_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 given on when to use this tool versus alternatives. It doesn't mention client_list for viewing, client_delete for removal, or any prerequisite context. The agent must infer usage from the description alone.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it merely restates the operation. It does not disclose that deletion is irreversible, whether it is a soft or hard delete, what happens to associated data, or what the response looks like.
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. It is concise and readable, though slightly redundant with the title and omits useful behavioral context that would not hurt the flow.
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 mutation tool with no annotations and no output schema, the description is thinner than it should be. The agent can infer how to call it from the schema, but it is not told what happens after deletion, whether the action is reversible, or what consequences 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?
Schema description coverage is 100% and the id parameter is documented as 'Entry id from entry_list.' The description adds little beyond that, only restating that deletion happens 'by id,' so it meets the baseline but does not elevate parameter understanding.
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'), a clear resource ('time entry'), and the method ('by id'). This is distinguishable from sibling tools like entry_edit or entry_mark_billed because the verb and target are explicit 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 given about when to use this tool versus entry_edit, entry_add, or other time-entry tools. The description does not mention prerequisites, alternatives, or any 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?
With no annotations, the description carries the full burden of disclosing side effects, but it never states whether this tool creates an invoice, modifies time entries, or is read-only. The phrase 'Turn tracked billable time into invoice line items' implies a transformation rather than a safe summary, leaving the mutation status ambiguous.
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; the core operation and output fields are front-loaded, and the currency example adds concrete value. Every clause 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 partially substitutes for a missing output schema by listing what the line items contain, but it leaves out essential context: whether calling this tool mutates any state, how the output is grouped or structured, and how it relates to invoice_create or invoice_from_hours. For a four-parameter, annotation-free tool, this 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?
Schema description coverage is 100%, so the schema already documents project, from, to, and unbilled_only. The description maps 'project or client' to the project parameter and describes output fields, but it adds no additional meaning to the input parameters beyond what the schema 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 identifies a specific operation—turning tracked billable time into invoice line items—and enumerates the output fields: hours, hourly rate, amount per task, and total. It also adds a concrete currency behavior. However, it does not explicitly distinguish this summary tool from siblings like invoice_create or invoice_from_hours, and 'turn into line items' could be misread as actually creating 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 when-to-use or when-not-to-use guidance is provided. The description does not name alternatives such as invoice_from_hours or invoice_create, and it never states whether this should be used as a read-only preview before invoicing.
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?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the return format (JSON) and that the result is the exact representation used by downstream tools, which is useful. It does not mention behavior around the optional variant parameter, missing profiles, or error cases, but for a simple getter this is a moderate gap.
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. It states the core action and format first, then adds the important downstream-use context. Every phrase earns its place and there is no redundant filler.
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 optional parameter and no output schema, the description should at least mention the variant parameter and its implications. It also does not clarify whether the profile can be empty or what happens if no profile is stored. The downstream-consumer note helps, but the missing parameter guidance leaves the description incomplete.
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 0% and the description does not explain the 'variant' parameter at all. The schema only says it is an optional string, with no enum or further guidance. This parameter semantics are entirely absent from both schema and description, so an agent cannot know what values are valid or what effect variant has on the returned profile.
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 ('Return'), identifies the resource ('the stored profile'), and specifies the output format ('as JSON'). It also clarifies that the returned value is the exact canonical profile used by downstream tools like resume_create. It does not explicitly differentiate from profile_set, but the read intent is clear.
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 this tool should be used when an agent needs to see the exact profile data that will feed resume, cover letter, or tailoring operations. However, it does not explicitly state when not to use it or mention alternatives such as profile_set for modifying the profile.
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 no annotations, the description carries the full disclosure burden, but it only says 'Remember' and describes the future benefit. It does not state whether an existing contact with the same name is upserted, whether a new contact is always created, or what the tool returns/side effects are.
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?
Single-sentence, front-loaded with the core action and resource, and uses an illustrative example instead of restating schema. The phrase 'later' appears once in the main clause and once in the example, a tiny redundancy.
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 set operation, the schema plus description cover required inputs and the purpose. The main missing context is mutational behavior (create vs update) and success/failure output, which no annotation or output schema helps fill.
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 documented in the schema (100% coverage), so the description does not need to repeat details. It adds only the high-level 'time zone and working hours' framing and the scheduling use case, which is sufficient but minimal.
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 ('Remember') and identifies the resource ('a client or teammate's time zone and working hours'), then ties it to a concrete downstream use case. It does not explicitly contrast with contacts_list or explain whether setting overwrites, 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 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 – when you want to store a person's zone and hours for later scheduling. It provides no exclusions or comparison with sibling tools such as contacts_list or find_meeting_slots, so an agent must infer the exact boundary.
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 no annotations provided, the description only mentions output (file path, block count, layout) and claims 'Free and unlimited'. It does not disclose side effects like file overwriting behavior (default false), the possibility of errors, or what happens if the file exists. This is a transparent gap.
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 brief and front-loads the core purpose. However, the phrase 'Free and unlimited' is extraneous and adds noise without aiding tool selection, 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?
Given the moderately complex nested schema (sections with headings, paragraphs, lists, tables), the description is sparse. It does not illustrate the concept of 'structured sections' or how the layout styles (plain, letter, proposal) affect output. While the schema fills many gaps, the description alone is not fully self-contained.
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 every parameter already has a descriptive comment. The tool description adds no additional meaning about parameters 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 states a specific verb ('write') and resource ('a real .docx file') and clarifies the input format ('structured sections'). It also lists the return values, making the tool's purpose unmistakable. This clearly distinguishes it from siblings like doc_from_markdown or doc_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 explicit guidance is given on when to use this tool versus alternatives such as doc_from_markdown or doc_fill_template. The description does not mention scenarios or conditions that would prefer this tool, leaving the choice to inference.
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?
With no annotations, the description carries the behavioral burden. It usefully discloses that invoiced periods are never re-issued and that amount changes affect future invoices only. However, it does not mention partial-update semantics, whether this is destructive in any way, or what happens to existing future invoices when interval/date fields change.
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?
Two sentences with no filler. The action and key field list are front-loaded, and the important future-invoice caveat is clearly stated immediately after. Every sentence 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 13 parameters, a partial-update semantic (required id only), and no output schema, the description is under-specified. It does not state whether this is a patch (only provided fields change) or a replace operation, what the response contains, whether omitted fields are preserved, or whether certain changes are invalid when invoices exist. The one behavioral caveat is helpful but insufficient for 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?
Schema description coverage is only 38%, so the description should compensate by explaining parameter meaning or update behavior. It merely lists field groups already visible in the schema and omits tax_note, anchor_day, end_of_month. It adds no guidance on formats, relationships between fields, or which combinations are valid.
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 a specific action ('Change a schedule's client, items, currency, cadence, dates, due days, notes or auto_generate flag') and names the resource. It does not explicitly differentiate from schedule_create or schedule_pause/resume, but the 'change' framing makes the update purpose evident.
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: this tool modifies an existing schedule, as opposed to creating, pausing, or deleting one. However, there is no explicit guidance about when to prefer this over schedule_create or when a schedule should not be updated, nor mention that only changing fields need to be passed.
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?
With no annotations, the description carries the full burden. It does disclose the important behavioral trait that computation uses a real date so DST changes are reflected. However, it does not mention what happens when no overlap exists, whether holidays are considered, or the output format, leaving notable gaps.
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 two sentences with no filler. The core definition is front-loaded, and the DST nuance is a meaningful addition. Every sentence 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 core concept is clear and the schema covers all parameters, but there is no output schema and no annotation coverage. The description does not explicitly state the return shape or edge-case behavior for impossible overlaps, so it is adequate but 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%, so the parameters are already well documented with names, defaults, and examples. The description adds only the interpretation that 'listed place' corresponds to the zones parameter. This meets the baseline but does not go beyond 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 clearly defines what is computed: the daily window when every listed place is within working hours. It is specific about the resource and scope, and the DST qualifier adds precision. It lacks an explicit verb and does not contrast with sibling time tools, so it barely misses 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 given about when to use this tool versus alternatives such as find_meeting_slots, free_busy, or business_days. The agent must infer from the description that this is for working-hours overlap across zones. No exclusions or alternative conditions 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add genuine value: the wall-clock interpretation rule, the offset/trailing-Z exception, and the natural-language input support. However, it omits the output format and error/edge-case behavior (though the gap/fold enums are already documented in the schema), so coverage is partial rather than comprehensive.
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?
Three sentences with zero waste. The primary action is front-loaded in the first sentence, the interpretation rule follows, and the accepted formats close it out. Every sentence earns its place with distinct 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?
Input handling is well covered (parsing rules, accepted formats, zone interpretation), and the gap/fold DST edge cases are documented in the schema. But with no output schema and no annotations, the description should have disclosed what the response looks like or how results are shaped; its omission leaves an agent to invoke the tool without knowing what to expect back. Moderate complexity (4 optional edge-case params) was not fully exploited.
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?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: it explains that 'time' is read as wall-clock in from_zone unless it carries an offset or trailing Z, enumerates accepted formats (datetime string, ISO, '3pm tomorrow'), and clarifies that multiple target zones are expected. This materially helps an agent construct valid inputs.
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 ('Convert'), resource (time), and scope ('from one place to others'), making the core function clear. The parsing rules and accepted input formats add further specificity. However, it does not differentiate itself from sibling tools like 'convert' or 'convert_many', which could plausibly do the same job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 the several time-related siblings ('now', 'convert', 'convert_many', 'dst_changes', 'business_days'). There is no mention of exclusions, prerequisites, or conditions that would select this tool over an alternative.
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?
With no annotations, the description carries the full burden and it does add beyond-schema value: it states the return payload ('a count of the blocks written, by type'), important since no output schea exists, and the policy 'Free and unlimited'. It does not describe failure behavior when a file already exists or conversion errors, though the overwrite default is already captured 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the core purpose front-loaded in the first. The imperative 'Call this tool to' is slightly redundant framing and 'Free and unlimited' is ancillary, but overall the text is compact, scannable and every substantive piece 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 5-parameter tool with 1 required and no output schema, the description plus schema covers the essentials: purpose, return value, parameter defaults and overwrite policy. It is weak on routing among the many document siblings and silent on error/conflict behavior, but for a simple conversion tool this is adequate rather than deficient.
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 80%, above the high threshold, so the baseline applies. The description adds no parameter-level meaning: the markdown parameter is already extensively documented in the schema and the style enum values are self-seplanatory. The mention of block counts hints at supported constructs but adds nothing beyond the schema's list of headings, lists, tables and code blocks.
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 descrition uses a clear verb+resource framing: 'turn markdown into a .docx', with the title 'Markdown to Word' reinforcing the same conversion. It is unmistakably a markdown-to-docx converter and the direction implicitly sets it apart from siblings like resume_to_markdown and doc_to_html, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this tool to turn markdown into a .docx' is an explicit invocation instruction, giving an agent the canonical use case. However, no alternatives or exclusions are provided, which matters here because the sibling list contains plausible adjacent document tools (doc_to_html, doc_create, convert, proposal_create) that an agent might conflate with this one.
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?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the most important behavior: this is a partial update and omitted fields are left untouched. It does not mention validation behavior, permissions, side effects, failure modes, or the return value, leaving moderate transparency gaps.
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?
Two short sentences with no filler. The key partial-update caveat is stated immediately after the action, making the description easy to scan and process.
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 11-parameter mutation tool with no annotations and no output schema, this description is under-specified. It gives enough to attempt a simple edit, but does not explain return semantics, error/validation behavior, or the meaning of several fields, so an agent cannot fully predict the outcome of calling 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?
The schema documents only 6 of 11 parameters (55%), so field descriptions are incomplete. The description adds a useful generic semantic—only supplied fields are changed—which affects how all parameters should be interpreted. However, it does not clarify ambiguous fields like task, project, tags, note, or billable, so the added parameter meaning is shallow.
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 ('Change fields') on a specific resource ('existing entry'), and the title clarifies it is a time-entry edit. It is distinguishable from entry_add, entry_delete, and entry_list, though it does not explicitly name an alternative, so it stops short of 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing entry' implies this tool is for modifying already-created time entries, and 'Only the fields you pass are changed' implies a partial-update workflow. However, there is no explicit when-to-use/when-not-to-use guidance or routing to entry_add/entry_delete, so 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?
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?
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?
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 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?
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
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?
No annotations are provided, so the description carries the full behavioral burden. It mentions grouping and per-currency totals but does not explicitly disclose read-only behavior, the clamping behavior on the free tier, the default unbilled_only behavior, or the output shape. These gaps are partially covered by the schema, but the description itself adds little beyond a summary.
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 two sentences, front-loads the main purpose, and avoids excessive detail. The phrase '(group by)' is slightly redundant, but overall every sentence contributes useful 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?
For a reporting tool with six parameters, a rich schema, and no output schema, the description provides the essential context: period-based timesheet totals, grouping options, and the plain-total fallback. It does not spell out return values, but the format parameter and schema descriptions cover the remaining details.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining why group_by exists ('hours per project, how much to bill') and what omitting it produces ('the plain total per currency'), which goes beyond the schema's parameter names and enums.
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 resource ('Timesheet report') and the core output: total tracked hours and billable money for a period, optionally grouped by project, day, task, or tag. It is clear enough to distinguish from sibling tools like invoice_summary or forecast, though it uses a noun phrase rather than an explicit verb like 'generate' or 'show'.
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?
It gives practical guidance for the group_by parameter ('Omit group_by for the plain total per currency') and implies a billing/timesheet use case. However, it does not explicitly say when to use this tool instead of alternatives such as invoice_summary or forecast, nor does it state any 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?
No annotations are present, so the description carries the full burden. It mentions the 'Pro' revision-count behavior but omits error handling, precedence rules, or 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?
A single sentence that is compact and directly states the action, target, and notable output 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?
Describes the return value but leaves gaps around parameter requirements, not-found behavior, and interaction between id and title. Adequate for a simple read but 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 covers both parameters with short descriptions; the tool description repeats them but adds little beyond the schema, so it meets the baseline for high 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?
States a specific verb ('Return') and resource ('a clause in full'), with details about variables and revision count that distinguish it from list/search operations.
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?
Clearly indicates retrieval by id or title, but does not explicitly mention when to prefer list/search alternatives or what happens if both parameters are omitted.
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?
With no annotations, the description carries the responsibility of disclosing behavior, and it does add important context: Pro keeps a version of the previous text while the free tier overwrites without history. This is a meaningful behavioral caveat beyond the schema. It does not cover return values or permission requirements, but the key side-effect is stated.
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?
Two concise sentences with no wasted words: the first states the operation and its targets, the second adds the critical versioning caveat. The information is front-loaded 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 description includes the core purpose and a notable behavioral distinction, but it leaves gaps around the full set of mutable fields and the actual meaning of 'text' versus 'body'. With no output schema and no annotations, an agent may not know what response to expect or how to set fields like language or title. This is a moderate gap rather than a severe one.
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 only 13% (only 'id' is described), so the description must compensate. It lists several updatable fields but uses 'text' where the schema property is 'body' and omits 'title' and 'language', leaving the parameter mapping ambiguous and incomplete. This is insufficient for an agent to confidently construct a full update request.
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 ('Change') and resource ('clause'), and it names several mutable fields, which clearly conveys the update intent and distinguishes it from sibling tools like clause_add or clause_delete. However, it omits 'title' and 'language' from the field list, so its differentiation is slightly incomplete.
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 wording implies updating an existing clause rather than creating or deleting one, but there is no explicit statement of when to prefer this tool or avoid alternatives. With many sibling tools in the same domain, an agent has to infer the usage context from the action verb and field list.
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?
With no annotations, the description carries the behavioral burden. It usefully discloses that re-importing a name replaces the existing entry and that URL feeds are a Pro feature, but it does not describe the return value, success/failure behavior, or persistence semantics beyond 'keep it under a 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?
Three compact sentences, front-loaded with the main action and no filler. Each sentence contributes a distinct piece of information: the operation, the input modes, provider compatibility, and overwrite behavior.
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?
Inputs and the important replace-on-reimport behavior are covered, and the schema documents all four parameters. However, because there is no output schema and no annotations, the agent is left without any stated return value or error semantics, which is a meaningful gap for an import 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 description coverage is 100%, so the baseline is 3. The main description adds helpful context by naming path, text, and URL as input alternatives and noting Pro for URLs, but it does not clarify whether exactly one source is required or what happens if multiple are supplied.
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?
States a concrete action: read an .ics export and store it under a name. It clearly identifies the resource and avoids tautology, though it does not explicitly differentiate itself from sibling calendar tools like ics_create or ics_forget.
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?
Opens with a direct 'Call this tool to...' directive, so the primary use case is clear. It names the three input modes and flags the Pro requirement for URLs, but gives no explicit when-not-to-use guidance or routing among the many calendar-related siblings.
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?
No annotations are provided, so the description carries the burden; 'list' signals a read operation, and the filter phrase indicates behavior. However, it does not disclose pagination, ordering, whether unfiltered means all invoices, or the response shape, leaving clear gaps.
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 with no filler; the action and all filters are front-loaded. Every part 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 and all parameters are named, but with no output schema and no sibling differentiation, the definition omits return format, default scope, and pagination/ordering behavior. Functional enough for a basic call, but 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?
The description maps all four parameters to meaningful filter categories and adds 'issue-date range' context for to/from. With schema coverage at 50%, client and status receive no additional meaning beyond their parameter names/enum, so it partially but does not fully 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?
States the verb 'List' and the resource 'invoices', and enumerates the filtering dimensions (status, client, issue-date range). It is clear on its face, though it does not explicitly contrast with sibling tools like invoice_get or invoice_summary.
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 'optionally filtered' phrasing implies the tool is for fetching multiple invoices and can be narrowed by criteria, but it does not state when to prefer this over invoice_get (single invoice) or invoice_summary (aggregates), nor give 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context: the data source (shared profile from mcp-invoice and mcp-docx), the placement (footer), and page coverage (every page). However, it does not disclose whether the source file is modified vs. a new file is written, and the trailing 'Pro.' hints at licensing/feature gating without explaining it — a meaningful transparency gap for a write operation.
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 core guidance is compact — two substantive sentences plus a one-word tail. However, 'Call this tool to' is filler that restates the title, 'from the shared profile mcp-invoice and mcp-docx write' is grammatically tangled, and the standalone 'Pro.' contributes nothing actionable. The useful information is front-loaded but the presentation is sloppy.
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 writing tool with no annotations and no output schema, the description covers the core what and when adequately, and the shared-profile sourcing explains where the business data comes from. Gaps remain: the ambiguous 'Pro.' licensing implication, no reassurance about whether the source PDF is left untouched, and no contrast with pdf_stamp for generic watermarking needs. It is sufficient for a capable agent to invoke correctly, 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?
Schema description coverage is 100%, so the schema fully documents all four parameters (path, out_path, pages, overwrite), establishing a baseline of 3. The description adds the high-level semantic context that the watermark content is business name and VAT id, but it adds no per-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 states a specific action (put business name and VAT id in the footer of every page) and identifies a clear resource (PDF documents). The business-specific scope and the shared-profile source implicitly differentiate it from sibling pdf_stamp, though that contrast is not explicit. The awkward phrasing of 'from the shared profile mcp-invoice and mcp-docx write' and the cryptic trailing 'Pro.' slightly cloud an otherwise 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage timing: 'Use it before sending a document out.' It also implies the condition for use — documents that should carry the business identify from the shared profile. It does not name alternatives (e.g., pdf_stamp) or state when not to use this tool, so it falls short of a 5.
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?
With no annotations, the description bears the full behavioral disclosure burden. It clearly signals a read-only operation by saying 'Return the stored profile', which is the primary behavior. However, it does not describe how optional parameters affect the output or what the markdown contains, leaving behavioral details under-specified.
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 that front-loads the core operation and then lists concrete use cases. Every word serves a purpose, with no redundant or vague phrasing. It is an example of concise, well-structured documentation.
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 optional parameters that are wholly undocumented, no output schema, and no annotations. The description explains only the general retrieval action but leaves critical context missing, such as how variant and target_role modify the output and what max_pages restricts. An agent would be uncertain how to make a tailored call.
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 0% and the description adds no information about any of the three parameters: variant, max_pages, or target_role. An agent would have to guess their meanings from names alone. The description fails to compensate for the lack of schema 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 uses a specific verb, 'Return', and identifies the resource: 'the stored profile as markdown'. It also lists concrete use cases (form, email, ATS box), which helps distinguish it from the sibling resume_to_html. 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: whenever markdown output is needed for pasting into forms, emails, or ATS systems. It does not explicitly name alternatives or exclusionary scenarios, but the use-case context makes the appropriate situation clear.
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?
No annotations are provided, so the description must disclose behavior. It does: events must not have started yet, the lookahead is up to a year, and the output includes how long until the event begins. It does not cover the no-event-in-range case, but for a simple read-style tool the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences with no filler. The key criteria and output are front-loaded, and every clause adds 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?
For a tool with one optional parameter and no output schema, the description covers what 'next' means, the one-year horizon, and the countdown output. The schema supplies the calendar default, and no major operational detail is missing for this simple 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 already fully describes the sole parameter, calendar, including its optionality and default to every imported calendar. The description adds nothing beyond the schema, 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 the resource and the selecting behavior: the next event that has not started yet, with time until it begins. It is distinct from the listing/search siblings because it returns a single future event, though it does not explicitly name any 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 statement about when to use next_event versus events_list, events_search, free_busy, or calendars_list. The intended context is only implied by the tool name and semantics, not explicitly communicated.
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?
No annotations are provided, so the description carries the full burden. It discloses the return shape (cadence, amount, due date, status) but does not mention pagination, ordering, or the behavior when the optional status filter is used. For a simple read-only list operation this is adequate, but it leaves some behavioral details unstated.
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 that packs the entire output contract into a readable form with zero filler. The key output fields are front-loaded and each 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 straightforward list operation with one optional enum parameter and no output schema, the description is largely complete: an agent knows what the tool returns. It would be more complete if it explicitly connected the status parameter to filtering, but the schema's enum makes that inferable. The lack of pagination/ordering details is a minor gap for this simple tool.
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 optional status parameter with an enum, but the description never explains that this parameter filters results by status. It mentions 'status (active or paused)' only as part of the output, which could mislead an agent into thinking the parameter is merely echoed in results. With 0% schema description coverage, the description needed to clarify the parameter's role.
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 returns every schedule and enumerates the exact fields included (cadence, per-period amount, next due date, status). This clearly identifies the resource and the nature of the operation. It doesn't explicitly differentiate from schedule_get or schedule_upcoming, but the phrase 'Every schedule' strongly signals this is the list-all tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's context clear: it returns all schedules with specific fields. No alternatives or exclusions are mentioned, but the tool's name and the 'Every schedule' wording provide enough context for an agent to know when to use it versus schedule_get or schedule_upcoming. A brief mention of alternatives would earn a 5, but the context is otherwise unambiguous.
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?
No annotations are provided, so the description carries the full burden. It does disclose the free-tier truncation behavior and the output fields, which is useful. It does not mention read-only status, ordering, timezone, or whether already-overdue items are included, so transparency is partial.
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?
Two sentences, front-loaded with the core output, and no filler. The free-tier limitation is important context and is kept brief, though it overlaps with the schema 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?
For a simple one-parameter read tool with no output schema, the description covers the essential return values and the key free-tier constraint. It is complete enough for an agent to call it correctly, though details like ordering or grouping of currencies are left implicit.
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 days parameter description already covers default, horizon, and free/Pro behavior. The tool description adds little beyond restating 'next N days' and the free-tier first-3 occurrences behavior, so it does not meaningfully expand 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 what the tool returns: a table of schedule occurrences due in the next N days, with amount per occurrence and total per currency. It is distinguishable from siblings like schedule_list or schedule_get by its focus on upcoming due occurrences, though it does not explicitly name an alternative.
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 'next N days' and 'falling due' language implies this is for due-date lookahead queries, but there is no explicit guidance about when to choose this over schedule_list, schedule_get, or schedule_history. Usage context is implied rather than 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?
With no annotations, the description carries the full burden of disclosing behavior. It lists the statistics computed but does not state whether the tool is read-only, whether it modifies the file, how missing values are handled, or what happens with unsupported file types. This lack of side-effect clarity is a gap.
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 brief and front-loaded, with the key usage directive in the first sentence and the statistical capabilities listed in the second. There is no redundant or filler content.
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?
The description covers what the tool does and what statistics it returns, which is sufficient given the lack of an output schema. It does not describe error cases or edge cases, but the core behavior is adequately specified.
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 path parameter is explained by the description ('spreadsheet or CSV file path'), and the columns parameter has a schema description. However, the sheet parameter has no explanation and is not discussed in the description, so one of three parameters is not adequately documented.
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 identifies the tool's purpose: computing whole-column statistics (count, empty, distinct, min, max, sum, mean, median) from spreadsheet or CSV files. It also distinguishes this tool from ordinary file readers by stating that built-in file readers cannot parse spreadsheets.
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 gives some usage context: use it for spreadsheet or CSV file paths when built-in file readers are unsuitable. However, it does not explicitly contrast this tool with sibling tools like sheet_read, sheet_query, or sheet_find, nor does it state when to prefer one of those 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?
With no annotations, the description carries more burden, and it does disclose the write side effect and the return payload (rows, columns, byte size, column names). However, it does not describe clobbering behavior, preservation of other sheets, or failure conditions; these are left mostly to the schema's mode descriptions rather than the tool 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?
A single sentence with no filler, front-loading the primary action and the key return information. Every part of the sentence contributes to understanding the tool's purpose and output.
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?
The schema is rich enough to cover the parameters, and the description fills the missing return-value information plus file-type scope. It could also mention mode side effects or route to sibling tools, but the essential invocation context is present.
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 mode, path, rows, sheet, and out_path are all explained in the schema. The description itself adds no parameter-level nuance, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('write rows') and a concrete resource ('an excel (xlsx) or csv/tsv/json file'), and it also states what the tool returns. This clearly separates it from read/query/find siblings by the write 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?
The opening 'Call this tool to write rows...' is a direct instruction but not usage guidance. It does not mention when to choose this over sheet_read, sheet_query, or sheet_convert, nor does it explain prerequisites or when append vs overwrite vs new_file should be selected.
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?
With no annotations, the description carries the burden. It discloses that it re-fetches, appends new observations (a write operation), and returns specific metrics. However, it does not mention potential side effects like generating alerts, rate limits, or whether it is long-running. The schema description adds 'Nothing runs in the background', but that is not in the main 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 sentence that front-loads the purpose ('This is what actually checks prices') and then lists the key behaviors and return values. It is concise and every clause adds value, though it could be split into clearer sentences for readability.
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 explains what the tool does and what it returns, which covers the core functionality. However, it omits important contextual details like the recommended usage pattern (call once per session, then read alerts_pending) which is only present in the schema description. There is no output schema, so the return fields are described, but side effects or prerequisites are not fully 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?
The input schema covers 100% of the parameters (id and all) with clear descriptions. The description adds little beyond the schema: it mentions 'one watch or every watch' which mirrors the schema. No extra parameter-specific semantics are provided.
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: 're-fetches one watch or every watch' and the resource 'watch'. It lists the exact return data (current, previous, min, max, change %, extraction confidence, target hits), making it distinct from siblings like price_check (likely a one-off check) or price_history (likely returns historical data without refreshing).
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 only hints at usage with 'This is what actually checks prices' but does not explicitly state when to use this tool vs alternatives or mention exclusions. However, the parameter schema for 'id' includes guidance ('call this whenever the user asks about prices, drops or alerts - typically once at the start of a session, then read alerts_pending'), which is part of the tool definition but not in the main description text.
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?
With no annotations, the description carries the behavioral disclosure burden. It adds meaningful traits: the forecast is 'expected' rather than actual, it aggregates by calendar month and currency, it draws from 'every active schedule', and it varies by plan tier. It does not mention return format or error behavior, but the core behavioral scope and limitations are conveyed.
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 two concise sentences with no filler. The main purpose and output granularity are front-loaded, and the plan limitation is stated efficiently in the second sentence.
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 single-parameter tool with no output schema and no annotations, the description explains what the result contains, the data source, the time horizon, and plan-based limits. It lacks explicit mention of the response structure or error conditions, but the tool is simple enough that agents have sufficient context to invoke it correctly.
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?
Schema coverage is 100% and already documents months as an integer with min, max, and default. The description adds valuable plan-dependent semantics: Free accounts are limited to 3 months while Pro allows up to 120. This helps an agent decide whether a requested months value is feasible before calling.
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 defines the tool as producing expected invoiced revenue per calendar month per currency, with the scope being active schedules. This is more specific than a bare restatement of the title, but it does not explicitly differentiate from close sibling tools like invoice_summary or overdue_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 direct 'use this when' guidance, nor does it name alternatives or exclusions. The Free/Pro month limits imply some usage constraints, but there is no explicit advice on when to choose this tool over its finance-focused siblings.
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?
With no annotations provided, the description carries the full behavioral burden. It does disclose a genuine side effect — persistence to a shared profile consumed suite-wide — and the one-time intent ('Call it once, first'). However, it does't state whether a subsequent call with only a subset of fields merges into or overwrites previously stored values, nor does it mention any return/confirmation, both of which matter for a write tool with 15 optional fields.
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?
Two sentences with the scoping claim front-loaded. The content list, persistence fact, and usage directive each earn their place, and there is zero filler. The emphatic 'ONE' may be stylized but it functionally reinforces differentiation from sibling tools.
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-time setup call, the description covers scope, contents, persistence, and invocation order, and the rich schema covers parameter details. The remaining gaps are partial-update semantics on re-invocation (merge vs overwrite) and explicit routing relative to docx_business_set; with no output schema there is no hint at the return either.
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 baseline is therefore 3. All 16 fields are already documented in the schema, including alias relations (vat/tax_rate/vat_rate → default_tax_rate) and the conditional email/phone rules. The description adds only high-level category grouping (name, address, VAT id, bank details, defaults) and no per-parameter 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 identifies the resource — the single suite-wide business profile — and enumerates its contents (name, address, VAT id, bank details, defaults). It differentiates from siblings by declaring itself 'THE ONE...for the whole suite' and stressing that 'every other server reads' it, which separates it from docx_business_set and prophile_set/prophile_get, though it never naes 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call it once, first' is an explicit temporal instruction placing this tool before any other invoicing work, and the claim that the profile is what 'every other server reads' tells the agent this is the shared setup entry point. No when-not-to-use guidance or naed alternatives are given, so it doesn't quite reach a 5.
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?
With no annotations, the description carries the burden and does add some transparency by stating it returns an output path and recommending the browser/PDF workflow. However, it does not disclose overwrite behavior or other side effects beyond writing; the overwrite semantics live only in the parameter schema, not in the tool 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 short and front-loaded, with three sentences that convey purpose, return value, and next step. Minor filler like 'Call this tool' is present, but it is still 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 5-parameter tool with no annotations and no output schema, the description covers the main workflow but leaves important aspects unaddressed: what variant and target_role control, and how overwrite behaves. The schema partially fills this, but the description alone is not fully complete.
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 only 60%, and variant and target_role have no descriptions in the schema. The tool description does not compensate for these gaps; it only indirectly refers to out_path via 'Returns the output path'. It adds no meaning for the undocumented 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 states a specific action ('write the resume'), a specific resource ('the resume'), and the output form ('semantic HTML with a print stylesheet'). It clearly distinguishes this from sibling resume_to_markdown by calling out the HTML and print-stylesheet behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: use this when the goal is printable resume HTML, then open in browser and print to PDF. It does not explicitly name alternatives or exclude Markdown, so it misses the top score but is still clearly actionable.
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?
With no annotations, the description must carry the behavioral burden. It discloses that the tool parses spreadspreadsheets and performs filter/group/aggregate/sort operations in one call. It does not state whether the file is modified, nor describe output shape or defaults, but the query-oriented wording implies a read-only transformation, leaving room for more 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?
Two sentences with no filler: the first routes to the right class of files, the second states the core multi-operation behavior and gives a concrete filter example. It is front-loaded and every sentence 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 has 9 parameters, nested aggregate objects, and no output schema, so a minimal viable description needs more than two sentences. The schema covers most parameters, but the description does not explain return shape, default limit, or when to prefer sibling tools like sheet_read or sheet_stats. It 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?
Schema description coverage is 78%, so most parameters are already documented. The description adds the helpful where-syntax example ('[Qty] > 10') and reinforces the combined query capability, but it adds no meaning beyond the schema for group_by, aggregate, sort, or the as output enum. 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 specific operation verbs ('Filters, groups, aggregates and sorts in one call') and identifies the target resource (spreadsheet or CSV path). It also clearly distances itself from built-in file readers. However, it does not explicitly contrast with sibling spreadsheet tools like sheet_read, sheet_stats, or sheet_find, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing: call this tool for any spreadsheet or CSV file path, and warns that built-in file readers must not be used for them. This is clearer than implied usage. It lacks explicit guidance on when to choose this over sibling sheet_* tools, but it does provide a clear context and an exclusion.
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?
There are no annotations, so the description carries the behavioral burden. It discloses the primary side effect ('Save'), and explicitly states what the operation returns: stored clause id, title, category, tags, detected variables, and the updated count of owned clauses. This gives the agent a concrete model of the operation's effect, though it does not cover duplicate handling, permissions, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action first and then the return value. Every phrase contributes useful information, and there is no filler, repetition, or unnecessary background.
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?
With no output schema, the description provides a helpful list of return fields and gives the agent a clear sense of the operation's outcome. The input schema covers parameter details thoroughly. It is not fully complete because it omits the output format and any caveats about limits or duplicate titles, but those are not critical 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?
Schema description coverage is 86%, so the structured schema already documents most parameters well. The description adds only a small amount of parameter-related meaning by mentioning that variables are 'detected in its body,' which relates to the body placeholder behavior already covered in the schema. No further compensation is required.
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: 'Save a reusable contract or proposal clause to the library.' This clearly indicates a creation/persistence operation and makes the tool understandable next to siblings like clause_update, clause_delete, and clause_get. However, it does not explicitly distinguish itself from clause_import or other similarly named tools.
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 this tool is for adding a new clause to the library, which is clear context for creation. It does not explicitly state when to prefer this over clause_update, clause_import, or contract_assemble, nor does it mention any exclusions or 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?
No annotations are provided, so the description carries the full behavioral burden. It discloses one valuable non-obvious trait — 'A deleted starter clause is not re-seeded on the next call' — which tells the agent the deletion is persistent even for starter clauses. However, for a destructive operation it does not disclose cascading effects on contracts assembled from the clause, idempotence when the id does not exist, or reversibility, leaving significant behavioral gaps.
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?
Two sentences, each earning its place: the first states the primary action, the second adds a crucial behavioral caveat about starter clauses. The main action is front-loaded and there is no filler or redundant restating of the title.
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 tool — one required parameter, full schema coverage, no output schema — the description covers purpose and the key persistence behavior. Minor gaps remain: behavior when the id or title does not match any clause, and whether deleting a clause impacts contracts that reference it. These are moderate but not blocking for a single-parameter 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?
Schema description coverage is 100% — the 'id' parameter is documented as 'Clause id or exact title' — so the baseline of 3 applies. The description adds no parameter-level detail, such as how to resolve an exact title or what happens when the id is not found. The schema carries the full weight, and the description does not compensate beyond it.
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 verb and resource: 'Remove a clause from the library.' This clearly distinguishes the tool from its siblings — clause_add, clause_get, clause_update, clause_list, clause_search — which perform different operations. The title and description align, so an agent can identify the tool's purpose without opening 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb: an agent can infer this tool is for removing a clause. However, the description gives no explicit when-to-use or when-not-to-use guidance, and does not mention alternatives such as clause_update for editing instead of deleting or clause_search for locating the clause first. The re-seeding caveat is more behavioral context than routing guidance.
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?
No annotations are provided, so the description must carry behavioral disclosure. It does state ordering ('newest categories first') and the read-only nature implied by 'List', but the ordering phrase is ambiguous and pagination, return format, or potential limits are not disclosed. It adds some behavior context but not full clarity.
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 filler and the core action is front-loaded. The phrase 'newest categories first' is somewhat awkward but the description remains appropriately compact.
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 list tool, the description covers the core scope and filtering behavior. However, the ambiguous ordering phrase and complete lack of output/return details, especially with no output schema or annotations, leave a meaningful gap for an agent trying to reliably use the result.
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 one undocumented 'category' string with 0% description coverage. The description compensates by explaining that the list can be 'narrowed to one category,' giving the parameter a clear role. It does not enumerate valid values or format, but for a simple optional filter this is sufficient.
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 a specific verb and object: 'List every clause.' It also states the optional category filter, which clearly distinguishes this broad listing tool from focused retrieval tools like clause_get or clause_search. The resource and scope are immediately understandable.
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: use this to list all clauses, optionally filtered by category. However, it does not explicitly contrast with clause_search or clause_get, and provides no when-not-to-use guidance. Context is present but exclusions and alternatives are left to inference.
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?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the output is a template skeleton for lawyer review, explicitly states it is not legal advice, and mentions the free tier limit of 3 agreements per month. It does not detail file overwrite behavior, but the schema already covers that through the overwrite parameter.
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?
Three concise sentences with a clear front-loaded action, followed by return value note, legal disclaimer, and usage limit. Every sentence contributes information without repetition or filler.
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?
The description covers the key non-schema information an agent needs: what is produced, what is returned, the legal nature of the output, and a usage restriction. Since there is no output schema, the minimal return-value disclosure is helpful, though it could be more explicit about error cases or quota enforcement details.
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 89%, so the input schema already documents most parameters in detail. The description adds little beyond mentioning that the fee and file path are returned, which does not directly clarify parameter semantics. It neither compensates for undocumented parameters nor adds meaningful input guidance 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 states a specific action ('produce') and resource ('freelance service agreement .docx'), making the core purpose clear. It does not explicitly distinguish itself from related sibling tools like contract_assemble or proposal_create, but the type of document is specific enough to guide selection.
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?
It gives a direct imperative ('Call this tool to produce...'), which clearly indicates the intended use case. However, it does not mention alternatives or when not to use it, and with siblings like contract_assemble nearby, the lack of routing guidance leaves some ambiguity.
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?
There are no annotations, so the description carries the burden of explaining behavior. It discloses that the tool writes a cover letter, uses the stored profile, and returns the output path, word count, and unresolved bracketed prompts. It does not mention overwrite/failure behavior or the need for a pre-existing profile, but the write action is explicit.
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 two concise, front-loaded sentences. It states the action and scope immediately, then adds valuable return-value context. There is no filler or redundant rewording of the schema.
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 an 8-parameter tool with no annotations and no output schema, the description covers core returns and document scope, but omits required parameters, preconditions, overwrite semantics, and how to choose this over resume_create/proposal_create. It is minimally viable but has clear gaps.
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 only 63%, and the description adds little per-parameter meaning. The 'bracketed prompt' phrase echoes what the highlights schema already says; parameters like role, company, and hiring_manager remain undocumented in both the schema and description.
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 verb ('write'), a specific resource ('one-page cover letter'), and a clear source ('from the stored profile'). It also gives the document structure ('opening, fit, proof, close'), which distinguishes it from sibling tools like resume_create or proposal_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use it: when a one-page cover letter should be written from the stored profile. It does not name alternatives or exclusions, but the intended trigger is clear enough for an agent to select it appropriately.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully communicates recurrence expansion, sorting by start, timezone fallback behavior, and ID reusability. It does not describe response shape or pagination, but still provides meaningful behavioral context beyond a simple 'list events' 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?
Three short, information-dense sentences: the first states scope and ordering, the second clarifies timezone behavior, and the third explains useful downstream tool compatibility. Every sentence earns its place with no filler.
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 no output schema, the description covers the essential behavioral context: date window, recurrence expansion, sorting, timezone handling, and ID usefulness for related tools. It does not detail the response envelope, but the gap is modest given the clear scope and title.
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 already documents all four parameters with 100% coverage, so the description does not need to define them. It adds one useful nuance about the 'zone' parameter and local time display, which goes slightly beyond the schema, but the schema remains the primary source of parameter 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 core behavior is clear: 'Every event between two dates, recurring expanded to occurrences, sorted by start' names the resource and the operation. It does not explicitly contrast with sibling tools like events_search, so differentiation is implied 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving all events in a date range and notes that resulting IDs work for event_export or event_to_time_entry. However, it does not explicitly say when to use events_list versus events_search, free_busy, next_event, or other calendar-related siblings.
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?
With no annotations, the description carries the transparency burden. It does disclose return content (UTC instant, local time per participant, fairness score) and ordering, but it leaves side-effect/read-only status implicit and does not mention behaviors like saved-contact resolution or free-tier truncation, although some of those appear in the schema descriptions.
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?
Two concise sentences lead with the core action and then describe the output shape and ordering. No filler, no repetition of schema content, and every sentence 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?
There is no output schema, but the description usefully summarizes the return values, and the rich parameter schema covers the inputs thoroughly. It is complete enough for correct invocation, though explicit usage guidance and side-effect disclosure would make it fully self-sufficient without 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?
Schema description coverage is 100%, so the schema already explains every parameter. The description adds context about output format and ranking but no additional parameter-level meaning, matching the baseline of 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 uses a specific verb ('Rank') and clear resource ('times when every participant is inside their own working hours'), and separates this tool from siblings like free_busy or conflicts by describing the fairness-ranked slot output. The title and description together leave no ambiguity about 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: the tool clearly exists for finding mutually workable meeting times across participants. However, it does not explicitly say when to choose this over alternatives like free_busy, conflicts, or overlap, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the return value and its purpose, but does not explicitly state read-only/non-mutating behavior, rate source, freshness, or error conditions. It is adequately transparent for a lookup, but not exhaustive.
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?
Two compact sentences, front-loaded with when to use, followed by the return contract. No filler or redundancy.
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 tool with a thorough schema, the description covers when to call it and what it returns. The main gap is that the output shape is defined only by reference to 'expense_to_invoice', which may be ambiguous if that concept isn't known to 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 description coverage is 100%, with good detail about target, currencies, direction, and defaults. The description adds no additional parameter meaning beyond what the schema already explains, 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?
clear and specific: it is a call-to-get FX rates for multi-currency invoices/rebills, returning a shaped object and rate date. It does not explicitly contrast itself with sibling rate tools like rates_latest or convert, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger condition (rebill or invoice spans more than one currency) and an explicit alternative (asking the user for rates). It lacks comparison to sibling FX rate tools, so it doesn't fully cover when-not-to-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?
The description reveals that a new PDF is written and warns that every page must appear exactly once to avoid drops. But with no annotations, it does not disclose failure behavior, whether the original file is left untouched, or whether out_path can overwrite an existing file. The core behavior is clear, but the mutation safety profile is incomplete.
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 short and front-loaded with the key purpose and constraint. The trailing 'Pro.' appears to be a truncated or meaningless fragment, which slightly hurts polish, but the overall structure is efficient and 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?
For a simple reorder operation, the description gives the essential information: write a new PDF, preserve all pages exactly once, and use pdf_pages for subsets. However, with no output schema or annotations, it leaves gaps around return values, error cases, and out_path behavior. It is adequate but 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 coverage is fair: path and order have useful descriptions, and order is well explained. The description adds the idea of 'write a new PDF' but does not clarify out_path semantics beyond what the schema's type implies. It does not explain overwrite behavior or whether out_path may equal path.
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 and resource: 'write a new PDF with pages in the order you give.' It clearly identifies the function and distinguishes it from pdf_pages, which handles subsets. The purpose is unambiguous and easy to act on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to call the tool and directs the agent to pdf_pages for subset operations. It also clarifies the exact ordering constraint. However, it does not mention other alternatives like pdf_merge or pdf_split, though those are less directly related.
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?
With no annotations, the description carries the transparency burden. It conveys a read-only audit-log operation and states exactly what will be returned: every generated period, invoice number, dates, amount, and PDF path. It does not cover licensing/Pro requirements or error cases, but the core behavior is clearly disclosed.
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 one focused sentence that front-loads 'audit log for one schedule' and then compresses the return fields into a clear colon-delimited list. Every clause adds information; there is no filler, repetition, or unnecessary detail.
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 one-parameter, low-complexity read tool with no output schema, the description is complete enough: it names the schedule scope and the returned fields. An agent can select and call the tool correctly with a schedule id; missing pagination or exact JSON shape is not essential here.
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 only defines a required string id with no description, so the description must compensate. The phrase 'for one schedule' tells the agent that id refers to the schedule whose history should be retrieved, which is the essential semantic for this single-parameter tool.
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 resource as one schedule's audit log and enumerates the returned contents—generated periods, invoice number, dates, amount, and PDF path—so an agent can understand it is a historical read. It does not use an explicit action verb such as 'get' or 'list,' and it does not explicitly contrast with sibling schedule tools like schedule_get or schedule_upcoming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 schedule_history rather than schedule_get, schedule_upcoming, or schedule_list. It implies a schedule id is needed by saying 'for one schedule,' but it gives no explicit context, prerequisites, or alternative routing.
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?
With no annotations, the description carries the burden of behavioral disclosure. It states what the tool returns (sheet names, size, header row, column types, samples) and implies a read-only overview operation, but it does not explicitly say whether it modifies anything, how errors are handled, or how 'size' and 'samples' are defined. This is adequate but not deeply transparent.
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?
Two sentences with no filler. The first sentence leads with when to call the tool and the prohibition on built-in readers, and the second compactly lists the returned overview contents. Every phrase 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 one-parameter overview tool, the description covers the trigger, the supported file types, and the key return elements. It lacks an explicit output structure and more detail on relationship to sibling sheet tools, but it is sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single required path parameter with supported extensions and tilde expansion. The description only restates 'any spreadsheet or CSV file path,' adding no new semantic detail beyond the schema, so the 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 this as the entry point for spreadsheet and CSV files and specifies the exact overview contents: sheet names, size, header row, column types, and samples. It distinguishes from built-in file readers, but it does not explicitly contrast it with sibling tools like sheet_read or sheet_query, so it stops just 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call this tool for any spreadsheet or CSV file path and warns that built-in file readers cannot parse spreadsheets and must not be used. 'Start here' gives a clear sequencing cue, but it does not name the sibling alternatives for subsequent data access, so the guidance is strong yet not fully alternative-aware.
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?
With no annotations, the description carries the burden. It discloses plan-dependent default time ranges, giving some insight into behavior, but it does not explicitly state that the operation is read-only or describe any side effects, rate limits, or data sensitivity.
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 two concise sentences, with the main purpose stated upfront and additional behavior details in the second sentence. No fluff or redundancy is present.
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?
In the absence of an output schema, the description does not clarify the return format (e.g., list of event objects, count, metadata). While 'find events' implies a result set, the lack of detail on what the response contains could leave an agent uncertain about downstream processing.
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?
Schema coverage is 100%, and the description adds meaningful context by explaining how from/to behave when omitted (default windows) and what fields are searched. This goes beyond the schema's simple date and query definitions, providing practical usage 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 ('find') and clearly identifies the resource (events) and the search scope (title, description, location, attendees). It distinguishes this from a plain listing tool by emphasizing the phrase search across imported calendars.
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?
It states that it searches every imported calendar and describes default date windows based on plan, but it does not explicitly mention when to prefer this over sibling tools like events_list or how it differs from them. Guidance on when-not-to-use or alternatives is missing.
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?
With no annotations, the description must carry behavioral weight. It does disclose the main side effect (writing a file) and the return values (path and meeting time). However, it does not mention overwrite behavior, whether invites are sent, error handling, or DST edge cases, which leaves important behavior implicit.
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?
Two sentences with no filler. The purpose is front-loaded and the return information is concise and useful. 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 12-parameter tool with no annotations and no output schema, the description is minimal but adequate. The rich schema covers parameter details, but the description lacks explicit sibling differentiation, overwrite/safety behavior, and a fuller picture of the 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no parameter-level meaning beyond saying the meeting time is returned in UTC and the provided zone, which is output behavior rather than 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 states a specific action — write a .ics calendar file for one meeting — and clearly identifies the resource. This distinguishes it from nearby siblings like ics_import and event_export, since the focus is on creating a single .ics file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to call the tool: write a .ics calendar file for a single meeting. It does not explicitly name alternatives or when-not conditions, but the intended use case is unambiguous despite the large sibling set.
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?
With no annotations provided, the description carries the full burden, and it does well by disclosing not just that it returns a record but also the nested richness of that record, including the unusual credit-note-adjusted open balance. It does not discuss error cases or permissions, but the read-only nature is clear from 'Return'.
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 that efficiently conveys the core purpose and key return-value details. The parenthetical '(see credited_minor)' is somewhat cryptic and unexplained, slightly reducing clarity, but overall there is no wasted wording.
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 single-parameter get operation with no output schema, the description covers the essential information an agent needs: what it returns, the scope ('one invoice number'), and notable computed fields. It could be more complete with explicit not-found behavior, but the core call context is adequately covered.
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 only documents 'number' as a string with zero description coverage. The tool description adds that it identifies the invoice, which is minimal but useful; it does not specify format, uniqueness requirements, or how to discover valid invoice numbers.
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 ('Return') with a clear resource ('the full stored record for one invoice number'), making the tool's purpose unmistakable. It also highlights distinctive content (line items, tax breakdown, credit-note-adjusted balance) that separates it from siblings like invoice_summary or invoice_list.
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: when you have an invoice number and need the full record rather than a summary. However, it does not explicitly contrast it with alternatives such as invoice_summary, invoice_list, or invoice_pdf, leaving routing decisions partly to inference.
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?
With no annotations, the description carries the behavioral disclosure burden. It describes what the returned record contains (items, cadence, dates, rules, invoice count), which is useful, but it does not explicitly state that this is a read-only operation or what happens when the id or client name does not match a schedule.
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. It front-loads the core purpose and then lists the meaningful components returned, making it efficient and easy to parse.
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 one-parameter getter with no output schema, the description adequately explains what the tool returns. It covers the main stored-record components and leaves no obvious gap that would prevent 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?
The schema already fully documents the single parameter, including that it accepts a schedule id or client name. The description adds no parameter-level details 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 title and description clearly state a specific verb (get), a specific resource (one schedule), and the scope (the full stored record). This distinguishes it from schedule_list, schedule_upcoming, and schedule_history without needing to inspect those tools.
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 use when the full record of a single schedule is needed, but it does not explicitly state when to use this tool versus siblings such as schedule_list or schedule_upcoming. There is no mention of alternatives or exclusion conditions.
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?
No annotations exist, so the description carries the full behavioral burden. It does disclose that this is a read-style operation ('Show') and specifies what data it returns. It does not, however, describe behavior when no timer is running (error, empty state, or zeroes), which is a meaningful gap for a status tool.
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 zero filler. The primary purpose ('Show the running timer') is front-loaded, and the additional details ('how long it has been running,' 'today's total hours') are packed efficiently into one clause.
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 zero-parameter read tool, the description covers the core return content adequately. The omission of the no-active-timer case is the main gap, and with no output schema available, the agent must guess the return shape when a timer isn't running.
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 an empty object, so there is nothing for the description to add. Per the zero-parameter baseline of 4, this dimension is adequately handled; no param documentation is needed.
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 names a specific verb ('Show'), a clear resource (the running timer), and enumerates exactly what the agent will learn: elapsed running time and today's total hours. It naturally distinguishes itself from sibling mutations like timer_start and timer_stop, which are clearly different operations.
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 intended use is implied well: an agent calls this when asked about the ongoing timer's state or today's hours. However, it never explicitly says when to prefer this over siblings such as entry_list or forecast, nor does it state exclusions or prerequisites (e.g., whether a timer must be active).
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does explain what the tool returns: the business-day count, calendar total, and weekend/holiday counts, which gives a useful model of behavior. However, it does not explicitly state the important limitation that there is no built-in national holiday calendar and that holidays must be passed by the caller; that information exists in the schema instead.
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 two sentences with no wasted words. It front-loads the core purpose, then immediately states the return values, which is exactly the information an agent needs to invoke and interpret the tool correctly.
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 calculation tool with four documented parameters and no output schema, the description is nearly complete: it states the operation, use context, and returned components. The only minor gap is that the description leaves the holiday-calendar limitation implicit, but the schema explicitly covers it, so the agent can still call 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 parameters in detail. The description adds use-case context and return semantics but does not provide meaning beyond the schema for individual parameters. A baseline of 3 is therefore 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 states a specific action and resource: 'Count the business days between two dates in a place.' It also names concrete use cases ('delivery dates and payment terms') and the output components, making the tool's purpose unambiguous. No sibling tool overlaps, so further differentiation is unnecessary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: counting business days in a place, especially for delivery dates and payment terms. It does not explicitly name alternatives or exclusions, but no sibling tool appears to offer the same calculation, so the context is sufficient for an agent to select it.
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?
With no annotations, the description carries the burden and does meaningful work: it discloses ranking precedence, the Pro-only tag filter behavior, and the fallback of skipping rather than refusing. It does not cover output shape or authorization requirements, but the core non-obvious call behavior is surfaced.
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?
Three tight sentences with no filler. The most decision-relevant information (ranked scope, ranking priority, and free/Pro behavior) is front-loaded and each sentence 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 search tool, this is largely complete: it identifies the searchable resource, the ranking behavior, and the filter constraints. The main remaining gap is that the category parameter has no schema description and is only indirectly covered by the phrase 'categories', but this does not prevent a competent agent from 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 schema already describes query, tags, and jurisdiction, so the description adds limited parameter-level meaning. It does clarify category's role by mentioning categories as a search target, and it reinforces the tag-skipping behavior, but it does not substantially go 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?
States a specific verb and object: 'ranked search over clause titles, tags, categories and bodies'. The ranking detail further distinguishes it from a plain list (clause_list) and from other clause tools.
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 this is the right tool when ranked keyword search over clauses is needed, and it explains filter availability. However, it does not explicitly say when to prefer clause_list or other clause tools instead, so usage guidance is mostly implied rather than explicit.
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?
Since no annotations are provided, the description carries the burden of behavioral disclosure. It states that the operation is non-mutating (list), has no filtering ('every stored client'), and reveals the returned fields. It does not mention pagination, sorting, or authorization, but for a simple zero-parameter read-only tool this is sufficient 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, efficient sentence with no redundant wording. It front-loads the core action and scope, then lists the relevant output fields, so every word earns its place.
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 zero-parameter tool with no output schema and no annotations, the description is complete enough for an agent to invoke it correctly. It clearly states the scope ('every stored client') and the fields that will be returned, leaving no significant gap.
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 input schema has zero parameters, so there is no parameter information that the description needs to enrich. The baseline of 4 applies because no parameter semantics are 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 names a specific action and resource ('List every stored client') and specifies the returned fields (id, address, email, VAT id), so it is clear and not a tautology. It does not explicitly name or distinguish itself from sibling list tools such as contacts_list, so it falls 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives, and no sibling tool is referenced. The intended usage is only implied by the action 'List' and the resource 'every stored client'.
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?
With no annotations provided, the description carries the behavioral disclosure burden, and it delivers a clear return contract: path written, clauses in document order, filled variables, and missing facts left as bracketed prompts. This complements the schema's 'never as an invented value' guarantee. It does not explicitly flag the file-writing side effect or overwrite behavior, though those are well documented in the overwrite parameter's schema 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?
Two sentences with zero waste: the first front-loads the action verb and resource, the second packs return-value details into a single dense clause. Every phrase ('path written', 'document order', 'filled variables', 'bracketed prompts'') conveys information not present elsewhere in prepared form.
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 tool with 8 parameters, a nested values object, no output schema, and no annotations, the combination of an exhaustively documented schema and a description that covers return semantics is fairly complete. The remaining gaps are tool-selection guidance against sibling creation tools and a top-level side-effect statement, but the agent can correctly invoke this tool from what is provided.
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 even though the description adds no new parameter-level meaning. The return-value sentence does reinforce the semantics of clause_ids (document order) and values (missing facts stay as bracketed prompts), but the schema already explains every parameter in detail. No uplift above baseline is earned.
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 names a specific verb ('build'), a clear resource ('contract or proposal document'), and the mechanism ('from library clauses'), which separates it from siblings like contract_create and proposal_create. The scope is explicit and an agent can tell this assembly tool apart from the clause-library management tools without inspecting schemas.
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 phrase 'build a contract or proposal document from library clauses' implies the use case: assembling documents from an existing clause library. However, the description gives no explicit when-not-to-use guidance and never names the overlapping siblings (contract_create, proposal_create, doc_fill_template), so routing between those alternatives is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of explaining behavior. It discloses the key output traits: exact UTC instant and offsets before/after the change. This is meaningful for an agent. It could say more about empty results or return shape, but for a simple query tool this is reasonably transparent.
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?
Two concise sentences. The first states the output content, and the second provides a practical use case. Every sentence earns its place, and there is no filler.
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 low-complexity, two-parameter tool with no output schema, the description gives enough context: what is returned, the time detail, and the intended use. It could be slightly richer by noting what happens when a zone has no daylight-saving changes, but nothing critical is missing for normal 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?
Schema coverage is 100%, with clear descriptions for year ('Calendar year, default this year') and zone ('Place or IANA zone'). The description adds no extra parameter 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies what the tool provides: daylight-saving clock changes for a place/year, with UTC instants and before/after offsets. It does not use a strong verb like 'returns' or 'lists', but the resource and output content are specific. It is distinguishable from time-related siblings by focusing on DST transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit use case: checking whether a recurring call moves for one participant in March or October. This is practical and helps an agent know when this tool is relevant, though it does not name alternatives or explicitly say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses that a new invoice number is allocated and never reused, that the invoice is persisted ('stored'), and that the call returns subtotal, discount, per-rate tax lines and total. These are behavioral facts beyond the bare 'create' verb, though side effects like auto-creating unknown clients appear only 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler; the core purpose is front-loaded and the second sentence packs the key behaviors (numbering, return shape). Every phrase 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 7-param creation tool with no annotations and no output schema, the description covers the essential procedural facts — number allocation, persistence, return structure — while the richly detailed schema handles currency-mixing refusal, aliases, and D-R24/D-R46 rounding rules. The division of labor is sensible; the description would only need to add more if the schema were thinner.
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 and the schema already documents all 7 parameters in detail. The description adds marginal context by hinting that discount and per-rate tax lines appear in the returned invoice, mapping loosely to discount_percent and tax_rate, but it adds no syntax or format 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?
States a specific verb and resource ('Create an invoice') plus the exact scope ('for a client from a list of items'). The qualifier 'from a list of items' distinguishes it from siblings like invoice_from_hours and invoice_generate_due without opening their schemas.
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 phrase 'from a list of items' implies the itemized-billing use case, but the description never names alternatives or states when not to use it. No explicit exclusion routes the agent toward invoice_from_hours or invoice_generate_due; the usage is inferred rather than stated.
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?
With no annotations, the description carries the behavioral disclosure burden. It clearly states the side effect ('Creates... an invoice') and the result behavior ('returns a single-line invoice, converting the rate... and echoing back any entry_ids'). This gives an agent a solid sense of what will happen, though it could also mention that the invoice is not automatically marked billed until entry_mark_billed is called.
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?
Two sentences, front-loaded with the essential use case, then the key behavioral details. Every sentence adds value without unnecessary elaboration or restating 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 a rich schema, the tool has 14 parameters, no annotations, and no output schema, so the description alone is not enough for an agent to fully understand the return shape or the full behavior across optional parameters. It explains the core case well but leaves significant context to be inferred from 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?
The description adds meaning for the core fields client/hours/rate and the relationships around fx_rates and entry_ids, but schema coverage is only 50% and many optional parameters (notes, due_days, tax_rate, discount_percent, issue_date) are not addressed in the description. It partially compensates for the schema gap but does not fully carry the burden for all 14 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?
States a specific operation: 'Creates and returns a single-line invoice' for bill one client for N hours at an hourly rate. Differentiates from sibling tools like invoice_create by framing it as a 'Shortcut' for the common case, making its scoped purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use it: 'Shortcut for the common case: bill one client for N hours at an hourly rate.' It also notes the conversion behavior when fx_rates is provided. It falls short of explicitly naming alternatives or saying when not to use it, but the context strongly implies its intended niche.
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?
With no annotations, the description carries the burden of disclosing side effects, and it does: it creates 'real' invoices, renders PDFs, and returns a summary of created, skipped, and still-due items. The parameter descriptions add idempotency, dry-run, and limit details, further improving 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 two tight sentences: it leads with the core behavior and follows with the return summary. No redundant phrasing or filler, and it is well-structured for quick agent parsing.
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?
The tool has no output schema, but the description names the three return categories and the parameter descriptions cover defaults, idempotency, dry-run, and the 60-invoice cap. This is sufficient for an agent to invoke the tool correctly, though return structure details 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?
Schema description coverage is 100%, so the parameters are already fully documented in the schema. The main description does not add parameter-level meaning beyond the schema, which matches the baseline of 3 for high 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 states a specific action: create real invoices for schedule occurrences on or before as_of that haven't been invoiced, and render PDFs. This clearly identifies the resource and behavior, distinguishing it from siblings like invoice_create or invoice_from_hours by focusing on schedule-driven batch generation.
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 context is implied: this is for generating due invoices from schedules, especially in bulk. However, it does not explicitly state when to choose this over alternatives like invoice_create or invoice_from_hours, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key side effect (writing a PDF file) and the return value (the path of the file written), which is important behavioral information. It does not mention overwrite behavior or error cases, but for this simple rendering tool the core behavior is transparent.
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 two short sentences with no filler. The primary purpose is front-loaded in the first sentence, and the second adds the essential return-value detail. Every sentence 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 tool with no output schema, the description plus schema covers purpose, output format, parameter meanings, and return value. It could additionally mention what happens when the invoice number is invalid, but that is not essential for an agent to invoke the tool correctly in the common case.
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 input schema already documents both parameters thoroughly, including the default out_path and the guarantee that bytes written are PDF. The free-text description adds no parameter semantics beyond what the schema covers, matching the 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 uses a specific verb ('render') with a clear resource ('a stored invoice') and output format ('an A4 PDF'), and states the return value. It is not a tautology and clearly identifies the tool's function, though it does not explicitly contrast with sibling pdf_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening phrase 'Call this tool to render a stored invoice' gives a clear context for when to use it. It does not name alternatives or provide when-not-to-use exclusions, so it stops short of a 5, but the usage intent is unambiguous.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. The verb 'Show' implies a read-only, non-destructive action, and the expected output is described. However, there is no explicit statement about side effects, authentication needs, or whether the status is checked live or from cached data, though this is less critical for a zero-parameter status tool.
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. It front-loads the primary action and scope, then gives the output dimension and upgrade location. Every clause adds value; there is no filler 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?
For a zero-parameter tool with no output schema, the description covers the essential context: which servers are checked, what statuses are shown, and where to upgrade. A minor omission is the exact response format or return structure, but that is not critical given the simplicity of the 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 tool has zero parameters and the input schema is an empty object, so there are no parameter semantics to explain. The baseline for zero parameters is 4, and the description adds no unnecessary parameter-related text.
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's purpose with a specific verb ('Show') and resource: the license status of five named servers (time-tracker, price-tracker, spreadsheet, invoice, expense-tracker). It also indicates the output dimension ('free or Pro') and upgrade guidance. This distinguishes it from the sibling tool license_activate, which implies activation rather than status checking.
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 makes it easy to infer this is a status/read-only tool, but it does not explicitly state when to use it versus license_activate. There is no mention of when not to use it or which alternative to choose. An agent would have to rely on sibling names and context rather than direct guidance.
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?
With no annotations, the description carries the full burden of disclosing behavior. It explicitly says rotation is added to existing rotation, that a new file is written rather than modifying the source, and it adds the free-tier 30-page limit. It does not mention error behavior or return value, but the core side effects are well covered.
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?
Four short sentences, front-loaded with the primary purpose, and each sentence adds distinct value: action/sign, use case, output behavior, and free-tier limit. No filler or redundant restating of the schema.
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 5-parameter tool with no annotations and no output schema, the description covers the essential behavioral facts needed to select and call it: cumulative rotation, new-file output, and page limit. It could go further on overwrite behavior and return values, but the schema already documents overwrite and the invocation requirements are adequately covered.
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 already documents all five parameters and their meanings, so the baseline is 3. The description mostly repeats degrees and cumulative rotation that the schema already states; it adds only the general note that a new file is written.
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: turn PDF pages by multiples of 90 degrees, with clockwise positive. It also conveys the key semantic that rotation is additive to existing page rotation, which distinguishes it from page-reordering or splitting tools, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete context: fixing a sideways scan. This is clear enough for an agent to decide when rotation is needed, but it does not name alternative tools or state when not to use this tool.
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?
With no annotations provided, the description carries the disclosure burden and handles the main safety trait well: it writes a new file and leaves input untouched. It also reveals the free-tier restriction on PAID/DRAFT presets. It does not mention overwrite consequences or billing behaviour for custom text, though the schema partially covers those.
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?
Three short sentences, with the core action front-loaded and no filler. The free-tier sentence earns its place because it changes how the caller should pick text.
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 9-parameter tool with no annotations and no output schema, the description covers the primary use case and the key non-destructive behaviour, while the schema documents all parameters. It could be more complete about return values and what happens when overwrite is false, but the high schema coverage keeps it 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?
Parameter coverage in the schema is 100%, so the description only needs to add non-schema context. It adds useful framing around text presets and colours, but largely restates what the text/colour parameter descriptions already say. 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 a concrete action: draw a word such as PAID or DRAFT on PDF pages with chosen colour and position. It clearly identifies the resource and operation, but it does not explicitly differentiate it from the similar sibling pdf_watermark_business, so it misses the top bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Call this tool to draw..." gives a direct use context, and the free-tier note tells the agent when preset behaviour applies. It does not state exclusions or name alternatives such as pdf_watermark_business, so it is clear but not fully routed.
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?
With no annotations present, the description carries the full burden. It discloses that the tool fetches the page and extracts price-related data, and it names the exact returned fields. It leaves minor gaps around failure modes and whether each check persists historical data, but the core behavior is transparent for a simple read-like tool.
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?
Two sentences carry the purpose, the differentiator from generic web fetching, and the return values. Every sentence earns its place and the main instruction is front-loaded. No filler or redundancy.
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 one-parameter tool with no output schema, the description is largely complete: it says when to use it and what it returns. It does not describe failure behavior for invalid or unparseable URLs, nor the side effect of creating/updating a price check history, so a little is left to the agent's inference.
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 single url parameter as 'Product page URL, including https://', giving 100% coverage. The description only repeats that it takes a product URL and adds no new 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names a specific action ('check a price') on a specific resource ('any product URL') and lists the structured outputs returned. It distinguishes itself from using a generic web tool, but it does not explicitly differentiate from the related siblings price_history and price_add_manual, so the differentiation is implicit rather than direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: 'Call this tool for any product URL' when a generic web fetch would return raw HTML without the price. It provides clear context for when to use it, but it does not mention exclusions or alternatives such as price_history for historical data or price_add_manual for manual entries.
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?
No annotations are present, so the description must carry the behavioral burden. It discloses that the tool persists profile content and returns a count of what was stored, but it does not describe update-versus-merge-versus-replace semantics or what happens to an existing profile; that is left to the schema's merge/replace parameter descriptions. The description is minimally transparent and nowhere contradicts 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?
Two sentences, with the core action and content categories front-loaded and the return-value statement adding useful operational information. There is no filler 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?
The schema is rich, covering defaults, required flags, ordering constraints, and Pro-only restrictions, so the description does not need to repeat those details. The description supplies the missing high-level context and return behavior; only an explicit note about merge/replace preconditions would make it fully self-contained.
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 already documents the majority of parameters, including name/email defaults, merge/replace requirements, experience ordering, and Pro-only fields. The description groups facts at a higher level (contact details, skills, education, roles with bullets) but adds little field-specific 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Store the profile' and lists the fact categories it accepts (contact details, summary, skills, roles, education, certifications, languages). It also connects the tool to its downstream purpose, 'every resume and cover letter is built from,' which clearly distinguishes it from read-side and document-generation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to call: it populates the shared profile that all resumes and cover letters are built from, so an agent knows to invoke it before document generation. It does not name alternatives or provide when-not conditions, but for a store-vs-get sibling relationship the context is clear enough.
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?
No annotations are present, so the description carries the behavioral disclosure burden. It discloses the return value ('Returns the new rate and... how many already logged entries changed') and the conditional re-rating behavior, plus the underlying purpose of turning tracked hours into money. It does not detail side-effect nuance, but it is far more than a minimal mutation 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?
Two sentences, no fluff, front-loaded with the core purpose and then the return behavior. Every clause 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?
There is no output schema, so the description's mention of the return value is valuable. It covers the main return contract and the conditional effect on logged entries. It could add exact response shape or caution about re-stamping entries, but the parameter schema already handles the input side thoroughly.
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 adds no parameter-level detail beyond the schema, but the schema already thoroughly documents project, currency, hourly_rate parsing behavior, only_missing, and apply_to_existing.
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 verb and resource: 'Set the hourly rate and currency' for a project or client. This clearly differentiates it from sibling read-oriented tools like rates_latest, rate_history, and rate_on.
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 the use case—setting a project/client rate—but does not explicitly say when to use it versus alternatives or when not to use it. The sibling list contains read-style rate tools, but no routing between them is provided.
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?
With no annotations, the description carries the burden and does disclose useful traits: it returns the ECB rate date and cache age, signaling the result may be cached or stale. It doesn't mention read-only status or network behavior, but 'Returns' implies no side effects and the cache-age note is valuable.
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 dense sentence states purpose and return values with no filler. The cache-age mention is the only extra detail, and it 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 optional-parameter read tool, the description covers the purpose, the return payload (rates, date, cache age), and the schema covers parameter details. It could mention historical alternatives or error conditions, but these are not necessary 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?
The input schema already contains rich descriptions for both parameters, including the default behavior of base and the 200-item limit for quotes. The tool description adds no additional parameter semantics, so the baseline 3 applies given schema coverage of 100%.
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?
States a clear verb+resource: call for the most recent ECB daily reference rates. The phrase 're-expressed against any base' adds specificity beyond the title. It doesn't name sibling tools, but 'latest' and 'ECB' distinguish it from historical or conversion-focused siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to call it for the most recent ECB reference rates, which is a clear context. It does not mention alternatives like rate_history or fx_rates_for, nor state when not to use it, so it lacks exclusion guidance.
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?
With no annotations, the description carries the transparency burden and does a reasonable job: it states that parsing is best-effort by mentioning 'anything unparsed' and describes the return contents. It does not discuss side effects, but the tool's read-only nature is strongly implied by 'Read' and 'extract', and the save parameter is documented 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The primary action is front-loaded, and the return information follows naturally. Every sentence 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 read-only parse tool with no output schema, the description explains what is returned: parsed profile, sections found, and unparsed content. The main gaps are the meaning of 'variant' and explicit routing versus sibling conversion tools, but the core invocation and expected result are 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?
Schema description coverage is 67%, so the baseline is 3; path and save are already documented in the schema. The tool description adds no parameter-level meaning and leaves 'variant' undocumented, so it does not compensate for 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 uses a specific verb ('extract') and resource ('existing Word resume') and clearly names the target output ('profile shape') with its components. It distinguishes from sibling conversion tools by emphasizing structured profile extraction, but it does not explicitly name 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening 'Call this tool to...' is an explicit usage directive, and the context is clear: use this when you need an existing .docx parsed into the profile shape. It does not list exclusions or compare with resume_to_markdown/htl, but the guidance is not merely implied.
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?
With no annotations provided, the description must carry behavioral details, and it does: matching is case insensitive, every cell is searched, and the result includes cell addresses plus a row preview. It does not explicitly state that the operation is read-only, but the search behavior and return description make that reasonably clear.
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 two sentences with no filler. It front-loads the call instruction, adds a key limitation of file readers, and gives the most important behavioral and output details succinctly.
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 search tool with 3 fully documented parameters and no output schema, the description covers the core behavior, return shape, and case sensitivity. It could mention the optional sheet default or the 200-hit limit, but those are already present in the schema, so the description is close to 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%, so the baseline is 3. The description adds context about searching 'every cell' and mentions CSV alongside spreadsheets, but it does not add meaningful parameter-level detail beyond what the schema already provides for path, text, and sheet.
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 behavior: searching every cell of a spreadsheet or CSV for text and returning cell addresses with row previews. It explains why this tool is needed ('built-in file readers cannot parse spreadsheets'), but it does not explicitly differentiate it from sibling tools like sheet_read or sheet_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It directly says when to use the tool: whenever you need to search a spreadsheet or CSV for text. The note about built-in file readers gives practical context, but it does not explicitly state when not to use this tool or mention alternatives among the spreadsheet sibling tools.
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?
With no annotations, the description carries the full burden and discloses that the tool is read-only, writes nothing, and changes nothing, plus what it returns. It could add prerequisites or auth notes, but for a non-mutating analysis tool this is solid.
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?
Two-sentence description, front-loads read-only nature and outputs, ends with actionable next step. No redundant 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 3-parameter tool with no output schema and no annotations, the description covers purpose and outputs but leaves 'variant' unexplained and is vague about where the existing facts come from. It's usable but not fully complete.
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 explains job_description and limit, but description adds no parameter-level meaning and completely ignores 'variant', which has no schema description. At 67% schema coverage, the description should compensate for the undocumented parameter but 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?
Description states a specific verb ('gap analysis') with a clear resource ('against a posting') and enumerates exact outputs (matched keywords, missing ones, coverage figure, orderings). It differentiates from siblings like resume_create by framing itself as the read-only analysis step, and the title reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear workflow context: perform gap analysis, then act with resume_create. It does not explicitly list alternatives or exclusions, but the sibling reference makes intended usage evident.
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?
No annotations are provided, so the description must convey side effects. It states that the timer is stopped and an entry is logged, and that duration and entry id are returned. However, it does not mention error handling for when no timer is running or potential idempotency issues.
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?
Two concise sentences with no redundant wording. The main action is front-loaded, and the return value is stated clearly.
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 tool with one parameter and no output schema, the description covers the main behavior and result. It lacks explicit preconditions (e.g., a timer must be running) but that is implied and acceptable for this scope.
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 'note' is fully described in the schema, and the description repeats it as 'Optional note stored with the entry'. Schema coverage is 100%, 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?
Clearly states the action 'Stop' and the resource 'running timer', and adds context that it logs the time entry. This distinguishes it from timer_start and timer_status, and aligns with sibling tools like entry_add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: use when there is a running timer to end and record. It does not explicitly mention alternatives or when not to use, but the action is straightforward and the intent is clear.
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?
No annotations are provided, so the description must carry the behavioral burden. It clearly states what the tool does: list variables used across clauses and map them to clause usage. However, it does not disclose the exact return format, whether results are deduplicated, or what happens if a clause is invalid or a variable is repeated across clauses.
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 front-loads the input condition and immediately states the action and purpose. Every phrase earns its place, and the 'nothing missed' motivation clarifies why an agent would call the tool.
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 one-parameter read-only list operation, the description covers what the tool does, why to use it, and what the output contains (variables and their clause usage). No output schema exists, so the stated result shape is the main fallback, and it is adequately described. Minor details like return formatting or empty results are not necessary for basic 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 schema already documents clause_ids as clause IDs or titles. The description adds the conceptual meaning of clauses as the source of variables, but does not add new parameter-level detail. 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 names a specific operation (list every variable), the input (a set of clauses), and the output scope (which clause uses each variable). This clearly distinguishes it from any sibling tool and makes the tool's purpose immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context: this should be used before assembling something and is meant to ensure nothing is missed. It does not explicitly name alternative tools or exclusions, but the sibling list contains no competing variable-listing tool, so this is sufficient guidance.
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?
No annotations are present, so the description carries full behavioral disclosure. It explicitly states that both the calendar and its local .ics copy are removed and that nothing else is touched. This gives strong clarity on the destructive scope and side effects, though it omits failure modes or reversibility.
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?
Two short sentences with the core action front-loaded and a clear no-side-effect clarification. Every word contributes to the meaning; there is no redundancy or unnecessary detail.
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 simplicity of the tool, one fully documented parameter, and no output schema requirement, the description covers the essential knowledge needed to use it safely: exactly what will be removed and what will not. Any missing details like not-found handling are negligible for a focused 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 schema already provides a full description for the only parameter (name: 'The calendar name from calendars_list'), so the tool description adds minimal parameter-level meaning. The phrase 'imported calendar' hints at the domain but does not add syntax, format, or constraints beyond the schema. Combined with 100% schema coverage, 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?
States a specific action with verb and resource: 'Remove one imported calendar and the local copy of its .ics file.' 'Nothing else is touched' adds a precise scope boundary, distinguishing it from broader deletion operations and showing it is the inverse of ics_import.
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 context is implied by the term 'imported calendar' and the tool name ics_forget, but there is no explicit when-to-use statement, named alternative, or exclusion such as 'use this instead of deleting the calendar.' The description tells what it does but not specifically when to choose it over other actions.
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?
With no annotations, the description carries the burden. It discloses the non-destructive nature (history kept, can be resumed) and the core effect (stops invoice generation). It does not mention permissions or side effects, but for a simple pause operation this is sufficient.
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?
Two sentences with the core action front-loaded, followed by important qualifiers. No wasted words; every clause adds value.
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 single-parameter tool with no output schema, the description covers the essential behavioral context (non-destructive, reversible) and the scope of effect (stops invoice generation). It could mention return value or prerequisites, but these are not critical for a simple pause action.
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 0% and the description does not explain the 'id' parameter at all. It is left implicit that 'id' refers to the schedule identifier, but the description adds no meaning beyond the schema's minimal string type. Since coverage is low, the description should compensate, but it does not.
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?
States a specific verb ('stop'), resource ('a schedule'), and the key distinction from deletion: it does not delete, keeps history, and can be resumed. This clearly differentiates it from schedule_delete and schedule_resume siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the alternative of deletion by emphasizing that history is kept and it can be resumed, which suggests using this instead of schedule_delete when preservation matters. However, it does not explicitly name schedule_resume or schedule_delete as alternatives or give explicit when-to-use conditions.
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?
With no annotations, the description carries the transparency burden. It clearly says 'reads rows' and reveals output modes plus pagination via limit/offset or A1 range. It does not explicitly say 'read-only/no modification', but the read verb and output-focused wording provide adequate expectation for a low-risk read tool.
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?
Two concise, front-loaded sentences. The routing instruction is stated first, followed by a compact capability summary covering format and pagination with 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?
Given six parameters and no output schema, the description covers the essential invocation context: target file type, output format, and pagination choice. Remaining gaps, such as explicit sibling-tool alternatives and more detail on path semantics, are minor because the schema already documents the parameters.
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 input schema already covers about 83% of parameters, and the description reinforces meaning for the path parameter as a spreadsheet or CSV file path. It also clarifies that limit/offset and A1 range are alternative pagination mechanisms, matching and supplementing the schema descriptions.
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 names a specific action ('Reads rows') on a specific resource ('any spreadsheet or CSV file path') and lists output formats. It distinguishes the tool from built-in file readers but does not explicitly distinguish it from sibling sheet tools such as sheet_query or sheet_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger: call this tool for any spreadsheet or CSV file path, and explicitly says built-in file readers must not be used for them. It does not, however, contrast with sibling sheet_* tools, so an agent might not know when sheet_query or sheet_info 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It transparently indicates a read-only status operation scoped to the local machine, and it sets expectations about the kind of information returned (cached items, age, refresh time). It does not explicitly state that the operation has no side effects, but 'status' implies a non-mutating check.
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 two concise sentences with no filler. The first sentence front-loads the core output fields, and the second sentence adds an important usage caution. Every word earns its place.
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 zero-parameter status tool with no output schema, the description fully covers what the agent needs: what the tool reports, its local/offline context, and when to consult it. Nothing critical is missing 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?
The tool has zero parameters, so there are no parameter semantics to explain. The description sufficiently substitutes for an empty schema by describing what the tool reports, and the baseline for zero-parameter tools is 4.
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 that the tool reports what is cached, how old the cache is, and when it will refresh. This differentiates it from sibling rate/value tools by focusing on cache state rather than rate data itself, though it lacks an explicit verb like 'returns' or 'shows'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for use: check this before trusting a rate on a machine that has been offline. It does not discuss when not to use it or name alternative tools, but the provided guidance is actionable and specific.
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?
No annotations are provided, so the description carries the behavior disclosure burden. It is transparent about the operation's scope ('Every calendar imported into this server') and the exact data fields returned, which effectively communicates a read-only listing behavior. It does not spell out side effects or failure modes, but the verb 'List' and the descriptive sentence make the non-destructive nature evident.
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 front-loads the subject and scope, then lists the returned attributes. There is no redundancy, filler, or unnecessary detail; every part of the sentence contributes to the agent's understanding.
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 zero-parameter, no-output-schema list tool, the description covers the essential information needed to call it: what is listed, the scope, and the fields in the result. It does not mention ordering, pagination, or empty-result behavior, but those are minor for this simple metadata-listing tool and are not required by the input schema or annotations.
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 there is no parameter-semantics burden on the description. The schema is fully coverage because there is no schema to explain. This meets the baseline 4 for a no-parameter tool.
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 title 'List imported calendars' states a specific verb and resource, and the description expands on it: it enumerates exactly what will be returned—name, source, event definition count, and import date. This clearly distinguishes it from sibling tools like schedule_list or events_list, which concern schedules and events rather than calendar import metadata.
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: use this tool to inspect imported calendars on the server. However, it provides no explicit guidance about when to prefer it over alternatives, and it does not excludeevent or schedule listing tools. For a simple zero-parameter list tool this is acceptable, but not fully explicit.
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?
With no annotations provided, the description carries the full burden and does a good job: it discloses the side effect (writing the library to a file) and the return contract (path, format, clause count). It could also mention failure behavior or explicitly state that the source library is not modified, but the core behavioral contract is well covered.
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 two sentences with no wasted words. The action and scope are front-loaded, and the second sentence gives a compact list of return values. Every sentence 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 relatively simple export tool with 3 parameters, no output schema, and a clear schema, the description plus schema provides enough context for correct invocation: destination path, required format, overwrite behavior, return values, and scope. It doesn't discuss error cases or the Pro-vs-free behavior beyond what the schema notes, but those are secondary for a straightforward export.
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 per cent, and each parameter already has a meaningful description. The tool description adds no additional parameter-level semantics; it only reinforces the overall scope. A baseline score of 3 is appropriate when the schema carries the parameter-documentation 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 uses a specific verb ('write'), names the resource ('the whole clause library'), and states the output ('one file'), which clearly differentiates it from per-clause operations like clause_get, clause_add, and clause_import. The scope qualifier 'whole' removes ambiguity about partial exports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly opens with 'Call this tool to...' and defines the intended use case for exporting the full clause library. It doesn't name alternatives or state when not to use it, but the use case is clear enough that an agent would not confuse it with the many unrelated sibling tools.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly reveals that deletion is conditional and that the tool names any referencing document when refusing deletion. It is not annotated as destructive, but the word 'Delete' inherently signals destruction, and the description adds non-obvious dependency 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?
Two succinct sentences with no filler. The first sentence states the action and precondition, the second details the refusal behavior with a specific list of document types. Front-loaded and easy to parse.
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 single-parameter delete tool with no output schema, the description covers the main behavior, the dependency restriction, and the error response style. A minor gap is that it does not state success response behavior, but the core information needed to select and invoke the tool correctly is present.
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 documents the only parameter with the note 'Client name or id, exactly as client_list shows it.' The description adds no additional parameter-level meaning, so the baseline of 3 applies because the schema is doing the heavy lifting.
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 and resource: delete a stored client, and clarifies the key condition that it must be unused. This clearly distinguishes it from sibling tools like client_add and client_list, and the title 'Delete a client' is reinforced rather than merely restated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you want to delete a client that has no references, and it warns that referenced clients will be refused. It does not name an alternative tool, but no close alternative for deletion exists among siblings, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the core behavioral traits: returns all overlapping pairs, includes collision minutes, handles whole-day events separately, and enforces a plan-based date window. It could add output structure details, but it covers the most important behaviors for correct invocation.
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?
Three tightly written sentences lead with the primary semantic, then add scope, special cases, and plan limits. Every sentence provides actionable information with no filler.
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 read-only detection tool with three parameters and no output schema, the description gives enough behavioral and contextual information to select it and call it correctly. It leaves some return-format details unspecified, but the core semantics are covered.
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. Descriptions of from, to, and calendar already exist in the schema; the tool description mostly repeats the calendar default and adds a plan limit, but adds little per-parameter meaning beyond what the schema provides.
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 defines the tool as finding every pair of overlapping events and reporting the collision minutes. It also notes that it spans all calendars by default unless one is named, which sharply distinguishes it from single-calendar event tools like events_list or free_busy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete context for when to use the tool: when cross-calendar clashes matter, and it explains the optional calendar parameter behavior. It does not explicitly name alternatives or say when not to use it, but the use case is strongly implied.
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?
With no annotations present, the description carries the burden of conveying side effects. Listing saved contacts is clearly a read-only operation, and the description adds useful context about computed fields (current local time and working-hours status), though it does not explicitly state that no data is modified.
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 conveys the core function and the extra computed information. There is no redundancy or unnecessary detail.
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 parameterless list tool, the description provides sufficient context: it names the resource, the scope ('everyone you have saved'), and the enriching fields (local time and working-hours status). It could be slightly more explicit about the output shape, but that is not critical for such a simple 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 tool has zero parameters, so there are no parameter details to document. The baseline for no parameters is 4, and the description appropriately focuses on the output and behavior rather than input fields.
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 that the tool returns all saved contacts along with their current local time and working-hours status. The title reinforces the resource (saved contacts) and the action (list), distinguishing it from the related contacts_set tool.
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 intended use is implied by the title and description: use this when you need to see saved contacts and their time/working-hours info. However, it does not explicitly contrast with alternatives like contacts_set or mention conditions when 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly discloses the data source (ECB daily reference set), the fields returned (rate against euro and decimal places), and the scope limitation. While it does not state return formatting or ordering, it provides solid transparency for a simple read-only listing tool.
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 compact: two sentences that front-load the core purpose and then add the important constraint about unsupported currencies. Every sentence earns its place and there is no redundant or filler wording.
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 parameterless listing tool with no output schema, the description gives enough information about the result contents and scope to be usable. A minor gap is that it does not mention how to request specific data or how results are ordered, but those are not critical for this simple 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 tool has zero parameters, so the baseline is 4. The description appropriately focuses on what the tool returns rather than parameter details, since there are none to document.
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 that this tool returns every currency in the ECB daily reference set along with its euro rate and decimal places. It also establishes a clear boundary by noting that anything not on the list cannot be converted, which differentiates it from sibling conversion tools.
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 the tool should be used to check which currencies are supported for conversion, especially through the sentence 'Anything not on this list cannot be converted here.' However, it does not explicitly say when to use this tool versus sibling tools like rates_latest, convert, or fx_rates_for.
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?
No annotations are present, so the description carries the burden. It discloses that the tool returns a path, does not render PDF directly, and is 'free and unlimited.' This gives useful behavioral context, though it doesn't cover all edge cases.
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 two sentences, concise, and well-structured. It covers purpose, output, and a key usage hint without fluff or redundancy.
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 tool with three well-documented parameters, the description provides enough context: converts docx to semantic HTML, returns path, supports PDF workflow, and is free/unlimited. It lacks an output schema but doesn't need one. Minor gaps like error behavior are not critical.
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 already fully describes all three parameters (path, out_path, overwrite) with clear descriptions. The tool description adds context about the conversion purpose but does not add new meaning to the parameters themselves, matching the baseline for full 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 clearly states the tool converts .docx to semantic HTML, mentions the output is a file path, and highlights its use for printing to PDF. This is specific and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'This is the supported PDF route; no PDF is rendered here,' which directs when to use this tool (when HTML is needed for PDF output) and what to avoid (expecting direct PDF). While it doesn't name alternative tools, the condition is clear.
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?
With no annotations, the description carries the behavioral burden. It discloses that the tool persists a timesheet entry and only accepts already-worked time, and it hints at rate/currency conversion with the example '90 euros an hour' -> EUR. However, it does not describe what the tool returns, whether it mutates anything besides creating the entry, or what happens when a project name doesn't match.
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?
Two sentences front-load the purpose and then give the core usage rules without redundant wording. Every sentence adds meaningful information: what the tool does, what inputs are required, and how rate/currency can be expressed.
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 schema documentation covers all 10 parameters in detail, the description doesn't need to repeat them. It provides the essential behavioral model and parameter relationships needed to call the tool correctly. The lack of an output schema is a minor gap, but not critical for a create-style timesheet 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?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the relationship between start, end, and minutes ('start plus either end or minutes'), and by giving a concrete natural-language rate example ('90 euros an hour' -> EUR) that clarifies how string rates and currencies are meant to be supplied.
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 names a specific verb and resource: 'Log ... time you already worked on a project - a timesheet entry.' It clearly distinguishes this from live-timer or time-conversion siblings by emphasizing 'already worked,' and the title 'Add time entry' matches the behavior exactly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a clear use case: recording already-completed work as a timesheet entry, which implies it is not for ongoing-time tracking or future scheduling. It also explains the required input pattern: 'start plus either end or minutes.' It does not name alternative tools explicitly, but the context is clear enough to guide selection.
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?
Explicitly states 'Writes nothing', which is a key side-effect disclosure given the lack of annotations. It also clarifies that it returns arguments rather than performing the entry creation, but doesn't mention potential validation 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?
Two concise sentences with no redundant wording. The key information—what it does, its side-effect-free nature, and the follow-up action—is front-loaded and efficiently communicated.
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?
Sufficient for a tool with 4 straightforward parameters. It tells the user exactly what to do with the output ('pass the JSON straight to entry_add'), though a bit more detail about the return shape would have been helpful given the absence of an 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 schema already covers all parameter meanings (event_id source, project/client, rate format, currency fallback). The description adds no extra parameter detail, so it stays at the baseline for full 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?
Clearly states it takes an event and returns the exact arguments for entry_add, with the specific purpose of converting a past meeting into billable time. This distinguishes it from sibling tools such as entry_add or events_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates when to use it ('a meeting that already happened becomes billable time') and directs the user to pass the result to entry_add. It doesn't explicitly contrast with every alternative, but the use case is clear.
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?
No annotations are provided, so the description carries the full burden. It discloses the write behavior ('Returns the file path written'), the output content, and the format. It does not mention overwrite or clamping behavior, but the input schema already documents the free-tier/pro clamping for date ranges.
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?
Two sentences, front-loaded with the primary purpose, and every sentence adds essential information: what it exports, for whom, the row structure, and the return value. No filler or redundancy.
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?
With no output schema, the description correctly explains the return value ('file path written') and the file content. It covers the essentials for an agent to select and invoke the tool. Minor omissions like file overwrite behavior or encoding are acceptable given the schema richness and simple nature of the export 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 description coverage is 100% with clear descriptions for all four parameters (to, from, path, project). The description does not add parameter-specific meaning, but the baseline of 3 is appropriate because the schema fully covers the 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 states a specific verb ('export'), resource ('the timesheet'), output format ('CSV file, excel-friendly'), and purpose ('hand to a bookkeeper'). It also specifies the row structure ('one row per entry with hours, billable, rate, currency and amount'), which clearly distinguishes it from other export-related siblings like clause_export or event_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('Call this tool to export the timesheet to a CSV file...') and for whom ('hand to a bookkeeper'). It does not name alternative tools or state when not to use it, but among the siblings there is no direct alternative for timesheet CSV export, so the guidance is clear.
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?
With no annotations, the description carries the transparency burden and does a solid job, explicitly stating the merging behavior, the exclusion of free/transparent events, and that whole-day events block the day. It does not mention read-only behavior or return shape, but the core behavioral traits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence with a memorable opening phrase and no filler. Every clause contributes a meaningful detail about behavior or scope.
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?
The tool has six parameters and no output schema, so the description needs to cover key semantics and likely outcomes. It explains the busing rule, the free-window concept, and important calendar event behavior. It stops short of describing exact output fields or timezone handling, but those are partly covered by 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%, so the parameters are already well documented. The description only loosely maps to 'calendars named' and 'working hours', adding little beyond what the schema provides.
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's function: it returns merged busy blocks from selected calendars and free gaps within working hours. It also differentiates itself from calendar-listing or event-searching tools by focusing on availability windows and busy merging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description sets the context well: use this when you need to know where time is booked and where free windows remain within working hours. It does not explicitly name sibling alternatives or state when-not-to-use, so it misses full exclusion guidance.
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?
With no annotations provided, the description carries the full burden of disclosure. It explicitly reveals additive behavior, overpayment refusal with open-balance feedback, and the full-payoff default when amount is omitted. It does not describe the response or whether the invoice status changes, but the critical behavioral surprises 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action, then packs the most important behavioral details and the optional-amount shortcut into minimal space. Every sentence contributes directly to correct tool usage.
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 moderate-complexity mutation tool with no output schema, the description covers the essential call semantics: what happens on partial payment, overpayment, and full payoff. Minor gaps remain around the return value and how the invoice's paid status is reflected, but an agent has enough 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 high at 80%, so the baseline is 3. The description adds meaningful emphasis to the 'amount' parameter semantics (additive, never replacing, omit to pay in full), but it does not add extra explanation for the required 'number' parameter or the optional metadata fields, which remain under-specified.
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 clearly states the action ('Record a payment') and the resource (an invoice), and the title reinforces the intent. It is immediately distinguishable from sibling tools like invoice_get, invoice_list, and invoice_create because it focuses on recording payment against an existing invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear practical usage context: call this when receiving a payment for an invoice, and explains the key behavior of adding to existing paid amounts and handling full payoff by omitting amount. It does not explicitly name alternatives or exclusion criteria, but the context is strong enough for an agent to select it appropriately.
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?
With no annotations, the description carries the behavioral disclosure burden. It does disclose the significant side effect that activation applies to every server in the bundle at once, but it does not mention reversibility, failure modes, or what happens if a license is already active.
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 compact sentence delivers the action, scope, and format constraint without filler. The key verb 'Activate' leads immediately.
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 one-parameter, no-output-schema tool, this description is nearly sufficient: it tells the agent what to pass and the activation scope. Missing details like post-activation verification or irreversibility are useful but not required to invoke it correctly.
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 already covers the 'key' parameter at 100%, so the baseline is 3. The description adds the specific MCPL1.xxx.yyy format, giving the agent extra validation guidance 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 is specific: it names the verb 'Activate', the resource 'Pro license key', and the scope 'every server in the bundle at once'. It also supplies the key format, making it easy to distinguish from the related license_status sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The trigger context is clear: use this tool when a Pro license key needs to be applied to the whole server bundle. It does not explicitly mention alternatives like license_status or state exclusions, so it misses a 5.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states 'Read-only, never modifies the file,' which is critical for safe agent decisions. It also mentions the output scope and encryption detection, giving useful behavioral context beyond a bare instruction.
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?
Two sentences with no fluff. The direct 'call this tool' instruction is front-loaded, followed by a compact list of result categories and a clear safety guarantee. Every sentence 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 one-parameter read-only inspection tool, the description is largely complete: it specifies the input, the output content, and the safety behavior. There is no output schema, so a bit more detail about the returned structure could help, but the listed fields are sufficient 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?
The single parameter 'path' is fully documented in the schema with 100% description coverage, so the baseline of 3 applies. The tool description does not add additional parameter detail, but none is necessary because the schema already explains path resolution and expansion.
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 ('inspect') and a clear resource ('a PDF'), then enumerates the exact information returned: page count, page sizes, paper name, metadata, and encryption status. This distinguishes it from sibling PDF tools like pdf_merge, pdf_split, or pdf_text, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening line, 'Call this tool to inspect a PDF,' explicitly states when to use it. It does not name exclusions or explicitly compare to alternatives such as pdf_count, but the scope is clear enough that an agent can reliably choose it for read-only inspection rather than transformation or text extraction.
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?
With no annotations, the description carries the full burden. It discloses key behaviors: 'Page sizes are kept as-is', 'Inputs are never modified', and 'Free tier: up to 5 files per merge'. It does not mention error handling or output details, but these are less critical for a merge operation.
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 concise, consisting of three sentences that cover purpose, behavior, and constraints without unnecessary details. It is well-structured and front-loaded with the primary 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?
For a simple merge tool, the description provides enough context for an agent to call it correctly: it specifies the order, the output file, and the free tier limit. It lacks details on error conditions or file format specifics, but these are not essential for a basic operation and the schema covers parameter-level details.
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 (paths, out_path, overwrite). The main description does not add additional meaning beyond the schema; it only reinforces the order for paths. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the verb 'join' and the resource 'PDFs', specifying that it combines several PDFs into one in the given order. This distinguishes it from sibling tools like pdf_split, pdf_rotate, or pdf_stamp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by saying 'Call this tool to join several PDFs into one' and notes the order of files. However, it does not explicitly compare with alternatives or state when not to use it, though the purpose is sufficiently distinct from siblings like pdf_split.
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?
With no annotations, the description carries the behavioral disclosure burden. It discloses output semantics (reference, total, file path) and a free-tier quota, both of which are not inferable from the schema. It does not mention overwrite behavior, but the schema's overwrite parameter covers that specific detail.
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?
Two sentences, front-loaded with the action and output, with no wasted words. The quota note is a single useful clause that an agent needs for planning.
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?
The tool has 10 parameters, nested objects, and no output schema, so the description must clarify return values; it does so by stating reference, total, and file path. It also adds quota context. Some details such as letterhead source and overwrite policy are left to the schema, but the schema documents them well.
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 90%, so the schema already documents the parameters in detail. The description lists summary, scope, deliverables, timeline, price, and terms as input categories, but adds no per-parameter meaning beyond what the schema provides.
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 verb ('produce') and resource ('client-ready .docx proposal') and lists the major input categories. It is clearly distinguished from proposal_update by its creation focus and from contract tools by the proposal-specific output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening instruction 'Call this tool to produce a client-ready .docx proposal' gives a direct, clear use case. It does not explicitly name alternatives or when-not-to-use cases, but the purpose is specific enough that an agent can route to it for proposal generation.
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?
With no annotations, the description carries the behavioral burden. It discloses important behavior: only passed fields change, omitted fields come from stored creation data, and the tool returns changed fields and the file path. It does not cover error cases or irreversibility, but the core mutation semantics are transparent.
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?
Three short sentences with no filler. The core purpose, update behavior, and return value are all stated clearly 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 mutation tool with no annotations and no output schema, it covers the key operational details: how to identify the proposal, the merge behavior, where default values come from, and what is returned. Edge cases like missing references or exact response formatting are absent, but the description gives enough 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 only 11%, so the description needs to compensate. It adds the crucial partial-update semantic and clarifies that only reference is required. However, it does not explain formats or meanings for most parameters, such as valid_until, timeline duration, or price amounts, beyond what the schema types already indicate.
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 a specific verb, 'Rewrite,' and identifies the exact resource: an existing proposal identified by reference. It clearly distinguishes itself from creation tools like proposal_create by emphasizing 'existing' and 'in place.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is for modifying an existing proposal rather than creating a new one. It does not explicitly name alternative tools or state a when-not-to-use rule, but the 'existing proposal' and 'in place' wording provides enough context.
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?
With no annotations, the description carries the behavioral disclosure burden. It adds useful behavior beyond the schema: 'A window wider than the free 90 days is shortened, not refused.' It also discloses that rows appear per published business day and that summary statistics cover the window. This is meaningful transparency for a read-only historical query.
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?
Three short sentences, zero filler. The purpose is front-loaded, the return summary is compressed, and the key free-tier caveat is placed last without redundancy. Every sentence 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?
The main decision-relevant context is present: what the tool returns, the pair/window scope, and the free 90-day shortening behavior. There is no output schema, so the short output description is valuable, though it could add sorting or missing-data behavior. Still, for a 6-parameter query tool with rich schema, this is near-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%, so the baseline is 3. The description does not independently define parameter details, but the schema already documents base/quote currency, date filtering, days, and max_rows. No compensation is needed.
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 names a specific verb and resource: 'the ECB rate of one currency pair across a window.' It also defines the output shape (one row per published day plus min, max, average, change), which clearly separates it from siblings like rates_latest, rate_on, or fx_rates_for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a direct call instruction ('Call this tool for...') and a clear context of use: a currency pair over a time window. It does not explicitly name alternatives or exclusion conditions, so it falls short of a full when/when-not breakdown, but the intended use is clear.
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?
With no annotations, the description carries the full burden. It discloses two non-obvius behaviors: it returns both directions so a reciprocal is never reported as the published figure, and it shortens out-of-window dates rather than refusing them. These are genuine behavioral insights beyond the schema, though response structure and error cases are not detailed.
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?
Three sentences, each earning its place: the purpose is front-loaded, followed by the reciprocal guarantee and the date-shortening edge case. No fluff, no repetition of schema content.
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 3-parameter tool with full schema parameter documentation, the description covers purpose and the two most surprising behaviors. A small gap remains in describing the response shape beyond naming its components, but the tool is otherwise well specified for an agent to call 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?
Schema description coverage is 100% and each parameter has a rich description, including the inversion caveat on 'from' and holiday/weekend/free-window behavior on 'date'. The description itself adds no new parameter-level meaning, so it earns the baseline 3 rather than higher credit.
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 verb, resource, and scope: 'Call this tool for the ECB rate of one pair on one date.' It clearly distinguishes the tool from currency-conversion and range-based siblings by emphasizing single-pair/single-date scope. The reciprocal remark adds further identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: ECB rate, one currency pair, one date. However, it does not explicitly name when-not-to-use or point to alternatives such as rate_history (ranges) or rates_latest (current), even though several for-ex sibling tools exist.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a write operation, and it goes beyond a basic statement by disclosing return values and content-modifying behavior: it returns the output path, estimated page count, dropped bullets, and matched/missing keywords. This gives an agent visibility into side effects and potential content loss.
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 covers the action, output format, and key return details efficiently, making it easy to parse.
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?
The description is adequate for a 7-parameter tool with no annotations or output schema: it states the action, output format, and return information. It could additionally mention overwrite behavior or profile prerequisites, but the input schema covers most of those details, and the return list is notably 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 86%, so the baseline is 3. The description adds some contextual meaning by mentioning dropped bullets and keyword matching, which relates to max_pages and keywords, but it does not substantially explain parameter formats or relationships beyond what the schema already covers.
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 verb ('write') and resource ('stored profile to a Word .docx'), making the tool's core function immediately clear. It distinguishes this tool from siblings like resume_to_markdown, resume_to_html, and resume_read by explicitly naming the output format and operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Call this tool to write the stored profile to a Word .docx' gives a clear context for when to use it. It does not explicitly list alternatives or exclusions, but the sibling names (resume_to_markdown, resume_to_html) make the alternative cases inferrable.
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?
No annotations are provided, so the description carries the behavioral burden. It discloses the key non-obvious trait that nothing is invoiced immediately, and states what the call returns (schedule id, summary, next dates). It could mention persistence or duplicate behavior, but the most important side-effect timing is covered.
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?
Three short sentences deliver purpose, return value, and behavioral caveat with no filler. The most important distinction—no invoicing happens here—is front-loaded near the end without bloating the definition.
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 no output schema, the description usefully states the return shape. Given no annotations, it also flags deferred invoicing. The rich 12-parameter schema covers the rest; the only real gap is the lack of explicit routing to one-off invoicing alternatives.
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 every parameter is already documented clearly. The description only summarizes the input categories at a high level and does not add new parameter-specific semantics beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Define a repeating invoice') and enumerates its core inputs: client, line items, billing interval, start/end. The final sentence differentiates it from invoice_generate_due by clarifying that no invoice is created here, so an agent can distinguish it from invoicing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear workflow context: the schedule is created now, but invoices are only produced later when invoice_generate_due runs. It does not explicitly name a one-off alternative such as invoice_create, so it stops short of a full when-not-to-use statement.
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?
With no annotations provided, the description carries the full burden and discloses the key behaviors: it writes a new file next to the source unless out_path is given, never modifies the source, and returns the new path with row/column counts. It does not cover what happens if out_path already exists or the fidelity loss of xlsx-to-csv conversion, which are minor but relevant gaps.
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?
Three sentences, zero filler: trigger/purpose first, then side-effect behavior, then return value. Every sentence earns its place and the most decision-relevant info is 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?
The schema fully documents all four parameters, and the description covers purpose, side effects, and return value despite having no output schema and no annotations. Missing details like overwrite behavior when out_path already exists and cross-format fidelity caveats are gaps, but an agent has everything needed to call 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?
Schema description coverage is 100% and each parameter already has a rich description (extension list, ~ expansion, default sheet selection, out_path constraint). The description merely reinforces the out_path default and source-immutability, adding no new parameter-level meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (convert) plus resource (a sheet) and the exact format scope (xlsx, csv, json). This clearly distinguishes it from sheet_read/sheet_write and the generic convert/convert_many siblings, so an agent knows immediately which tool handles format conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Call this tool to convert a sheet between excel (xlsx), csv and json" provides a clear trigger condition for when to invoke it. It does not explicitly name alternatives or state when not to use it (e.g., sheet_read for reading content), so it stops short of a 5.
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?
No annotations are provided, so the description carries the burden; it discloses the key side effect: only one timer runs and starting a new one stops and logs the previous one. It does not elaborate on output or persistence beyond that, but the core behavioral trap is explicitly flagged.
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?
Two sentences with no filler. The first sentence front-loads action and scope; the second delivers the most important behavioral caveat.
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 state-transition tool with fully described schema parameters, the description captures purpose and the critical runtime constraint. It does not describe return values, but no output schema exists and the endpoint's behavior is adequately specified for selecting and invoking 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?
The input schema covers all 5 parameters with their own descriptions, so the description does not need to repeat those semantics. It adds 'project or client' context but leaves rate, tags, and currency details to the schema, which is appropriate at full 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?
States a specific action ('Start a stopwatch') and resource scope ('billable work on a project or client'), and the single-timer limitation distinguishes it from siblings like timer_stop and timer_status. The title and name are expanded, not merely echoed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context: use when beginning billable tracking for a project or client. It does not explicitly name alternatives or exclusions, so it stops short of the top score.
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?
With no annotations, the description carries the behavioral disclosure burden. It transparently states that calling the tool starts tracking the URL, records an initial observation, supports an optional target, and is re-read via watch_refresh. This makes the side-effecting, stateful nature of the tool clear without relying on 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 three short sentences with no filler. It front-loads the core instruction and rationale, then compactly summarizes the watch lifecycle and the relationship to watch_refresh. Every sentence contributes useful 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 simple parameter set, no annotations, and no output schema, the description is largely complete: it explains what the tool does, why it exists, what side effects occur, and what to call next. It does not mention the return value or any watch identifier needed for later operations, but this is a modest gap for a straightforward 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 input schema already describes all four parameters with 100% coverage, so the baseline is 3. The description adds little beyond restating that a product URL is the input and that a target is optional; it does not provide additional format, constraint, or interaction details 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 a clear action: 'Starts tracking it' for any product URL, with an explicit first observation and optional target. It differentiates itself from a generic web fetch tool by explaining that generic fetching returns raw HTML without the price, and names watch_refresh as the follow-up action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: call this tool for product URLs when a generic web tool would be insufficient because it returns raw HTML without the price. It also points to watch_refresh for re-reading. It does not discuss when to prefer related tools like price_check or price_add_manual, but the core when/why is clear.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that imports can be added or replaced, that some may be skipped or blocked by the free clause cap, and it describes the exact return information (counts plus new library total). This gives the agent meaningful awareness of side effects and outcomes beyond a simple one-line summary.
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?
Two sentences with no wasted words. The first sentence states the purpose and scope; the second sentence describes the return value. The most important behavioral outcome, bulk-loading from file, is front-loaded.
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?
The tool's purpose, source format, overwrite option, and return metrics are all covered either in the description or the parameter descriptions. Since there is no output schema, the description appropriately discloses the return payload. No critical missing information prevents an agent from calling 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?
Schema description coverage is 100%, and both node parameters are already thoroughly documented in the schema. The description adds no additional parameter semantics because the schema already explains path formats, JSON Pro restriction, overwrite behavior, and the free clause cap. 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 ('bulk-load') with a clear resource ('clauses into the library') and source ('markdown or JSON file'). This clearly distinguishes it from single-clause tools like clause_add and export tools like clause_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening phrase 'Call this tool to bulk-load' clearly identifies the intended use case. It signals that this is for batch importing rather than individual clause operations, and the sibling list reinforces the contrast with clause_add. It does not explicitly exclude alternatives, but the intended scenario is clear.
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?
No annotations are provided, so the description carries the behavioral burden. It adds meaningful behavioral details beyond the schema: all conversions share the same ECB rate date, and each result is rounded to its target currency's minor units. It does not describe the response shape, but the described behavior is clear and non-contradictory.
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?
Two concise sentences deliver the core behavior without wasted words. The key constraint (one source, many targets, same rate date) is front-loaded, and the rounding detail adds value without bloating the description.
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 covers input semantics and key behavior, but there is no output schema and no explanation of what the result format looks like. An agent can invoke the tool reasonably well, but it cannot predict whether the response is an array, a map keyed by currency, or something else.
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?
Schema description coverage is only 33%, so the description must compensate. It maps 'amount' to the single input amount, 'from' to the source currency, and 'to' to the many target currencies. This gives the agent the parameter roles even though the schema only documents 'to' with a brief description.
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 verb ('Convert') with a precise resource scope: one amount, one source currency, many target currencies, all using the same ECB rate date. The 'many targets' qualifier clearly distinguishes this tool from the sibling 'convert' and other rate-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the intended use case: converting one amount into multiple currencies at once. It does not explicitly name alternatives or state when not to use the tool, but the 'one source, many targets' framing gives an agent enough context to select it over the singular 'convert' sibling.
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?
No annotations are provided, so the description carries the behavioral burden. It discloses the return behavior: outline of headings, full text in document order, or block structure, and notes that usage is free and unlimited. 'Extract' also implies a non-destructive read operation, though it does not explicitly state 'does not modify the file.'
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 short, front-loaded with the invocation guidance, and delivers the output behavior in a singlefollow-up sentence. The 'Free and unlimited' note is brief and adds useful operational context without bloating the description.
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 two-parameter read tool with 100% schema coverage and no output schema, the description provides the essential decision and invocation information: what file type to target, what the tool returns, and the two output flavors. Nothing critical 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?
Schema description coverage is 100%, so the schema already fully documents both 'path' and 'format.' The description's mention of outline/headings and block structure loosely maps to the format enum, but it does not add meaningful parameter semantics 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 uses a specific verb and resource: 'extract the text of an existing .docx.' It clearly differentiates this tool from siblings like doc_to_html, pdf_text, and resume_read by specifying the .docx text-extraction behavior and the outline/block-structure output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening phrase 'Call this tool to extract the text of an existing .docx' gives explicit guidance on when to use it. It does not name alternative tools or exclusion cases, but the context is clear enough for an agent to select it for reading .docx text.
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?
No annotations are provided, so the description carries the burden of explaining behavior. It discloses that a new .ics file is written, that UTC times are used, and that the file is intended for sending or importing elsewhere. It does not describe error cases or what happens if both ids and from/to are supplied, but the core behavior is transparent.
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?
Two focused sentences, no filler. The purpose and key usage distinction are front-loaded, and the timezone detail is placed where it matters. Every sentence 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 adequate for a straightforward export tool, but gaps remain: it does not clarify what happens when both ids and from/to are omitted or supplied together, and it only references events_list as the source for ids while the schema also allows events_search and next_event. With no output schema, a bit more detail about expected results would strengthen completeness.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful cross-parameter guidance by presenting ids and from/to as mutually exclusive alternatives, and explains why UTC matters for the output. This goes beyond simply restating 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 a specific action and resource: 'write chosen events to a new .ics file'. It clearly separates this from siblings like export_csv or ics_create by focusing on exporting existing events into an .ics file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly tells the agent how to scope the operation: pass either ids or a from/to window. It does not explicitly name sibling tools to avoid, but the context of sending or importing the .ics elsewhere is clear enough for correct use.
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?
No annotations are present, so the description carries the behavioral burden. It discloses the inclusion rule ('unpaid or partly paid ... past due'), the computed fields (days overdue, outstanding amount, total per currency), and the service trait 'free and unlimited.' It doesn't explicitly state there are no side effects, but the report framing and output enumeration make the read-only behavior clear.
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 tight sentence that front-loads the trigger before the criteria and outputs. Nothing is redundant with the schema, and every clause contributes to call selection or expected results.
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 one-parameter read-only report with no output schema, the description provides the scope, the selection criteria, and the return fields. There are no hidden prerequisites or additional inputs, so an agent has enough to call 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?
Schema coverage is 100%: the only parameter as_of is already described ('YYYY-MM-DD, defaults to today'). The description adds no extra parameter detail, which is acceptable at the baseline since the schema already documents it.
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 opens by naming the exact user question it answers ('which invoices are overdue?') and then defines the resource and selection rule: every unpaid or partly paid invoice past its due date. It lists the output fields, so an agent can distinguish it from broader invoice tools even without opening 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger: use it when the user asks which invoices are overdue. It doesn't explicitly mention alternatives or when not to use it, but in a large sibling set the question-based trigger is sufficient context for typical selection.
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?
With no annotations provided, the description carries the burden of disclosing behavior. It explicitly states 'Read-only' and explains error handling: unreadable files are reported per file while others still count. This provides useful transparency beyond basic functionality.
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 succinct and well-structured. It efficiently conveys the core functionality, additional behavior, and limitations without unnecessary verbosity, making it easy for an agent to parse and act upon.
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 simplicity of the tool and the absence of an output schema, the description provides comprehensive context. It covers the purpose, edge-case handling, safety (read-only), and usage limits (free tier), leaving no critical gaps for an agent to make an informed call.
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 already provides a description for 'paths' as 'Paths to the PDF files,' achieving 100% coverage. The tool description adds context by specifying 'any number of PDFs' and explaining how unreadable paths are handled, enriching the semantic understanding of the parameter.
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's function: counting pages per file and providing a total for multiple PDFs. It distinctly identifies the resource (PDFs) and the operation (page counting), setting it apart from sibling tools like pdf_info or pdf_pages.
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 by stating 'for any number of PDFs' and 'Read-only,' but it does not explicitly mention alternatives or when not to use this tool. The guidance is implicit rather than explicit, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It explicitly states that already-generated invoices remain untouched, that generation history is kept as an audit trail, and that the call returns the client plus remaining invoice/history counts. This clearly signals a destructive but scoped operation.
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 three short sentences with the action front-loaded. Each sentence adds distinct high-value information: what the tool does, what it preserves, and what it returns. There is 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 single-parameter tool with no output schema, this definition is complete. The description covers side effects and return values, while the schema fully documents the id parameter and its deletion implications. The only notable gap is alternative routing, which is already captured under usage guidelines.
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, id, is already documented in the schema with 100% coverage, including the ability to pass a client name and the permanent deletion/re-creation warning. The tool description adds no additional parameter-level meaning, so the 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 opening sentence 'Remove a schedule' states a specific action and resource. The rest clarifies the scope of the deletion and what is preserved, making the tool's purpose unambiguous and distinct from sibling lifecycle tools like schedule_pause, schedule_resume, and schedule_update.
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 this is for permanent removal and gives consequential context, but it never explicitly says when not to use it or recommends non-destructive alternatives such as schedule_pause for temporary stops. The guidance is mostly implied by the tool name and the deletion semantics.
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?
With no annotations provided, the description carries the behavioral disclosure burden. It does this well by explaining a non-obvious consequence: periods that fell due while paused are still due and will be created by the next invoice_generate_due. It does not mention error handling or idempotency, but the key behavioral nuance is covered.
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 two short sentences with no filler. The primary action is front-loaded, and the second sentence adds important behavioral context without redundancy. Every sentence contributes.
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 has one required parameter, no output schema, and no annotations, the description is sufficient. It defines when to use the tool and the important downstream effect on invoice generation, so an agent has what it needs to invoke 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?
The schema coverage is 0%, so the description should compensate for the undocumented id parameter. It does not explicitly say that id identifies the paused schedule to resume, though 'a paused schedule' implies the target. For a single, simple required parameter this is a minor gap rather than a critical one.
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 verb and resource: 'Make a paused schedule active again.' This clearly expresses the operation and target, and the word 'schedule' disambiguates it from the unrelated resume_to_markdown, resume_read, and resume_create 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear condition for use: the schedule must be paused. It does not explicitly name alternatives like schedule_update or schedule_pause, but the condition and action are clear enough for an agent to select this tool appropriately.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It is transparent about what the tool returns: watches meeting the stated price-drop criteria, along with change percentage and reading confidence. It does not mention data freshness or whether it triggers refreshes, but for a list-like read operation this is reasonably complete.
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 packs the purpose, the triggering question, the two inclusion criteria, and the key output fields without any filler. It is front-loaded with the user intent and stays tightly scoped.
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 zero-parameter tool, the description is sufficient to call it and understand the return value's key fields. It leaves minor ambiguity around terms like 'target' and 'previous observation', but the overall behavior is clear and no output schema exists to compensate.
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 input schema is empty and 100% covered. The description does not need to document parameter semantics. Baseline 4 applies because there is nothing missing for an invocation.
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 ('lists every watch') and defines the exact conditions for inclusion (price at/below target, or ≥5% drop). It clearly differentiates itself from siblings like watch_list (all watches) and price_check (single current price) by focusing on pending discount alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening phrase 'Answer "did anything I watch get cheaper?"' gives a clear trigger for when to use this tool. It does not explicitly exclude alternatives such as price_check or watch_list, but the use case is implied well enough for an agent to select it correctly.
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?
No annotations are provided, so the description carries the burden, and it discloses the key behaviors: writing a new file, returning the new path, and reporting replaced, unfilled, and ignored placeholders. It also adds the non-obvious behavior that calling with no values lists placeholders instead of filling. It could state explicitly that the original template is never modified, but 'write a new file' plus the schema's out_path default make this reasonably clear.
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 two sentences with the primary action front-loaded. It includes only essential information: the operation, the return value, and the alternate listing mode. No filler or duplication of schema details.
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?
With no annotations and no output schema, the description still covers the main call, the return payload, and the no-values listing mode. It relies on the schema for overwrite and out_path details, which is acceptable, and it could add a brief note that the original template itself is not modified, but overall it is complete enough 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.
Parameters4/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, but the description adds meaningful value by explaining that omitting values triggers placeholder listing. This clarifies that values is optional and that an empty/absent values object has a distinct, useful behavior. The ignored-status language also helps the agent interpret values that do not match any placeholder.
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 action: replace {{placeholders}} in an existing .docx and write a new file. It also distinguishes the tool from document creation/reading siblings like doc_create, doc_read, and cover_letter_create by focusing on template filling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Call this tool to replace {{placeholders}}' clearly establishes the primary use case, and the no-values listing mode provides a secondary use. It does not explicitly name sibling alternatives or when-not-to-use conditions, but the intended context is clear.
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?
With no annotations, the description carries the full burden, and it does disclose the main behaviors: entries get stamped, reports and invoice_summary stop offering them, and double-billing is prevented. The ids parameter description adds that already-billed entries are left alone and listed back, which is useful idempotency behavior. It does not detail reversibility or permissions, but the core mutable effect is transparent.
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 one tight sentence that front-loads the purpose and consequence. Every clause earns its place, with no repetition of the title or filler.
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 mutation tool with no output schema and no annotations, it covers what it does, when to run it, why it exists, and how to select entries. Minor gaps are an explicit statement of what is returned for successfully billed entries and whether the change can be undone, but the tool is callable with the information provided.
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?
Schema descriptions already cover parameters, so the baseline is 3. The description adds meaningful selection semantics: 'Pass either ids or project plus from and to' plus the typical source 'entry_ids invoice_summary returned'. This clarifies the two mutually exclusive calling modes and helps an agent avoid passing conflicting 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 uses a concrete verb and object ('stamp the tracked hours ... with the invoice number') and explains the business purpose ('so report and invoice_summary stop offering them and the same hours are never billed twice'). This clearly differentiates it from siblings like invoice_mark_paid, which marks an invoice paid rather than the underlying time entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger condition ('after an invoice is issued') and references invoice_summary as the source of entry ids, making the workflow placement clear. It does not enumerate exclusions or alternatives, but an agent can infer when this tool is the right step.
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?
No annotations are provided, so the description carries the burden of explaining behavior. It discloses the default local+UTC result with no zones and enumerates accepted input formats. It does not describe output shape or ambiguity of abbreviations, but for a simple read-only time lookup this is reasonable 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 compact and efficient: the purpose is in the first sentence, input flexibility is second, and default behavior is third. Every sentence earns its place and no unnecessary detail is included.
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 single optional parameter with no annotations and no output schema, the description covers how to invoke it and what the default call returns. It does not specify the exact result structure, but the tool's simplicity and clear intent make it adequately 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 already describes the zones parameter and an example, so the baseline is 3. The description adds meaningful detail by listing the accepted forms — IANA zones, city names, country names, and abbreviations — and by stating behavior when the parameter is omitted. That goes beyond the schema's minimal description.
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 specific verb and resource: it reports the current time in one or more places. It also clarifies accepted input types (IANA zones, city names, country names, abbreviations), which distinguishes it from sibling time tools like convert_time and overlap. This is enough for an agent to select it appropriately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use it for current time in one or more places, and explains the default behavior when no zones are provided. It does not explicitly name alternatives or exclusions, so it falls just short of full guidance.
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?
With no annotations present, the description carries the full burden of behavioral disclosure. It usefully states that the input PDF is never modified, that duplicate page requests are copied twice, and that the free tier supports files up to 30 pages. These are genuinely helpful behavioral traits beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, all substantive: purpose, ordering example, duplicate behavior, input safety, and a size limit. The primary action is front-loaded, and no word is wasted.
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 four-parameter tool with no output schema, the description covers the essential operational semantics: how page selection works, why duplicates matter, and that the source is untouched. The optional overwrite flag is already explained in the schema. It does not discuss failure modes, but that is acceptable given the tool's simplicity.
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?
Schema coverage is 100%, so each parameter already has a description. The description adds value on top by illustrating the count interpretation ('2,4-6' gives four pages) and emphasizing duplicate copying behavior for the pages parameter. This reinforces and clarifies the schema rather than simply repeating it.
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 opens with an explicit verb and resource: 'pull selected pages into one new PDF'. This clearly states the action and distinct scope, differentiating it from merge-all or split-into-multiple tools like pdf_merge or pdf_split. The detail 'in the order written' further clarifies a unique behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a direct call-to-action ('Call this tool to pull selected pages into one new PDF') and a concrete page-range example, so the agent knows exactly when to invoke it. It does not explicitly name alternative tools or exclusion criteria, but the context is clear enough to route the call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states the tool is read-only, indicates it returns nothing for scans, describes how custom-encoded fonts produce glyph indices, and notes that it reports which case applies. It also discloses the free-tier limit, giving an agent good expectations about behavior and constraints.
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 compact and front-loaded: it opens with a direct instruction, then adds the key limitations and the safety attribute. Every sentence contributes information relevant to invoking the tool correctly or understanding its outputs. The free-tier note is brief and does not bloat the 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?
Given the simple two-parameter schema and no output schema, the description covers the essential edge cases: scans, custom-encoded fonts, and read-only behavior. It could be slightly more explicit about the exact return format, but 'says which case applies' partially addresses that. Overall, this is a complete enough description for an agent to select and 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?
The input schema has 100% description coverage for both parameters: 'path' is described as the PDF to read and 'pages' includes an example format and defaults to every page if omitted. The description adds no additional parameter-level 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('best-effort text extraction') and the resource ('standard-font PDFs'), and clarifies it is read-only. This distinguishes it from sibling PDF tools like pdf_info, pdf_merge, or pdf_pages by focusing on extracting text content. The title and description together leave no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to call the tool ('for best-effort text extraction from standard-font PDFs') and gives clear exclusions by noting scans return nothing and that no OCR is performed. It does not explicitly name an alternative tool to use for scanned or non-standard PDFs, but the context is clear enough for an agent to select this tool appropriately.
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?
With no annotations, the description carries the behavioral disclosure burden. It reveals that results are sorted newest last, that each observation includes price, currency, source, and confidence, and that free accounts see only the last 30 records. This is meaningful behavioral context beyond the schema, though it does not address errors or the id/url selection 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 two sentences with no filler. The primary action and target resource are front-loaded, and the behavioral details are concise and relevant. Every sentence 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 list operation with three optional parameters and no output schema, the description adequately covers return fields, ordering, and a service limitation. It lacks explicit guidance on conflicts between id and url or error cases, but those are minor for this tool's simplicity.
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 input schema already covers all three parameters with descriptions, so the baseline is 3. The description adds useful semantics by framing id/url as identifying a single watch and by linking the free-tier 30-record cap to the limit parameter. This goes slightly beyond the schema's basic property 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 states a specific action ('list stored observations') on a specific resource ('one watch') and details the returned data: price, currency, source, and extraction confidence. This clearly distinguishes it from siblings like price_check, which would focus on current pricing rather than historical observations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use the tool ('Call this tool to list stored observations for one watch') and gives context about ordering and free-tier limits. It does not explicitly name alternative tools or exclusion conditions, but the use case is clear enough to route an agent correctly.
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?
No annotations are provided, so the description carries the burden. It discloses key side effects: no invoice is created for the skipped period, every other period bills normally, and it returns the amount not billed and how to undo. It does not explicitly describe the undo behavior as an action of this tool, but the schema covers that.
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?
Two sentences with no wasted words. The core action, effect, and return value are stated efficiently 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?
The description plus rich schema covers the main decision (skip vs. pause), the invoicing effect, and the return value. It omits explicit mention of the undo parameter as a call path, but the schema documents it. Sufficiently complete for a three-parameter 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 all parameters are already documented in the input schema. The tool-level description adds minimal parameter-specific meaning beyond the 'single occurrence' context, 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?
States a specific verb and resource: 'Skip a single occurrence of a schedule.' It explicitly distinguishes from pausing and references the sibling schedule_pause in the period parameter description, making selection unambiguous for 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool: 'This is the answer to pause this client for October' and contrasts with schedule_pause, which stops the whole schedule and back-bills missed periods. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses the converted amount, the cross rate to 6 decimals, the rounding applied, and the rate date used. The parameter descriptions further reveal important behaviors like default-to-currency, minor-unit rounding, weekend/holiday fallback, and the 90-day window fallback. This gives an agent a reliable picture of the tool's behavior, including edge cases.
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 two tightly written sentences: the first front-loads the call action and scope, the second compactly enumerates the return contract. Every clause adds value, and the parameter descriptions are detailed without being bloated.
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?
There is no output schema, but the description compensates by listing the returned fields: converted amount, cross rate to 6 decimals, rounding applied, and rate date used. Combined with complete parameter documentation and fallback behaviors, an agent has enough information to invoke the tool correctly and interpret the result.
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 rich descriptions for all four parameters including defaults, rounding behavior, date fallback, and the euro cross-rate path. The main description adds high-level context but does not need to restate parameter details; 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('convert an amount') with a clear resource scope: any two ECB-quoted currencies, today or on a past date. It is easily distinguished from sibling tools like convert_time or currency-rate lookups because it focuses on a single conversion and its output contract. The title and description reinforce each other 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening phrase 'Call this tool to convert an amount' gives a direct, actionable usage instruction, and the scope (single amount, ECB currencies, date choice) defines the context clearly. It does not explicitly name alternatives such as convert_many or fx_rates_for, so it stops short of a full 5, but the guidance is well implied.
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?
With no annotations, the description carries the behavioral burden. It discloses that the tool returns stored prices from the last refresh rather than live values, which is a meaningful behavioral trait. It does not mention pagination, ordering, or empty-list behavior, but for a simple no-parameter listing tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the action and resource, lists the return fields, and ends with the critical freshness caveat. Every word earns its place.
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 no-parameter list tool with no output schema, the description adequately conveys both the return content and the relevant staleness behavior. An agent knows what to expect and how the data relates to watch_refresh.
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 input schema has zero parameters, so there is nothing for the description to clarify. Baseline 4 applies because parameter semantics are not a concern.
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 ('Show') with a clear resource ('every tracked item') and enumerates the exact data fields returned. This unambiguously identifies it as the watch-list listing tool and distances it from watch_add/watch_remove or price_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The caveat 'Prices are as of the last watch_refresh, not live' provides clear context that this is a read-only snapshot and implicitly points to watch_refresh for more current data. It does not explicitly name alternatives or exclusion conditions, but the freshness context is enough for an agent to choose correctly.
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?
No annotations are provided, so the description carries the full burden. It discloses a critical behavioral trait: stored observation history is deleted and cannot be recovered, which alerts the agent to the irreversible destructive nature of this operation.
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?
Two sentences with no filler. The action is front-loaded, the parameter options are stated, and the critical irreversible consequence is included in a compact second sentence.
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 two-parameter tool with no output schema, the description fully covers purpose, parameter selection, and the only significant behavioral consequence. There is no missing guidance an agent would need to invoke it correctly.
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?
Schema coverage is 100%, so the parameter descriptions already provide baseline meaning. The description adds value by explicitly presenting id and url as alternatives ('Give either id or url'), clarifying that they should not both be supplied.
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 ('stop tracking') and clearly identifies the resource ('an item' or watch). It distinguishes this tool from siblings like watch_add, watch_list, and watch_refresh by focusing on removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: when you want to stop tracking an item. It also clarifies the two input modes (id or URL), though it doesn't explicitly name alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the important side effect (creates a watch for the URL if not present) and the return value (stored price and observation count). No annotations are present, so the description carries the full burden and meets it well.
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?
Two succinct sentences that front-load the purpose and then cover side effects and return value. Every word earns its place with no redundancy.
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 tool with no output schema, the description helpfully mentions the return contents (stored price and observation count) and side effects. It could specify the response shape more precisely, but it is sufficient for typical 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?
Schema descriptions already cover all four parameters, including format examples for price and ISO for currency. The description does not add significant extra semantic meaning beyond what the schema 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?
Clearly states the action (store a price), the resource (a manually read price), and the specific context (shops that block automated requests). It is easily distinguished from sibling tools like price_check, which imply automated retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly indicates when to use this tool: when you read the price yourself and automated requests are blocked. This provides clear guidance relative to automated price-checking alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects, and it does so well. It explicitly states the source is never modified unless out_path points at it, and it describes the return value: new file path, row count, and a preview of the first rows. This gives an agent a clear mental model of the operation's 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 two sentences and every sentence earns its place. The core purpose and the critical safety behavior are front-loaded, and the return-value information is compactly included. There is no redundant repetition of schema details.
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?
The description is complete for correct invocation: it covers the operation, the crucial file-safety behavior, and the return values. With 7 parameters fully documented in the schema and no output schema, the description fills the remaining gaps without omitting anything an agent needs to know to call the tool correctly.
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?
Schema coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by explaining the key safety semantic: the source is never modified unless out_path points at it. It also frames the operation as producing a new file, which helps disambiguate the role of out_path.
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 and resource: 'add a computed column' and 'save the result to a NEW file.' This clearly distinguishes the tool from sibling sheet tools, especially ones that may modify the source file, and leaves no ambiguity about the core action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to call the tool: to add a computed column and produce a new file. It also clarifies the source file is never modified unless out_path points at it, giving clear context. It does not explicitly name an alternative tool or a when-not-to-use condition, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden: it discloses that the input is never modified, that it writes one new PDF per range, that overwrite defaults to false, and that nothing is written if any target 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 short, front-loaded with the action, and uses compact examples. No redundant sentences.
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 4-parameter tool with no output schema, the description is complete: it defines range syntax, output naming with placeholders, overwrite behavior, and constraints. An agent has enough information to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter has a meaningful description: ranges syntax, overwrite default, and out_path_pattern placeholders with an example. This exceeds the baseline for covered 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 explicitly says 'write one new PDF per range', a specific action on a specific resource, and the 1-based range examples make the split behavior unambiguous. This distinguishes it from siblings such as pdf_merge and pdf_reorder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to call the tool ('to write one new PDF per range') and gives a concrete range example. It does not explicitly contrast with alternative PDF tools, so it falls short of 5.
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

mcp-office-suite MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![mcp-office-suite MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/theluckystrike/mcp-office-suite/badges/card.svg)](https://glama.ai/mcp/servers/theluckystrike/mcp-office-suite)

Score Badge

Copy to your README.md:

[![mcp-office-suite MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/theluckystrike/mcp-office-suite/badges/score.svg)](https://glama.ai/mcp/servers/theluckystrike/mcp-office-suite)