Website Spec

by website.specification.mcp

Overview Discussions Admin

Server Details

Provides a platform-agnostic specification of the technical features every decent website should have

Ownership verified

Status: Healthy
Uptime: 100.0% over 48 days
Last Tested: 2026-10-04 08:21
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.7/5.0

Scored 2026-09-30 21:00 across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: analyze_site performs an audit, while the rest are read-only accessors for different spec views (categories, changes, checklist, topic, list, search). Overlaps between list_topics, get_checklist, and search are explicitly clarified in the descriptions, guiding correct selection.

Naming Consistency4/5

Most tools follow a consistent verb_noun snake_case pattern (get_categories, get_changes, get_checklist, get_topic, list_topics, analyze_site). The lone exception is 'search', which lacks a noun object, though it is still clear and common.

Tool Count5/5

Seven tools are well-scoped for a spec browsing and auditing server. Each tool earns its place: discovery, listing, retrieval, search, delta tracking, checklist generation, and site analysis.

Completeness5/5

The surface covers the full lifecycle of spec consumption: category discovery, topic listing and retrieval, full-text search, change tracking, audit checklist generation, and site auditing. No obvious gaps exist for a read-only specification website.

Available Tools

7 tools

analyze_siteAnalyse a public websiteA

Read-only

Inspect

Fetch an operator-approved public site and report against every current spec topic. Samples up to five HTML pages, runs HTTP checks and optionally sends extracted public text to TypeSafe Jev for semantic checks. Requires an X-Audit-Token header and a configured hostname allowlist. Returns Markdown and structured JSON, including evidence and unverified topics. Does not execute JavaScript, authenticate to the target, submit forms, or certify whole-site compliance. Can incur TypeSafe usage charges.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Public HTTP(S) starting URL; no query string, fragment, credentials or custom port.
`maxPages`	No	Maximum HTML page attempts, including the starting page.
`includeJev`	No	Send extracted public page text to TypeSafe for semantic judgements.

Output Schema

ParametersJSON Schema

Name	Required	Description
`report`	Yes	Versioned audit report, with all topics, checks and evidence.
`markdown`	Yes

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile, and the description adds substantial context beyond them: required X-Audit-Token header, configured hostname allowlist, the ~five-page sampling limit, the fact that TypeSafe Jev is invoked and can incur usage charges, and the identity of returned artifacts (Markdown + structured JSON with evidence and unverified topics).

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?

Purpose is front-loaded, then constraints, then outputs and exclusions. Every sentence carries distinct information (auth, allowlist, sampling cap, cost, non-capabilities) with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a rich output schema and full annotations, the description supplies exactly what remains: prerequisites (token, allowlist), side effects (cost), and boundaries (no JS/auth/forms/certification). Nothing an agent needs to invoke it correctly is missing.

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 all three parameters are already fully documented in the schema. The description's mention of sampled pages and optional text submission loosely maps to maxPages and includeJev but adds no syntax or constraint detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb+resource ('fetch an operator-approved public site and report against every current spec topic') with the analysis scope made concrete via sampling, HTTP checks, and optional semantic checks. It is instantly distinguishable from the all-retrieval siblings (get_*, list_topics, search).

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?

Gives clear context for when the tool applies (operator-approved public site, spec-topic reporting) and enumerates exclusions (no JS execution, no target auth, no form submission). It does not explicitly name a sibling alternative or decision rule for choosing it over them, so it stops short of a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_categoriesList categoriesA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of categories returned (always ten).
`categories`	Yes	All top-level categories in canonical display order.

TDQS

