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

Describes HTTP method, path, params, body but does not disclose return value format, error behavior, or authentication details. With no annotations, more transparency on response would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Reasonably concise with a clear 'Args' section. The example of fetching openapi.json adds extra but valuable information. Could trim slightly but overall well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Provides enough to use the tool: method, path, params, body, and a link to full docs. However, no output schema or description of return value is a gap for completeness. Adequate but not exemplary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the docstring clearly explains each parameter: method (GET/POST/PATCH/DELETE), path (relative to base), params (query parameters), body (JSON for POST/PATCH). Adds useful context beyond bare schema.

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

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

Description explicitly states it calls any Aikount API endpoint not covered by a dedicated tool, clearly distinguishing it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear guidance to use when an endpoint is not wrapped by a dedicated tool, and suggests fetching the OpenAPI spec for discovery. No explicit when-not-to-use, but context is sufficient.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It only states that a contact is created and explains the `country` parameter. Missing details include required permissions, side effects, return format, and validation behavior. This is insufficient for trust.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with one sentence, but is too brief for a tool with 8 parameters. It earns its place by stating purpose and clarifying one parameter, but lacks depth for other aspects. Acceptable but not optimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 parameters, defaults, no output schema, no annotations), the description is incomplete. It does not explain all parameters, what the response looks like, or how creation fits with other tools like list_contacts. Significant gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only explains the `country` parameter, leaving 7 out of 8 parameters (vat, name, email, notes, legal_name, is_customer, is_supplier) unexplained. This provides minimal added semantic value.

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

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

The description clearly states the verb and resource: 'Create a contact'. This is specific and distinguishes it from sibling tools like list_contacts, as there is no other creation tool. 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or situations where this tool is not appropriate. Agents are left to infer usage from the name alone.

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

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

Without annotations, the description discloses that the invoice is created as a draft, not finalized. It details the unit format (major units) and line structure. However, lacks information on idempotency, authorization, or error states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, front-loading the key action, followed by a clear note on units, then a bullet-like list of line fields and arguments. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers most parameters but omits notes, currency, and due_date (though optional). No output schema exists, so return value is not explained. For a 7-parameter tool with 3 required, the description is quite complete but could mention the optional fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description thoroughly explains parameters: contact_id, doc_date, series_id, lines format with field-level details (description, quantity, unit_price in euros, tax_type_id, discount_pct, irpf_rate). It compensates fully for the missing schema descriptions.

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

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

The description clearly states 'Create a DRAFT sales invoice', with a specific verb and resource. It distinguishes from sibling tools like issue_invoice and get_invoice by emphasizing the draft nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call issue_invoice to assign a number, providing clear when-to-use guidance and indicating that this tool only creates drafts. Also specifies required arguments.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states that the tool polls status/result, but does not disclose whether it is idempotent, blocking, error behavior, or any other behavioral traits beyond a basic poll operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence that efficiently conveys the core purpose and includes a cross-reference to a related tool. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description should provide more context about return values, error handling, and polling behavior. It only mentions status/result without detailing what is returned or how to interpret it, leaving significant gaps for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for the job_id parameter, and the description does not add any meaning or guidance about the parameter (e.g., format, source, uniqueness). This leaves the agent with no semantic help for using the parameter correctly.

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

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

The description clearly states the tool's purpose: to poll the status/result of an AI ingest job. It uses a specific verb (poll) and resource (status/result of AI ingest job), and references the sibling tool ingest_purchase_pdf to provide context and distinguish it from the ingestion initiation tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by referencing ingest_purchase_pdf, suggesting this tool is used after initiating an ingest job. However, it does not explicitly state when to use it vs alternatives or provide exclusions.

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

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

The description states it returns the full invoice, implying no side effects. Without annotations, it carries the burden but does not mention error handling, rate limits, or authentication. It is minimal but sufficient for a simple read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no wasted words. It efficiently conveys the essential purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description implies the response is the full invoice, which guides the agent. It is complete for a simple fetch but could benefit from mentioning the output format or key fields. Sibling tools are differentiated implicitly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not elaborate on the doc_id parameter beyond the schema. With 0% schema coverage, the description could explicitly state that doc_id is the invoice's UUID, but it only says 'by UUID' without linking to the parameter.

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

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

