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.2/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: categories, checklist, single topic, topic list, and search. No ambiguity between them.
All tool names follow a consistent verb_noun pattern using snake_case (get_categories, get_checklist, get_topic, list_topics) with search being the only exception but it's a common standalone verb that fits the pattern.
Five tools is an ideal size for a spec documentation server, covering discovery, retrieval, and search without unnecessary bloat.
The set covers listing categories and topics, fetching full topic pages, grouped checklists, and full-text search. As a read-only reference, this surface is complete and leaves no dead ends.
Available Tools
5 toolsget_categoriesList categoriesARead-onlyIdempotentInspect
Read-only. List the ten top-level spec categories with their summaries and topic counts. Takes no arguments. 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 | |
| categories | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently states it lists only the top ten categories and includes summaries and counts. This is sufficient for a read-only listing, though omits potential details like ordering or pagination.
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?
A single, clear sentence with no wasted words. It efficiently conveys the tool's purpose and output.
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 simplicity (no params, no output schema), the description is mostly complete. It could enhance by describing the output structure, but it covers the core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no additional explanation is needed. The description adds no param info, but nothing is lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'ten top-level spec categories', and the output includes 'summaries and topic counts'. It distinguishes from sibling tools like get_checklist or 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?
No explicit guidance on when to use this tool versus alternatives, though the name and sibling list imply it's for categories.
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. 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. | |
| 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total checklist items across all groups. |
| filters | Yes | |
| categories | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly describes a read operation (returning a checklist) with no indication of side effects. While it could explicitly state it is read-only, the description is sufficiently transparent for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first states the main action and format, the second provides usage context. No extraneous information; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential aspects: what is returned, grouping, and filtering. It could elaborate on what 'spec items' are and how grouping works, but it is adequate for a simple checklist tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds that parameters are optional filters by category and status, but does not explain the meaning of enum values (e.g., 'required' vs 'recommended'). This provides basic context but lacks depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a Markdown checklist of spec items grouped by category, with optional filtering. It distinguishes itself from siblings like get_categories, get_topic, list_topics, and search by specifying the output format and grouping.
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 a clear use case ('Useful for site audits'), implying when to use the tool. However, it does not explicitly state when not to use it or mention alternatives, though the context from sibling tool names aids differentiation.
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 | |
| mdUrl | Yes | Raw Markdown URL. |
| title | Yes | |
| status | Yes | |
| sources | No | Primary-source citations for this page. |
| summary | Yes | |
| updated | No | ISO 8601 timestamp of the last content update, or null. |
| category | Yes | |
| markdown | Yes | The full page as Markdown with YAML frontmatter. |
| relatedSlugs | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return value (YAML frontmatter + rendered body) but does not mention error behavior or side effects, which is acceptable for a read-only fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the action and result, the second elaborates on the return structure. Well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and no output schema, the description sufficiently explains the input (how to get slug) and output (frontmatter fields + body), making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes the slug param as kebab-case. The description adds value by providing examples and explicit sources (list_topics, search) for obtaining valid slugs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches full canonical Markdown for a single spec page by slug, distinguishing it from siblings like list_topics (which lists slugs) 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?
The description explains that the slug parameter should come from list_topics or search, guiding the agent on prerequisite steps, but does not explicitly address when to avoid this tool.
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. 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. | |
| 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Topics actually returned (after `limit`). |
| total | Yes | Total topics matching the filters, before `limit`. |
| topics | Yes | |
| 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?
No annotations provided, but the description clearly indicates a read-only listing operation with no destructive actions. It does not disclose potential edge cases like empty results or pagination, but for a simple list tool, it is adequate.
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, no redundant information. The primary action is stated first, followed by return fields and an example. Highly 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?
For a low-complexity tool with three optional parameters and no output schema, the description covers purpose, filters, and returns. It is sufficient for an agent to understand the tool's primary use case, though missing explicit pagination or ordering details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions optional filtering by category and status, but does not explain the 'limit' parameter or provide details on the enum values. With 0% schema description coverage, the description adds some context but could be more explicit.
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?
Clear verb ('list') and resource ('spec topics'), with explicit mention of optional filters and return fields. Example usage ('canonical list of e.g. all required SEO topics') distinguishes it from siblings like get_topic 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?
Provides a specific usage scenario ('when the user wants the canonical list...'), which implies when to use. However, it does not explicitly state when not to use or mention alternative tools.
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. Tokenised on whitespace; each token is matched (substring) 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that it performs search and returns results, but does not mention if it is read-only, side effects, authentication needs, or performance characteristics. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states functionality and output, the second gives usage guidance. No redundant or extraneous words. Very concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 params, no output schema), the description covers the return fields and scope. It could mention pagination or ranking order, but the core information is present. Adequate for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'query' has a description). The description does not add meaning beyond the schema; it implies 'keyword' usage but does not elaborate on query syntax or the 'limit' parameter. The schema defaults and constraints are clear, so the description provides marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs full-text search across all spec pages and returns specific fields (title, status, etc.). It distinguishes itself from sibling tools like get_topic and list_topics by being a keyword-based search over all pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when the user asks about a topic by keyword,' providing clear guidance on when to invoke it. It does not mention when not to use it, but the context of siblings implies alternatives for specific retrievals.
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!