tc39-mcp

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

No annotations provided, so the description carries full burden. It discloses key behaviors: fetching as JSON, default editions, and the constraint on 'at'. It implies read-only nature but does not explicitly state it or mention error handling.

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, front-loaded with the core purpose, and contains no unnecessary words. Every sentence adds value.

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 absence of an output schema, the description adequately explains the input parameters and behavior. It lacks details on error handling or the exact structure of the returned JSON, but it is sufficient for a simple get 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 only 25% with only 'at' having a description. The description adds meaning by explaining default values for spec and edition, and the condition for using 'at'. This compensates for the low schema 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 the tool fetches a parsed TC39 clause as structured JSON, specifying the verb 'Fetch' and resource 'TC39 clause'. It distinguishes from siblings like 'clause.list' and 'clause.outline' which have different operations.

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 when to use the 'at' parameter (only for edition='main') and the default values for spec and edition. However, it does not explicitly compare with sibling tools or state when not to use this 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?

No annotations exist, so the description must disclose behavioral traits. It mentions 'list' which is read-only, but fails to confirm safety, side effects, pagination, or rate limits. The description adds minimal behavioral context beyond the name.

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, front-loaded with purpose and essential filter 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 7 optional parameters and no output schema, the description lacks return value structure, pagination behavior, or ordering. Important details like limit and edition are missing, making it incomplete for effective use.

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

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

With 0% schema description coverage, the description explains key parameters: kind, section, has_algorithm, spec, and at. However, it omits limit and edition, leaving some gaps. Overall, it adds significant value for most parameters.

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 lists parsed spec clauses with optional filters, listing specific filters (kind, section prefix, has_algorithm) and explaining spec and at parameters. It distinguishes itself from sibling tools like clause.get (single clause) and spec.search.

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 implies usage for listing/filtering but does not explicitly state when to use it versus alternatives (e.g., clause.get for a specific clause). No when-not or exclusion criteria are provided.

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

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

No annotations are provided, so the description must cover behavioral details. It explains the parameters controlling depth and scope, but does not mention whether the operation is read-only, any side effects, or the structure of the output.

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 states the main purpose, and the second explains the key parameters. It is ideally concise and front-loaded.

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

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

Given the lack of output schema and annotations, the description provides adequate but incomplete context. It explains how to limit the output but not what the output contains (e.g., tree structure details). The optional nature of all parameters is implied but not stated.

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 schema has 0% description coverage, so the description must compensate. It explains 'depth' and 'under' but does not explain 'spec' (enum values 262/402) or 'edition'. Thus, half the parameters are clarified, meeting a baseline but not fully.

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 that the tool returns a section tree (table of contents) for a parsed spec and edition. The verb 'Return' and resource 'section tree' are specific, and the distinction from sibling tools like clause.get or clause.list is implicit.

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 does not provide explicit guidance on when to use this tool versus alternatives (e.g., clause.get, clause.list). The context of siblings is present, but no when-to-use or when-not-to-use 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 must disclose behavior. It implies a read-only fetch but does not mention error handling, return format, or any side effects. Adequate but minimal.

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?

Single sentence that is front-loaded with the key action and resource, no wasted words. Every part contributes to understanding.

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 tool is simple (one required param) but the description omits return value details since there is no output schema. It's complete for a basic fetch but leaves users wondering about the response structure.

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 adds value by explaining that the 'name' parameter accepts either a slug (exact match) or a name (case-insensitive). However, it does not define what a slug is or provide examples.

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 'Fetch', the resource 'one TC39 proposal', and the two lookup methods (slug exact, name case-insensitive), distinguishing it from sibling tools like proposal.list.

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 explicit guidance on when to use this tool vs alternatives like proposal.list or clause.get. The description implies usage for fetching a single proposal but doesn't clarify when to use slug vs name or handle failures.

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 provided, so description carries full burden. It mentions 'static index' hinting at read-only, but does not explicitly state non-destructive behavior, any side effects, permissions, rate limits, or data freshness. This lack of behavioral context is a significant gap 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?

