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

Annotations only declare readOnlyHint=false, so the description must carry the rest. It does add real behavior beyond the annotations: omitting importe pays all pending balance and transitions the invoice to 'paid', and writes must be enabled. It still doesn't say whether the action is reversible or how to undo it (e.g., cs_delete_payment).

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?

Three short, front-loaded sentences with no filler; the core action comes first, then the default-amount rule, then the precondition. Slight redundancy between the description and the importe field description keeps it from a 5.

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 4-parameter mutation tool with no output schema, the definition covers the action, the default-amount side effect and the write-access prerequisite. Missing only a note on return shape and how to reverse a payment, which are modest gaps.

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 75% and the schema itself documents fecha, importe and formaPagoId, including the default-all-pending semantics for importe. The description largely restates that default rather than adding new parameter meaning, so baseline 3 applies.

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

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

States a specific verb+resource pair ('Registra un pago ... o cobro ... en una factura') and clarifies that the same tool covers both received and issued invoices. It does not explicitly contrast with siblings like cs_delete_payment or cs_list_payments, but the write action 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?

Provides a useful precondition ('Requiere escritura activada') and explains the default behavior when no amount is given, which implies when to omit importe. However, it names no alternatives (e.g., how this differs from listing or deleting payments) and gives no guidance on partial-payment scenarios.

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 sole annotation readOnlyHint=false already signals a mutation, so credit here comes from added context: the write-enablement prerequisite and the accepted file formats (PDF or image). It remains silent on whether re-attaching overwrites a prior file, size limits, and what the call returns, which are meaningful gaps 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.

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

Two short sentences, front-loaded with the action and the file-type constraint, followed by the permission prerequisite. No filler and nothing redundant with the schema.

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 four-required-parameter mutation with no output schema, the description covers the target, the accepted inputs, and the write-enablement prerequisite. The remaining gap is return/overwrite behavior, which is moderate rather than critical given the tool's narrow scope.

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 50%, with descriptions present only for periodo and rutaArchivo. The description partially compensates by explaining that the target is a received or issued invoice, which maps onto the undocumented 'tipo' enum, but it adds nothing about 'invoiceId' or about format expectations for the file path beyond the schema text.

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 gives a concrete verb and resource: 'Adjunta un archivo local (PDF o imagen de la factura) a una factura recibida o emitida', including accepted file types and the two invoice kinds. That is specific enough to distinguish it from the reverse-direction sibling cs_download_invoice_pdf, though it never names that sibling explicitly.

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?

'Requiere escritura activada' is a clear prerequisite for use, and the file-type scope implies when the tool applies. However, there is no explicit when-not guidance (e.g. what to do if the invoice has no PDF yet, or whether this replaces an existing attachment), leaving usage partly inferred.

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 annotation only declares readOnlyHint=false, so the description does add value with "Requiere escritura activada", a real precondition an agent must satisfy before calling. However, it says nothing about what happens on a duplicate NIF, whether the call fails or merges, or what a successful creation returns — relevant gaps for a mutation tool.

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

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

Three short sentences: action, dedup precaution, precondition — each carries distinct information and nothing is redundant. Front-loading the core action is exactly right.

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 an 8-parameter creation tool with no output schema and near-zero schema coverage, the description is too thin: it never enumerates the required fields, key formats, or success/error behavior. Sibling routing and the write precondition are covered, but the input contract is left almost entirely unexplained.

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 only 13% (just 'nombre' documented as 'Razón social'), so the description is expected to compensate and does not: it mentions no fields, formats, or whether 'nif' must be unique/valid. The agent must infer the required identity fields (nombre, nif) and the meaning of the six optional address/contact parameters entirely from terse property names.

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?

"Crea un proveedor nuevo" states a specific verb (create) and resource (provider), which is unambiguous and clearly distinct from siblings like cs_search_entities or cs_create_received_invoice. It stops short of indicating what data the provider record holds, but the action itself is unmistakable.

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

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

