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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the payload includes parameter requirements and a body schema, but says nothing about behavior on an unknown operation_id (error vs. empty) or the response shape beyond the field list.

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 that enumerates the three things returned, with no filler. It is efficient but arguably under-specified rather than concise, since nothing else anchors the unusual meta-tool 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?

An output schema exists, so the returned fields need not be described again, and the schema is trivial (one required string). What is missing is the link from holded_search_operations to operation_id, which is the only real risk an agent faces when calling this 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% for the single parameter, so the schema gives no meaning to operation_id. The description treats it only as 'an operation's' and never says whether the id is an API endpoint identifier, a Holded document id, or the value returned by holded_search_operations.

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?

Specific verb ('Inspect') plus resource ('an operation') and an enumeration of what is exposed: description, required path/query parameters, and body schema. It maps naturally onto the sibling holded_search_operations (find) vs this tool (inspect detail), though the ambiguous word 'operation' (API endpoint vs. business operation) is never disambiguated.

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 statement of when to use this rather than holded_search_operations or the generic holded_read/holded_write, and no prerequisites such as where an operation_id comes from. The lookup-then-inspect workflow is only inferable from the sibling names.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety and idempotency need no restating. The description adds one genuinely useful fact beyond that – the response envelope {status, data} – but omits behavior an open-world executor needs: what happens with an unknown or stale operation_id, and whether there is rate limiting or side-effect risk from open-world access.

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, but the terseness is under-specification rather than economy – the same word count could have carried a real routing rule or a parameter hint.

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?

An output schema exists, so the return values needn't be explained, and the annotations cover the safety profile. What is missing is essential to a generic open-world dispatcher: which operations are available, how to discover or look up an operation_id, and how this differs from holded_get_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 description coverage is 0% across three parameters, so the description carries the full burden and adds nothing: it never explains that operation_id is a catalog key, nor what query and path_params do (presumably a querystring map and a path placeholder map). An agent must guess both the shape and the source of every argument.

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?

"Execute a catalog GET operation" states a verb and a read-only class of operation, but "catalog" is undefined and the tool never says what domain (Holded documents, contacts, invoices, etc.) or which resources it reaches. An agent cannot distinguish this from holded_get_operation without opening the schema, so the purpose is close to a restatement of the name "read".

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 only guidance is "Inspect its schema first," which is a procedural caution rather than a when-to-use rule. Nothing tells the agent when to pick this generic executor over holded_get_operation or holded_search_operations, or how to obtain a valid operation_id in the first place.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description only adds that results are "paginated summaries" — useful but thin given an output schema already exists to describe the return shape.

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

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

Two sentences, front-loaded with the action and resource, no filler. Minor deduction for a stray line break splitting "paginated summaries" and for packing the filter enumeration into the same sentence as the core 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?

With an output schema present and annotations covering safety, the description needn't explain return values. However, for a five-parameter discovery tool it leaves filter-combination semantics and any notion of what an "operation" record represents unstated.

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 carries the burden. It maps meaning onto three of five parameters (search, api, tag) but is silent on limit/offset beyond the word "paginated", and never says whether api/tag combine as AND filters with the free-text search.

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?

Specific verb plus resource: "Search the offline API catalog" with the searchable dimensions named (words, Holded api, tag). The word "offline" implicitly separates this discovery tool from the execution siblings holded_read/holded_write, though the siblings are never 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?

There is no explicit "use this when" statement and no alternatives are named, so the agent must infer that this is the discovery step before calling holded_get_operation or holded_read. The phrase "offline API catalog" hints at the pattern but does not state 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 destructive=true, idempotent=false and openWorld=true; the description adds context they don't carry — that user authorization is required, that writes must not be retried automatically, and that uploads are capped at 10 MiB decoded. The response shape is also sketched. It doesn't say what an error or partial failure looks like, which matters for a destructive non-idempotent 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 with no padding; the operation type and the schema-inspection instruction are front-loaded. The oddly indented multi-line formatting in the middle costs a little readability but no content is wasted.

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

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

Output schema exists, so skipping return-value detail is fine. For a destructive, non-idempotent, open-world generic write dispatcher, however, the description never explains how to obtain a valid operation_id, what happens when a write fails midway, or what "user authorization" concretely requires — the biggest gaps for this complexity level.

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 carries the full burden and it only discharges part of it: the files array is spelled out field-by-field with the size cap, which is genuinely valuable. The four other parameters (operation_id, body, query, path_params) get nothing beyond their names, and operation_id is the required one.

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 class (POST/PUT/PATCH/DELETE) and resource (a catalog operation identified by operation_id), and the read/write split against holded_read is implicit in the name plus the HTTP verb list. It never names a sibling tool or describes which Holded domain the operation targets, so the agent knows the shape of the action but not the surface area.

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?

"Inspect the schema first" and "never automatically retry failed writes" give real operational guidance about how to invoke it, and one exclusion is stated. But there is no guidance on where operation_id comes from (holded_search_operations / holded_get_operation) and no routing advice to the read counterpart, leaving the discovery workflow to inference.

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