The description 'Fetch one sales invoice in full by UUID' clearly specifies the action (fetch), object (one sales invoice), and scope (in full). It distinguishes from sibling tools like list_invoices which fetch multiple summaries. However, it could explicitly link 'doc_id' to the UUID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives (e.g., list_invoices). No prerequisites or conditions are mentioned, such as requiring the doc_id from a prior list.

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

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

No annotations provided, so description must disclose behavior. Only states 'in full' but doesn't elaborate on what fields are returned, error scenarios, or rate limits. Could mention 'returns complete purchase object'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no fluff, front-loaded with action and resource. Efficient and clear. Could be slightly improved by adding output hint, but still good.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with 1 param and no output schema, but description fails to mention return format, error handling, or typical use cases. Adequate for a fetch tool but leaves agent with little context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but description only says 'by UUID' giving vague hint about doc_id format. Does not specify that doc_id is a UUID string or provide any additional meaning beyond schema.

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

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

Description clearly states verb 'Fetch', resource 'purchase document', and scope 'by UUID'. Distinguishes from sibling tools like list_purchases (list vs. get) and get_invoice (different resource). Minor vagueness in 'purchase document', but acceptable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., list_purchases), no exclusions or prerequisites. Simply implies usage via description. Lacks explicit context.

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

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

Without annotations, the description fully carries the burden of behavioral disclosure. It details the async nature, OCR process, dedup mechanism (by invoice identity), and the effect of the force parameter, providing a comprehensive behavioral profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a summary line, detailed behavioral explanation, and parameter descriptions. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately covers the async workflow and result retrieval via polling. It is complete for a 2-parameter tool, though could mention error handling or file size limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains file_path's file type support and force's purpose to bypass dedup, fully compensating for the schema's lack of descriptions.

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

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

The description clearly states it queues a purchase PDF for AI extraction, OCR, and dedup, creating a purchase document. It distinguishes itself from sibling tools like get_ingest_job and get_purchase by explaining the async workflow and dedup logic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (to ingest purchase PDFs) and provides guidance on the force parameter for bypassing dedup. It also advises polling get_ingest_job for results, but does not explicitly mention when not to use or alternative tools.

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

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

Discloses that the operation is irreversible-ish and why, and warns about contiguous numbering. With no annotations, this is full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise two sentences covering purpose and key usage warnings, no extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description covers the action, the constraint, and user guidance completely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter doc_id is not described in detail, but the tool name and description imply it is the draft invoice identifier. Schema coverage is 0%, so description partially compensates.

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

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

The description clearly states it issues a draft invoice and assigns the next legal number, distinguishing it from create_invoice and list_invoices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the irreversible nature and that it should not be used for renumbering, plus instructs to confirm with user.

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

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

No annotations are provided, so the description carries full burden. It only states 'Read ledger movements' implying a read-only operation, but lacks details on authorization requirements, rate limits, or whether ledger movements are destructive. The description is minimal and does not disclose potential side effects or constraints beyond the basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: one sentence for purpose, then clearly listing parameters with usage hints. No extraneous information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, no annotations, and no output schema, the description should be more comprehensive. It omits explaining limit and offset, and does not describe the return format or any pagination behavior. While it covers core parameters, the overall completeness is insufficient for an agent to use the tool correctly without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning for account_id (UUID, resolve from list_accounts) and date parameters (ISO date bounds), but fails to mention limit and offset parameters present in the schema. With 0% schema description coverage, the description should compensate, but it leaves two parameters undocumented, providing only partial value.

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

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

The description clearly states 'Read ledger movements for ONE PGC account', specifying the action (read), resource (ledger movements), and scope (one account). This distinguishes it from siblings like list_accounts (lists accounts) or list_bank_movements (bank movements).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides implicit guidance by noting that account_id should be resolved from list_accounts, but does not explicitly state when to use this tool versus alternatives like trial_balance or list_bank_movements. No exclusions or when-not scenarios are mentioned.

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

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