It explicitly names the alternative workflow — search first with cs_search_entities to avoid duplicates — and states a precondition (write access must be enabled). What it lacks is guidance on what to do when a near-match is found (abort vs. proceed) or when the write flag is off.

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 only readOnlyHint=false supplied, the description adds real behavioral context: the server computes IVA and taxable bases per line, Contasimple rejects duplicates keyed on número+proveedor+año, and write access must be enabled. It does not say what is returned (e.g. the new invoice id) or how the duplicate rejection surfaces (error vs silent skip), which would be needed for a 5.

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?

Three short sentences, each carrying distinct information: what it creates, the server-side tax calculation, the duplicate-rejection constraint, and the write-access prerequisite. Nothing is redundant and the core action is front-loaded.

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

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

For a mutation tool with 11 parameters, 73% schema coverage and no output schema, the description covers creation behavior and duplicate handling well. However, it never states the return value (invoice id for follow-up tools such as cs_attach_file or cs_add_payment), leaving a meaningful gap for a create operation.

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

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

Schema coverage is 73%, so the schema already documents most fields including proveedorId, numero, fecha, claseId and the line-level base/ivaPorcentaje. The description adds meaning by explaining that IVA and bases are computed per line, but it does not clarify the interaction between base, ivaPorcentaje, imputacion or retencionPorcentaje, so baseline 3 applies.

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

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

States a specific verb and resource: 'Registra una factura recibida (de un proveedor)', which clearly distinguishes it from sibling creation tool cs_create_provider and from read tools like cs_list_invoices. It does not explicitly name which sibling handles the alternative path, keeping it below a 5.

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

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

The description gives a precondition ('Requiere escritura activada') which is genuine usage guidance, but it offers no when-to-use vs alternatives routing, e.g. checking for an existing invoice with cs_search_invoice_by_number before creating, or resolving proveedorId via cs_search_entities. Usage 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.

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is known. The description adds one genuinely new behavioral fact — that write access must be enabled — but says nothing about whether the deletion is permanent, whether the invoice balance/total is recalculated, or what a failure 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.

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

Two short sentences with the action and the prerequisite front-loaded; nothing is redundant. The terseness is efficient rather than padded, though it leaves no room for the side-effect details an agent would want.

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 destructive mutation with no output schema and only half the parameters documented, the definition is thin: it does not state irreversibility, the effect on invoice totals, or any recovery path. Annotations cover the destructive flag, but the description should carry more of the consequence story.

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 50% and the description names both concepts, making clear a payment is removed from a specific invoice, which reinforces the required invoiceId/paymentId pairing. It still adds no detail on the undocumented invoiceId or on how to obtain these IDs beyond the schema's hint pointing at cs_list_payments, so it does not fully compensate for the coverage gap.

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?

States a specific verb and resource in Spanish: 'Elimina un pago registrado por error en una factura', which unambiguously identifies deletion of a payment tied to an invoice. It is clearly distinct from the sibling write tool cs_add_payment and the read tool cs_list_payments, though it never names those siblings explicitly.

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?

'registrado por error' implies the intended scenario (only payments recorded in error should be removed) and 'Requiere escritura activada' gives a precondition, which is real usage context. However, there is no explicit statement of when NOT to use it, no alternative (e.g. correcting vs. deleting via cs_add_payment), and no note that the action is irreversible, so the guidance stays 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.

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

readOnlyHint=true tells the agent the server-side invoice is not modified, but the description usefully adds that the output is written to a local path, which is a filesystem side effect the annotation does not capture. It stops short of saying whether an existing file is overwritten, whether the target directory must exist, or what happens on failure; the tension between readOnlyHint and a local file write is left unresolved.

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 zero filler; the action and destination are stated immediately. It is efficient, though the brevity comes at the cost of the missing guidance noted elsewhere.

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

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

For a tool that writes a file to disk with no output schema and half its parameters undocumented, the description should cover overwrite behavior, directory requirements, and error cases but covers none. It is a minimal one-liner for a tool that has real side effects an agent needs to anticipate.

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 only 50%: rutaDestino is documented as an absolute path, but invoiceId has no description anywhere and the text merely says "de una factura" without clarifying where the ID comes from (e.g., cs_list_invoices) or its format. The description adds essentially no meaning 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 verb "Descarga" plus resource "el PDF de una factura" clearly identifies the operation (retrieve an invoice PDF), which is distinct from data-returning siblings like cs_get_invoice or cs_list_invoices. However, the description does not explicitly name or differentiate it from those siblings, so it falls short of a 5.

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

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

