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., "@MCP Document & Task Server Find the Q1 report"
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.
Example Model Context Protocol (MCP) servers from the Medium article The Model Context Protocol (MCP): Fundamentals, Real-World Applications, and Building AI Agent Integrations.
Two self-contained MCP servers that any compatible AI host (Claude Desktop, Cursor, or a custom agent) can discover and use automatically.
server.py -- Document database with three tools:
search_documents(query) -- search documents by title
get_document(doc_id) -- retrieve a document by ID
create_document(title, content, author) -- create a new document
task_server.py -- Task tracker with two tools:
search_tasks(query) -- search tasks by title keyword
get_tasks_by_status(status) -- get tasks by status (todo, in_progress, done)
Related MCP server: Task Manager MCP Server
# Clone the repo
git clone https://github.com/deepujain/mcp-doc-server.git
cd mcp-doc-server
# Create virtual environment and install dependencies
uv venv
source .venv/bin/activate
uv sync# Document server
mcp dev server.py
# Task tracker (in a separate terminal)
mcp dev task_server.pyThe Inspector opens in your browser. Click Tools > List Tools, select a tool, fill in the input, and hit Run Tool.
Add to .cursor/mcp.json in your project root:
{
"mcpServers": {
"document-db": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-doc-server", "run", "server.py"]
},
"task-tracker": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-doc-server", "run", "task_server.py"]
}
}
}Replace /path/to/mcp-doc-server with the actual path. Restart Cursor, then ask in agent chat:
"Find the Q1 report and summarize it"
"What tasks are in progress?"
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"document-db": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-doc-server", "run", "server.py"]
},
"task-tracker": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-doc-server", "run", "task_server.py"]
}
}
}Restart Claude Desktop. The tools appear automatically.
Python 3.10+
UV package manager
MIT
Create a new document in the database.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| author | Yes | ||
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the action without mentioning whether creation is idempotent, requires permissions, or has side effects.
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 too short and under-specified. It lacks essential information and is not appropriately sized for a tool with three required parameters.
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 has three required parameters and no output schema, the description should explain parameter usage or return values. It does not, leaving the tool incomplete for an agent.
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 0%, meaning the description adds no meaning to the three parameters (title, content, author). It fails to compensate for the lack of parameter documentation.
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-resource pair ('Create a new document') and clearly distinguishes from sibling tools 'get_document' and 'search_documents', which involve reading or searching.
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 gives no guidance on when to use this tool, prerequisites, or when not to use it. No alternatives or usage context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a document by its ID. Returns the full document including content.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves a document and returns its content, but does not disclose any permissions, side effects, rate limits, or limitations. However, it correctly implies a read-only operation without contradiction.
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 no wasted words. The description is front-loaded with the core action and immediately clarifies the return value. Every sentence serves a purpose.
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 tool with one parameter and no output schema, the description adequately covers what it does and what it returns. It explains the return value as 'full document including content', which compensates for the lack of output schema.
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% schema description coverage, the description must add meaning. It states 'by its ID' connecting the single parameter 'doc_id' to the operation, but provides no additional constraints, format, or examples beyond the schema's string type.
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 'Retrieve' and the resource 'document by its ID', and specifies the result includes full content. It distinguishes itself from sibling tools 'create_document' and 'search_documents' by focusing on retrieval by ID.
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 when you have a document ID, but lacks explicit guidance on when to use alternatives like 'search_documents' for queries or 'create_document' for new documents. No mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search documents by title. Returns matching document IDs and titles.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially fills the gap by stating the return format (IDs and titles) and implying a read-only operation. However, it does not mention pagination, sorting, or any side effects.
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 brief and to the point, with two sentences that convey the essential action and expected output. No unnecessary text.
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 presence of an output schema (not detailed here), the description is adequate for a simple search tool. However, it could improve by clarifying the query format or scope, especially with no annotations.
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 description says 'by title' but the only parameter is named 'query' with no further description. Schema coverage is 0%, so this adds minimal meaning beyond the parameter name itself.
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 ('Search') and the resource ('documents'), and the phrase 'by title' adds specificity. It is distinct from sibling tools create_document and get_document.
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 guidance is given on when to use this tool vs alternatives, nor any exclusions or recommendations. The agent must infer that search is for retrieval versus creation or singular access.
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. Dates show when Glama detected each change.
v0.1.0create_documentget_documentsearch_documentsEach tool has a clearly distinct purpose: create, retrieve by ID, and search by title. There is no ambiguity between them.
All tools follow a consistent verb_noun pattern in snake_case (create_document, get_document, search_documents), making naming predictable.
With only 3 tools, the server feels minimal for a 'Document & Task Server'. The count is borderline low but not excessively so.
The tool set lacks update and delete operations for documents, and entirely omits task-related functionality despite the server name. This creates significant gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent docs and memory for AI agents — read, write, organize & search a shared workspace.
AI-native task management: list, create, update and archive tasks with rich context for AI agents
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Ingest, manage, and retrieve documents for RAG-powered AI applications
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/deepujain/mcp-doc-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