No annotations provided, so description carries full burden. It implies a read-only list operation but does not explicitly state non-destructive nature, side effects, or limitations. Discloses output fields but lacks behavioral details beyond that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. Front-loaded with what the tool does, then usage details. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description covers return fields (code, name, UUID, balance) and usage context for ledger and browsing. Missing explicit pagination explanation for limit/offset, but overall complete for a filtered list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description compensates well. Explains 'group' as leading PGC digit and 'search' as code or name. Does not explicitly describe 'limit' and 'offset', but their usage is conventional. Adds meaning beyond schema.

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

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

The description clearly states the tool lists the Spanish PGC chart of accounts with specific fields (code, name, UUID, balance) and ties it to a specific use case (resolving UUID for ledger). It distinguishes itself from sibling tools by focusing on accounts listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly explains when to use: 'resolve an account's UUID for ledger, or browse by group or search'. It describes group meaning (PGC digits) and search as free-text. While it doesn't explicitly state when not to use, the guidance is clear and actionable.

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

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

With no annotations, the description must fully convey behavioral traits. It only says 'list bank movements', implying a read operation, but fails to mention pagination (limit/offset), order, or what happens on empty results. No details on potential side effects or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear front-loaded purpose and a labeled list of arguments. No unnecessary words, though the Args formatting could be improved for readability. Overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks crucial details for a 7-parameter tool with no output schema or annotations. It does not explain the return format, pagination behavior (limit/offset defaults), or any ordering. The agent may not know how to use pagination or interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning for 5 of 7 parameters (treasury_id, status, from_date, to_date, search) with examples and types, but omits limit and offset entirely. Since schema coverage is 0%, the description partially compensates but is incomplete.

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

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

The description clearly states 'List bank movements' with optional scoping to a treasury, using a specific verb and resource. It distinguishes the tool from siblings like list_invoices or list_purchases, which deal with different entities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as reconcile_movement or searching via other endpoints. There is no explicit statement of when not to use it or any usage context.

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

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

No annotations provided; description does not disclose behavioral traits beyond listing. Lacks details on side effects, rate limits, or scope restrictions (e.g., which workspace).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Highly concise: one-line title followed by bulleted Args section. No redundant text, well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequately describes parameters but lacks return format details or output schema. Given no output schema, agent may not know what fields to expect in results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description fully explains each parameter: search (free-text match on name/legal name/VAT), kind (customer/supplier filter), limit (page size 1-500), offset (pagination). Adds significant value over schema.

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

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

Clearly states 'List contacts (customers and suppliers)', specifying verb and resource. Differentiates from sibling tools like list_invoices and list_accounts by explicitly mentioning the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus siblings. Does not mention prerequisites or context in which listing contacts is appropriate.

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

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

With no annotations, the description carries full burden but only mentions lifecycle states. It does not disclose pagination behavior, ordering, read-only nature, or any side effects. The description fails to convey that this is a safe read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear purpose line and structured args list. Every sentence contributes value. However, the omission of limit/offset could be considered a completeness issue rather than conciseness; the description itself is not verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, no output schema, and 0% schema coverage, the description is incomplete. It fails to explain pagination (limit/offset), return format, or default behavior. For a list tool, these are essential details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds value by explaining status, contact_id, from_date, and to_date with examples and format hints. However, it omits limit and offset parameters entirely, which are critical for pagination. Coverage is partial.

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

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

The description clearly states the tool lists sales invoices and provides a lifecycle summary. It is distinct from sibling tools like get_invoice (single invoice) or create_invoice. However, it does not explicitly differentiate itself from list_purchases or other list tools, and could be more specific about scope (e.g., 'all invoices').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides parameter examples but no guidance on when to use this tool versus alternatives like list_purchases or get_invoice. There is no mention of prerequisites or scenarios where this tool is appropriate or not.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication needs, or rate limits. The agent gets no safety or side-effect information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with a single sentence that front-loads the action. Every word is necessary, and there is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of output schema and annotations, the description is too minimal. It does not explain the return format or how to use parameters effectively, leaving significant gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides no information about the parameters (limit, offset, search). With 0% schema description coverage, the description fails to add meaning beyond the bare schema, which is insufficient.

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

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