There is no guidance on when to use this instead of cs_get_invoice or cs_attach_file, nor any stated prerequisites (valid invoiceId, existing directory, permissions). The agent must infer the use case entirely from the name and the single sentence.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by stating what the response contains (lines, payments, issuer, receiver), but says nothing about behavior for an invalid or nonexistent id, or about permissions/visibility scope.

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?

One compact sentence, front-loaded with the action and resource, with the parenthetical enumerating return content efficiently. No filler.

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 single-parameter read tool whose annotations cover safety and whose return contents are enumerated inline (no output schema exists), this is nearly complete. The only missing piece is failure behavior for a bad id.

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?

There is a single parameter with 0% schema description coverage; the description only partially compensates by saying the lookup is 'por su id', establishing it as the invoice identifier. It adds no format, range, or source hint (e.g., where to obtain the id) beyond the schema's integer type.

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?

States a specific verb+resource ('Obtiene el detalle completo de una factura') and enumerates the returned components (líneas, pagos, emisor, receptor), which clearly distinguishes it from list/search siblings. It does not explicitly name the alternatives (cs_list_invoices, cs_search_invoice_by_number), so it falls short of a 5.

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

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

The phrase 'por su id' implies this is the path to take when you already know the invoice identifier, versus browsing via cs_list_invoices, but that contrast is only inferred. No explicit when-to-use or exclusions are given.

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

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

The readOnlyHint annotation already establishes this is a safe read. The description adds that the result is a catalog of valid values to be plugged into a specific field, but says nothing about output shape, whether values are static/cacheable, or whether either tipo returns a different set — modest added value beyond annotations.

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

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

Two short sentences with zero filler; the purpose is front-loaded and the prerequisite note follows. Every clause carries 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?

For a single-parameter lookup with no output schema and a readOnly annotation, the definition covers what an agent needs to select and call it. A brief note on what the response contains (e.g., identifiers plus labels) would close the only remaining gap.

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

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

Schema description coverage is 0%, so the description must compensate, and it partially does by mapping the concept to 'facturas recibidas o emitidas', which corresponds to the received/issued enum. However, it never states that tipo selects between those two sets, nor what each returns, so the enum values are left to be inferred from the schema alone.

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

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

States a specific verb and resource ('Lista las clases ... válidas para facturas') and clarifies the domain meaning of 'clases' as expense/income types, which is not obvious from the name. It is clearly differentiated from siblings like cs_list_payment_methods and cs_list_periods by resource, though it doesn't name them explicitly.

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?

Gives an explicit when-to-use signal: 'Necesario para invoiceClass al crear', telling the agent this lookup is a prerequisite for invoice creation. It stops short of naming the consuming sibling (cs_create_received_invoice) or stating exclusions, so it is clear context rather than a full routing rule.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description's burden is lighter. It adds the quarter scope and the fact that filters are optional, but says nothing about default period behavior, pagination defaults, or result volume limits — details that only appear buried 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.

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

A single, front-loaded sentence with no filler. It is efficient, though the terseness leaves little room for the usage and behavioral context the tool would benefit from.

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 9-parameter list tool with no output schema and only a readOnlyHint, the description is minimal: it omits pagination behavior, default period, and what a returned invoice record contains. The rich schema descriptions partially compensate, but an agent still has gaps to fill by inference.

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 89%, so the schema already documents nif, tipo, desde/hasta, filas, inicio, numero and periodo. The description adds marginal value by mapping 'emitidas o recibidas' to the tipo enum and 'de un trimestre' to periodo, but no syntax or semantics beyond that. Baseline 3 fits when the schema does the heavy lifting.

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?

States a specific verb and resource ('Lista facturas') plus scope ('emitidas o recibidas de un trimestre') and the existence of optional filters. An agent can tell it lists invoices, but the description does not name the closest siblings (cs_search_invoice_by_number, cs_get_invoice) to distinguish when this enumeration is the right choice.

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?

