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

With no annotations, the description carries the full behavioral burden and usefully discloses two key traits: no network request is sent, and the verification code is masked with ***. It does not cover permissions, error behavior, or rate limits, but the core safety behavior is clear.

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?

It is a single, front-loaded sentence that states purpose, key behavior, and use case with no wasted words. Every clause 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?

An output schema exists, so return values need not be described. However, with 7 input parameters, 0% schema description coverage, and no annotations, the description does not provide enough parameter or invocation detail for an agent to use the tool correctly without inspecting the raw 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% across 7 parameters, and the description mentions only the general idea of checking condition syntax. It does not explain what conditions, qty, kind, skip, output, status, or databases mean or how they should be supplied.

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: it builds a GPSS API URL without sending it, explicitly distinguishing this from sibling tools like gpss_search and gpss_get that would send requests. It also names the intended check use case.

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 clearly says the tool is for checking condition syntax and that it does not send the request, which gives strong context. It does not explicitly name an alternative sibling to use when actually sending a request, so it falls short of full when-to-use routing.

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 which three code families are returned, which is real behavioral content, but says nothing about read-only nature, whether the codes are exhaustive/cached, or any access constraints. For a zero-parameter listing tool this is acceptable but 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 front-loaded sentence naming the verb and all returned categories with zero filler. Nothing redundant or padded.

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, the return shape need not be explained, and the description already summarizes the three code categories returned. For a trivial zero-param listing tool this is nearly complete; only the reason to call it (feeding codes into other gpss_* tools) is 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?

The tool takes zero parameters, so the baseline of 4 applies. The description's enumeration of the three code categories aligns with the output rather than inputs, adding no parametric complexity.

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 (列出/list) and three concrete resources: GPSS 資料庫代碼, 檢索欄位代碼, 輸出欄位代碼. An agent can tell this is a reference/lookup tool rather than a search or retrieval tool like gpss_search or gpss_get, 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?

Usage is only implied: an agent can infer it should call this to obtain valid code values before using gpss_search or gpss_build_url, but the description never states that relationship or any precondition. No when-not-to-use guidance is 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?

With no annotations, the description carries the full behavioral burden. It discloses that the result contains an abstract and claims and that it is a single-record retrieval, but does not state that it is read-only, what happens on a miss, or any auth/rate considerations.

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-loads the core action, identifier types, and return contents, followed by a useful concrete example. Nothing is padded, though the example could be tied more tightly to the 'by' parameter.

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 output schema covers return values and the description still summarizes them, but gaps remain for a 3-parameter tool: the 'databases' parameter is undisclosed and the PN-vs-AN selection mechanism is only implied. Adequate but with clear omissions.

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 compensate. It clarifies that 'number' accepts either a publication number or an application number (implying the selector role of 'by'), but the third parameter 'databases' is never mentioned and there is no enum/default guidance.

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 and resource ('取單筆 GPSS 資料') and states the identifier types accepted (PN or AN) plus the returned content (摘要與請求項). The '單筆' scoping implicitly distinguishes it from gpss_search, but 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 single-record nature and a concrete example imply when to use it over gpss_search, but there is no explicit when-to-use statement, no when-not condition, and no named alternative such as gpss_build_url or gpss_search.

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 and does so well: it discloses the '+'/'-' operator semantics, that an empty databases list means all 23 databases, the values of status and kind, and the default output field set. It omits auth/permission needs and result-size behavior, but the query-construction contract is thoroughly disclosed.

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 dense but nearly every clause carries information; the tool's purpose is front-loaded and examples are packed inline. It reads as one long run-on rather than cleanly separated sentences, but there is little true waste.

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 return values need not be explained, and the description covers the complex nested conditions object and enum-like status/kind values. The main gap is pagination (qty/skip) and the field-code vocabulary, which appears delegated to the sibling gpss_codes.

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% (params have only titles like 'Qty' and 'Skip'), so the description must compensate, and it does for conditions, databases, status, kind, and output. However qty (default 20) and skip (default 0) are never mentioned, leaving pagination semantics undocumented.

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: GPSS 檢索 (searching the TIPO GPSS patent database), which clearly differs from siblings like gpss_get (retrieval by ID) and gpss_build_url (URL construction). It does not explicitly name those siblings, but the search semantics are 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?

The description explains how to use the tool (query syntax, field codes, database selection) rather than when to use it versus gpss_get or ops_search. No exclusions or routing conditions are stated, so usage is 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?

With no annotations, the description carries the full behavioral burden, and it only discloses one trait: the number is auto-normalized to docdb format. It says nothing about OPS authentication requirements, rate limits, behavior on invalid/unknown numbers, or field coverage variance across offices.

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?