A4.7/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 dateA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`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

ParametersJSON 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.

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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_checklistWebsite checklistA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

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

ParametersJSON 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.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the bar is lower, yet the description adds real context: the output is a Markdown checklist of tickable lines with status and canonical URL, grouped in canonical order, and the output is deterministic. That is genuine behavioral disclosure beyond the structured fields.

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?

Front-loaded and dense with useful routing information, and every sentence roughly earns its place. Minor redundancy: the opening "Read-only" and "No side effects" restate readOnlyHint, slightly inflating the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, yet the description still clarifies output format and determinism. Combined with the filter defaults and sibling routing, nothing an agent needs to call this correctly is missing.

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?

Schema coverage is 100% with fully documented enums, so the baseline is 3. The description adds the default-filter semantics (all statuses returned when status is omitted) and reinforces the category grouping behavior, which is a modest but real increment over the schema.

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?

States a specific verb and resource ("Return a Markdown checklist of spec items grouped by category") and immediately names the sibling it is not (list_topics), so an agent can differentiate without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use list_topics for a flat list instead of grouped checkboxes, and the audit_url prompt to drive an actual audit. It also states the default filtering behavior (all statuses unless status is passed), covering both when to use and how the filters change scope.

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 pageA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

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

ParametersJSON 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`.

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 topicsA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`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

ParametersJSON 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).

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 specA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

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

ParametersJSON 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.

TDQS

A5/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 30, 2026
- Addedanalyze_site
1 tool updateJun 20, 2026
- Addedget_changes
5 tool updatesJun 9, 2026
- Changedget_categories5 fields changed
  - addedOutput schema / properties / categories / description
```
Added value: +"All top-level categories in canonical display order."
```
  - addedOutput schema / properties / categories / items / properties / summary / description
```
Added value: +"One-sentence description of the category."
```
  - addedOutput schema / properties / categories / items / properties / title / description
```
Added value: +"Human-readable category title."
```
  - addedOutput schema / properties / categories / items / properties / topicCount / description
```
Added value: +"Number of spec topics in this category."
```
  - addedOutput schema / properties / count / description
```
Added value: +"Number of categories returned (always ten)."
```
- Changedget_checklist12 fields changed
  - addedOutput schema / properties / categories / description
```
Added value: +"Checklist groups in canonical category order, each holding its items."
```
  - addedOutput schema / properties / categories / items / properties / items / description
```
Added value: +"Checklist entries in this category, in canonical page order."
```
  - addedOutput schema / properties / categories / items / properties / items / items / properties / slug / description
```
Added value: +"Kebab-case identifier; pass to `get_topic`."
```
  - addedOutput schema / properties / categories / items / properties / items / items / properties / status / description
```
Added value: +"Spec status tier: `required`, `recommended`, `optional`, or `avoid`."
```
  - addedOutput schema / properties / categories / items / properties / items / items / properties / summary / description
```
Added value: +"One-sentence summary of the item."
```
  - addedOutput schema / properties / categories / items / properties / items / items / properties / title / description
```
Added value: +"Human-readable page title."
```
  - addedOutput schema / properties / categories / items / properties / items / items / properties / url / description
```
Added value: +"Canonical HTML URL of the spec page."
```
  - addedOutput schema / properties / categories / items / properties / slug / description
```
Added value: +"Kebab-case category identifier."
```
  - addedOutput schema / properties / categories / items / properties / title / description
```
Added value: +"Human-readable category title."
```
  - addedOutput schema / properties / filters / description
```
Added value: +"The filters that were applied (omitted keys mean no filter)."
```
  - addedOutput schema / properties / filters / properties / category / description
```
Added value: +"The category filter that was applied, if any."
```
  - addedOutput schema / properties / filters / properties / status / description
```
Added value: +"The status filter that was applied, if any."
```
- Changedget_topic9 fields changed
  - addedOutput schema / properties / category / description
```
Added value: +"Top-level category this topic belongs to."
```
  - addedOutput schema / properties / relatedSlugs / description
```
Added value: +"Slugs of related topics; each can be passed to `get_topic`."
```
  - addedOutput schema / properties / slug / description
```
Added value: +"Kebab-case identifier of this page."
```
  - addedOutput schema / properties / sources / items / properties / publisher / description
```
Added value: +"Publishing body (e.g. WHATWG, W3C, IETF), if known."
```
  - addedOutput schema / properties / sources / items / properties / title / description
```
Added value: +"Title of the cited source."
```
  - addedOutput schema / properties / sources / items / properties / url / description
```
Added value: +"URL of the cited source."
```
  - addedOutput schema / properties / status / description
```
Added value: +"Spec status tier: `required`, `recommended`, `optional`, or `avoid`."
```
  - addedOutput schema / properties / summary / description
```
Added value: +"One-sentence summary of the topic."
```
  - addedOutput schema / properties / title / description
```
Added value: +"Human-readable page title."
```
- Changedlist_topics7 fields changed
  - addedOutput schema / properties / filters / properties / category / description
```
Added value: +"The category filter that was applied, if any."
```
  - addedOutput schema / properties / filters / properties / status / description
```
Added value: +"The status filter that was applied, if any."
```
  - addedOutput schema / properties / topics / description
```
Added value: +"Matching topics in canonical spec order (by category, then page order)."
```
  - addedOutput schema / properties / topics / items / properties / category / description
```
Added value: +"Top-level category this topic belongs to."
```
  - addedOutput schema / properties / topics / items / properties / status / description
```
Added value: +"Spec status tier: `required`, `recommended`, `optional`, or `avoid`."
```
  - addedOutput schema / properties / topics / items / properties / summary / description
```
Added value: +"One-sentence summary of the topic."
```
  - addedOutput schema / properties / topics / items / properties / title / description
```
Added value: +"Human-readable page title."
```
- Changedsearch5 fields changed
  - addedOutput schema / properties / results / description
```
Added value: +"Ranked matches, most relevant first; empty when `count` is 0."
```
  - addedOutput schema / properties / results / items / properties / category / description
```
Added value: +"Top-level category this topic belongs to."
```
  - addedOutput schema / properties / results / items / properties / status / description
```
Added value: +"Spec status tier: `required`, `recommended`, `optional`, or `avoid`."
```
  - addedOutput schema / properties / results / items / properties / summary / description
```
Added value: +"One-sentence summary of the topic."
```
  - addedOutput schema / properties / results / items / properties / title / description
```
Added value: +"Human-readable page title."
```

4 tool updatesJun 8, 2026

Changedget_checklist2 fields changed

changedInput schema / properties / category / description

Previous value: -"Filter to a single top-level category. Call `get_categories` for the list with descriptions and topic counts. Omit to include all ten categories."New value: +"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`."

