A
licenseNot graded
qualityC
maintenanceEnables MCP clients to access and read mdbook documentation, including structure, content, and search.
12 npm
3
MIT
docs
Server Details
Political Comms documentation MCP server: search docs, query the docs filesystem. No auth.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 44 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.5/5.0
Scored across 3 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: query_docs_filesystem_political_comms provides read-only shell access to the docs, search_political_comms performs semantic search, and submit_feedback handles doc issue reporting. There is no overlap or ambiguity between them.
Naming Consistency3/5
All names use a verb_noun pattern, but the conventions vary: 'query_docs_filesystem_political_comms' is long and specific, while 'search_political_comms' and 'submit_feedback' are shorter and less patterned. This mixed structure makes the full set slightly less predictable.
Tool Count5/5
Three tools is well-scoped for a documentation server: semantic search, filesystem-based read/search, and feedback. Each tool earns its place without excessive redundancy or missing core functionality.
Completeness5/5
The query_docs_filesystem tool subsumes page reading, listing, and regex search, while search_political_comms handles broad queries. The feedback tool covers reporting documentation issues. No obvious gaps exist for the domain.
Available Tools
3 toolsquery_docs_filesystem_political_commsARead-onlyIdempotentInspect
Run a read-only shell-like query against a virtualized, in-memory filesystem rooted at / that contains ONLY the Political Comms documentation pages and OpenAPI specs. This is NOT a shell on any real machine — nothing runs on the user's computer, the server host, or any network. The filesystem is a sandbox backed by documentation chunks.
This is how you read documentation pages: there is no separate "get page" tool. To read a page, pass its .mdx path to head or cat — a page at the URL path /some/page lives at /some/page.mdx. To search the docs with exact keyword or regex matches, use rg. To understand the docs structure, use tree or ls.
Paths are specific to this site — never guess them. Discover real paths with tree / -L 2, ls /, or the search tool before reading. If a path does not exist, that only means the guess was wrong; it does NOT mean the topic is undocumented — use rg -il "keyword" / to find where it is covered.
Workflow: Start with the search tool for broad or conceptual queries like "how to authenticate" or "rate limiting". Use this tool when you need exact keyword/regex matching, structural exploration, or to read the full content of a specific page by path.
Supported commands: rg (ripgrep), grep, find, tree, ls, cat, head, tail, stat, wc, sort, uniq, cut, sed, awk, jq, plus basic text utilities. No writes, no network, no process control. Run --help on any command for usage.
Each call is STATELESS: the working directory always resets to / and no shell variables, aliases, or history carry over between calls. If you need to operate in a subdirectory, chain commands in one call with && or pass absolute paths (e.g., cd /some-directory && ls or ls /some-directory). Do NOT assume that cd in one call affects the next call.
Examples (replace the placeholder paths with real ones from tree or search):
tree / -L 2— see the top-level directory layoutrg -il "rate limit" /— find all files mentioning "rate limit"rg -C 3 "apiKey" /some-directory/— show matches with 3 lines of context around each hithead -80 /some/page.mdx— read the top 80 lines of a specific pagehead -80 /page-one.mdx /page-two.mdx /section/page-three.mdx— read multiple pages in one callcat /some/page.mdx— read a full page when you need everythingcat /openapi/api-reference/openapi.json | jq '.paths | keys'— list OpenAPI endpoints
OpenAPI specs for this site are mounted at: /openapi/api-reference/openapi.json. Use them to answer questions about endpoints, request/response schemas, parameters, and authentication.
Output is truncated to 30KB per call. Prefer targeted rg -C or head -N over broad cat on large files. To read only the relevant sections of a large file, use rg -C 3 "pattern" /path/file.mdx. Batch multiple file reads into a single head or cat call whenever possible.
When referencing pages in your response to the user, convert filesystem paths to URL paths by removing the .mdx extension. For example, /some/page.mdx becomes /some/page.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | A shell command to run against the virtualized documentation filesystem (e.g., `rg -il "keyword" /`, `tree / -L 2`, `head -80 /path/file.mdx`). |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context beyond them: it is a sandbox, not a real machine; there is no network or process control; each call is stateless; output is truncated to 30KB; and paths must be discovered rather than guessed. 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?
Although long, the description is dense and every section earns its place: safety model, command list, statelessness warning, path resolution, usage examples, OpenAPI mount, truncation, and URL conversion. It is well-structured with bold headers and a front-loaded summary of what the tool is.
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 single-parameter shell-like tool with no output schema, the description is remarkably complete: it covers supported commands, safety boundaries, state behavior, path discovery, file-to-URL conversion, OpenAPI location, output limits, and batching guidance. There are no critical gaps for an agent to call it correctly.
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?
The single `command` parameter has a good schema description, but the tool description goes far beyond it with supported command lists, path conventions (.mdx mapping), statelessness guidance, chaining with `&&`, and concrete examples. This meaningfully enriches the parameter semantics.
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 opens with a precise verb and resource: 'Run a read-only shell-like query against a virtualized, in-memory filesystem rooted at `/`' containing only Political Comms docs and OpenAPI specs. It explicitly distinguishes itself from a real shell, and by naming search_political_comms as the broad-search sibling, it makes selection obvious.
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 gives an explicit workflow: use search_political_comms for broad/conceptual queries, and use this tool for exact keyword/regex matching, structural exploration, or reading full pages. It also says to discover paths with `tree`, `ls`, or search before reading, and warns against guessing paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_political_commsSearch documentationARead-onlyIdempotentInspect
Search across the Political Comms knowledge base to find relevant information, code examples, API references, and guides. Use this tool when you need to answer questions about Political Comms, find specific documentation, understand how features work, or locate implementation details. The search returns contextual content with titles and direct links to the documentation pages. If you need the full content of a specific page, use the query_docs_filesystem tool to head or cat the page path (append .mdx to the path returned from search — e.g. a result at /some/page is read with head -200 /some/page.mdx).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag read-only, idempotent, non-destructive. The description adds context about what the search returns (contextual content with titles and links) and how to access full content, which is useful behavioral info beyond the 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?
Three dense sentences, each earning its place: purpose, usage guidance, and alternative workflow. The .mdx example is concrete and helpful without being bloated.
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?
For a single-parameter search tool with no output schema, the description covers return format and the follow-up path to the sibling tool. It doesn't mention result limits or pagination, but those are minor for this use case, so a 4.
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 the baseline is 3. The description doesn't add extra detail about the query parameter itself beyond describing what the search covers, so a 3 is appropriate.
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 action (search), the resource (Political Comms knowledge base), and the scope (code examples, API references, guides). It distinguishes itself from the sibling query_docs_filesystem by clarifying it returns search results with links, not full page content.
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?
It explicitly states when to use this tool ('when you need to answer questions about Political Comms, find specific documentation, understand how features work, or locate implementation details') and directs users to query_docs_filesystem for full page content, including the .mdx detail. This is an explicit when/when-not with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackSubmit documentation feedbackAInspect
Report a problem with this documentation site so the docs team can fix it. Use when a documentation page is incorrect, outdated, confusing, incomplete, or has a broken example. This is for feedback about the documentation content itself — not for product support requests or feedback about this tool or assistant.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The URL path of the documentation page the feedback is about (the page you were reading, without the `.mdx` extension). | |
| feedback | Yes | A clear description of the documentation issue or suggestion — what is incorrect, outdated, missing, or confusing. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a write operation (readOnlyHint=false, idempotentHint=false), and the description adds meaningful context: feedback is routed to the docs team and is scoped to documentation content. It stops short of describing what happens after submission (e.g., whether a confirmation is returned, whether it creates an issue), but it does not contradict the annotations and provides useful behavioral framing.
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?
Three sentences, all informative. The first sentence states the purpose, the second gives concrete usage criteria, and the third excludes non-documentation feedback. No filler or redundancy; the most important information is front-loaded.
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?
For a simple two-parameter tool with no output schema, the description and schema together cover the essential information: what to submit, which page, what kind of feedback, and when to use it. The only minor gap is the lack of detail about the post-submission result or confirmation behavior, which is not critical but would make it fully 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 description coverage is 100%, and the parameter descriptions already explain 'path' (URL path without .mdx extension) and 'feedback' (clear description of the issue). The tool description reinforces the kind of feedback expected but adds no technical semantics beyond the schema, so the baseline score of 3 is appropriate.
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's function: 'Report a problem with this documentation site so the docs team can fix it.' It identifies the specific resource (documentation site) and the action (reporting a problem), and it distinguishes itself from the sibling query/search tools by being feedback-oriented. It also explicitly carves out what it is not for: product support or feedback about the tool/assistant.
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 gives explicit when-to-use guidance: 'Use when a documentation page is incorrect, outdated, confusing, incomplete, or has a broken example.' It also provides a clear when-not-to-use boundary: 'not for product support requests or feedback about this tool or assistant.' This is strong, actionable usage direction.
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 update
- Changed
submit_feedback1 field changed- changed
Input schema / properties / path / descriptionPrevious value: -"The documentation page path the feedback is about (e.g., the page you were reading, such as `/quickstart`)."New value: +"The URL path of the documentation page the feedback is about (the page you were reading, without the `.mdx` extension)."
3 tool updates
- Changed
query_docs_filesystem_political_comms1 field changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"
- Changed
search_political_comms1 field changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"
- Changed
submit_feedback1 field changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"
Related MCP Connectors
Read-only MCP server for the OrchestKit docs: full-text search + Markdown fetch. No auth.
Search and retrieve published Alkemata articles, pages, and guidance through a read-only MCP server.
MCP server for querying Forkast documentation
Search and read the public Applivery docs (MDM & app distribution). Read-only, no auth.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceMCP server that exposes one or more documentation folders (Markdown, MDX, TXT) to AI agents, enabling listing, reading, and searching of documentation files.-
- AlicenseAqualityCmaintenanceServes Neo-MoFox official documentation to MCP clients, enabling searching, listing, and reading docs via tools and resources.3MIT
- FlicenseAqualityCmaintenanceEnables MCP-compatible clients to search and read local markdown documentation, allowing agents to retrieve relevant doc snippets or full files by path.2-
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.