Front-loads the resource and its payload contents, then immediately follows with the practical input rule and examples. Dense but every clause is doing work; 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?

An output schema exists so return values need no explanation, and the numbering guidance is genuinely valuable. However, for a tool in a crowded ops_* family with zero annotation coverage, the absence of any authentication, error-mode, or sibling-routing information leaves real 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 0%, so the description must compensate. It does an excellent job on `number` with five format examples across EP/TW/US, but `fmt` (default 'auto') is left completely unexplained, so half the parameters remain semantically opaque.

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 resource and enumerates exactly what the bibliographic payload contains (IPC/CPC, applicants, citations, family id), which distinguishes it from ops_fulltext, ops_legal_status, and ops_family by content rather than by name alone. It never explicitly names a sibling, so an agent must still infer which of the many ops_* tools to pick.

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 concrete input guidance (write the number as published) but never states when to choose this tool over ops_fulltext, ops_register, or ops_family, nor any prerequisite or exclusion. Usage is implied through the example numbers only.

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 and does well: it discloses the quota cost model (one call per page, 4GB/week), the file side effect (saved to TW_PATENT_MCP_DOWNLOAD_DIR, default path), and that multi-page results are auto-merged. It omits auth requirements, which is the main remaining 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?

Dense and front-loaded: the core action, link source, range syntax, quota cost, and output location all appear in a tight paragraph with no filler. Slightly packed but every clause 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?

Covers the workflow, quota constraint, storage side effect, and merging behavior; an output schema exists so return values need not be explained. Missing only auth/permission context and the merge=false semantics.

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 compensate, and it largely does: `link` gets a concrete format example, `pages` gets syntax ('1-5' or 'all') plus its dependency on max_pages, and max_pages is mentioned. Only `merge` is left ambiguous (what merge=false produces is never stated).

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 ('download EPO OPS image PDF') and immediately ties it to its sibling by specifying that `link` comes from ops_images. An agent can distinguish this tool from ops_images, ops_fulltext, etc. without opening a schema.

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 a clear workflow: use ops_images first to check the page count, then choose the range, and warns that each page counts toward the weekly 4GB quota. No explicit when-not scenario is stated, but the sequencing guidance is concrete 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 carries the full behavioral burden. It does disclose one genuinely useful trait — a rate limit of 1 request per second — which the agent could not otherwise know. However, it says nothing about authentication requirements, what constitutes a family lookup, or failure behavior for invalid numbers.

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 terse clauses, front-loaded with the resource identity and followed by the rate constraint. Nothing is padded. It is efficient to the point of being cryptic, but structurally sound and free of waste.

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 return values need not be described. But for a tool with three parameters, zero schema coverage, and no annotations, the description is too sparse: it never states what operation is performed on 'number' nor what a patent family result contains, leaving real 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 description coverage is 0%, so the description must compensate, and it does so only for one of three parameters: it states that constituent accepts 'biblio' or 'legal', which the schema does not convey. The required 'number' parameter and 'fmt' are left entirely unexplained in both schema and description.

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 names a specific resource (EPO OPS INPADOC patent family), which is more than a tautology, but it omits the verb entirely — an agent must infer that this retrieves family data. It does not distinguish itself from siblings such as ops_biblio or ops_legal_status, which operate on the same EPO OPS corpus.

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/when-not guidance and no alternative tool is named. The mention that constituent can be biblio or legal reads as parameter information, not usage direction. An agent gets no help deciding between ops_family, ops_biblio, and ops_legal_status.

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, and it does disclose one real constraint: full text is only available for EP, WO and some European countries. However it says nothing about authentication, rate limits, or whether partial results are returned for unsupported jurisdictions.

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 front-loaded sentences with no filler; the resource and its main constraint come first. Slightly telegraphic, but 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?

An output schema exists so return values need no explanation, and the part values plus coverage note cover the essentials. Still missing the format/meaning of the required 'number' parameter and any auth or pagination context for a 3-param 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 the description must compensate. It does define the 'part' parameter's enum-like values, which is genuinely useful, but leaves 'number' (the required param) and the 'fmt' parameter completely undefined.

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?

Identifies the resource (EPO OPS fulltext) and names the three valid 'part' values (claims/description/abstract), which is enough to distinguish it from ops_biblio and ops_images. It never states the verb explicitly (retrieve/fetch), but the resource 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?

