This server lets you search and read verbatim text from Terry Bouricius's book Democracy Without Politicians: Government By the People — returning only the author's actual words, never AI-generated summaries or paraphrasing.
Get book metadata (get_book_info): Retrieve the title, author, license, a free-copy link, and full table of contents.
List all chapters (list_chapters): Browse all 17 chapter numbers and titles.
Read full chapter text (get_chapter): Fetch verbatim chapter text by number (1–17) or title substring, with pagination support.
Search the book (search_content): Run keyword searches across the entire book and get back the most relevant verbatim paragraphs with their chapter source.
Explore key principles (get_principles): Access 12 curated entry points into the book's core arguments, each with a verbatim excerpt and chapter reference.
Understand the multi-body sortition design (get_multi_body_design): Retrieve verbatim descriptions of all seven specialized randomly-selected bodies in Bouricius's governance design from Chapter 16 (e.g., Agenda Council, Policy Juries, Oversight Councils).
Look up terminology: Get a list of ~20 key terms or find the verbatim passage where a specific term is introduced.
Discover real-world cases: Find real-world examples cited by the author (e.g., Athens, Ostbelgien), each with a verbatim excerpt.
Every response includes attribution to the author and guarantees only his exact words.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Democracy Without Politicians MCP What does Bouricius say about sortition?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A "search and read the book" MCP server for Terry Bouricius, Democracy Without Politicians: Government By the People (Routledge, 2026).
The book is CC BY-NC-ND 4.0 (Open Access — free copy at Taylor & Francis). The author, Terry Bouricius, gave express permission (2026-06-23) to build a question-and-answer / indexing tool over it, on one condition:
"the search tool find relevant text within the book, and display my actual words, rather than AI-generated summaries."
This server is built to honour exactly that. Every tool returns verbatim passages from the book — nothing is summarised or paraphrased:
search_content, get_chapter return the book's text directly.
get_principles and get_multi_body_design are curated entry points: a short topic/body label (navigation only) plus a verbatim excerpt the server retrieves from the book at request time. The labels orient you; the substance is always Bouricius's own words.
Every response carries attribution to the author.
If you build on this, keep that contract: surface his text, attribute him, and never present paraphrase as his words.
Related MCP server: french-politics-mcp
Tool | Returns |
| Title, author, license, free-copy link, table of contents |
| The 17 chapters (numbers + titles) |
| A chapter's verbatim text by number (1–17) or title (paginated) |
| Keyword search → the most relevant verbatim paragraphs + chapter |
| 12 key topics, each with a verbatim excerpt and its chapter |
| The seven bodies of the multi-body sortition design (Ch 16), each with a verbatim excerpt |
| ~20 terms he coins or relies on (index) |
| The verbatim passage where he introduces a given term |
| Real-world examples he cites (Athens, Ostbelgien, BC, Paris, Oregon, Fishkin, …), each with a verbatim excerpt |
| A chapter's verbatim anchor passages |
Every tool returns Bouricius's own words; the topic/term/case labels are navigation only. A build test (scripts/verify-enrichment.mjs) asserts every excerpt any tool can return is a verbatim substring of the book.
git clone https://github.com/zhiganov/democracy-without-politicians-mcp
cd democracy-without-politicians-mcp
npm install
npm run gen # (re)generate src/book-data.ts — optional; the text is already committed
npm run build # tsc -> dist/
node scripts/smoke.mjs # end-to-end tool test
node scripts/verify-rework.mjs # dump the retrieved verbatim excerpts to eyeballIt's hosted — no clone, no Node, no build. Point your client at the remote server.
Claude Code (user scope — works from any directory):
claude mcp add --transport http -s user democracy-without-politicians https://democracy-without-politicians-mcp-production.up.railway.app/mcpClaude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"democracy-without-politicians": {
"url": "https://democracy-without-politicians-mcp-production.up.railway.app/mcp",
"transport": "http"
}
}
}Restart the client after adding.
Clone and build (see Build above), then register the local stdio server:
claude mcp add democracy-without-politicians -s user -- node "<abs-path>/dist/index.js"Or in claude_desktop_config.json:
{
"mcpServers": {
"democracy-without-politicians": {
"command": "node",
"args": ["<abs-path>/dist/index.js"]
}
}
}"What's Bouricius's case that election reform can't fix democracy?"
"Show me what the book says about Review Panels vs Policy Juries."
"What does the book say about objections to sortition?"
"Pull the passage where he describes the Rules Council."
Democracy Without Politicians: Government By the People by Terrill "Terry" Bouricius (Routledge, 2026), CC BY-NC-ND 4.0 (Open Access). This tool is shared with the author's express permission (2026-06-23) and displays verbatim text only.
Dual-licensed (see LICENSE + NOTICE): the server code is MIT; the embedded book text in src/book-data.ts remains © Terry Bouricius under CC BY-NC-ND 4.0 — non-commercial, with attribution, no derivatives of the text. Generated with the book-power pipeline.
Title, author, license, free-copy link, usage note, and table of contents of Democracy Without Politicians by Terry Bouricius.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description lists returned content but does not disclose behavioral traits like read-only or side effects; no annotations to supplement.
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?
Single sentence, front-loaded with key info, no wasted words.
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 param-less tool returning fixed book info, the description fully covers the output contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100%, so description adds no param info; baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns title, author, license, etc. for a specific book, distinguishing it from siblings that cover chapters, designs, principles, etc.
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?
Usage is implied as retrieving book info, but no explicit when-to-use or alternatives among siblings are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a chapter's verbatim text by number (1-17) or title substring. Long chapters paginate via offset/nextOffset.
| Name | Required | Description | Default |
|---|---|---|---|
| number | No | Chapter number 1-17 | |
| title | No | A substring of the chapter title | |
| offset | No | Character offset to start from (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It mentions pagination via offset/nextOffset, which is useful, but does not disclose behavior when both number and title are provided, or when neither is provided. It also lacks details on error handling or text formatting.
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, front-loaded with the core purpose, and immediately followed by the pagination detail. No wasted words; every phrase 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?
Despite having no output schema and no annotations, the description covers the basic retrieval functionality and pagination. However, it lacks information on required parameters (none required, but likely number or title should be supplied), conflict resolution when both are given, and case sensitivity of title matching. This leaves room for ambiguity.
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 already provides clear descriptions for all 3 parameters (100% coverage). The description adds minimal value beyond the schema: it confirms the range for number and that offset is used for pagination. This is adequate but does not significantly augment the schema.
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 returns a chapter's verbatim text, specifying the two identification methods (number or title substring). It effectively distinguishes from sibling tools like list_chapters, which lists chapters, and search_content, which searches across content.
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 implies usage via number or title but does not explicitly say when to prefer this tool over siblings, nor does it mention when not to use it. For example, it doesn't clarify that get_chapter is for retrieving full text while list_chapters is for listing titles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bouricius's signature 'multi-body sortition' reference design (Chapter 16): the seven specialised randomly-selected bodies (Agenda Council, Interest Panels, Review Panels, Policy Juries, Coordination Council, Rules Council, Oversight Councils), each with a VERBATIM excerpt from the book.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that it returns verbatim excerpts from the book, which is transparent about content. However, it does not mention any safety or side effects, though none are expected for a simple read 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 a single sentence that efficiently conveys the tool's purpose and enumerates the bodies. It is front-loaded with the core concept. Could be slightly more concise but carries necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is complete enough. It tells exactly what is returned (the design with excerpts). No additional context seems necessary for this simple 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?
There are zero parameters, so per the baseline rule, the score is 4. The description adds no param-specific meaning because none exist, and schema coverage is trivially 100%.
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 Bouricius's specific 'multi-body sortition' reference design from Chapter 16, listing all seven specialized bodies. This precisely distinguishes it from siblings like get_chapter (which returns chapter content broadly) or get_principles.
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 implies the tool is used to retrieve that specific design, but does not explicitly state when to use it versus alternatives, nor provides any conditions or exclusions. Usage is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Key topics/arguments in the book as curated entry points. Each returns a VERBATIM excerpt in the author's own words plus its chapter — not a summary. Use get_chapter or search_content to read further.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It discloses that the tool returns a verbatim excerpt and chapter, not a summary, which is transparent about the output format. However, it does not mention any potential limitations such as number of entries or pagination, but given the lack of parameters, this is minor.
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 extremely concise with two sentences. The first sentence states the purpose and scope, the second adds specific details about output format and suggests alternative tools. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is fully complete. It explains what the tool does, what it returns, and how it relates to sibling tools, requiring no additional context for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the input schema provides no information beyond type object with no properties. The description adds no parameter-specific meaning, but according to the rule for 0 parameters, baseline is 4. The description compensates by explaining the output instead.
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 'returns' and the resource 'key topics/arguments in the book' with a specific scope 'curated entry points'. It further distinguishes from siblings by noting that it provides verbatim excerpts with chapter references, not summaries, and directs to get_chapter or search_content for further reading.
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 advises using get_chapter or search_content to read further, providing clear guidance on when to choose alternatives. While it does not explicitly state when not to use this tool, the context is clear that this is for curated entry points and not for full text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all 17 chapters with their numbers and titles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides the fixed number of chapters (17) and notes the output fields (numbers and titles), which adds transparency beyond no annotations. However, it does not disclose ordering, performance, or read-only behavior.
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 a single, front-loaded sentence that conveys all necessary information without waste. Every sentence earns its place.
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, the description adequately explains what is returned. It lacks details like ordering, but for a fixed list of 17 items, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since there are no parameters and schema coverage is 100%, the description adds value by specifying the output format (numbers and titles). Baseline with 0 params is 4, and the description meets this.
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 action ('list all 17 chapters') and the specific resource ('chapters'). It distinguishes from siblings like 'get_chapter' by implying a full listing versus a single retrieval.
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 does not explicitly state when to use this tool versus alternatives. However, the sibling tool names imply that this is for a complete list, while 'get_chapter' is for a specific chapter. No explicit guidance on context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across the full book text; returns the most relevant verbatim paragraphs with their chapter. Use for 'what does Bouricius say about X' questions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms | |
| limit | No | Max results (default 8, max 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description bears full burden. It discloses that it returns 'most relevant verbatim paragraphs with their chapter', but does not explain relevance ranking, case sensitivity, or supported operators. It is adequate but not thorough.
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: first covers purpose and output, second gives a usage hint. No unnecessary words. 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 simple search tool with no output schema, the description adequately explains return values (verbatim paragraphs and chapter). It could mention result limits or sorting, but the mention of 'most relevant' covers ranking. Minor gaps in full transparency.
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 100% for both parameters 'query' and 'limit', so the description adds marginal value. It contextualizes the result as 'most relevant verbatim paragraphs', which enhances understanding beyond schema descriptions.
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 uses specific verb 'search' and resource 'full book text', and specifies the output 'most relevant verbatim paragraphs with their chapter'. It also provides an example use case, clearly distinguishing it from sibling tools like get_chapter or list_chapters.
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 states when to use: 'Use for what does Bouricius say about X questions.' It does not mention when not to use or alternatives, but the sibling tools context and the clear purpose provide implicit guidance. Still, explicit exclusion could improve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0get_book_infoget_chapterget_multi_body_designget_principleslist_chapterssearch_contentScored across 6 tools
Each tool has a distinct purpose: metadata retrieval, chapter access, specific design explanation, topic-based excerpts, chapter listing, and full-text search. No overlap in functionality.
All tools follow a verb_noun pattern (get_*, list_*, search_*), with consistent use of underscores and descriptive nouns. No mixing of conventions.
Six tools cover the essential operations for a book reference server: metadata, chapter access, topic exploration, and search. The count is neither too sparse nor excessive.
The tool set provides full navigation: metadata, chapter listing, verbatim chapter content, curated principle excerpts, and keyword search. No obvious gaps for accessing the book's content.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read and search exact public source URLs with stable paragraph citations.
Complete classical & world literature — search + cite exact passages, facing sources, 50+ languages.
Read-only semantic search over Vedic scripture verses, commentaries, and recorded lectures.
Search Ellen G. White’s writings by keyword to surface relevant quotations. Retrieve exact passage…
