Website Spec
Server Details
Provides a platform-agnostic specification of the technical features every decent website should have
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.8/5 across 5 of 5 tools scored.
Each tool has a distinct purpose: get_categories for top-level categories, get_checklist for grouped markdown output, get_topic for a single page, list_topics for a flat list, and search for full-text relevance ranking. The descriptions clearly differentiate them, so an agent would not confuse them.
Three tools use a 'get_' prefix, one uses 'list_', and one is a bare verb 'search'. While all are imperative and descriptive, the mix of prefixes and a bare verb is a minor inconsistency, but still readable and predictable.
With 5 tools, the set is well-scoped for a spec server. It covers discovery, listing, detail retrieval, search, and a specialized checklist view without being overly numerous or thin.
The tool set provides complete coverage for a read-only spec domain: categories, indexed lists with filters, single-page retrieval, full-text search, and a formatted checklist. No obvious gaps like a missing 'get all slugs' or 'get related topics' because list_topics and get_topic suffice.
Available Tools
6 toolsget_categoriesList categoriesARead-onlyIdempotentInspect
Read-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 | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of categories returned (always ten). |
| categories | Yes | All top-level categories in canonical display order. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), description adds 'No side effects' and 'returned in canonical display order', providing useful behavioral context.
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 that are information-dense without redundancy: purpose, scope, output details, and usage guidance all front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, an output schema exists, and the description explains what is returned (summaries and topic counts) and ordering, it is 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?
No parameters exist, and schema coverage is 100% (baseline 4). Description notes 'Takes no arguments', which is consistent with schema but does not add new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the ten top-level spec categories with summaries and topic counts, providing a specific verb, resource, and output details that distinguish it from sibling 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?
Explicitly tells users to 'Call this first' to discover valid category filter values used by other tools, giving 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-onlyIdempotentInspect
Read-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`. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds that the spec is 'hand-curated and typed' (added/changed/status/removed), describes the structure of returned entries, and mentions the RSS feed. 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?
Somewhat long but every sentence adds value. Front-loaded with purpose and usage, then details. Could trim minor redundancy ('the same history is published as an RSS feed' could be supplementary) but 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?
Given the complexity (3 parameters, output schema exists, annotations present), the description is comprehensive: covers purpose, usage, behavioral nuances, parameter details, and even external resources. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with decent param descriptions. The tool description adds extra context: `since` is framed as 'the date you last audited a site', `type` enum values are explained in detail (e.g., 'status = a topic promoted or downgraded between tiers'), and `limit` defaults are 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 'Read-only. Return the spec's change history' and identifies itself as 'the delta tool for a returning agent'. It uses specific verbs and resources, and the sibling context differentiates it from other tools like list_topics.
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 use: pass `since` for delta audits, omit for recent changes. Provides a concrete re-check cadence ('monthly, or whenever you start a fresh audit') and contrasts with the broader audit process.
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-onlyIdempotentInspect
Read-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`. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, but the description adds valuable context: 'No side effects', 'output is deterministic', and describes grouping and ordering. No contradictions found.
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 plus a usage guidance sentence. Front-loaded with key info: 'Read-only. Return a Markdown checklist...' No wasted words; every sentence contributes.
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 2 optional params, output schema present, and sibling tools, the description covers what the tool returns, filters, side effects, ordering, and intended use (site audits). Completely adequate.
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% with enums and descriptions. The description adds context: 'optionally filtered by category and/or status', mentions that omitting `status` includes all, and references `get_categories` for category list.
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 starts with 'Return a Markdown checklist of spec items grouped by category', clearly stating the verb and resource. It distinguishes from siblings by naming `list_topics` for flat lists and `audit_url` for actual audits.
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?
Explicit guidance on when to use this tool vs alternatives: 'Use list_topics instead when you want a flat list... or the audit_url prompt to drive an actual audit'. Also clarifies default behavior: 'Returns all statuses unless status is passed'.
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-onlyIdempotentInspect
Read-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`. |
Output Schema
| 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`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds return content details but 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?
Three concise sentences, front-loaded with 'Read-only', no fluff.
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 strong annotations and output schema, description sufficiently explains what and when.
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 covers parameter fully; description reinforces usage context but doesn't add new semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches full canonical Markdown for a spec page by slug, distinguishing from siblings like 'search' and 'list_topics'.
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 to use after getting a slug from 'search' or 'list_topics', and advises to call 'search' first if only keywords.
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-onlyIdempotentInspect
Read-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`. |
Output Schema
| 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds deterministic ordering, no side effects, and default behavior for omitted parameters, enriching 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?
One paragraph with clear structure: primary action, filtering options, behavioral details, sibling comparison. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema available, description covers all necessary aspects: filtering, defaults, ordering, and relationships to siblings. Nothing essential is missing.
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 parameters have schema descriptions (100% coverage). Description adds behavioral context: default when omitted, example values, and ordering impact, making each parameter's effect clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns the canonical list of spec topics, optionally filtered by category and status, with fields listed. Explicitly distinguishes from siblings like 'search' 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?
Provides explicit guidance on when to use this tool ('complete, unranked index') and directs to alternatives for different use cases (search, get_checklist, get_topic), including an example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch the specARead-onlyIdempotentInspect
Read-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`. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant value beyond annotations: describes no side effects, in-memory snapshot, sub-millisecond speed, and details of token matching and scoring. Annotations already declare read-only and idempotent, so description supplements without redundancy.
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?
Each sentence earns its place: purpose, behavior, usage guidance, and parameter notes are compactly presented. No fluff.
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 output schema exists, the description still lists output fields and provides comprehensive behavioral context. Combined with annotations, it fully informs an agent for correct 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 coverage is 100% with good descriptions. The description adds example queries and clarifies substring matching and token handling, but the schema already provides sufficient detail for basic 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?
Clearly states it performs 'full-text search across every spec page' with ranking and returns specific fields. Distinguishes from sibling tools by naming alternatives.
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 tells when to use (keyword lookups without slug) and when to prefer alternatives (list_topics for complete sets, get_topic for known slug).
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.
Discussions
No comments yet. Be the first to start the discussion!