Single sentence front-loading the main action and immediately listing filters. Every clause adds value; no wasted words or repetition.

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 5 parameters, zero annotations, no output schema, and many sibling tools, the description covers all parameters but lacks explicit details on pagination (limit), default behavior, and return format. Missing output schema means the agent doesn't know what fields are returned. Adequate for a simple listing tool but not 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 0% (no descriptions), so description must compensate. It explains all but one parameter (limit) in terms of filtering logic and possible values (spec enums, stage options, champion and contains as substring). Though limit's purpose is vaguely implied, the description adds significant meaning beyond the schema's type/enum definitions.

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 verb 'list', the resource 'TC39 proposals', and the source 'static index (tc39/proposals)'. Immediately distinguishes from siblings like proposal.get (single proposal) and spec.* tools by focusing on listing and filtering.

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?

Lists available filter parameters (spec, stage, champion, contains) with example values, guiding when to use each. Doesn't explicitly state when not to use or name alternatives, but the variety of filters implies querying scenarios. Sibling tool proposal.get is implied for single-item retrieval.

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 provided, so description carries the burden. Describes in detail the content returned (package info, per-snapshot metadata, headers). Does not mention side effects, but as a read-only retrieval, behavior is clear and transparent.

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?

Single sentence containing rich information without fluff. Every piece of information earns its place, listing all key return elements compactly.

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 no parameters, the description covers the return content adequately. Could mention that this tool helps discover available specs, but is already fairly 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?

Tool has 0 parameters; input schema provides no additional meaning. Description adds no parameter info, but baseline 4 is appropriate since there are no parameters to describe.

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?

Description clearly states tool provides a self-description of the MCP server, listing package name, version, and per-snapshot pin metadata for each supported spec edition, plus test262 and proposals index headers. Distinct from siblings which focus on specific sub-resources like clauses or proposals.

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 explicit when-to-use or alternatives mentioned, but the tool's role as a self-description with no parameters implies it is for overall server info. Usage can be inferred, but lacks explicit guidance compared to 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?

No annotations provided, so description carries full burden. It discloses behavioral traits such as returning references, mentioning the reverse index is AOID-densified, and parameter effects. No contradictions. However, it could mention that it is a read-only operation.

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

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

Two sentences with no waste. First sentence states purpose, second sentence provides key details. Front-loaded and efficient.

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 and no output schema, the description covers purpose and two parameters but leaves spec, limit, and edition unexplained. The return format is not described. Incomplete for a relatively complex 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 description must explain parameters. It explains direction and include_cross_spec but not spec, limit, or edition. While id is implied, other parameters lack explanation. Partially compensates for low schema 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?

Description clearly states the tool returns outgoing and/or incoming cross-references for a given clause id. This is distinct from sibling tools like clause.get, clause.list, etc., which provide clause content or lists but not specifically cross-references.

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?

Description implies usage when cross-references are needed, but does not explicitly state when to use or not use alternatives. It provides clear context for the direction and include_cross_spec parameters, but lacks explicit exclusions.

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 discloses the tool's behavior: it reports specific change types and field-level details. No contradictions or missing behavioral traits for a read-only diff 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?

Two sentences with no wasted words. The first sentence states the core function, the second adds details and defaults. Information is front-loaded.

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

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

Given 4 parameters (1 required), no output schema, the description sufficiently explains inputs and output content. Missing output structure details are not critical for understanding.

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 schema has 0% parameter descriptions, but the description adds meaning: 'id' is the clause, 'from'/'to' are editions with defaults, and 'spec' specifies the standard (enum). This compensates well for the lack of schema documentation.

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 performs a clause-level diff across two editions, specifying the types of changes reported (identical, modified, added, removed) and a field-level breakdown. This distinguishes it from siblings like clause.get which retrieves a single clause.

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 defaults for 'from' and 'to' (latest stable release and main), which helps usage. However, it does not explicitly compare to other tools or state when not to use.

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 key behavior: combining two specs, interleaving by score, and tagging. It also mentions the search_steps parameter's effect. However, without annotations, it lacks details on case sensitivity, regex support, ordering guarantees, and whether it is read-only. Some behavioral traits are missing.

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: two clear sentences about the main function and one about a parameter specialization. No redundant words, and key information is front-loaded.

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

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

The description gives a good overview for a search tool, but lacks details on default limits, pagination, or response format (no output schema). It is adequate but not exhaustive given the tool's complexity (two specs, merging logic).

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 parameters. The description adds meaning for search_steps ('also matches algorithm step text') but does not explain limit or query beyond their obvious semantics. Given the lack of schema descriptions, the description should provide more guidance for all parameters.

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 it searches both ECMA-262 and ECMA-402 simultaneously, interleaves hits by score, and tags each hit with its spec. This distinguishes it from similar tools like spec.search (which searches a single spec) and test262.search.

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 says 'Use it when you don't know which spec defines a symbol,' providing clear guidance. However, it does not explicitly mention when not to use it or list alternatives, though the context of sibling tools implies 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 carries full burden. It discloses the default off state of `include_sdo` and the behavior when no parameters are given (lists all non-terminals with counts). It does not mention side effects or permissions, but the tool appears read-only and the description is transparent about core 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?

