Provides a platform-agnostic specification of the technical features every decent website should have
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 4.7/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: get_categories for categories, get_changes for history, get_checklist for checklists, get_topic for single page, list_topics for listing, and search for full-text. There is no overlap.
Most tools follow 'get_' pattern (get_categories, get_changes, get_checklist, get_topic), but list_topics and search break the pattern. However, all names are intuitive and consistent in using lowercase with underscores.
With 6 tools covering categories, search, listing, details, checklist, and changes, the count is well-suited for a specification reference. Each tool serves a clear need without excess.
The tool set covers all read operations needed for a specification: discovery (categories, search), browsing (list_topics, get_checklist), deep dive (get_topic), and change tracking (get_changes). No obvious gaps for its intended use.
get_categoriesList categoriesARead-only. List the ten top-level spec categories with their summaries and topic counts. Takes no arguments. No side effects; categories are returned in canonical display order. Call this first to discover the valid category filter values used by list_topics, get_checklist, and search results.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of categories returned (always ten). |
| categories | Yes | All top-level categories in canonical display order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false. The description adds 'No side effects' (consistent) and mentions categories are returned in 'canonical display order,' which is useful context beyond the annotations. No contradictions.
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 'Read-only.' Every sentence adds unique value: purpose, no arguments, side effects, ordering, and usage guidance. 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?
For a simple list tool with an output schema (even though not shown here), the description covers what it returns (categories with summaries and topic counts), behavior (no side effects, ordering), and why to call it. Fully complete for the tool's 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?
No parameters exist; schema coverage is 100%. The description correctly notes 'Takes no arguments,' which reinforces the schema. Baseline 4 is appropriate for zero-parameter tools.
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 ten top-level spec categories with summaries and topic counts. It distinguishes from sibling tools by explaining that categories serve as filter values for other tools like list_topics, get_checklist, and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to 'Call this first' to discover valid category filter values, and names the sibling tools that use these categories. This provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_changesGet spec changes since a dateARead-only. Return the spec's change history — new pages, status promotions/downgrades, substantive rewrites, and removals — newest first, each resolved to the current topics it affects (slug, title, current status, category, URL). This is the delta tool for a returning agent: pass since (the date you last audited a site) to get only what has changed, then re-audit just those topics instead of the whole spec. Omit since to get the most recent entries. The spec is hand-curated and typed (added/changed/status/removed), so this is a precise signal, not a raw timestamp diff. The same history is published as an RSS feed at https://specification.website/changelog/rss.xml for out-of-band polling. A sensible re-check cadence is monthly, or whenever you start a fresh audit.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter to one kind of change. `added` = a new spec page or category. `status` = a topic promoted or downgraded between tiers. `changed` = a substantive rewrite of an existing page. `removed` = a page that was live and has been deleted. Omit to include all four kinds. | |
| limit | No | Maximum number of change entries to return, newest first. Defaults to 20 when `since` is omitted, or up to 100 within a `since` window; clamped to 1–100. | |
| since | No | Return only changes on or after this date (ISO `YYYY-MM-DD`; longer ISO datetimes are accepted and truncated to the day). Typically the date of your last audit. Omit to get the most recent changes regardless of date. Example: `2026-05-01`. |
| Name | Required | Description |
|---|---|---|
| type | Yes | The `type` filter that was applied, or null. |
| count | Yes | Number of change entries returned. |
| since | Yes | The `since` date that was applied (truncated to YYYY-MM-DD), or null. |
| latest | Yes | Date of the most recent change in the whole spec (independent of filters). Store this and pass it back as `since` next time. |
| changes | Yes | Matching change entries, newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the read-only nature, the hand-curated and typed nature of changes, and the resolution format. Adds context beyond annotations (readOnlyHint, idempotentHint) by detailing what each change type means and how results are structured.
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 efficiently structured with a clear first sentence stating purpose, followed by usage guidance and parameter details. Every sentence adds information 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?
Given the tool has an output schema, the description covers all necessary context: purpose, parameter behavior, usage scenario, cadence, and even an alternative data source (RSS). It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are covered in the schema (100% coverage), so baseline is 3. The description adds value by explaining the 'since' parameter's typical use as 'date of your last audit' and clarifying the 'type' enum values, earning a 4.
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 the spec's change history with specific change types and resolution to current topics. It differentiates itself from siblings like list_topics and get_topic by being the 'delta tool' for returning agents.
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 explains when to pass 'since' (last audit date) vs omit it (most recent entries), recommends a monthly cadence, and mentions the alternative RSS feed. This provides clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_checklistGet an audit checklistARead-only. Return a Markdown checklist of spec items grouped by category, optionally filtered by category and/or status. Built for site audits — each item is a tickable line with status and canonical URL. Returns all statuses unless status is passed. No side effects; items are grouped by category in canonical order and the output is deterministic. Use list_topics instead when you want a flat list rather than grouped checkboxes, or the audit_url prompt to drive an actual audit of a target URL.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by spec status tier. `required` = the web-platform contract breaks or a clear class of users is harmed without it. `recommended` = a modern site should do it. `optional` = context-dependent. `avoid` = outdated, harmful, or superseded. Omit to include all four tiers. Example: `required`. | |
| category | No | Filter to a single top-level category. Call `get_categories` for the list with descriptions and topic counts. Omit to include all ten categories. Example: `seo`. |
| Name | Required | Description |
|---|---|---|
| total | Yes | Total checklist items across all groups. |
| filters | Yes | The filters that were applied (omitted keys mean no filter). |
| categories | Yes | Checklist groups in canonical category order, each holding its items. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations (readOnlyHint, idempotentHint) by stating no side effects, deterministic output, items grouped by category, and that all statuses are returned unless filtered. While annotations already indicate safety, the description enriches the behavioral model.
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 and front-loaded with 'Read-only.' Each sentence adds distinct value: purpose, filtering behavior, comparison with alternatives, and guarantee of no side effects. 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?
Given the presence of an output schema and moderate complexity, the description fully covers tool behavior: what it returns (Markdown checklist), grouping, filtering options, determinism, and related tools. It is complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have full schema coverage with descriptions and enums. The description provides additional context on the meaning of status tiers and references 'get_categories' for category details. This reinforces but does not significantly add beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a Markdown checklist of spec items grouped by category, optionally filtered by category and/or status. It specifies the tool is read-only and built for site audits. It distinguishes from siblings by referencing 'list_topics' for a flat list and the 'audit_url' prompt for driving an audit.
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 provides when to use this tool versus alternatives: 'Use `list_topics` instead when you want a flat list rather than grouped checkboxes, or the `audit_url` prompt to drive an actual audit of a target URL.' It also clarifies that omitting status returns all statuses, guiding proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_topicGet one spec pageARead-only. Fetch the full canonical Markdown for a single spec page by its slug: YAML frontmatter (title, status, category, sources, related slugs) plus the rendered body. Use this once you have a slug from search or list_topics. If you only have keywords, call search first.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Kebab-case slug, as listed by `list_topics` or `search`. Matched case-insensitively, with close-match suggestions on miss. Examples: `content-security-policy`, `meta-robots`, `llms-txt`. |
| Name | Required | Description |
|---|---|---|
| url | Yes | Canonical HTML URL. |
| slug | Yes | Kebab-case identifier of this page. |
| mdUrl | Yes | Raw Markdown URL. |
| title | Yes | Human-readable page title. |
| status | Yes | Spec status tier: `required`, `recommended`, `optional`, or `avoid`. |
| sources | No | Primary-source citations for this page. |
| summary | Yes | One-sentence summary of the topic. |
| updated | No | ISO 8601 timestamp of the last content update, or null. |
| category | Yes | Top-level category this topic belongs to. |
| markdown | Yes | The full page as Markdown with YAML frontmatter. |
| relatedSlugs | No | Slugs of related topics; each can be passed to `get_topic`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by confirming it is 'Read-only' and detailing the return structure: 'YAML frontmatter (title, status, category, sources, related slugs) plus the rendered body.' It also mentions close-match suggestions on miss, providing behavioral context beyond 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, front-loaded with 'Read-only.' and the core purpose. Every sentence 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?
Given the tool has one parameter, full schema coverage, and an output schema (implied), the description adequately covers the return structure and prerequisite usage. It lacks details on error scenarios but is sufficient for a simple fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the input schema already thoroughly describes the 'slug' parameter with examples and behavior (case-insensitive, close-match suggestions). The description does not add significant additional meaning beyond restating that it fetches by slug.
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 'Fetch the full canonical Markdown for a single spec page by its slug'. It specifies the verb 'Fetch', the resource 'canonical Markdown for a single spec page', and the input parameter 'slug'. It also distinguishes itself from sibling tools like 'search' and 'list_topics' by noting the prerequisite of having a slug from those tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this once you have a slug from `search` or `list_topics`.' and 'If you only have keywords, call `search` first.' This clearly communicates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_topicsList spec topicsARead-only. Return the canonical list of spec topics, optionally narrowed by category and/or status, each with title, status, category, summary, and URL. Returns ALL statuses unless status is passed; omitting limit returns every matching topic. No side effects; results are deterministic and returned in canonical spec order (by category, then page order). This is the right tool when you want a complete, unranked index (e.g. "every required SEO topic"). Use search instead for relevance-ranked keyword lookup, get_checklist for audit-style grouped output, and get_topic to fetch one page in full.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of topics to return after filtering. Omit to return every matching topic; clamped to 1–200 when given. | |
| status | No | Filter by spec status tier. `required` = the web-platform contract breaks or a clear class of users is harmed without it. `recommended` = a modern site should do it. `optional` = context-dependent. `avoid` = outdated, harmful, or superseded. Omit to include all four tiers. Example: `required`. | |
| category | No | Filter to a single top-level category. Call `get_categories` for the list with descriptions and topic counts. Omit to include all ten categories. Example: `seo`. |
| Name | Required | Description |
|---|---|---|
| count | Yes | Topics actually returned (after `limit`). |
| total | Yes | Total topics matching the filters, before `limit`. |
| topics | Yes | Matching topics in canonical spec order (by category, then page order). |
| filters | Yes | The filters that were applied (omitted keys mean no filter). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: states no side effects, deterministic results, canonical order. Annotations already declare readOnlyHint and idempotentHint, but description reinforces and expands on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise (approx. 100 words) and well-structured: purpose first, then filtering details, then side effects/order, then usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, filtering, defaults, side effects, order, usage, and alternatives. Given output schema exists and parameters are well-documented, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds an example for status and clarifies default (omitting limit returns all). This adds some value but does not significantly go beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the canonical list of spec topics, optionally narrowed by category or status. It explicitly distinguishes from siblings like search, get_checklist, and get_topic.
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 says when to use this tool ('complete, unranked index') and provides alternatives (search for ranked, get_checklist for grouped, get_topic for single). Also explains behavior of omitting limit and status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch the specARead-only, deterministic full-text search across every spec page. Ranks pages by weighted keyword matches in title, slug, summary, and body, and returns the top results with status, category, canonical URL, Markdown URL, and matching body excerpts. No side effects and no live-web access — it queries an in-memory snapshot bundled at build time, so it returns in well under a millisecond. Use this for keyword/topic lookups when you do NOT already know the slug. Prefer list_topics when you want the complete, unranked set of pages matching a category/status filter; prefer get_topic when you already know the exact slug.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of ranked results to return. Defaults to 5; clamped to 1–25. | |
| query | Yes | Free-text query, matched case-insensitively as substrings (not whole words). Split on whitespace; tokens shorter than 2 characters are ignored, so single-letter terms match nothing. Punctuation other than / _ . - is treated as a separator. Each token is scored against title, slug, summary, and body. Example: `content security policy` or `alt text`. |
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of results returned (0 if no match). |
| query | Yes | The query that was run, echoed back. |
| results | Yes | Ranked matches, most relevant first; empty when `count` is 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; the description adds that it is deterministic, has no side effects, no live-web access, uses an in-memory snapshot, and returns in under a millisecond. No contradiction with 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?
Four sentences with clear ordering: purpose, return value, behavioral traits, usage alternatives. No filler; each sentence earns its place. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (full-text search), full schema coverage, strong annotations, and presence of output schema, the description covers all essential aspects: what it does, how it works, when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions). The description enriches this with details on substring matching, tokenization, punctuation handling, and limit clamping, adding significant value over the schema alone.
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 this is a read-only full-text search tool across spec pages, specifies the fields matched (title, slug, summary, body) and return fields. It distinguishes itself from siblings by naming list_topics and get_topic as alternatives, making its purpose 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?
Provides explicit when-to-use guidance ('keyword/topic lookups when you do NOT already know the slug') and direct comparisons to siblings: prefer list_topics for unfiltered category/status results, get_topic for exact slugs. This is exemplary for tool selection.
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!
