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

No annotations are provided, so the description must carry the full burden. It transparently discloses that uncached versions trigger a download that may require a second call. It also explains the two output modes. While it doesn't cover all potential edge cases (e.g., error handling), the key behavioral trait is well documented.

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

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

The description is concise: four sentences covering two distinct modes, prerequisites, and first-use behavior. No redundant words. Information is front-loaded with 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?

Given 9 parameters and no output schema, the description is remarkably complete. It explains the two output modes, how to pick versions, and the caching behavior. The only minor gap is that it doesn't describe the format of the structural summary, but that's a niche detail. Overall, it provides sufficient context for correct tool 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 100%, so the baseline is 3. However, the description adds significant context beyond the schema: it explains how 'section_number' changes the output type (summary vs. diff), and gives concrete examples like '5.15.2'. The 'old_version' description also clarifies it accepts archive tokens and release selectors, which is not in the schema. This adds substantial semantic value.

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

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

The description starts with 'Compare two versions of a 3GPP specification', clearly defining the verb and resource. It then distinguishes two modes: without section_number (structural summary) and with section_number (line-level diff). This differentiates it from sibling tools like 'get_section' or 'list_versions'.

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 explicitly tells when to use each mode and directs to use 'list_versions first to see which versions exist'. It also explains behavior on first use (download/conversion) and instructs to retry if a download is in progress. This is clear guidance on usage vs. alternatives.

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

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

The description explains the scope of extraction (only top-level assignments from blocks between ASN1START/ASN1STOP markers), behavior with and without the name parameter, case-insensitive and separator-ignoring matching, and handling of past versions (downloaded and converted on first use). Since no annotations are provided, the description carries full burden, which it largely fulfills, though it could be more explicit about potential limitations (e.g., if the tool is destructive or read-only).

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 moderately concise for the amount of information conveyed, but it is somewhat lengthy (multiple sentences). It is front-loaded with the core purpose, then progressively adds details on usage modes, matching behavior, and version handling. Every sentence adds value, but some redundancy could be trimmed (e.g., explaining matching behavior both in the main description and in the parameter description).

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

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

Given the tool's complexity (6 parameters, multiple usage modes, no output schema), the description provides comprehensive guidance on how the tool behaves in different scenarios (with/without name, with/without spec_id, with version). It also addresses how to cite results and how to discover versions. The only gap is the lack of information about the return format or output structure, but since there is no output schema, the description could be more explicit about what the tool returns (e.g., structured text, markdown, etc.).

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 100%, so each parameter is already documented in the schema. The description adds extra context beyond the schema, such as the effect of omitting spec_id to search across all specs, the matching behavior (case-insensitive, separator-ignoring), and the fact that name is required when spec_id is omitted. It also explains the version parameter behavior and recommends list_versions. However, since schema coverage is complete, the description exceeds the baseline of 3 but does not substantially add new meaning for every parameter.

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

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

The description clearly states the tool extracts ASN.1 definitions from 3GPP specifications, specifying verb ('Get', 'extracts') and resource ('ASN.1 definitions from the 3GPP specifications'). It distinguishes it from siblings like get_section by explaining that the defining clause can be hundreds of kilobytes, which get_section can only page through.

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 explicitly states when to use this tool (e.g., 'Use it when you know a type, IE or constant name and need its definition or constraints') and when to use alternatives (e.g., 'the defining clause can be hundreds of kilobytes, which get_section can only page through'). It also provides guidance on omitting spec_id when the specification is unknown, and directs users to call list_versions first to see available versions.

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 provided, the description carries full burden and excels: it states the output is base64-encoded, mentions a latency caveat for archived versions ('up to a few minutes'), and explains the default version behavior. This fully discloses behavioral traits.

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 three sentences, front-loaded with the main action and output, and each sentence adds unique value. Could be slightly more concise by combining the first two sentences, but no superfluous content.

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

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