'Con filtros opcionales' only hints that filtering is possible; it gives no when-to-use rules, no prerequisites, and no routing to alternatives such as cs_search_invoice_by_number or cs_get_invoice. The only implicit guidance is the quarter scoping, which an agent must infer.

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?

readOnlyHint=true already declares this is a safe read, and the description adds that the result includes each method's id — useful but minimal. It says nothing about whether the list is workspace-scoped, whether it can be empty, or ordering, so behavioral context beyond the annotation is thin.

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 short sentence with zero filler: purpose, examples, key return field, and downstream usage all front-loaded. Nothing could be removed without losing 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?

With no parameters and no output schema, the description carries the return-shape burden and does so partially by naming the id field and example values. It does not state whether the full set of methods is always returned or whether results may be filtered, a minor gap for a zero-arg lookup 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 tool takes no parameters, so there is nothing for the description to document; baseline 4 applies. The description instead spends its words on the return field (id) that matters for chaining, which is a reasonable use of space.

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?

States a specific verb and resource ('Lista las formas de pago configuradas') and enumerates concrete examples (transferencia, tarjeta, domiciliación), so the agent knows this is a configuration catalog rather than transaction data. It does not explicitly differentiate itself from the similarly named sibling cs_list_payments, which lists actual payments, leaving slight room for confusion.

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

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

Explicitly names the downstream consumer: the returned id is 'necesario para cs_add_payment', which tells the agent exactly when to call this tool (before adding a payment). There is no explicit when-not guidance or mention of the other listing siblings, but the invocation context is clear.

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 readOnlyHint=true annotation already establishes the safety profile, so the description is only obligated to add context beyond it — and it adds essentially none. It says nothing about ordering, pagination, result size, or what happens when the invoice has no payments, all of which matter for a list tool.

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?

One short, front-loaded sentence with no redundant wording. It is efficient, though the brevity comes at the cost of the missing behavioral detail noted elsewhere.

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

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

This is a simple single-parameter read tool with no output schema, so the bar is modest, and the annotations already cover the read-only nature. However, with zero schema coverage on invoiceId and no indication of return shape or result ordering, an agent is left guessing about output behavior.

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 invoiceId carries no documented meaning in the schema; the description partially compensates by making clear the parameter identifies the invoice whose payments are returned. It still gives no format, type, or validation detail, so the compensation 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?

Names a specific verb (lista) and resource (los pagos o cobros registrados en una factura), so an agent can tell it retrieves payments as opposed to creating or removing them. It does not explicitly name cs_add_payment or cs_delete_payment as the mutating siblings, so differentiation is inferred from the verb 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.

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

There is no when-to-use guidance, no mention of alternatives, and no stated prerequisites beyond the implicit need for an invoice. An agent must infer that this is the read counterpart to cs_add_payment 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?

While annotations confirm read-only safety, the description provides crucial behavioral context by stating the status of the periods ('abiertos o cerrados') and gives a specific format example ('2026-4T').

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 highly efficient, front-loading the core function and providing a clarifying example immediately, resulting in zero 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 that it takes no parameters and its safety profile is handled by annotations, the description is fully complete for a simple financial read operation.

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

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

Schema coverage is 100% (zero parameters), so the description is not required to add semantics to input parameters. Baseline 3 is appropriate for a parameter-less tool.

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

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

The description uses a specific verb ('Lista') and resource ('periodos contables'), clearly distinguishing its function as a financial lookup 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?

As a parameter-less tool, it is easy to use. The description provides strong context by defining exactly what is being listed (accounting periods) without needing explicit 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?

The readOnlyHint already establishes this is a safe read operation. The description adds domain semantics (pending collection/payment invoices for a month) but does not explain whether the result is an aggregate summary, a list, or what 'pending' precisely means, and there is no output schema to fill that gap.

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 short sentence with no wasted wording, front-loading the resource and scope. It is terse enough to be efficient, though the parenthetical enum mapping and missing verb make it slightly less structured than ideal.

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 read-only tool the description covers the domain and parameter intent, and the readOnlyHint covers safety. However, with no output schema and no explanation of the summary's return shape, an agent still lacks important information about what it will receive.

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 the description must carry parameter meaning. It usefully maps tipo's enum values to business meanings (issued=collection, received=payment) and implies mes/anio scope, but it does not explicitly define the month/year format or clarify the summary granularity.

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 identifies the resource (pending invoices) and scope (a month) and maps issued/received to collection/payment, which is clear. It lacks an explicit verb like 'summarize' or 'list' and does not distinguish itself from cs_list_invoices, leaving some ambiguity about whether it returns aggregates or invoice records.

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

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

