w3c-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.7
Disambiguation5/5
Every tool has a clearly distinct purpose with no overlap. The tools are organized around specific resources (CSS properties, HTML elements, PWA specs, WebIDL, general specs) and actions (get vs. list vs. search), making it easy for an agent to select the right one. For example, get_css_properties retrieves property definitions, while list_css_specs enumerates available specs, avoiding confusion.
Naming Consistency5/5
The naming follows a highly consistent verb_noun pattern throughout, using snake_case uniformly. All tools start with either 'get_', 'list_', or 'search_' followed by a clear noun phrase (e.g., get_css_properties, list_w3c_specs). This predictability makes the tool set easy to navigate and understand at a glance.
Tool Count5/5
With 11 tools, the count is well-scoped for the server's purpose of accessing W3C web specifications and related data. Each tool earns its place by covering distinct aspects like CSS, HTML, PWA, WebIDL, and general spec operations, without being overly broad or sparse. This aligns with typical MCP server ranges (3-15 tools) for focused domains.
Completeness4/5
The tool surface is nearly complete for the domain of retrieving W3C specification data, covering key operations like getting details, listing, and searching across various resource types. A minor gap exists in update or modification tools, but this is reasonable as the server appears focused on read-only access to public specs, and agents can work around this limitation for typical querying tasks.
Average 3.2/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: e.g., whether it returns structured data or raw text, if there are rate limits, authentication needs, error handling, or pagination. For a tool with no annotation coverage, this leaves significant gaps in understanding operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get HTML element definitions') and adds necessary scope ('from a specific spec or all specs'). There's no wasted language, repetition, or unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 2 parameters with full schema coverage, the description is incomplete. It lacks details on return values, error conditions, behavioral constraints, and differentiation from siblings. For a tool in a context with multiple similar tools (e.g., 'list_element_specs'), more guidance is needed to ensure the agent can use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('spec' and 'element'). The description adds minimal value beyond the schema, as it only implies the optional nature of 'spec' ('If omitted, returns all elements') without detailing parameter interactions or examples. Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't enhance parameter understanding significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('HTML element definitions') with scope ('from a specific spec or all specs'). It distinguishes from siblings like 'get_css_properties' by focusing on HTML elements rather than CSS properties, but doesn't explicitly contrast with 'list_element_specs' which might overlap. The purpose is specific and understandable, though sibling differentiation could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_element_specs' or 'search_w3c_specs'. It mentions the scope ('specific spec or all specs') but doesn't explain use cases, prerequisites, or exclusions. Without such context, the agent lacks clear direction for tool selection among similar siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves specifications but does not describe any behavioral traits such as whether it's a read-only operation, potential rate limits, authentication needs, or what the return format looks like (e.g., list, object). For a tool with no annotation coverage, this is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with relevant examples. It is appropriately sized and front-loaded, with no unnecessary words. However, it could be slightly more structured by explicitly mentioning the parameter's role, but this is minor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a simple parameter, the description is incomplete. It adequately covers the purpose but lacks behavioral context (e.g., read-only nature, return format) and usage guidelines. For a tool in a server with many specification-related siblings, more completeness is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage, providing a clear definition for 'coreOnly'. The description does not add any meaning beyond the schema, as it does not mention parameters or their effects. With high schema coverage, the baseline score is 3, as the schema adequately documents the parameter without additional description input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all Progressive Web App (PWA) related specifications' with specific examples (Service Worker, Web App Manifest, etc.). It uses a specific verb ('Get') and resource ('PWA related specifications'), but does not explicitly distinguish it from sibling tools like 'get_w3c_spec' or 'list_w3c_specs', which might also retrieve specifications. This makes it clear but not fully differentiated from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, nor does it reference sibling tools like 'get_w3c_spec' or 'list_w3c_specs' that might be related. This leaves the agent without explicit usage instructions, relying solely on the tool name and description for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') but does not cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or the format of returned data. For a tool with no annotation coverage, this is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the first sentence directly stating the tool's purpose and the second providing helpful context about WebIDL. Both sentences earn their place by adding value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex data (WebIDL definitions). It does not explain the return format, potential errors, or behavioral traits, leaving gaps in understanding how to interpret results. With no structured fields to compensate, the description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'shortname' parameter clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as examples of valid shortnames or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get WebIDL interface definitions for a specification.' It specifies the verb ('Get'), resource ('WebIDL interface definitions'), and target ('specification'), with an additional clarifying sentence about WebIDL's role. However, it does not explicitly differentiate from sibling tools like 'list_webidl_specs' or 'get_w3c_spec', which might offer overlapping functionality, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings such as 'list_webidl_specs' and 'get_w3c_spec' available, it fails to specify scenarios where this tool is preferred, such as for detailed interface definitions rather than listings or general spec info. This lack of context leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists specs but doesn't cover critical aspects like whether it's read-only, pagination behavior, rate limits, authentication needs, or what the output format looks like. This leaves significant gaps for an agent to understand how to interact with it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without any unnecessary words. It is front-loaded and efficiently conveys the core purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and the description lacks behavioral details, it is incomplete for effective use. While it's a simple list operation, the absence of information on output format, potential constraints, or differentiation from siblings reduces its utility for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description doesn't add parameter details, which is acceptable in this case. Baseline is 4 for zero parameters, as the schema fully handles the lack of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('CSS specifications that have property definitions available'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_w3c_specs' or 'list_element_specs', which likely list different types of specifications, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list_w3c_specs' or 'get_css_properties'. It implies usage for retrieving CSS specs with property definitions but offers no explicit context, exclusions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List all specifications') but doesn't describe behavioral traits such as pagination, rate limits, authentication needs, or what the output looks like (e.g., format, structure). This leaves significant gaps for a tool that likely returns a list of data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core action ('List all specifications') and efficiently specifies the scope ('that have HTML element definitions available'), making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the output contains (e.g., list of spec names, URLs, metadata) or any behavioral aspects like error handling. For a tool with no structured output documentation, this leaves the agent with insufficient context to use it effectively beyond the basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, as there are none to document. A baseline of 4 is appropriate since no parameters exist, and the description doesn't introduce any confusion about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('specifications that have HTML element definitions available'), making the purpose understandable. It distinguishes from some siblings like 'get_css_properties' or 'get_w3c_spec' by focusing on HTML element definitions, but doesn't explicitly differentiate from 'get_html_elements' or 'list_w3c_specs', which might overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'get_html_elements' or 'list_w3c_specs'. The description implies a context of listing specifications with HTML element definitions, but it lacks explicit when-to-use or when-not-to-use statements, leaving the agent to infer usage from the name and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states it 'gets' information, implying a read-only operation, but doesn't disclose behavioral traits such as error handling, rate limits, authentication needs, or response format. The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and lists included information types without unnecessary words. Every part of the sentence adds value, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description is incomplete. It doesn't explain what the return values look like (e.g., structure of detailed information), error conditions, or other behavioral aspects. For a tool with zero annotation coverage, this leaves significant gaps in understanding how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'shortname' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as examples or usage notes. Baseline score of 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific web specification', specifying the types of information included (URLs, status, repository, and test info). It distinguishes from sibling tools like list_w3c_specs by focusing on a single specification rather than listing multiple, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when detailed information on a specific specification is needed, as opposed to listing or searching tools. However, it doesn't provide explicit guidance on when to use this versus alternatives like get_webidl or get_spec_dependencies, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a listing operation, implying it's likely read-only and non-destructive, but doesn't specify aspects like pagination, rate limits, authentication requirements, or what format the list returns. This leaves significant gaps for an agent to understand how to interact with it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without any unnecessary words or structural fluff. It's front-loaded and efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a basic listing operation. However, it lacks details on behavioral traits like response format or limitations, which would be helpful for an agent to use it correctly in context with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately doesn't mention any. This meets the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 resource ('specifications that have WebIDL definitions'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list_w3c_specs' or 'get_webidl', but the focus on WebIDL specifications provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_w3c_specs' or 'get_webidl', nor does it mention any prerequisites or exclusions. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states what the tool does but lacks behavioral details such as whether it returns a list or detailed objects, if there are rate limits, authentication needs, or potential side effects. For a read operation with no annotation coverage, this is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get CSS property definitions') and includes key scope information ('from a specific spec or all specs'). There is no wasted wording, and it directly communicates the essential function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with full schema coverage but no output schema or annotations, the description is minimally adequate. It covers the basic purpose and scope but lacks details on return values, error handling, or behavioral traits, which are important for a tool that might return complex data. It meets the baseline for a simple read tool but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('spec' and 'property') with clear descriptions. The description adds marginal value by reinforcing that omitting 'spec' returns all CSS properties, but it doesn't provide additional context like format examples or interaction between parameters beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'CSS property definitions', specifying the scope as 'from a specific spec or all specs'. It distinguishes from siblings like 'get_html_elements' or 'get_w3c_spec' by focusing on CSS properties rather than HTML elements or general specs. However, it doesn't explicitly differentiate from 'list_css_specs' which might list specs rather than properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'from a specific spec or all specs', suggesting it can be used with or without the 'spec' parameter. However, it provides no explicit guidance on when to use this tool versus alternatives like 'search_w3c_specs' or 'list_css_specs', nor does it mention any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds context beyond the input schema by specifying that dependency data is not available and returns empty arrays, which is crucial for understanding the tool's limitations. However, it lacks details on error handling, response format, or other behavioral traits, preventing a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of two concise sentences. The first sentence states the core purpose, and the second adds critical behavioral context about limitations. There is no wasted text, and every sentence earns its place by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with one parameter), no annotations, and no output schema, the description is moderately complete. It covers the purpose and a key limitation (dependency data unavailability), but lacks details on output structure, error cases, or how it differs from sibling tools. This makes it adequate but with clear gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'shortname' clearly documented as 'Specification shortname.' The description does not add any additional meaning or context about this parameter beyond what the schema provides. According to the rules, when schema coverage is high (>80%), the baseline score is 3, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get basic information for a specification.' It uses a specific verb ('Get') and resource ('specification'), but does not explicitly differentiate it from sibling tools like 'get_w3c_spec' or 'search_w3c_specs', which likely serve similar purposes. This omission prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by noting that dependency data is unavailable and returns empty arrays, suggesting this tool is for basic info only. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'get_w3c_spec' or 'search_w3c_specs'), nor does it outline prerequisites or exclusions. This leaves gaps in clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions optional filtering but lacks details on pagination (implied by 'limit'), rate limits, authentication needs, or the structure of returned results. For a list tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List W3C/WHATWG/IETF web specifications') and succinctly covers optional filtering. Every word earns its place, with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and filtering options but lacks details on result format, pagination behavior, or error handling, which are important for a list operation without structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value by summarizing the filtering options ('organization, keyword, or category') but does not provide additional syntax, format, or usage details beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('W3C/WHATWG/IETF web specifications'), making the purpose specific and unambiguous. It distinguishes this tool from siblings like 'get_w3c_spec' (singular retrieval) and 'search_w3c_specs' (likely broader search) by emphasizing listing with optional filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by mentioning optional filtering parameters (organization, keyword, category), which helps guide when to apply these filters. However, it does not explicitly state when to use this tool versus alternatives like 'search_w3c_specs' or 'list_css_specs', missing explicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the search behavior but lacks critical details like whether results are paginated, sorted, or include metadata; what happens on empty queries; or any rate limits or authentication needs. For a search tool with no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and search scope with zero wasted words. Every part earns its place by clarifying the tool's function and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search with two parameters), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and search scope but lacks behavioral details (e.g., result format, error handling) that would be needed for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (query and limit). The description adds no additional parameter semantics beyond what the schema provides, such as query format examples or limit constraints, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Search web specifications') and resource ('by query string'), and distinguishes from siblings by specifying the search scope ('searching in title, shortname, and description'), unlike list-oriented siblings (e.g., list_w3c_specs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context for text-based queries, but does not explicitly state when to use this tool versus alternatives like list_w3c_specs or get_w3c_spec. It provides clear search scope but lacks explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![w3c-mcp MCP server](https://glama.ai/mcp/servers/shuji-bonji/w3c-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shuji-bonji/w3c-mcp)

Score Badge

Copy to your README.md:

[![w3c-mcp MCP server](https://glama.ai/mcp/servers/shuji-bonji/w3c-mcp/badges/score.svg)](https://glama.ai/mcp/servers/shuji-bonji/w3c-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shuji-bonji/w3c-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server