Click on "Deploy 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., "@Ask Lao Tzu MCP Give me a reflection on uncertainty from the Tao Te Ching."
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.
Ask Lao Tzu MCP is a small, source-aware Model Context Protocol server for the 81 chapters of the Tao Te Ching. It gives an AI client structured access to the classical Chinese text, James Legge's 1891 public-domain translation, chapter search, practical reading paths, and gentle reflection prompts.
The project is deliberately modest: it is a reading companion, not an oracle. Tools return source material and invitations to think; they do not claim to settle translation disputes, diagnose a person, or make high-stakes decisions on a user's behalf.
get_chapter: Chinese text, Legge translation, line pairs, a stable chapter URL, and the original chapter title.
search_chapters: local full-text search across the title and both source languages.
get_reflection: a topic- or chapter-aware prompt with source chapter references.
list_topics: useful reading paths such as leadership, uncertainty, simplicity, and relationships.
Related MCP server: Yijing Bazi MCP Server
npm install
npm run build
node dist/index.jsFor development, use npm run dev. The server speaks MCP over stdio, so it can be added to any compatible desktop client. An example client configuration is in docs/CLIENT_CONFIG.md.
Point the client at the absolute path to dist/index.js and use node as the command. Keep the server local unless you have deliberately added authentication and transport controls.
The Chinese received text and James Legge translation are included for reading and research. James Legge's 1891 translation is public domain. See docs/SOURCES.md for provenance and the limits of the dataset. The software is MIT licensed; the text dataset carries its own public-domain attribution.
The companion website is asklaotzu.com/tao. It offers a browsable bilingual reading experience, but the MCP server remains useful offline.
For reproducible data work, pair this server with the companion Tao Te Ching Open Data repository.
Read one Tao Te Ching chapter with Chinese text, James Legge public-domain translation, and line pairs. Use this when a user asks about a chapter or wants a source-aware reading.
| Name | Required | Description | Default |
|---|---|---|---|
| chapter | Yes | Chapter number from 1 to 81 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'Read' signals a non-mutating operation, and the listing of content components gives a sense of the return payload. Still, it does not address error behavior, edge cases, or access constraints, so it is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the core action and content in the first sentence and usage context in the second. Every part earns its place and there is no filler or redundant wording.
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 single-parameter read tool with no output schema, the description covers the return contents and offers usage guidance. It could be slightly more explicit about when to prefer sibling tools, but the information necessary to call and interpret the result is present.
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 schema describes the sole parameter (chapter, 1–81) with 100% coverage. The description adds conversational context ('Tao Te Ching chapter') but no extra syntax or semantics beyond the schema, so the baseline of 3 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?
The description uses a specific verb ('Read') and resource ('one Tao Te Ching chapter'), and enumerates the content components (Chinese text, Legge translation, line pairs). It is clearly distinct from sibling tools like search_chapters or list_topics, which focus on discovery rather than full-chapter 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?
It explicitly states when to use the tool: 'when a user asks about a chapter or wants a source-aware reading.' However, it does not mention when not to use it or name alternatives such as search_chapters for finding verses, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a grounded reflection prompt connected to one or more chapters. The prompt invites agency and does not diagnose or replace professional care.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional topic such as letting-go, leadership, or relationships | |
| chapter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds a useful boundary that the prompt does not diagnose or replace professional care, but it does not explain how chapters are matched, what 'grounded' means, or whether output is deterministic.
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 efficiently written sentences with no wasted words. The core action is front-loaded)Skip, and the safety caveat 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?
Reasonable for a simple tool with two optional parameters, but ambiguity remains about how a single chapter parameter maps to 'one or more chapters,' and with no output schema the return value is only broadly described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; the description mentions 'one or more chapters' but the schema only provides a single integer chapter parameter. It does not explain how topic and chapter interact or what each contributes, adding minimal meaning beyond 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?
States a specific verb ('Return') and resource ('grounded reflection prompt') connected to chaptersinates it from siblings like get_chapter or search_chapters by focusing on reflection prompts, though it does not explicitly name any sibling.
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?
Implies usage for generating reflection prompts tied to chapters, but gives no explicit when-to-use, when-not-to-use, or alternatives. The context is clear, but no exclusion criteria or selection guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List practical Tao reading paths and their chapter numbers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description carries the burden of behavioral disclosure. It accurately describes a read/list operation (no state change implied). However, it doesn't disclose details like whether paths are fixed/canonical, whether the list includes all paths or is paginated, or whether the result includes only chapter numbers or additional metadata such as titles. Without annotations, more behavioral context would be valuable.
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?
One sentence with no filler. It front-loads the action (list) and the object (practical Tao reading paths) and adds the relevant detail (chapter numbers). No redundant wording.
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 parameterless list tool with no output schema, the description is fairly complete: it states the resource type and what information is included. It could clarify whether the output is a flat list or structured, but given the simplicity (0 params, no schema), the description is sufficient 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description's mention of the output (reading paths and their chapter numbers) is the main information an agent needs. Baseline for 0 params is 4, and the description adequately explains what the tool returns.
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?
States a clear verb and resource: 'list' Tao reading paths with chapter numbers. It distinguishes itself from siblings like get_chapter (single chapter retrieval) and search_chapters (search) by indicating it returns reading paths – curated collections of chapters. However, it doesn't explicitly name the siblings it is not.
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?
Implied usage: this tool lists reading paths, so an agent would use it before reading chapters or to get a high-level overview of practical Tao paths. It doesn't explicitly state when not to use it or name alternatives like search_chapters, but the purpose is reasonably inferable from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find chapters by a word or phrase in the title, Chinese text, or Legge translation. This is a lightweight local search, not a claim about canonical interpretation.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search phrase |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that the search is local, lightweight, and not a statement about canonical interpretation, which is useful framing. However, it omits practical behavior such as match semantics, result shape, ordering, or limits, leaving significant room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core purpose is front-loaded, and the caveat in the second sentence is concise and relevant. No sentence is wasted.
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 single-parameter, search-oriented tool, the description is adequate but not complete. It lacks any mention of what a result looks like, since there is no output schema, and does not explain pagination, matching behavior, or limits. The agent can invoke it correctly but may not know how to interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the sole parameter is 100%, so the baseline is 3. The description adds meaningful value by clarifying that the query can be a 'word or phrase' and by naming the fields the query applies to, going beyond the schema's bare 'Search phrase'.
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 a specific verb ('Find'), names the resource ('chapters'), and enumerates the searchable fields (title, Chinese text, Legge translation). This clearly distinguishes the tool from the sibling point-lookup tools, and the caveat about not claiming canonical interpretation further scopes its purpose.
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?
It provides context by calling this a 'lightweight local search', which implies a use case distinct from heavyweight or interpretive tools. However, it does not explicitly say when to use this versus get_chapter, get_reflection, or list_topics, nor does it state when not to use it. Basic context exists but no clear alternative routing.
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.1.0get_chapterget_reflectionlist_topicssearch_chaptersScored across 4 tools
Each tool targets a distinct action: reading a specific chapter, searching across texts, generating a reflection, and listing reading paths. There is no functional overlap between any of the four tools.
All tool names follow a consistent verb_noun pattern: get_chapter, search_chapters, get_reflection, list_topics. The verbs are specific and uniform, making the API predictable.
Four tools is well-scoped for a focused Tao Te Ching reading assistant. Each tool serves a clear purpose without unnecessary surface area or missing essential operations.
The tool set covers the core needs of the domain: retrieving chapters, searching content, guided reflection, and topical navigation. There are no obvious dead ends or missing lifecycle steps for the stated purpose.
Read, search and cite all 81 chapters of the Tao Te Ching, with per-rendering attribution.
I-Ching (周易) oracle: cast a hexagram, read classical commentary, get a reflection. Bilingual.
Search 15K rare pre-modern texts translated to English: philosophy, religion, science, literature.
Read released episodes, transcripts, citations, clips, reading trails, and flashcards.