There is a coverage constraint ('only EP, WO and some European countries') but no statement of when to choose this over ops_biblio/ops_images, no prerequisites, and no guidance on the required 'number' argument. Usage must be inferred entirely.

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 usefully discloses that output is a document inventory with page counts rather than the PDFs themselves, and flags coverage limitations, but says nothing about read-only nature, auth, rate limits, or pagination 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 dense sentences with the resource and returned fields front-loaded, and no wasted filler; the availability sentence is short and adds relevant scope.

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 return values need not be described, and the tool is simple (two parameters). However, with no annotations and zero parameter documentation, the description leaves the caller without the meaning of either argument, which is a real gap for correct 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% for both parameters. The description implies a case identifier (某件) but never explains the format of 'number' nor the purpose of 'fmt' or its 'auto' default, so it fails to compensate for the schema 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?

The description names a specific resource – the EPO OPS image/document list for a patent case – and enumerates the document kinds it reports (FullDocument, Drawing, FirstPageClipping) plus page counts. It is concrete enough that an agent knows it returns document metadata rather than file content, though it never names a sibling such as ops_download_pdf to sharpen the boundary.

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 or when-not-to-use statement; an agent is left to infer that this precedes a download by reading ops_download_pdf. The availability note (TW/US/EP gazettes mostly obtainable) hints at coverage but offers no routing rule or prerequisite.

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 behavioral burden. It does not mention authentication requirements, rate limits, or that this queries a live EPO OPS endpoint, and it gives no sense of what the legal-status payload contains.

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 compact sentence that front-loads the data source and resource, with the event examples adding useful scope. Nothing is padded, though the terseness leaves obvious gaps unaddressed.

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 return values need not be explained, but for a 2-parameter tool with 0% schema coverage and no annotations, the description should at least identify the number format and usage context. It omits both.

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% for two parameters, and the description mentions neither of them. It never clarifies what 'number' should be (EPO publication, application, or priority number) or what 'fmt' values are accepted, leaving the agent to guess input format.

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 names a specific resource and data domain: EPO OPS INPADOC legal status, with concrete event examples (valid, withdrawn, expired, annual fees). This is distinguishable from siblings like ops_biblio or ops_family, though it never states an explicit verb such as 'retrieve'.

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 indication of when to call this tool versus ops_biblio, ops_register, or ops_family, nor any prerequisite (e.g., a prior ops_search to obtain the number). The agent must infer usage entirely.

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, yet it says nothing about authentication, rate limits, read-only nature, or response behavior. It only implies a read-style lookup of register data, leaving most behavioral traits to inference.

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 compact sentence that front-loads the resource identity before the parameter hint, with no filler. It is appropriately sized, though the terseness is partly a symptom of under-specification rather than disciplined editing.

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 return values need not be explained, but with 0% parameter coverage and no annotations the description leaves the number format, the fmt semantics, and the tool's relationship to similar siblings unaddressed. For a 3-parameter EP-register tool this is 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?

Schema description coverage is 0%, so the description must compensate. It usefully enumerates the valid constituent values (biblio, events, procedural-steps), which the schema does not declare as an enum, but it says nothing about the required 'number' parameter's expected format or what 'fmt'/'auto' controls.

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 as the European Patent Register for EP cases and lists the constituent data types, which is more specific than a bare name. However, it never states the verb/action (retrieve/query) and gives no clue how it differs from the overlapping sibling ops_biblio, whose name suggests it may return the same 'biblio' constituent.

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 statement of when to use this tool versus alternatives such as ops_biblio, ops_legal_status, ops_family, or ops_fulltext, all of which appear in the sibling list. The only conditional hint is the constituent enumeration, which is parameter content rather than usage 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the 100-record cap and that constituent can be biblio or abstract, but says nothing about authentication/registration requirements, rate limits, or what the start/end paging does at the boundaries.

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?

Compact and front-loaded: the operation and scope come first, followed by example queries and then the constituent/limit constraints. Every sentence carries information, though the examples could be trimmed without loss.

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 return values need not be described. The essential CQL semantics, constituent options, and the 100-record limit are covered, but pagination parameters and the relationship to sibling search tools remain gaps for a 4-parameter search endpoint.

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 explains 'cql' richly via examples and clarifies 'constituent' (biblio vs abstract), but the 'start' and 'end' parameters are completely undocumented in both the schema and the description.

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 names a specific operation (EPO OPS CQL search) and its scope (global bibliographic data), and the concrete CQL examples make the resource unambiguous. It does not, however, differentiate itself from near-neighbours such as gpss_search or ops_biblio, leaving the agent to infer the boundary.

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 through the CQL syntax examples ('ti=battery and pa=tsmc', 'ipc=H01M10 and pd within ...'), which show the intended query style but never state when this tool should be chosen over siblings. There are no prerequisites, exclusions, or alternative-tool routing.

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