The description clearly states it lists 'catalog products/services', which is a specific verb and resource. It distinguishes from sibling tools like list_invoices or list_contacts, though it could be more explicit about the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It does not mention pagination, filtering, or use cases, leaving the agent without context for proper selection.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, pagination behavior, sorting, or filtering defaults. The description carries the full burden but fails to provide sufficient context beyond the basic listing action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is very concise but at the cost of missing essential details. It does not earn its place as it provides minimal information. A tool with 5 parameters requires more exposition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no schema descriptions, and no output schema, the description is severely incomplete. It lacks coverage of pagination, filtering logic, default values, and return format. The description fails to adequately prepare an AI agent for proper invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description does not explain any of the 5 parameters. It does not mention that limit/offset control pagination, that dates filter by date range, or that contact_id filters by supplier. The description adds no value beyond what the parameter names imply.

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

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

The description clearly states the tool lists purchase documents, specifying it includes supplier invoices and expenses. However, the sibling tool 'list_invoices' exists, and the description does not differentiate between 'purchases' and 'invoices', leaving potential ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like list_invoices or list_contacts. There is no mention of prerequisites or context for appropriate use.

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

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

No annotations are provided, so the description carries the full burden. It discloses the tool's read-only nature (list operation) and the output format (UUIDs). It does not mention any side effects or permissions, but for a simple list tool 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that front-load the core action and then provide essential context. Every sentence adds value, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has no parameters, no output schema, and no annotations, the description covers all necessary information: what the tool does, what it returns (unique UUIDs), and why it is useful. It is complete for a simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so no parameter documentation is needed. The description does not add parameter semantics, but the baseline for no parameters is 4, and the description is adequate.

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

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

The description clearly states the tool lists the tenant's tax types (IVA/IGIC/IPSI/IRPF) and provides specific examples, making the purpose unambiguous. It distinguishes from sibling tools like list_accounts or list_products by specifying the domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool: to resolve UUIDs for tax codes when referencing taxes in invoices/purchases. It implies that string codes should not be used, but does not explicitly state when not to use it or suggest alternatives, which would improve the score.

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

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

With no annotations, the description carries the full burden. It discloses the key behavioral difference: live balance for Stripe/PayPal vs snapshot for bank-feed treasuries. This is sufficient for a read-only list operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no waste. The first sentence front-loads the purpose, and the second provides essential behavioral detail. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the key distinction (live vs snapshot) and covers the basic purpose. For a list tool with standard pagination, it is mostly complete. Missing details on return format are acceptable without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not mention the pagination parameters (limit, offset) or their behavior. While these are standard, the description adds no value beyond the schema.

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

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

The description clearly states the verb 'List' and the resource 'treasuries (bank / Stripe / PayPal accounts) with balances'. It distinctly identifies the scope, differentiating from sibling tools like list_accounts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context about live vs snapshot balances for different treasury types, but lacks explicit guidance on when to use this tool over others or prerequisites. No exclusions or alternatives are mentioned.

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

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

No annotations provided, but description discloses return format (CSV text) and data content (per transaction breakdown), and implies read-only behavior. Lacks details on auth or limits but sufficient for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise, front-loaded with purpose, then distinguishes from sibling, then lists args. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with only 2 params; description explains output fully and references sibling. Output schema exists, so no need to detail return structure further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description adds examples (e.g., 2026 for year, 1-4 for quarter) and clarifies quarter range, adding meaning beyond schema types.

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

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

The description clearly states it returns 'Modelo 303 backing detail for one quarter as CSV text' with per-transaction breakdown, and distinguishes it from sibling tool modelo_303_summary for aggregated totals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use this tool ('useful for auditing the numbers') and when to use the sibling ('For the aggregated box totals, use modelo_303_summary').

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

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

