Independent MCP server for the TC39 specs (ECMA-262 + ECMA-402): clauses, search, diffs, history.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.8/5 across 17 of 17 tools scored. Lowest: 3.1/5.
Each tool targets a distinct function: clause operations vs. proposal queries vs. spec utilities vs. test262 search. Even the two search tools have clear differences (single vs. cross-spec).
All tools follow a consistent `domain.action` pattern using lowercase and snake_case for the action (e.g., `clause.get`, `spec.global_search`, `test262.search`). No mixing of conventions.
17 tools is appropriate for a comprehensive TC39 spec browser. Each tool serves a specific need without redundancy, covering clauses, proposals, grammar, symbols, tables, and test262.
The toolset covers the full lifecycle of exploring TC39 specifications: retrieving clauses, searching, cross-referencing, diffing editions, inspecting grammar and symbols, and querying proposals and test262.
clause.getAInspectFetch a parsed TC39 clause as structured JSON. spec selects '262' (default) or '402'. edition defaults to 'latest'. at: '<sha>' pins to a historical main snapshot (only valid for edition='main'); omit to query the live snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | Optional historical SHA pin (hex, 4-40 chars). Only valid when edition='main'; released editions have no per-SHA history to address. | |
| id | Yes | ||
| spec | No | ||
| edition | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description conveys the core read-only behavior ('fetch') and clarifies parameter constraints (e.g., at only valid for edition='main'). But without annotations, it omits details like error handling for invalid IDs or invalid SHA pins, and does not explicitly state that the operation is non-destructive.
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, consisting of four short sentences. It front-loads the primary purpose and then efficiently explains the key parameters without unnecessary elaboration.
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 4 parameters, no output schema, and no annotations, the description covers parameter behavior reasonably but fails to explain the 'id' parameter and does not describe the return value beyond 'structured JSON'. This leaves the tool somewhat incomplete for an agent to use correctly without prior knowledge.
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 description adds meaning for spec (default 262 or 402), edition (default 'latest'), and at (pins to historical snapshot), which the schema only partially describes. However, the required 'id' parameter is left unexplained—the tool does not specify how to identify a clause, leaving a significant gap in usability.
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, providing a specific verb and resource. This distinguishes it from siblings like clause.list (which likely lists multiple clauses) and clause.outline (which probably returns an outline structure).
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 parameter options for spec, edition, and at, giving some contextual guidance. However, it does not explicitly state when to use this tool over alternatives (e.g., clause.list for multiple clauses or proposal.get for proposals), nor does it mention prerequisites or common failure scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clause.listAInspectList parsed spec clauses with optional filters (kind, section prefix, has_algorithm). spec selects '262' or '402'. at: '<sha>' queries a historical main snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | ||
| kind | No | ||
| spec | No | ||
| limit | No | ||
| edition | No | ||
| section | No | ||
| has_algorithm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly describes listing behavior, filters, and historical querying. No mention of destructive actions or permissions, which is acceptable for a read-only listing.
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 concise sentences with no waste. All information is front-loaded and directly relevant.
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 7 parameters and no output schema, the description covers core functionality and key filters. Lacks detail on limit and edition, but overall sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates by explaining spec, at, and filter parameters (kind, section, has_algorithm). 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?
Clearly states it lists parsed spec clauses with optional filters (kind, section, has_algorithm). Differentiates from siblings by specifying the listing nature and historical snapshot querying capability.
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 context for filters and spec selection but lacks explicit when-to-use or alternatives guidance. Implies usage through examples but does not exclude cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clause.outlineBInspectReturn the section tree (table of contents) for a parsed (spec, edition). depth caps how deep the tree descends (1 = top-level only); under limits the tree to descendants of one clause id.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | ||
| depth | No | ||
| under | No | ||
| edition | No |
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 only states the basic behavior (return tree) and the effect of two parameters. It does not disclose whether the operation is read-only, any required permissions, error handling, or rate limits, which is insufficient 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?
The description is two concise sentences with no filler. It front-loads the primary purpose and then explains the parameters. Every sentence adds value, achieving high efficiency.
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 4 parameters, no output schema, no annotations, and no required fields, the description is incomplete. It omits details on the 'edition' parameter, return format, error conditions, and default behavior of parameters. A more comprehensive description is needed for this level of complexity.
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 description adds meaning to 'depth' and 'under' beyond the schema, but it does not explain 'edition' or the enum values of 'spec' (e.g., what 262 and 402 refer to). With 0% schema description coverage, the description provides some but not enough context 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 the action 'Return the section tree' and the resource 'for a parsed (spec, edition)', which distinguishes it from sibling tools like clause.get or clause.list. The optional parameters 'depth' and 'under' are explained, making the purpose 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 implies usage for obtaining a table of contents, but it does not explicitly state when to use this tool over alternatives or provide examples. No guidance on prerequisites or when not to use is given, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proposal.getAInspectFetch one TC39 proposal by slug (exact) or name (case-insensitive).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It explains the parameter modes (slug exact, name case-insensitive) but fails to disclose error handling, return format, or side effects for a read-like 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?
The description is a single 14-word sentence that front-loads the verb and resource, containing no extraneous information. Every word 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 the tool's simplicity (one param, no output schema), the description provides the essential retrieval semantics but omits what the tool returns or error conditions. It is adequate but leaves key behavioral aspects undocumented.
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 for the 'name' parameter. The description adds crucial meaning by clarifying that the parameter accepts either a slug (exact match) or a name (case-insensitive match), significantly aiding correct input.
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 specifies two query modes: by slug (exact) or name (case-insensitive). This distinguishes it from sibling tools like proposal.list, which likely returns multiple 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?
The description implies use for fetching a single proposal by identifier, contrasting with proposal.list for listing, but it does not explicitly state when to use this tool over siblings or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proposal.listAInspectList TC39 proposals from the static index (tc39/proposals). Filter by spec ('262'|'402'), stage ('0'|'1'|'2'|'2.7'|'3'|'finished'|'inactive'|'active'), champion (substring), or contains (name/slug substring).
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | ||
| limit | No | ||
| stage | No | ||
| champion | No | ||
| contains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior thoroughly. It only mentions a 'static index', hinting at read-only behavior, but does not explicitly state non-destructiveness, auth requirements, or rate limits. The absence of annotation_contradiction means no contradiction, but transparency is insufficient.
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-loads the core action, and includes all essential information without redundancy. Every word serves a 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?
The description is adequate for a simple listing tool but lacks details on return format, pagination, or ordering. The limit parameter is not explained, which is a gap given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains four of five parameters (spec, stage, champion, contains) with example values, but misses the limit parameter entirely. This adds meaning beyond the schema's raw property 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?
The description clearly states it lists TC39 proposals from a specific static index (tc39/proposals), which distinguishes it from sibling tools like proposal.get (single proposal) and clause.list (clauses). The verb 'List' and resource specification are precise.
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 the filtering options but does not explicitly state when to use this tool versus alternatives. It implies a browsing use case but lacks guidance on when not to use it, such as when a specific proposal is needed (use proposal.get).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spec.aboutAInspectSelf-description of this MCP server: package name + version, per-snapshot pin metadata (sha, fetched_at, biblio_commit, clause_count) for every supported (spec, edition), plus test262 + proposals index headers when present.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states what information is returned, implying a read-only operation. However, it does not explicitly state idempotency or lack of side effects, which would be 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?
Single sentence is compact but somewhat dense, listing multiple items. Could be split into bullet points for readability, but still effective.
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 simple tool, description covers all necessary information: what is returned (package name+version, pin metadata, headers). Missing format details but acceptable for an about 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?
No parameters exist, and schema coverage is 100% (empty schema). Description adds no parameter info because none is needed. It focuses on output, which is appropriate for a parameterless 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?
Description uses specific verb 'self-description' and clearly defines the resource: package info, pin metadata for each spec/edition, and index headers. It distinguishes from sibling tools like clause.get or proposal.list by focusing on server metadata.
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 use for introspection, but lacks explicit context on when to use this vs alternatives. Sibling tool names like spec.snapshots suggest more detailed snapshot info, so 'about' is clearly the overview. A note like 'Use this to discover available specs and editions' would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spec.crossrefsBInspectFor a clause id, return its outgoing references (clauses it cites) and/or incoming references (clauses that cite it — the back-reference index the parse alone doesn't expose). The reverse index is AOID-densified from step text. direction: 'in' | 'out' | 'both' (default). Outgoing also carries an external category: the clause's citations to external specs (Unicode, IETF, WHATWG) as resolvable URLs. Set include_cross_spec: true to also resolve outgoing references from ECMA-262 → ECMA-402 (or vice versa).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| spec | No | ||
| limit | No | ||
| edition | No | ||
| direction | No | ||
| include_cross_spec | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions that the reverse index is AOID-densified from step text and that outgoing includes an external category. However, it does not discuss error behavior, pagination, or performance implications, leaving gaps in transparency.
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 focused paragraph that front-loads the main purpose. It is detailed but not overly verbose, though it could be structured with bullet points for clarity. Overall 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?
No output schema exists, so description should explain return format. It mentions references are clause IDs and external URLs but does not describe the response structure, pagination, or behavior for missing parameters. Incomplete given complexity.
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 should compensate. It explains `direction` and `include_cross_spec` well, but fails to describe `spec`, `limit`, and `edition` parameters, covering only 3 of 6 parameters. The description adds meaning for some but leaves others undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns outgoing and incoming references for a clause ID, distinguishing it from siblings like clause.get or spec.search. It explicitly defines outgoing (cites) and incoming (cited by) and mentions external specs, giving a specific verb and resource.
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 cross-referencing but does not explicitly state when to use this tool vs alternatives like spec.search or clause.list. It mentions the direction parameter but lacks explicit guidance on when not 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.
spec.diffAInspectClause-level diff of one clause across two editions of a spec. Reports identical / modified / added / removed plus a field-level breakdown (title, signature, step count, reworded step indices, notes, crossrefs). from defaults to the latest stable release, to to main.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| to | No | ||
| from | No | ||
| spec | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the output (identical/modified/added/removed plus field breakdown) and parameter defaults, but does not disclose mutation status (likely read-only) or any limitations. Adequate 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?
Two sentences, front-loaded with the core purpose, no wasted words. Efficiently communicates the tool's function and key defaults.
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, no output schema, and multiple sibling tools, the description provides the gist but omits details on output structure and how to specify the clause (id). The spec enum and its implications are missing. Adequate for simple cases 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 description coverage is 0%, so the description must add meaning. It explains defaults for 'from' and 'to', but leaves 'id' (clause identifier) and 'spec' (spec version) unexplained. The enum for 'spec' is not described, and 'id' as required param lacks context.
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 performs a clause-level diff across two editions of a spec, listing the types of changes reported and the field-level breakdown. This distinguishes it from siblings like clause.get (which retrieves a single clause) and spec.about (which gives spec metadata).
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: diffing a clause across editions, with defaults for from and to. However, it does not explicitly state when not to use this tool or compare it to alternatives, though the purpose is distinct from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spec.global_searchAInspectRun spec.search across both ECMA-262 and ECMA-402 in one call and interleave hits by score. Each hit is tagged with the spec it came from. Use it when you don't know which spec defines a symbol. search_steps also matches algorithm step text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| search_steps | No |
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 dual-spec search and tagging, but omits details on pagination, result format, or any side effects. The behavior is typical for a search 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 concise sentences with no superfluous content. The key action and use case are 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?
No output schema is provided, and the description does not specify the result structure beyond 'each hit tagged'. Missing details on limit behavior, error cases, or how results are ordered beyond 'by score'. For a tool that aggregates across specs, more completeness is needed.
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%. The description only explains search_steps behavior; query and limit are left without any additional meaning beyond their names. For a required param like query, more context would be valuable.
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 runs spec.search across two specs and interleaves results, tagging each hit. It distinguishes from sibling spec.search by specifying the dual-spec scope.
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?
Explicitly advises use when the defining spec is unknown. Mentions search_steps for algorithm step matching, but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spec.grammarAInspectQuery grammar productions captured from the spec's <emu-grammar> blocks. { nonterminal } returns every production for that non-terminal (exact match); { contains } filters by RHS / name substring; neither lists all non-terminals + their production counts. include_sdo folds in SDO-attached productions (off by default).
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | ||
| limit | No | ||
| edition | No | ||
| contains | No | ||
| include_sdo | No | ||
| nonterminal | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the behavior for different parameter combinations and mentions the include_sdo parameter's effect. No destructive behavior is implied. Could add details about pagination or result size limits, but overall transparency is good for a query 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?
Description is a single paragraph of three sentences, front-loaded with the core action and then detailing parameter behaviors. No unnecessary words or repetition. Extremely concise while covering all key aspects of usage.
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, no required ones, and no output schema, the description is sufficient for basic usage but lacks details on output format and the remaining parameters (spec, edition, limit). It does not describe what the returned data looks like (e.g., list of strings, objects). Adequate but could be more 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?
Description explains nonterminal, contains, and include_sdo, which are the core filtering parameters. However, spec (enum: 262,402), edition, and limit are not explained. With 0% schema description coverage, the description partially compensates but leaves ambiguity for some parameters. Limit and edition are likely intuitive but not explicitly clarified.
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 verb 'Query' and resource 'grammar productions from spec's <emu-grammar> blocks.' It explains three behaviors: exact match via nonterminal, substring filter via contains, and listing all non-terminals with counts when neither is provided. This distinguishes it from sibling tools like spec.search or spec.tables.
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?
Explicitly describes when to use nonterminal vs contains, and what happens when neither is specified (lists all non-terminals with counts). Provides clear context for filtering. However, it does not mention when not to use this tool or suggest alternatives for full-text search, which would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spec.sdo_indexBInspectIndex Syntax-Directed Operations by the grammar production they're defined on. by: 'production' (default) groups SDOs under each production; by: 'sdo' groups productions under each SDO title. filter narrows to keys containing a substring (case-insensitive).
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | ||
| spec | No | ||
| limit | No | ||
| filter | No | ||
| edition | No |
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 grouping behaviors but does not mention safety (e.g., read-only/read-write), rate limits, or side effects. The tool appears to be a read operation, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundant information. Main purpose is front-loaded, and technical details follow efficiently.
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 and no output schema, the description does not explain the 'spec' (choosing ES version), 'edition', or 'limit' parameters. An agent may not know how to properly use these fields, reducing completeness.
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 meaning for 'by' and 'filter' parameters (explaining their values and effects). However, 'spec', 'limit', and 'edition' are not described, leaving gaps for those 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 indexes Syntax-Directed Operations by grammar production, using specific verbs and resource. It distinguishes from siblings like spec.grammar and spec.search by focusing on SDO indexing with grouping options.
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 the two grouping modes (by: 'production' vs 'sdo') and the filter parameter, which guides usage. However, it does not specify when to use this tool over alternatives or provide exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spec.searchAInspectSearch the parsed spec by clause id / aoid / title (+ step text with search_steps). Aoid-exact ranks first. at: '<sha>' searches a historical main snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | ||
| spec | No | ||
| limit | No | ||
| query | Yes | ||
| edition | No | ||
| search_steps | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses ranking behavior (aoid-exact first) and the `at` parameter for historical search. However, it does not explicitly state that the tool is read-only or describe response format, pagination, or error handling, leaving some behavioral aspects unclear.
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, using three short sentences to convey search modes, ranking, and historical search. No unnecessary information is included, and all sentences add 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 params, no output schema, many siblings), the description covers core functionality and key behavioral details but omits parameter details and output format. It is adequate for a search tool but leaves gaps that could affect proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explains `search_steps` and `at` partially, but fails to explain `spec`, `limit`, `edition`, and how multiple search criteria interact. The `query` parameter is implied but not formally described, leaving ambiguity for agent use.
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 specifies the tool's purpose: searching the parsed spec by clause ID, aoid, or title, with step text search via `search_steps`. It distinguishes itself from sibling tools like clause.get (retrieval) and spec.global_search (broader search) by detailing specific search modes and ranking 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 provides context on when to use the tool (for searching by various identifiers and historical snapshots) but does not explicitly state when to avoid it or offer comparisons to siblings. The `search_steps` parameter hints at a use case, but no alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spec.snapshotsAInspectList the live (spec, edition, sha, fetched_at) snapshots the hosted Worker is serving from R2. Filter by spec ('262'|'402') or edition (e.g. 'main', 'es2026'). Historical SHA-pinned copies are reachable via at: on clause.get / spec.search but aren't enumerated here.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | ||
| edition | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description bears full responsibility for disclosing behavior. It reveals that the tool serves live snapshots from R2, supports filtering by spec or edition, and that it does not return historical copies. Although it doesn't mention side effects (likely none, as it's a read operation) or performance characteristics, the provided context is sufficient for safe usage.
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 remarkably concise, consisting of two sentences that provide all necessary information without redundancy. It is front-loaded with the main purpose and then adds filtering details and differentiation from siblings.
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 that there is no output schema, the description adequately explains the return values (spec, edition, sha, fetched_at). It covers the purpose, filtering capabilities, and limitations (no historical copies). However, it omits potential details like pagination, rate limits, or default behavior when no filters are applied, but these are minor gaps 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?
With 0% schema description coverage, the description adds crucial meaning: spec is an enum ('262' or '402') and edition is a string (with examples like 'main', 'es2026'). This goes beyond the schema which only lists enum names without context, and for edition merely specifies type 'string'.
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 the specific verb 'List' and clearly specifies the resource: live snapshots (spec, edition, sha, fetched_at) from R2. It distinguishes itself from sibling tools like clause.get and spec.search by noting that historical SHA-pinned copies are not enumerated here.
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 (to list live snapshots) and when not to (for historical copies), providing alternatives: 'Historical SHA-pinned copies are reachable via at: on clause.get / spec.search but aren't enumerated here.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spec.symbol_resolveAInspectResolve spec notation like [[Prototype]] (internal slot), %Object.prototype% (well-known intrinsic), or ~number~ (sigil enum): return clauses that mention or define it, ranked by occurrence with a bump for definition-y sections.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | ||
| limit | No | ||
| edition | No | ||
| notation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the ranking algorithm (occurrence with bump for definition sections) and provides examples of inputs and outputs. This gives the agent a clear understanding of what to expect beyond a simple resolution.
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, well-structured sentence that front-loads examples and clearly explains the purpose and behavior. Every part adds value without 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?
The description covers the core functionality and return behavior but lacks documentation for three of four parameters. No output schema is provided, so details on the return format would be helpful, but the description adequately covers the main use case.
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 only adds meaning for the 'notation' parameter through examples, leaving 'spec', 'limit', and 'edition' undocumented. This is insufficient for a tool with 4 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 resolves specific spec notations (internal slots, well-known intrinsics, sigil enums) and describes the output behavior (return clauses ranked by occurrence with bump for definition sections). It effectively distinguishes from sibling tools like spec.search and spec.well_known_intrinsics.
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 use when resolving spec notations but does not explicitly state when to use this tool versus alternatives such as spec.search or spec.well_known_intrinsics. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spec.tablesBInspectList or fetch parsed <emu-table> content. { id } returns exactly that table (full columns + rows); otherwise list table summaries, optionally narrowed by a filter substring over the caption or id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| spec | No | ||
| limit | No | ||
| filter | No | ||
| edition | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description covers basic behavior (returns full rows with id, lists summaries otherwise, narrowable by filter) but lacks details on side effects, idempotency, permissions, or pagination. No annotations are provided to supplement.
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 at two sentences, front-loading the primary action. It is efficient but could benefit from slightly more structure to separate modes clearly.
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 5 parameters, no output schema, and no annotations, the description is insufficient. It omits parameter details for spec, limit, edition and does not describe return format, making it incomplete for effective tool 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?
Only two parameters (id and filter) are explained in the description; spec, limit, and edition are not mentioned despite 0% schema coverage. The description fails to clarify the role of these 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 lists or fetches parsed <emu-table> content, distinguishing between two modes (by ID and listing). It specifies the resource and differentiates from sibling tools that deal with clauses, proposals, etc.
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 when to use each mode (use id for specific table, otherwise list summaries) but does not explicitly provide guidance on when to use this tool versus other spec tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
spec.well_known_intrinsicsBInspectEnumerate the well-known intrinsics in a spec with their probable defining clauses. Driven from the canonical §6.1.7.4 WKI table when present (ECMA-262), else a %X% prose scan (e.g. ECMA-402). filter narrows by bare-name substring.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | ||
| limit | No | ||
| filter | No | ||
| edition | No |
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 enumeration behavior and the probabilistic nature for ECMA-402, but does not mention read-only safety, error conditions, rate limits, or authentication requirements.
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 that efficiently convey purpose and mechanism. No redundant information is present, though the parameter mention for filter could be integrated more smoothly.
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 does not specify the return format or structure, nor does it provide expected behavior for the 'limit' and 'edition' parameters. Given the absence of an output schema, the agent lacks sufficient context to fully understand what the tool returns.
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%, yet only the 'filter' parameter is explained in the description. The 'spec', 'limit', and 'edition' parameters receive no explanation, leaving the agent to guess their meaning. The description fails to compensate for the missing 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 the tool enumerates well-known intrinsics with probable defining clauses, using specific methods. However, it does not explicitly differentiate from siblings like spec.about or spec.search, which have different purposes.
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 mentions the underlying mechanism (canonical table vs. prose scan) for different specs, implying when each applies, but lacks explicit guidance on when to use this tool versus alternatives 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.
test262.searchAInspectSearch the tc39/test262 conformance suite from its indexed front-matter. query AND-matches whitespace tokens (case-insensitive) across each test's description + path; esid prefix-matches the front-matter esid. Returns ranked hits (path, GitHub url at the indexed SHA, esid, description, features, flags), capped at limit (default 20). Supply at least one of query / esid.
| Name | Required | Description | Default |
|---|---|---|---|
| esid | No | ||
| limit | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses return fields (path, GitHub URL, esid, description, features, flags), result capping, and matching semantics. It does not mention any side effects, which is acceptable for a read 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 two sentences long, front-loading the core purpose, then efficiently packing parameter behavior and return details. No wasted words.
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 provides enough context for an AI to correctly select and invoke the tool, covering input requirements, matching logic, and output structure, especially given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing the meaning of query (AND-match whitespace tokens case-insensitively), esid (prefix-match), and limit (default 20). All three parameters are well explained.
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 specifies 'Search the tc39/test262 conformance suite from its indexed front-matter,' distinguishing it from sibling tools like spec.search which search the ECMAScript specification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states that at least one of query/esid must be supplied, and explains the matching behavior for each parameter. However, it does not explicitly exclude alternative tools, though the context implies test262-specific usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.