changedInput schema / properties / status / description

Previous value: -"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."New value: +"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`."

Changedget_topic1 field changed
- addedInput schema / properties / slug / minLength
```
Added value: +1
```

Changedlist_topics2 fields changed

changedInput schema / properties / category / description

Previous value: -"Filter to a single top-level category. Call `get_categories` for the list with descriptions and topic counts. Omit to include all ten categories."New value: +"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`."

changedInput schema / properties / status / description

Previous value: -"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."New value: +"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`."

Changedsearch2 fields changed

changedInput schema / properties / query / description

Previous value: -"Free-text query. Tokenised on whitespace; each token is matched (substring) against title, slug, summary, and body. Example: `content security policy` or `alt text`."New value: +"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`."

addedInput schema / properties / query / minLength
```
Added value: +1
```

5 tool updatesJun 4, 2026

Changedget_categories1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "categories": {
+      "items": {
+        "properties": {
+          "slug": {
+            "description": "Use as the `category` filter value.",
+            "type": "string"
+          },
+          "summary": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "topicCount": {
+            "type": "integer"
+          }
+        },
+        "required": [
+          "slug",
+          "title",
+          "summary",
+          "topicCount"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "count": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "count",
+    "categories"
+  ],
+  "type": "object"
+}

Changedget_checklist3 fields changed

addedInput schema / properties / category / description

Added value: +"Filter to a single top-level category. Call `get_categories` for the list with descriptions and topic counts. Omit to include all ten categories."

addedInput schema / properties / status / description

Added value: +"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."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "categories": {
+      "items": {
+        "properties": {
+          "items": {
+            "items": {
+              "properties": {
+                "slug": {
+                  "type": "string"
+                },
+                "status": {
+                  "enum": [
+                    "required",
+                    "recommended",
+                    "optional",
+                    "avoid"
+                  ],
+                  "type": "string"
+                },
+                "summary": {
+                  "type": "string"
+                },
+                "title": {
+                  "type": "string"
+                },
+                "url": {
+                  "type": "string"
+                }
+              },
+              "required": [
+                "slug",
+                "title",
+                "status",
+                "summary",
+                "url"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "slug",
+          "title",
+          "items"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "filters": {
+      "properties": {
+        "category": {
+          "enum": [
+            "foundations",
+            "seo",
+            "accessibility",
+            "security",
+            "well-known",
+            "agent-readiness",
+            "performance",
+            "privacy",
+            "resilience",
+            "i18n"
+          ],
+          "type": "string"
+        },
+        "status": {
+          "enum": [
+            "required",
+            "recommended",
+            "optional",
+            "avoid"
+          ],
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "total": {
+      "description": "Total checklist items across all groups.",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "total",
+    "filters",
+    "categories"
+  ],
+  "type": "object"
+}

Changedget_topic2 fields changed

changedInput schema / properties / slug / description

Previous value: -"Kebab-case slug, as listed by `list_topics` or `search`. Examples: `content-security-policy`, `meta-robots`, `llms-txt`."New value: +"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`."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "category": {
+      "enum": [
+        "foundations",
+        "seo",
+        "accessibility",
+        "security",
+        "well-known",
+        "agent-readiness",
+        "performance",
+        "privacy",
+        "resilience",
+        "i18n"
+      ],
+      "type": "string"
+    },
+    "markdown": {
+      "description": "The full page as Markdown with YAML frontmatter.",
+      "type": "string"
+    },
+    "mdUrl": {
+      "description": "Raw Markdown URL.",
+      "type": "string"
+    },
+    "relatedSlugs": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "slug": {
+      "type": "string"
+    },
+    "sources": {
+      "description": "Primary-source citations for this page.",
+      "items": {
+        "properties": {
+          "publisher": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "title",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "status": {
+      "enum": [
+        "required",
+        "recommended",
+        "optional",
+        "avoid"
+      ],
+      "type": "string"
+    },
+    "summary": {
+      "type": "string"
+    },
+    "title": {
+      "type": "string"
+    },
+    "updated": {
+      "description": "ISO 8601 timestamp of the last content update, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "url": {
+      "description": "Canonical HTML URL.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "slug",
+    "title",
+    "category",
+    "status",
+    "url",
+    "mdUrl",
+    "summary",
+    "markdown"
+  ],
+  "type": "object"
+}

Changedlist_topics4 fields changed

addedInput schema / properties / category / description

Added value: +"Filter to a single top-level category. Call `get_categories` for the list with descriptions and topic counts. Omit to include all ten categories."

addedInput schema / properties / limit / description

Added value: +"Maximum number of topics to return after filtering. Omit to return every matching topic; clamped to 1–200 when given."

addedInput schema / properties / status / description

Added value: +"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."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "description": "Topics actually returned (after `limit`).",
+      "type": "integer"
+    },
+    "filters": {
+      "description": "The filters that were applied (omitted keys mean no filter).",
+      "properties": {
+        "category": {
+          "enum": [
+            "foundations",
+            "seo",
+            "accessibility",
+            "security",
+            "well-known",
+            "agent-readiness",
+            "performance",
+            "privacy",
+            "resilience",
+            "i18n"
+          ],
+          "type": "string"
+        },
+        "status": {
+          "enum": [
+            "required",
+            "recommended",
+            "optional",
+            "avoid"
+          ],
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "topics": {
+      "items": {
+        "properties": {
+          "category": {
+            "enum": [
+              "foundations",
+              "seo",
+              "accessibility",
+              "security",
+              "well-known",
+              "agent-readiness",
+              "performance",
+              "privacy",
+              "resilience",
+              "i18n"
+            ],
+            "type": "string"
+          },
+          "slug": {
+            "description": "Kebab-case identifier; pass to `get_topic`.",
+            "type": "string"
+          },
+          "status": {
+            "enum": [
+              "required",
+              "recommended",
+              "optional",
+              "avoid"
+            ],
+            "type": "string"
+          },
+          "summary": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "description": "Canonical HTML URL of the spec page.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "slug",
+          "title",
+          "status",
+          "category",
+          "summary",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "description": "Total topics matching the filters, before `limit`.",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "total",
+    "count",
+    "filters",
+    "topics"
+  ],
+  "type": "object"
+}

Changedsearch3 fields changed

addedInput schema / properties / limit / description

Added value: +"Maximum number of ranked results to return. Defaults to 5; clamped to 1–25."

changedInput schema / properties / query / description

Previous value: -"Free-text query."New value: +"Free-text query. Tokenised on whitespace; each token is matched (substring) against title, slug, summary, and body. Example: `content security policy` or `alt text`."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "description": "Number of results returned (0 if no match).",
+      "type": "integer"
+    },
+    "query": {
+      "description": "The query that was run, echoed back.",
+      "type": "string"
+    },
+    "results": {
+      "items": {
+        "properties": {
+          "category": {
+            "enum": [
+              "foundations",
+              "seo",
+              "accessibility",
+              "security",
+              "well-known",
+              "agent-readiness",
+              "performance",
+              "privacy",
+              "resilience",
+              "i18n"
+            ],
+            "type": "string"
+          },
+          "excerpts": {
+            "description": "Up to two body snippets showing the matched terms in context.",
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "mdUrl": {
+            "description": "URL of the raw Markdown for this page.",
+            "type": "string"
+          },
+          "score": {
+            "description": "Relevance score; higher is a closer match.",
+            "type": "number"
+          },
+          "slug": {
+            "description": "Kebab-case identifier; pass to `get_topic`.",
+            "type": "string"
+          },
+          "status": {
+            "enum": [
+              "required",
+              "recommended",
+              "optional",
+              "avoid"
+            ],
+            "type": "string"
+          },
+          "summary": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "description": "Canonical HTML URL of the spec page.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "slug",
+          "title",
+          "status",
+          "category",
+          "score",
+          "url",
+          "mdUrl",
+          "summary"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "query",
+    "count",
+    "results"
+  ],
+  "type": "object"
+}

5 tool updatesJun 3, 2026
- First observedget_categories
- First observedget_checklist
- First observedget_topic
- First observedlist_topics
- First observedsearch

Related MCP Servers

Citesurf MCP
Marketing Search Monitoring
citesurf
A
license
A
quality
C
maintenance
Enables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.
Updated 5 months ago (2026-04-23 11:46 UTC)
16
22 npm
1
MIT
Competitor Monitor AI MCP
Marketing Research & Data AI & Machine Learning
CSOAI-ORG
A
license
C
quality
B
maintenance
Competitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated a month ago (2026-09-04 12:36 UTC)
11
14 npm
40 PyPI
MIT
revnuvo-company-intelligence
Research & Data Monitoring Networking & Infrastructure
hardeyhemy
A
license
A
quality
C
maintenance
Revnuvo Company Intelligence tells AI agents what changed at a company, with evidence. It observes company websites, technologies, and DNS over time and returns timestamped, confidence-aware changes, signals, and monitoring.
Updated 18 days ago (2026-09-16 11:18 UTC)
9
MIT
industrylens-mcpofficial
Research & Data
IndustryLensOp
A
license
Not graded
quality
B
maintenance
Browse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.
Updated 2 months ago (2026-08-17 15:55 UTC)
MIT