Open MCP Server
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., "@Open MCP Serversummarize the document at /home/user/reports/q3_summary.txt"
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.
Open MCP Server
A modular Model Context Protocol (MCP) server with Prompts, Skills, and Workflows for personal productivity automation.
Features
Core Components
6 Prompt Templates - Reusable, parameterizable prompts for common tasks
11 Skills - Pre-defined task sequences that compose multiple tools
9 Workflows - Multi-step automation pipelines with conditionals and loops
15+ Tools - File operations, web scraping, git operations, system info, and AI summarization
Categories
Productivity: Daily planning, task prioritization, briefings
Development: Code review, project setup, refactoring guidance
Research: Topic exploration, document summarization
Document: File analysis, text summarization, word counting
Quick Start
# Install dependencies
npm install
# Build the project
npm run build
# Start the server
npm startServer Resources
Resource | Description |
| List all prompt templates |
| Get specific prompt template |
| List all available skills |
| Get specific skill details |
| List all workflows |
| Get specific workflow details |
| Server statistics and capabilities |
Available Tools
Prompt Management
list_prompts- List all prompts (optional category filter)search_prompts- Search prompts by query stringget_prompt- Get prompt template with parametersrender_prompt- Render a prompt with parametersvalidate_prompt- Validate prompt parametersget_prompt_categories- List all prompt categories
Skills (as Tools)
summarize_document- Read and summarize a fileanalyze_text- Read and analyze textsetup_project- Initialize a new projectdaily_briefing- Get daily productivity briefingproject_status- Get project status reportAnd 6 more...
Workflow Execution
execute_workflow- Execute a workflow by ID with variables
Original Tools
File:
read_file,write_file,list_directory,search_filesWeb:
fetch_url,scrape_htmlDev:
git_status,git_log,git_diff,system_info,get_timeAI:
summarize
Configuration
Command-line Arguments
node dist/index.js /path/to/workspace /home/user/documentsEnvironment Variables
GOOGLE_GENERATIVE_AI_API_KEY- Required for AI summarization features
Usage with Conductor
Add this MCP server to Conductor:
claude mcp add open-mcp -s user -- node /Users/sdluffy/conductor/workspaces/playground/san-jose/open-mcp/dist/index.jsOr add to your conductor.json:
{
"mcpServers": {
"open-mcp": {
"command": "node",
"args": ["/Users/sdluffy/conductor/workspaces/playground/san-jose/open-mcp/dist/index.js"]
}
}
}Project Structure
open-mcp/
├── src/
│ ├── index.ts # Main entry point
│ ├── core/ # Core engines
│ │ ├── prompt-manager.ts # Prompt template management
│ │ ├── skill-executor.ts # Skill execution engine
│ │ ├── workflow-engine.ts # Workflow engine with conditionals
│ │ └── registry.ts # Central component registry
│ ├── prompts/ # Prompt templates (YAML)
│ │ ├── productivity/
│ │ ├── code/
│ │ └── research/
│ ├── skills/ # Skill definitions
│ │ ├── categories/
│ │ │ ├── document.ts
│ │ │ ├── development.ts
│ │ │ └── productivity.ts
│ │ └── skills.ts # Skill registry
│ ├── workflows/ # Workflow definitions
│ │ ├── definitions/
│ │ │ ├── daily-routine.ts
│ │ │ ├── code-review.ts
│ │ │ └── project-setup.ts
│ │ └── workflows.ts # Workflow registry
│ ├── tools/ # Original tools
│ ├── types/ # TypeScript definitions
│ └── utils/ # Utilities
└── prompts/ # YAML prompt templatesForked Dependencies
We maintain forks of key dependencies for customization:
Repository | Fork | Purpose |
MCP SDK modifications | ||
OpenAI API spec |
Contributing to Forks
Make changes in your fork
Open a PR to the upstream repository
Reference the open-mcp issue you're solving
Development
# Watch mode
npm run dev
# Build
npm run build
# Run with output
npm run dev:fullAdding New Prompts
Create a YAML file in prompts/{category}/:
id: my_prompt
name: My Prompt
description: Description
category: productivity
template: |
Your template here with {{variables}}
parameters:
- name: variable
type: string
required: trueAdding New Skills
Create a skill in src/skills/categories/{category}.ts:
export const mySkill: Skill = {
id: "my_skill",
name: "My Skill",
description: "Description",
category: "my_category",
tools: [
{ tool: "tool_name", parameters: {...} }
],
inputSchema: { type: "object", properties: {...} },
outputSchema: { type: "object", properties: {...} }
};Adding New Workflows
Create a workflow in src/workflows/definitions/{name}.ts:
export const myWorkflow: Workflow = {
id: "my_workflow",
name: "My Workflow",
description: "Description",
steps: [
{ id: "step1", type: "tool", name: "Step 1", config: {...} }
]
};Architecture
┌─────────────────────────────────────────────────────────────────┐
│ MCP Client (Claude) │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ MCP Server (stdio) │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ Tool Registry │ │
│ │ ┌───────────┐ ┌───────────┐ ┌─────────────────────┐ │ │
│ │ │ Prompts │ │ Skills │ │ Workflows │ │ │
│ │ │ (Resource)│ │ (Tools) │ │ (Tools) │ │ │
│ │ └─────┬─────┘ └─────┬─────┘ └──────────┬──────────┘ │ │
│ └────────┼─────────────┼──────────────────┼─────────────────┘ │
│ │ │ │ │
│ ┌────────┼─────────────┼──────────────────┼─────────────────┐ │
│ │ ▼ ▼ ▼ │ │
│ │ ┌─────────┐ ┌─────────────┐ ┌──────────────────┐ │ │
│ │ │ Prompt │ │ Skill │ │ Workflow │ │ │
│ │ │ Manager │ │ Executor │ │ Engine │ │ │
│ │ └────┬────┘ └──────┬──────┘ └────────┬─────────┘ │ │
│ │ │ │ │ │ │
│ │ ▼ ▼ ▼ │ │
│ │ ┌─────────────────────────────────────────────────┐ │ │
│ │ │ Existing Tools │ │ │
│ │ │ file-tools | web-tools | dev-tools | ai-tools │ │ │
│ │ └─────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘Security
Path validation with allowed directories whitelist
Command injection prevention
Timeout protection on HTTP requests
Directory traversal attack prevention
License
MIT License - see LICENSE for details
Links
Available Tools
19 toolsexecute_workflowC
Execute a workflow by ID with optional variables
| Name | Required | Description | Default |
|---|---|---|---|
| workflowId | Yes | The ID of the workflow to execute | |
| variables | No | Variables to pass to the workflow |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('execute') but doesn't describe what execution entails (e.g., side effects, permissions needed, rate limits, or response format). This leaves significant gaps for a mutation 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, efficient sentence that front-loads the core action and key details (ID and optional variables). There is no wasted text, making it appropriately concise.
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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, error handling, or how it fits with sibling tools, leaving the agent with insufficient context for reliable use.
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%, so the schema already documents both parameters ('workflowId' and 'variables'). The description adds minimal value by noting that variables are optional, but doesn't provide additional context beyond what the schema specifies.
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 ('execute') and resource ('workflow by ID'), making the purpose understandable. However, it doesn't differentiate this tool from any sibling tools (like 'fetch_url' or 'render_prompt'), which would require a more specific scope or comparison.
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 provides no guidance on when to use this tool versus alternatives, such as other workflow-related tools or similar execution tools. It mentions optional variables but doesn't explain prerequisites, context, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_urlD
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| method | No | GET | |
| headers | No | ||
| body | No | ||
| timeout | No | ||
| followRedirects | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_promptB
Get a prompt template by ID with its parameters and examples
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Prompt template ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a prompt template with parameters and examples, which implies a read-only operation, but doesn't specify error handling (e.g., what happens if the ID is invalid), authentication needs, rate limits, or return format. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence that front-loads the core purpose ('Get a prompt template by ID') and adds essential details ('with its parameters and examples'). There is no wasted wording, and it directly communicates the tool's function 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 low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and output. Without annotations or an output schema, more guidance on what 'parameters and examples' entail would improve completeness, but it's not entirely incomplete for a simple retrieval 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?
The input schema has 100% description coverage, with the single parameter 'id' documented as 'Prompt template ID'. The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline is 3, as the schema adequately handles parameter semantics without extra description.
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 ('Get') and resource ('prompt template by ID') with specific attributes ('parameters and examples'). It distinguishes from sibling tools like 'list_prompts' (which lists multiple) and 'validate_prompt' (which validates). However, it doesn't explicitly differentiate from 'render_prompt' (which might render a template), making it slightly less specific than a perfect 5.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid ID), exclusions, or comparisons to siblings like 'list_prompts' for browsing or 'search_prompts' for finding IDs. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_prompt_categoriesB
Get all available prompt categories
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get all available prompt categories' but doesn't explain what 'available' means (e.g., based on permissions), how the data is returned (e.g., format, pagination), or any side effects. For a tool with zero annotation coverage, this is insufficient.
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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential 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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It states what the tool does but lacks behavioral details like return format or usage context. For a read-only tool with no structured output, more guidance would improve completeness.
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 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it doesn't incorrectly mention any. A baseline of 4 is appropriate for a parameterless tool with full schema coverage.
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 'Get' and the resource 'all available prompt categories', making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'list_prompts' or 'search_prompts' which might also retrieve prompt-related information, so it doesn't reach the highest clarity level.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'list_prompts' or 'search_prompts', nor does it specify any prerequisites or exclusions for usage, leaving the agent with minimal context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_timeD
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | No | ||
| format | No | iso |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
git_diffD
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . | |
| cached | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
git_logD
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . | |
| maxCount | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
git_statusD
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_directoryD
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| includeHidden | No | ||
| recursive | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_promptsC
List all available prompt templates, optionally filtered by category
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists prompts with optional filtering, but doesn't describe key behaviors such as whether it returns all prompts at once or uses pagination, what the output format looks like (e.g., list of objects with fields), or any rate limits or permissions required. For a list operation with zero annotation coverage, this is a significant gap.
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, efficient sentence that front-loads the core action ('List all available prompt templates') and adds the optional filtering detail. There is no wasted text, and it's appropriately sized for the tool's complexity.
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 moderate complexity (listing with filtering), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return values, behavioral traits like pagination or permissions, or how it differs from sibling tools. This leaves gaps for an AI agent to understand the tool fully in context.
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 has 1 parameter with 100% description coverage, providing an enum for the 'category' filter. The description adds minimal value beyond the schema by mentioning 'optionally filtered by category', but doesn't elaborate on semantics like what categories mean or how filtering works. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance parameter understanding.
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 ('List') and resource ('all available prompt templates'), and mentions optional filtering by category. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_prompt_categories' or 'search_prompts', which appear to be related to prompts. The purpose is clear but lacks sibling differentiation.
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 provides no guidance on when to use this tool versus alternatives like 'get_prompt_categories' (which might list categories) or 'search_prompts' (which might search prompts). It mentions optional filtering but doesn't specify contexts or exclusions for usage, leaving the agent with no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_fileD
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| encoding | No | utf8 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_promptC
Render a prompt template with the given parameters
| Name | Required | Description | Default |
|---|---|---|---|
| templateId | Yes | The ID of the template to render | |
| parameters | Yes | Parameters for the template |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions rendering with parameters but fails to disclose behavioral traits like whether it's read-only (likely, but not stated), error handling for invalid inputs, or if it modifies any state. This leaves gaps for a tool that processes data.
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, efficient sentence that front-loads the core action ('Render a prompt template') without unnecessary details. It earns its place by clearly stating the tool's function in minimal 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?
Given the tool's complexity (involving templates and parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'render' produces (e.g., formatted text, structured data) or how errors are handled, leaving the agent with insufficient context for reliable use.
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%, so the schema already documents both parameters ('templateId' and 'parameters'). The description adds no additional meaning beyond what's in the schema, such as examples of parameter usage or template formats, resulting in a baseline score of 3.
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 the action ('Render') and resource ('a prompt template'), but it's vague about what rendering entails (e.g., filling placeholders, generating text). It distinguishes from siblings like 'get_prompt' or 'validate_prompt' by implying transformation rather than retrieval, but lacks specificity about the output format or 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?
No guidance is provided on when to use this tool versus alternatives like 'get_prompt' (for raw templates) or 'execute_workflow' (for broader automation). The description implies usage with templates and parameters but doesn't specify prerequisites, such as needing an existing template ID from 'list_prompts'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scrape_htmlD
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| extractText | No | ||
| extractLinks | No | ||
| extractImages | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_filesD
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| pattern | Yes | ||
| excludePatterns | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_promptsC
Search for prompt templates by query string
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('search') but doesn't describe what 'search' entails—such as whether it returns partial matches, supports pagination, or has performance characteristics. For a search tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's function without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 lack of annotations and output schema, the description is incomplete for a search tool. It doesn't explain what the search returns (e.g., a list of templates, metadata), how results are structured, or any limitations. For a tool with no structured output information, this leaves critical gaps for the 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?
The input schema has 100% description coverage, with the 'query' parameter documented as 'Search query'. The description adds no additional meaning beyond this, such as examples or format details. Since the schema does the heavy lifting, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('search') and resource ('prompt templates') with the method ('by query string'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'list_prompts' or 'get_prompt', which appear to be related to prompt operations, so it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives like 'list_prompts' or 'get_prompt'. It mentions searching by query string, but doesn't specify scenarios, prerequisites, or exclusions, leaving the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarizeD
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| maxLength | No | ||
| language | No | en |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
system_infoD
| Name | Required | Description | Default |
|---|---|---|---|
| include | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_promptB
Validate parameters against a prompt template without rendering
| Name | Required | Description | Default |
|---|---|---|---|
| templateId | Yes | The ID of the template | |
| parameters | Yes | Parameters to validate |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool validates parameters but doesn't describe what validation entails (e.g., checking required fields, data types, constraints), what happens on success/failure (e.g., returns validation errors, boolean result), or any side effects (e.g., whether it modifies data). For a validation tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence that front-loads the core purpose ('Validate parameters against a prompt template') and adds a key constraint ('without rendering'). There is no wasted wording, and it directly communicates the tool's function in a structured manner.
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 complexity (validation with 2 parameters, no output schema, and no annotations), the description is insufficient. It lacks details on validation behavior, output format (e.g., what is returned on success/error), and how it integrates with sibling tools like 'render_prompt'. Without annotations or output schema, the description should provide more context to be complete for effective agent use.
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%, with clear descriptions for both parameters: 'templateId' as 'The ID of the template' and 'parameters' as 'Parameters to validate'. The description adds no additional semantic context beyond what the schema provides, such as explaining parameter formats or validation rules. With high schema coverage, the baseline score of 3 is appropriate as the schema adequately documents parameters.
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's purpose: 'Validate parameters against a prompt template without rendering'. It specifies the verb ('validate') and resource ('parameters against a prompt template'), and distinguishes it from 'render_prompt' by emphasizing 'without rendering'. However, it doesn't explicitly differentiate from other sibling tools like 'get_prompt' or 'search_prompts' beyond the validation aspect.
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 context by contrasting with 'render_prompt' through 'without rendering', suggesting this tool is for validation prior to rendering. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_prompt' for template inspection, or mention prerequisites such as needing a valid template ID. The context is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
write_fileD
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| content | Yes | ||
| encoding | No | utf8 | |
| createDirectories | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Most tools have distinct purposes, with clear separation between prompt management (get_prompt, list_prompts, render_prompt, validate_prompt), file operations (read_file, write_file, list_directory, search_files), git operations (git_diff, git_log, git_status), and utility functions (get_time, system_info, summarize). However, some tools like fetch_url and scrape_html could potentially overlap in web-related tasks, and the lack of descriptions for many tools creates minor ambiguity.
The naming follows a generally consistent verb_noun pattern (e.g., execute_workflow, get_prompt, list_directory, read_file), which is good. However, there are inconsistencies: some tools use underscores (git_diff) while others might imply similar patterns but lack clarity due to missing descriptions (e.g., summarize, system_info). The overall pattern is readable but not perfectly uniform.
With 19 tools, the count is on the higher side but still reasonable for a general-purpose 'Open MCP Server' aiming to cover multiple domains like workflows, prompts, file operations, git, and utilities. It feels slightly heavy, as some tools could be consolidated (e.g., multiple prompt-related tools), but it's not excessive and aligns with a broad scope.
The server covers several domains: prompt management has good coverage (list, get, render, validate, search), file operations are basic but functional (read, write, list, search), and git operations provide core commands. However, there are gaps: for workflows, only execute_workflow exists without tools for listing or managing workflows, and utility tools like fetch_url and scrape_html lack descriptions, making it hard to assess their coverage. Overall, it's moderately complete but has notable omissions.
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
AI-native project management for tasks, docs, collaboration, and agents.
Self-hosted AI prompt library: prompts, collections, tags, teams, chains. 29 MCP tools for agents.
One place to build, share, and govern the skills and tools your AI agents use at work.
Privacy-first work tracking with summaries, reports, coaching, and AI-ready long-term memory.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ishuru/open-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server