With no annotations, the description discloses it returns JSON with per-quarter data and fields. It does not mention side effects, authentication, or data freshness, but given it's a read-only query, the level of transparency is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences front-load the tool's purpose and usage guidance without any redundant or irrelevant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a zero-parameter tool with no output schema: it explains output type, content, and distinguishes from sibling. Slightly more detail on JSON structure would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist in the input schema, and schema coverage is 100%. Per guidelines, baseline score is 4; no additional parameter description needed.

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

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

Description clearly states the tool returns a JSON summary of every quarter's VAT activity, listing specific fields. It distinguishes from sibling modelo_303_csv by noting it provides a machine-readable overview versus a single-quarter AEAT file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises use of this tool for machine-readable overviews and directs to modelo_303_csv for AEAT-format single quarter files, providing clear when-to-use guidance.

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

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

No annotations are provided, so the description carries full burden. It only states the action ('manually match') but does not disclose side effects (e.g., whether it creates a record), authorization needs, reversibility, or any other behavioral traits beyond the immediate operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: a one-sentence summary followed by a clear Args list. Every word is necessary, and the structure front-loads the purpose. No redundant or extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter tool with no output schema, the description adequately covers purpose and parameters. However, it lacks any mention of the outcome or return value, which is important for an agent to understand what the tool produces upon success or failure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explicitly explains both parameters in a structured Args section: movement_id is a 'bank movement UUID' and document_id is an 'invoice or purchase UUID'. This adds meaningful context beyond the input schema, which only provides type and title. With 0% schema description coverage, this compensation is valuable, though no further format or validation details are given.

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

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

The description clearly states the tool's purpose: 'Manually match a bank movement to an invoice/purchase document.' It uses a specific verb ('match') and identifies both resources involved. This distinguishes it from siblings like 'reconciliation_board' or 'list_bank_movements' by specifying the exact action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as 'reconciliation_board', which might perform similar matching automatically. The description does not mention prerequisites, exclusions, or context for appropriate usage.

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

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

Discloses that the tool returns suggestions for confirmation, implying a read-only operation. No annotations exist, so the description bears full responsibility, and it adequately conveys the behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded, no wasted words. Every sentence adds essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description fully explains the purpose and content of the tool. It references the sibling tool for actions, making it contextually complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters to document, so baseline 4 applies. The description adds meaningful context about what the board contains, which adds value beyond the trivial schema.

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

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

The description clearly states 'Get the reconciliation board: suggested movement<->document matches.' It uses a specific verb and resource, and distinguishes from sibling tools like reconcile_movement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly explains that the system auto-reconciles matches with confidence >= 0.95, and suggests using reconcile_movement or dismiss for lower-confidence matches. Provides clear guidance on when to use this tool vs alternatives.

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

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

No annotations provided; description indicates read-only summary behavior but lacks details on auth needs or output structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences plus parameter line, no extraneous text, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Sufficient for a simple tool with one optional parameter and no output schema; covers scope, default behavior, and data format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only parameter at_date is explained beyond schema (ISO date, default today), compensating for 0% schema coverage.

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

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

Clearly states it computes a trial balance across all accounts, with explicit note that no account_id is needed, distinguishing it from account-specific tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage as a global overview tool; mentions it's a 'one-shot overview' without account_id, but does not explicitly contrast with siblings like ledger.

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

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

Discloses token verification, tenant info return, and endpoint behavior with API keys. No annotations provided, so description bears full responsibility; it does well but could mention idempotency or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise and front-loaded with purpose. Every sentence adds value without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description covers purpose, usage flow, response meanings, and a special note, making it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters; baseline is 4. Description adds value by explaining what the tool returns and how it authenticates.

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

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

Clearly states the tool verifies a token and returns active tenant details. Distinguishes from siblings by being a simple identity check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call this first, explains response codes (200 vs 401/403), and warns about endpoint differences for API keys vs interactive logins.

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