Provides tools for managing and editing documents, including a dedicated prompt template for formatting document content into Markdown.
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., "@Document MCP Server List all documents and read the content of deposition.md"
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 simple MCP (Model Context Protocol) server and MCP client for managing documents using FastMCP.
Tools:
read_doc_contents: Read the contents of a document.
edit_document: Edit a document by replacing text.
return all the docs: List all document IDs.
Resources:
docs://documents: JSON list of document IDs.
docs://documents/{doc_id}: Plain text content of a specific document.
Prompts:
format_to_md: Prompt template for formatting documents to Markdown.
Related MCP server: DevDocs MCP
Python 3.12 or higher
uv (Python package manager and project manager)
Ensure you have Python 3.12+ installed.
Install uv if not already installed:
pip install uvClone or download this project to your local machine.
Navigate to the project directory:
cd "path/to/mcp server"Create a virtual environment and install dependencies:
uv syncTo run the MCP server in development mode:
uv run mcp dev mcp_server.pyThe server runs on stdio transport, suitable for MCP clients.
Test client is provided in mcp_client.py to verify the server works.
To test:
In one terminal, start the server:
uv run python mcp_server.pyIn another terminal, run the test client:
uv run mcp_client.pyThis will connect to the server and list the available tools, printing them to the console.
For more advanced testing, you can modify mcp_client.py to call specific tools, read resources, or get prompts.
Example: To read a document content, you could add code like:
# Inside the async main function
doc_content = await client.call_tool("read_doc_contents", {"doc_id": "deposition.md"})
print(doc_content)mcp_server.py: The main MCP server implementation.
mcp_client.py: A test client for interacting with the server.
pyproject.toml: Project configuration and dependencies.
The server uses an in-memory dictionary for documents. Changes are not persisted.
Ensure the virtual environment is activated when running Python commands.
Edit a document by replacing a string in the documents content with a new string.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes | Id of the document that will be edited | |
| old_str | Yes | The text to replace. Must match exactly, including whitespace. | |
| new_str | Yes | The new text to insert in place of the old text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states 'replacing a string' without indicating whether it replaces all occurrences, behavior on missing string, or side effects like auto-save. Missing important mutation details.
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 is concise and front-loaded with the essential action and resource. 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 simple edit tool with fully documented parameters, the description is adequate but lacks details on error handling (e.g., what if old_str not found) and whether it replaces all occurrences or just the first.
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%, and the description adds value by clarifying that old_str must match exactly including whitespace. This goes beyond the schema's basic 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 clearly states the action (edit), resource (document), and method (string replacement). It effectively distinguishes from the sibling tool 'read_doc_contents' which is read-only.
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 vs alternatives. While the sibling tool name implies a read vs. edit distinction, no further guidance is provided on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents of a document and return it as a string.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes | Id of the document to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does state the output behavior ('return it as a string'), but does not mention error handling, permissions, or what happens when the document does not exist. For a simple read operation, this 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?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys both the operation and the return format.
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?
This is a simple tool with one parameter, full schema coverage, and no output schema. The description is largely complete for a read operation, especially since it explicitly states the return type. It could be slightly stronger with error or permission context, but nothing essential is missing for basic 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 schema already fully documents the only parameter, doc_id, as 'Id of the document to read', so schema coverage is 100%. The description adds no additional parameter meaning beyond the schema, matching the baseline score.
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 states a specific verb and resource: 'Read the contents of a document' and explicitly notes the return type as a string. This clearly distinguishes it from the sibling 'edit_document', which implies modification rather than 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 verb 'Read' establishes a clear context for when this tool is appropriate, and its contrast with 'edit_document' implies read-only usage. However, it does not explicitly state when not to use it or name the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a list of all the document ids.
| 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 burden. It states what the tool returns but doesn't disclose behavioral aspects like whether this is a read-only operation, potential performance implications for large document sets, pagination behavior, or authentication requirements.
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, zero waste. Every word contributes directly to understanding the tool's purpose without any redundant information.
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 list operation with no parameters, the description is adequate but minimal. Without annotations or output schema, it doesn't address important behavioral context like whether this returns a complete list or requires pagination, or what format the IDs are in.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description correctly indicates no parameters are needed ('all the document ids'), which aligns perfectly with the empty input 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 verb ('return') and resource ('list of all the document ids'), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'read_doc_contents', but the focus on IDs rather than contents provides implicit distinction.
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?
No explicit guidance on when to use this tool versus alternatives like 'read_doc_contents' or 'edit_document'. The description implies it returns IDs only, but doesn't state when that's preferable over fetching full document contents.
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.0edit_documentread_doc_contentsreturn all the docsScored across 3 tools
Each tool has a clearly distinct purpose: edit_document modifies content, read_doc_contents retrieves content, and return all the docs lists document IDs. There is no overlap in functionality, making tool selection unambiguous for an agent.
The naming is inconsistent with mixed conventions: edit_document uses snake_case with a verb_noun pattern, read_doc_contents uses snake_case but abbreviates 'document' inconsistently, and return all the docs uses a sentence-like format with spaces and no clear pattern. This lack of uniformity could confuse agents.
With only 3 tools, the set feels thin for a document management server, as it lacks operations like creating or deleting documents. While the tools cover basic read, list, and edit functions, the scope is limited and may require workarounds for full document lifecycle management.
There are significant gaps in the tool surface for document management: no create_document or delete_document tools, and missing operations like search or metadata updates. This incomplete coverage will likely cause agent failures when trying to perform common document workflows beyond reading, listing, and editing.
Markdown workspace for AI agents: read, write, organize, and share markdown documents.
Share HTML/Markdown documents via URL instantly. Create, edit, delete docs from any AI tool.
Publish and share access-controlled Markdown documents from any MCP-enabled AI tool.
Ingest, manage, and retrieve documents for RAG-powered AI applications