It implies usage for a monthly pending-invoice view via 'pendientes' and the tipo/month parameters, but never states when to choose it over cs_list_invoices or cs_list_periods. No exclusions or alternatives are provided.

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?

Annotations already declare readOnlyHint=true, and the description adds nothing beyond confirming it is a lookup. It does not disclose match behavior (exact vs partial), result limits, pagination, or what an empty result means — all relevant for a search tool with no output schema.

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

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

A single front-loaded sentence with zero redundant wording. It is efficient, though the brevity contributes to the missing behavioral detail rather than being purely a strength.

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 search tool with no output schema, the definition omits what is returned (entity list and fields), whether results are paginated or capped, and how partial matching works. The annotation covers only safety, leaving the functional contract thin.

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?

With only 33% schema coverage, the description compensates somewhat: 'proveedores o clientes' implicitly maps to the required 'tipo' enum, 'nombre' to 'texto', and 'NIF' to 'nif'. It still gives no syntax for NIF or clarifies matching rules, so it is adequate but not complete.

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?

States a specific verb ('Busca') and resource ('proveedores o clientes') plus the two lookup keys (nombre, NIF). It is clearly distinguishable from the sibling invoice tools, though it never explicitly contrasts itself with them.

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?

There is no guidance on when to use this versus alternatives, whether one of texto/nif takes precedence, or what happens when both are supplied. Usage is only inferable from the name and the word 'Busca'.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful scope information (searches across all periods, exact-match only), but says nothing about whether a no-match returns an empty list or an error, or whether multiple periods can yield multiple results.

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 the core behavior first and the use-case hint in parentheses; no wasted wording. It is perhaps too terse for what it leaves unsaid, but nothing present is superfluous.

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 one-parameter read tool with readOnlyHint and no output schema, the definition covers purpose and scope adequately. The main gap is return semantics: the plural 'facturas' and 'todos los periodos' suggest multiple possible matches, but the description never says whether it returns a list, a single invoice, or nothing.

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?

There is one parameter with 0% schema description coverage, so the description must compensate. It does partially, clarifying that matching is on the exact number rather than a substring or partial search, but it adds no format or example detail for the 'numero' 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 states a specific verb and resource ('Busca facturas') plus a precise matching rule ('por número exacto') and scope ('en todos los periodos'). This implicitly distinguishes it from cs_get_invoice and cs_list_invoices, though no sibling is named explicitly.

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 parenthetical 'útil para no duplicar' gives one concrete use case (checking for an existing invoice before creating one), which is genuine when-to-use guidance. However, it never names alternatives such as cs_get_invoice or cs_list_invoices, nor states when not to use it.

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

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

Annotations already declare readOnlyHint=true, so the description's added value is the disclosure that this call reports account-level permission state ('si la escritura está permitida') and the active identity context — useful information an agent cannot get from the annotation. It says nothing about latency, failure modes, or what an error response means, keeping it short of a 5.

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?

One compact sentence, front-loaded with the action and followed immediately by the returned payload. Every clause earns its place; it could only be improved by adding a short when-to-use lead-in.

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?

With no parameters, no output schema, and a read-only annotation, the description carries the right amount of detail by enumerating the three things returned (user, company, write permission). It is nearly complete; a brief note on what a failure indicates would close the remaining gap.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly does not waste space on inputs and instead frames what the caller receives.

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?

States a specific verb ('Comprueba la conexión') and spells out exactly what it returns: the active user, the active company, and whether writing is permitted. This distinguishes it from every sibling, which are all invoice/payment/entity operations, so no explicit sibling routing is needed.

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?

Usage is only implied: an agent can infer it is a pre-flight/identity check to run before other operations, but the description never says when to call it, whether it should be called first, or that no authentication state is mutated. No explicit alternatives or exclusions are given.

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