Given no output schema and 3 parameters, the description covers tool purpose, input semantics, latency behavior, and next steps via sibling links. It does not mention what happens if parameters are invalid or if an image doesn't exist, but the overall completeness is high for the context.

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

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

Schema coverage is 100% and already explains each parameter well. The description adds value by clarifying `version` accepts both version strings and archive tokens, and defaults to the database version, which goes beyond the schema 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 uses specific verbs ('Get an embedded image') and resource ('3GPP specification'), and clearly distinguishes this tool from siblings like `list_images` by stating its function and output format.

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 explicitly points to `list_images` for discovering available images and `list_versions` for version discovery, providing clear guidance on when to use alternative tools. However, it does not mention when not to use this tool (e.g., for non-image content).

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

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

No annotations are provided, so the description carries full burden. It describes the tool as a 'get' and 'look up' operation, implying it is read-only and non-destructive. However, it does not explicitly state that it is safe, nor does it mention pagination behavior (offset, max_lines) or what happens in edge cases like no results. The description is adequate but lacks explicit behavioral details beyond the verb choice.

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 three sentences long, front-loading the purpose in the first sentence and then elaborating on capabilities and usage. Every sentence contributes meaningful information without redundancy or fluff. It is compact and immediately informative.

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 6 parameters, no output schema, and no annotations, the description should provide a thorough understanding of the tool. It covers the main purpose, prerequisite workflow, and parameter usage, but it does not describe the output format (e.g., JSON/YAML), the meaning of offset and max_lines for pagination, or error handling. This leaves gaps in what a user can expect from the tool's response.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds value by providing concrete examples for the path parameter ('/nf-instances') and schema parameter ('NFProfile'), and by explaining the intended workflow for spec_id and api_name (use list_openapi to discover). This goes beyond the schema's structural descriptions, though it does not cover offset or max_lines.

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

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

The description clearly states the tool's purpose: 'Get OpenAPI definition content for 5G service-based interface APIs (TS 29.xxx series).' It distinguishes from siblings like list_openapi by specifying that it retrieves actual definition content, not just listing available APIs. The mention of looking up HTTP request/response details, paths, and schemas further clarifies the specific resource and action.

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

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

The description explicitly advises to 'Use list_openapi first to discover available API names,' providing a clear prerequisite and directing to an alternative tool. It also gives specific usage guidance for parameters: 'Use the path parameter to filter by API endpoint (e.g. /nf-instances) or the schema parameter to filter by data type (e.g. NFProfile).' This tells the user exactly when and how to use the tool.

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 fully handles behavioral disclosure. It reveals the 500-reference cap, pagination via offset, and that responses include structured data plus a total-count notice. It does not mention rate limits or authorization, but those are not critical for a read-only lookup 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?

The description is well-structured with clear sections for each direction, uses bullet-style formatting for readability, and every sentence adds essential guidance. No fluff or redundancy.

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

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

Given the tool's moderate complexity (5 parameters, two modes), the description covers all necessary details: parameter requirements per mode, default behaviors, response structure, pagination limit, and output format. Without an output schema, it still describes the return data adequately.

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%, so the baseline is 3. However, the description adds semantic value beyond the schema by explaining parameter roles in context (e.g., section_number is required for outgoing, optional for incoming) and linking params to use cases (include_subsections only relevant for outgoing).

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

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

The description clearly states the tool's purpose: finding cross-references between 3GPP specs and RFCs. It distinguishes two modes (outgoing and incoming) with specific resource targets (specs, RFCs, sections), and the sibling context shows no other tool overlaps with this function.

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 explicitly explains when to use outgoing vs incoming direction, lists required vs optional parameters for each, and notes a default behavior ('outgoing (default)'). It also mentions a cap of 500 references with pagination, guiding the agent on handling large result sets.

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 provided, the description carries full responsibility. It transparently explains how figures appear as `` links and how to fetch them with `get_image`, details LaTeX formula formatting (standalone vs. inline), describes version handling (first-use download/conversion), and reveals pagination behavior (default 200 lines). It does not cover error cases or what happens for invalid sections, but the behavioral disclosure is rich and helpful.

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

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