The description is three sentences, front-loaded with the main purpose. Each sentence adds distinct value, and there is no redundant or extraneous information. It is a model of conciseness.

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 6 parameters and no output schema or annotations, the description covers the essential behavior and the most important parameters. However, it lacks details on the return format and leaves three parameters (`spec`, `limit`, `edition`) partially or fully unexplained, limiting completeness for new users.

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 description must compensate. It explains `nonterminal`, `contains`, and `include_sdo` well, but omits meanings for `spec`, `limit`, and `edition`. `spec` is an enum but its purpose is implied only; `limit` and `edition` are not described at all.

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 that the tool queries grammar productions from spec `<emu-grammar>` blocks and explains the behavior for different parameter combinations (nonterminal exact match, contains substring, no filter lists all). It differentiates itself from sibling tools by being the only grammar-specific tool, though it does not explicitly name siblings.

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 `nonterminal`, `contains`, or neither, and mentions `include_sdo` behavior. It does not explicitly state when not to use the tool or recommend alternatives, but the context is sufficient for most use cases.

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 grouping behavior via 'by' and filtering via 'filter' with case-insensitive substring matching. However, it does not disclose other behavioral aspects like pagination (limit parameter), default values, or read-only nature. Without annotations, more behavioral context would be beneficial.

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 with two sentences. The first sentence states the purpose, and the second explains key parameters. No extraneous information.

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

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

With five parameters and no output schema, the description does not cover important details such as return format, behavior of 'spec' and 'edition', default values, or error conditions. It is insufficient for a complex 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?

Only two of five parameters ('by' and 'filter') are explained in the description. Parameters 'spec', 'limit', and 'edition' have no explanation despite schema description coverage being 0%. The description partially compensates but leaves major gaps.

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 indexes Syntax-Directed Operations by grammar production, with specific grouping modes. It identifies the verb 'Index' and resource 'SDOs', but does not explicitly differentiate from sibling tools like spec.search or spec.grammar.

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 guidance is provided on when to use this tool versus alternatives. It does not mention context, prerequisites, or when not to use it.

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

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

With no annotations, the description discloses key behaviors: aoid-exact results rank first, and the `at` parameter searches historical snapshots. No contradictory information is present, and it adds value beyond the schema.

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

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

The description is two concise sentences, front-loaded with the primary purpose, and no extraneous information. Every phrase adds value.

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 (6 parameters, no output schema), the description is minimal. It covers the core functionality but omits details on return format, all parameter options, and usage context. It meets minimum viability but has 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. It explains the `query` parameter implicitly and mentions `at` and `search_steps`, but fails to describe `spec`, `limit`, and `edition`. This leaves significant gaps for a 6-parameter tool.

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

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

The description clearly states the tool searches the parsed spec by clause id, aoid, or title, with an option to search step text. It distinguishes itself by mentioning aoid-exact ranking and historical snapshot searching, differentiating it from siblings like spec.global_search.

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 implies usage by listing search capabilities but does not explicitly state when to use this tool over alternatives (e.g., spec.global_search, test262.search). No direct comparison or exclusion criteria are provided.

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

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

No annotations are provided, so the description carries the full burden. It notes that the tool lists 'live' snapshots from R2, which is a read operation. It does not mention pagination or limits, but for a listing tool, the behavior is sufficiently transparent.

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 concise sentences. The first states the purpose and output, the second gives filtering options and exclusions. No unnecessary words; every sentence 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?

Given only two optional parameters and no output schema, the description fully explains what the tool returns, how to filter, and what it does not cover, making it complete for a listing 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 description coverage is 0%, but the description adds meaning by explaining that 'spec' filters by enum values and 'edition' by string examples. It could be more explicit about optionality, but it compensates well.

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 action ('List') and the specific resource ('live snapshots from R2'), including the output fields. It also distinguishes from siblings by noting that historical copies are accessible via other 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 explicitly explains how to filter using 'spec' or 'edition' with examples, and contrasts with alternatives (clause.get / spec.search) for historical snapshots, providing clear when-to-use 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 provided, the description explains that it returns clauses mentioning or defining the notation, ranked by occurrence with a bump for definition sections. This adds behavioral context but lacks details on auth needs, side effects, or performance 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?

