Website Spec

List spec topics

list_topics

Read-onlyIdempotent

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.

Input Schema

TableJSON 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

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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed7 schema fields changedJun 9, 2026
- 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."
```

Changed2 schema fields changedJun 8, 2026

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

Changed4 schema fields changedJun 4, 2026

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"
+}

First observedJun 3, 2026

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.

All Website Spec tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: get_categories for categories, get_changes for history, get_checklist for checklists, get_topic for single page, list_topics for listing, and search for full-text. There is no overlap.

Naming Consistency4/5

Most tools follow 'get_' pattern (get_categories, get_changes, get_checklist, get_topic), but list_topics and search break the pattern. However, all names are intuitive and consistent in using lowercase with underscores.

Tool Count5/5

With 6 tools covering categories, search, listing, details, checklist, and changes, the count is well-suited for a specification reference. Each tool serves a clear need without excess.

Completeness5/5

The tool set covers all read operations needed for a specification: discovery (categories, search), browsing (list_topics, get_checklist), deep dive (get_topic), and change tracking (get_changes). No obvious gaps for its intended use.

Resources

Need Help?