The description is a single paragraph of ~150 words, dense but well-organized. It front-loads the core purpose and sibling distinction, then covers output format, version handling, and pagination. While it could benefit from bullet points or more whitespace for scanning, every sentence adds value and there is no repetition. It is concise for the amount of information conveyed.

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 7 parameters, 2 required, no output schema, and no annotations, the description covers purpose, usage alternatives, output format (figures, formulas), version behavior, and pagination. It does not describe error handling (e.g., invalid section/spec) or the exact structure of the return value, but it provides enough context for an agent to use the tool effectively in most scenarios.

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% (all 7 parameters have descriptions), so baseline is 3. The description adds extra meaning beyond the schema: e.g., for `section_number` it gives an example ('5.1.2'), for `version` it explains the first-use download behavior, and for `offset`/`max_lines` it contextualizes pagination. This additional context improves parameter understanding.

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

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

The description clearly states the tool's purpose: 'Get the markdown content of a specific section in a 3GPP specification.' It also specifies the type of content (architecture, procedures, requirements) and explicitly distinguishes from the sibling tool `get_openapi` for API details. The verb 'get' and resource 'section' are specific and unambiguous.

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

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

The description provides direct guidance on when to use this tool vs. `get_openapi` for API details. It advises to call `list_versions` first to check available versions and explains pagination with offset and max_lines. This explicit context helps the agent choose the correct tool and navigate parameters effectively.

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 provided, the description carries full responsibility for behavioral disclosure. It reveals that passing a 'version' triggers a download and conversion on first use, and notes that section numbers often change between releases. These are important behavioral traits. However, it does not state whether the operation is read-only or whether it has any side effects beyond the initial conversion (e.g., caching behavior). The transparency is good but not exhaustive.

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

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

The description is two sentences long, with no wasted words. The first sentence defines the core purpose, and the second sentence adds targeted usage guidance and a behavioral note. Every sentence serves a clear function, and the structure is front-loaded with the most important information.

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

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

Given the tool's simplicity (2 parameters, no output schema), the description is nearly complete. It explains what the tool does, the version behavior, and a typical use case. It could be improved by briefly describing the return format (e.g., list of section numbers and titles), but the phrase 'section structure' provides enough context for an agent to infer the output. The absence of an output schema increases the value of a description, and this one is sufficient but not exhaustive.

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 100%, so the baseline is 3. The tool description adds minimal parameter-specific meaning beyond what the schema already provides. It mentions the 'version' parameter's purpose ('see the structure of a past version') and the conversion note, but the schema already describes the parameter's accepted formats and defaults. The description does not enrich the semantics of 'spec_id' beyond what is obvious.

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

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

The description clearly states the verb ('Get') and resource ('table of contents (section structure) of a 3GPP specification'). It distinguishes the purpose from siblings like 'get_section' (which reads a specific section) and 'list_versions' (which lists versions). The phrase 'check the table of contents before reading a section' further clarifies its role relative to sibling tools.

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

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

The description provides clear usage context: use this tool to inspect the section structure, especially before reading an older version. It warns that section numbers move between releases, implying when to use this tool over others. While it does not explicitly name alternative tools (e.g., 'get_section'), the guidance is direct and actionable. The version parameter description (in schema) adds additional hints like using 'list_versions', which compensates slightly.

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

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

The description discloses important behavioral traits such as the latency for archived versions ('takes up to a few minutes') and the defaulting behavior of the version parameter. No annotations are provided, so the description carries the full burden and does so effectively, though it could mention if the list is paginated or has size limits.

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

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

The description is concise (three sentences) and well-structured, with the main action upfront, followed by sibling tool reference, and version handling details. Every sentence adds value with no redundancy.

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

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