The description is a single sentence that is front-loaded with examples. It is concise but dense, earning its place. Slightly more structure could improve clarity.

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 4 parameters and no output schema, the description only addresses 'notation'. It omits explanation for 'spec', 'limit', and 'edition', which are crucial for correct invocation. The tool is one of many siblings, but the description does not provide enough context for an agent to select and call it properly.

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%. The description only explains the 'notation' parameter with examples, but fails to describe 'spec', 'limit', and 'edition' parameters. An AI agent lacks understanding of these required fields, making parameter semantics severely incomplete.

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

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

The description clearly states it resolves spec notation like [[Prototype]], %Object.prototype%, ~number~, and returns ranked clauses. It specifies the verb (resolve) and resource (spec notation), distinguishing it from sibling tools like spec.well_known_intrinsics and spec.global_search.

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 implies usage for resolving specific notations but does not explicitly state when to use this tool versus alternatives (e.g., spec.search, spec.well_known_intrinsics). No exclusions or when-not-to-use guidance is provided.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals basic operation but omits important traits such as what happens with invalid ids, pagination behavior, rate limits, or the structure of the returned data. The presence of a 'limit' parameter is not explained.

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, front-loaded with the main action, and efficiently covers the key usage distinction. No wasted words 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?

For a tool with 5 parameters and no output schema, the description is incomplete. It does not specify what a 'table summary' contains, how results are paginated or limited, or the effect of the 'edition' parameter. The agent lacks sufficient context to use the tool effectively without additional inference.

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

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

The input schema has 5 parameters with 0% description coverage. The description clarifies 'id' and 'filter' but does not explain 'spec', 'limit', or 'edition'. Given the low coverage, the description should compensate but fails to fully address parameter meaning.

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 it lists or fetches parsed `<emu-table>` content, with a specific distinction between using an id for exact fetch versus listing summaries. This uniquely identifies the tool's function among siblings, which focus on clauses, proposals, and other spec aspects.

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 some guidance on when to use id (exact fetch) versus no id (list summaries) and mentions optional filter by substring. However, it does not discuss when not to use the tool or suggest alternatives from the sibling tools, leaving the agent to infer appropriate contexts.

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 the source derivation method and filter behavior, but lacks information on output format, potential limitations, or side effects. The explanation is useful but incomplete.

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 (two sentences) and front-loaded with the core purpose. It could be improved by including brief mention of other parameters, but it remains efficient and clear.

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 4 parameters and no output schema, the description covers the main purpose and filter, but omits details on 'limit' and 'edition', and does not describe the return structure. This leaves some uncertainty for the agent.

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

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

With 0% schema description coverage, the description must compensate. It adds meaning for the 'spec' parameter by explaining the spec-specific behavior, and for 'filter' as a substring narrowing. However, 'limit' and 'edition' are not explained, leaving gaps.

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 enumerates well-known intrinsics with their probable defining clauses, and distinguishes it from sibling tools by specifying the source (canonical table or prose scan). It is a specific verb-resource pair with no ambiguity.

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 when to use it for different specs (262 vs 402) and mentions the filter parameter for narrowing. However, it does not explicitly state when not to use it or provide alternatives among sibling tools, though the context is clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses the search algorithm (AND-matching, case-insensitive, prefix for esid) and the return format (path, URL, esid, etc.), which is transparent. It could mention read-only nature but is sufficient.

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 that efficiently convey purpose, behavior, parameters, and return format. No unnecessary words, every sentence adds value.

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

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

For a search tool with 3 parameters and no output schema, the description covers input constraints, match behavior, and output fields. No gaps remain for an agent to understand usage and expectations.

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?

Despite 0% schema description coverage, the description thoroughly explains all three parameters: 'query' AND-matches tokens, 'esid' prefix-matches, and 'limit' defaults to 20. This fully compensates for the lack of schema descriptions.

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 it searches the tc39/test262 conformance suite, differentiating it from sibling tools like spec.search. It specifies the verb 'search', the resource 'test262 conformance suite', and details match behavior.

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 that at least one of 'query' or 'esid' must be supplied, providing clear context for usage. However, it does not explicitly compare to sibling tools or state when not to use this tool.

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