get_asn1

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.