Given the tool has only 2 parameters with full schema descriptions and no output schema, the description covers usage context well. It explains the version parameter's behavior and an edge case (archived version latency). A minor gap is not stating whether the returned list is complete or paginated, but overall it is sufficient for an agent to use the tool correctly.

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

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

The input schema provides 100% coverage with descriptions for both parameters, so the baseline is 3. The description adds useful context for the 'version' parameter (e.g., about archive tokens and release selectors) beyond the schema's brief note, but does not add new info for 'spec_id'.

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

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

The description clearly states the tool's action ('List embedded images in a 3GPP specification') and specifies what it returns ('image names, MIME types, and whether they are viewable by LLMs'). It distinguishes itself from sibling tools like 'get_image' by noting that 'list_images' lists images while 'get_image' retrieves a specific one.

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

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

The description provides clear guidance on when to use this tool vs alternatives: 'Use get_image to retrieve a specific image.' It also explains how to handle versions, including past archived versions that may have a delay. However, it does not explicitly mention when not to use it or other exclusions beyond the sibling differentiation.

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 must carry the full burden. It describes the basic action (listing definitions) and optional filtering, but does not disclose any behavioral traits such as return format, pagination, authentication requirements, or performance implications. For a simple read-only list tool, this is minimally adequate but lacks depth.

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 consists of two concise sentences. The first sentence defines the action and resource; the second provides usage context and an optional filter. Every phrase earns its place, with no redundancy or unnecessary detail.

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

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

Given the low complexity (one optional parameter, no output schema), the description is mostly complete. It links usage to get_openapi and mentions filtering. However, it does not explain the return data shape (e.g., list of API names) or differentiate from other sibling tools like list_specs or search_openapi. Slight room for improvement.

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% (the single parameter spec_id has a schema description). The description adds 'Optionally filter by spec ID,' which mirrors the schema. Since the schema already documents the parameter fully, the description adds minimal extra meaning, meeting the baseline for high coverage.

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

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

The description clearly states 'List available OpenAPI definitions from 3GPP specifications (TS 29.xxx series).' It uses a specific verb ('list') and resource ('OpenAPI definitions'), and distinguishes from siblings like get_openapi (which gets a specific definition) and list_specs (which lists specs). The context 'discover API names before calling get_openapi' further clarifies its role.

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 explicitly tells when to use the tool: 'Use this to discover API names before calling get_openapi.' It also mentions optional filtering by spec ID. While it does not explicitly state when not to use it or list alternatives (e.g., list_specs), the guidance is clear and contextually useful for an AI agent.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It adds pagination defaults and filter semantics beyond the schema, but does not mention authentication needs, output format, error behavior, or rate limits—leaving significant gaps for a tool with no 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 efficient sentences: first states purpose, second covers filtering and pagination. No wordiness, front-loaded key information.

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

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

For a listing tool with 4 optional parameters and no output schema, the description explains filters and pagination adequately but omits what the response looks like (e.g., fields returned, ordering). Without output schema, the description should hint at the return structure to be fully complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context that filters can be combined and how pagination works (limit/offset navigation), but most parameter meaning is already clear from schema descriptions. The added value is modest.

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

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

The description clearly states the verb "List" and the resource "available 3GPP specifications." It mentions optional filtering by series and ID prefix, plus pagination—fully distinguishing this from sibling tools that list images, OpenAPI specs, or versions.

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 optional filtering and pagination, so the agent knows how to use it. However, it does not provide any guidance on when NOT to use this tool vs. alternatives (e.g., search, get_section), missing the opportunity to prevent misuse.

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 provided, the description effectively discloses behavioral traits: newest-first order, the meaning of three statuses (database, cached, archive), and time cost for archive versions. No contradictions exist.

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

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

The description is well-structured with a clear purpose sentence, bulleted details, and a usage recommendation. It is concise with no redundant information, though slightly more compacting is possible.

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?

Despite having no output schema, the description fully explains the output (list of versions with status meanings) and connects to sibling tools, making the tool's usage context complete.

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

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

Schema coverage is 100% and the description adds no meaning beyond the schema's own parameter description ('Specification ID (e.g. TS 23.501)'). Baseline of 3 is appropriate.

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 explicitly states 'List the versions of a 3GPP specification, newest first' – a specific verb and resource that clearly distinguishes from sibling tools like list_specs (list specifications) and list_images (list images).

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

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

The description provides explicit context for use: 'Pass a version from this list to get_section or get_toc to read a past version.' This guides when to use the tool, but does not explicitly exclude scenarios where it should not be used.

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?

Given there are no annotations, the description carries full burden for behavioral disclosure. It explicitly states key behaviors: auto-quoting of hyphenated/dotted terms, exclusion syntax, porter stemming, pagination with total_count, and the precedence of spec_ids over spec_id. This is comprehensive beyond what the schema reveals.

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 structured with clear sections (Query syntax, Stemming, Pagination, Tips) and is well organized. It earns its length given the complexity of FTS5 syntax, but could be slightly more concise in the exclusion rules section, which repeats some details from the syntax list.

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

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

The description covers query syntax, stemming, pagination, and provides domain tips. There is no output schema, but the response structure is described inline (results, total_count, limit, offset). The description is complete for a search tool of this complexity. Minor gap: it does not explain what happens on an empty query or FTS5 syntax errors beyond auto-quoting.

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 100%, so the baseline is 3. The description does add value for some parameters (e.g., explaining spec_ids precedence over spec_id, and specifying default/max for limit), but mostly the query syntax details are an extension of the 'query' parameter's natural behavior rather than new parameter-specific semantics. The description does not add meaning significantly beyond the schema.

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

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

The description begins with a clear verb and resource: 'Full-text search across 3GPP specifications'. It specifies the technology (SQLite FTS5 syntax), and the query examples clearly differentiate it from sibling tools like search_openapi or list_specs. The purpose is specific and distinct.

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

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

The description provides extensive query syntax and tips for effective search (tips on exact terms, phrase search, column filters), but it does not explicitly state when to use this tool versus alternatives like search_openapi or get_section. There is no 'when-not-to-use' guidance. Usage is implied through examples and tips but not formally defined.

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 provided, the description carries full burden. It comprehensively discloses behavior: result granularity (one definition per hit), ranking (exact name matches first), $ref expansion depth, include_body effect, query syntax (including auto-quoting for special characters), tokenization rules (no stemming, split on hyphens/dots/underscores, no camelCase split), and pagination details. No contradictory or missing behavioral traits.

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

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

The description is well-structured with sections (Results, Query syntax, Tokenization, Pagination) and front-loaded with the main purpose. While it is long, every sentence provides necessary information given the tool's complexity. It could be slightly more concise, but it earns its length.

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

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

Given the complexity (7 parameters, no output schema, multiple sibling tools), the description is complete. It explains the result structure, how to follow up with get_openapi, the difference from search, tokenization idiosyncrasies, and pagination. It addresses all likely agent questions.

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 100%, but the description adds substantial value beyond the schema. It explains the query syntax in detail (operators, phrases, column filters, auto-quoting), the purpose and cost of include_body, how pagination uses limit/offset with total_count, and the meaning of kind (schema vs operation). The description makes the parameters much more usable.

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

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

Clearly states the tool performs full-text search on OpenAPI definitions of 5G APIs, using SQLite FTS5 syntax. It distinguishes from sibling tools by explicitly contrasting with 'search' (covers clause text, not OpenAPI) and 'get_openapi' (for when the document is already known).

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 explicit guidance: 'Use this when you need an API detail but do not know which API document holds it.' It also gives a clear alternative: 'When you already know the document, get_openapi reads it directly.' Additionally, it contrasts with the sibling 'search' tool, specifying that search covers different content.

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