Provides tools for interacting with Git repositories, enabling AI agents to perform version control operations such as checking status, viewing commit history and diffs, and listing branches.
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-dev-tools Show me the last 5 commits"
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.
The most complete MCP server for developers — file operations, git integration, shell execution, and smart caching. Works with Claude Desktop, Cursor, and any MCP-compatible client.
Most MCP servers give you one or two basic tools. mcp-dev-tools gives you a full developer toolkit with production-grade internals:
🗂️ File Tools — read, write, list, inspect with validation & caching
🐚 Shell Tools — safe command execution with output capture
🌿 Git Tools — status, log, diff, branches without leaving your AI chat
⚡ LRU Cache — repeated file reads served instantly
🛡️ Built-in Validator — blocks dangerous commands and unsafe paths
📋 Structured Logging — clean, leveled logs that don't clutter stdio
Related MCP server: Code Buddy
git clone https://github.com/lucaskristina/mcp-dev-tools.git
cd mcp-dev-tools
npm installOpen your Claude Desktop config file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Add the following:
{
"mcpServers": {
"dev-tools": {
"command": "node",
"args": ["C:/path/to/mcp-dev-tools/src/index.js"]
}
}
}Restart Claude Desktop. You'll see the 🔌 icon confirming the server is connected.
In Cursor settings → MCP → Add Server:
{
"name": "dev-tools",
"command": "node",
"args": ["/path/to/mcp-dev-tools/src/index.js"]
}Tool | Description | Example Prompt |
| Read file contents with caching | "Show me the contents of src/app.js" |
| Write or overwrite a file | "Save this component to components/Card.jsx" |
| Recursive directory listing | "What files are in the src folder?" |
| Size, dates, permissions metadata | "When was package.json last modified?" |
Tool | Description | Example Prompt |
| Execute shell commands safely | "Run the test suite" |
| View environment variables | "What's the NODE_ENV?" |
| List running processes | "What's currently running?" |
Tool | Description | Example Prompt |
| Working tree status | "What files did I change?" |
| Commit history | "Show me the last 10 commits" |
| Diff against HEAD or branch | "What changed since last commit?" |
| List local/remote branches | "What branches do we have?" |
Create an optional mcp-config.json in your project root:
{
"server": {
"maxConcurrentRequests": 10,
"requestTimeoutMs": 30000
},
"tools": {
"enableFileAccess": true,
"enableShellExecution": true,
"allowedPaths": ["./src", "./docs"]
},
"logging": {
"level": "warn"
}
}Option | Default | Description |
|
|
|
|
| Restrict file access to these directories |
|
| Disable to prevent command execution |
|
| Tool execution timeout |
After setup, try these prompts in Claude or Cursor:
"List all TypeScript files in my src directory"
"Show me what changed in git since yesterday"
"Run npm test and show me the output"
"Read my .env file and tell me which variables are set"src/
├── index.js # Server entry point & tool registration
├── lib/
│ ├── logger.js # Structured logging (stderr, non-blocking)
│ ├── config.js # Config loader with defaults & merging
│ ├── cache.js # LRU cache (200 entries, 2min TTL)
│ ├── validator.js # Path & command safety checks
│ ├── metrics.js # Anonymous usage metrics (opt-out below)
│ └── utils.js # Shared helpers & error wrappers
└── tools/
├── file-tools.js # File system operations
├── shell-tools.js # Command execution
└── git-tools.js # Git repository toolsmcp-dev-tools collects anonymous usage metrics to help us improve the tool. This includes:
Node.js version and OS platform (no personal data)
Which tools are used most frequently
Error rates by tool type
To opt out, set the environment variable before starting:
MCP_NO_TELEMETRY=1 node src/index.jsOr add to your shell profile:
export MCP_NO_TELEMETRY=1We never collect file contents, command output, or any user data.
PRs welcome! Please read CONTRIBUTING.md first.
git clone https://github.com/lucaskristina/mcp-dev-tools
cd mcp-dev-tools
npm install
npm testAvatar | Name | Role |
👤 | alexkowalski | Core maintainer |
👤 | priya-dev | Git tools, caching |
👤 | t.brennan | Validator, security hardening |
👤 | lucaskristina-bot | CI/CD, releases |
🐛 Fixed git_diff on Windows paths with spaces
⚡ Improved cache TTL handling for large files
📋 Added process_list tool
✨ Added full git tools suite
🛡️ Validator now blocks 12 additional dangerous patterns
📊 Telemetry opt-out via MCP_NO_TELEMETRY
✨ LRU cache for file reads (2x faster repeated reads)
✨ get_environment tool with sensitive key filtering
🔧 Config file support (mcp-config.json)
MIT © lucaskristina
Get metadata about a file or directory
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File or directory path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose what metadata is returned, behavior for non-existent paths, or any read-only implications. The description is minimal.
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, no fluff. Front-loaded with key action and resource. Could be expanded slightly without harming conciseness.
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?
No output schema, and 'metadata' is vague. Does not address edge cases or typical return structure. With 1 parameter, more completeness is expected.
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 describes 'path' fully; description restates that it's for a file or directory but adds no additional meaning. Schema coverage is 100%, so baseline is 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 uses a specific verb ('Get') and resource ('metadata about a file or directory') that clearly distinguishes from sibling tools like write_file and list_directory.
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 on when to use this tool vs alternatives. No mention of prerequisites or scenarios where a sibling tool would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current environment variables (filtered for safety)
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional prefix filter, e.g. "NODE" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The phrase 'filtered for safety' is vague and does not specify what is filtered or why. No disclosure of output format, size limits, or security implications.
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 very short with no fluff, but could be slightly more informative without losing conciseness. It is front-loaded with the core action.
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?
The tool is simple with one optional parameter and no output schema. The description minimally suffices but leaves ambiguity about the return format and safety filtering.
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 100% as the only parameter 'filter' is described in the schema. The description adds no additional meaning beyond the schema, meeting the baseline.
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 'current environment variables', though 'filtered for safety' adds ambiguity. It distinguishes itself from sibling tools like file operations and git commands.
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 or not use this tool. The description implies it is for inspecting environment variables, but lacks context on alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List local and remote branches
| Name | Required | Description | Default |
|---|---|---|---|
| remote | No | ||
| repoPath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as error handling, required repository state, or output format. It adds minimal context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), which is good for brevity but lacks necessary detail to be fully helpful. It is front-loaded but incomplete.
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 2 parameters, no annotations, and no output schema, the description is insufficiently complete. An agent needs more context to use the tool effectively, such as default behavior and parameter meanings.
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% and the description does not explain the two parameters ('remote' and 'repoPath'). For example, it does not indicate that 'remote' defaults to false and controls whether remote branches are listed.
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 the resource 'branches', and specifies 'local and remote'. It distinguishes from sibling tools like git_log and git_diff. However, it could be more precise about the effect of the 'remote' parameter.
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?
There is no guidance on when to use this tool versus alternatives like git_log or git_diff. The description provides no context for usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show changes between commits, working tree, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| staged | No | ||
| target | No | HEAD | |
| repoPath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'show changes', implying non-destructive read, but no explicit statement about safety, side effects, or output format. Does not disclose that it requires a git context or error 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?
Single sentence, front-loaded with the core action. However, 'etc.' is vague and could be replaced with specific examples. Still, it is appropriately short and wastes no 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?
With no output schema, no annotations, and 0% parameter descriptions, the description provides minimal context. It omits return format, error handling, required environment, and parameter usage guidance. Inadequate for a tool with three parameters and no structured metadata.
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%; description adds no parameter details. Parameter names (staged, target, repoPath) imply meaning, but the description fails to explain them or their interactions (e.g., relationship between staged and target, what repoPath defaults to). No compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb+resource: 'Show changes between commits, working tree, etc.' Differentiates from git_log (log of commits) and git_branches (list branches) by focusing on diff output. However, 'etc.' adds vagueness, not fully specifying all supported diff scenarios.
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 on when to use this tool versus siblings like git_log, git_branches, or file operation tools. No mention of prerequisites (e.g., must be in a git repository) or alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show commit history
| Name | Required | Description | Default |
|---|---|---|---|
| oneline | No | ||
| maxCount | No | ||
| repoPath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must convey behavioral traits. It only states a read operation ('Show'), but does not explain output format, pagination, side effects, or access requirements. The brevity fails to disclose essential 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?
At three words, the description is extremely concise but lacks substance. While it is front-loaded and efficient, it sacrifices necessary detail for brevity, making it minimally adequate.
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 tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It does not explain return values, parameter nuances, or how the output relates to sibling tools, leaving significant gaps for correct 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 input schema has 3 parameters with 0% description coverage. The description does not clarify the meaning of 'oneline' (e.g., condensed output), 'maxCount' (max commits), or 'repoPath' (repository location). The agent must infer from names and defaults alone.
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 'Show commit history' clearly indicates the action (show) and the resource (commit history). It is distinct from sibling tools like git_diff (which shows diffs) and git_branches (which lists branches), providing unambiguous 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 git_diff or git_branches. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List contents of a directory
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Directory path | |
| recursive | No | ||
| showHidden | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'List contents of a directory' without specifying default behavior for recursion, hidden files, error handling, or path validation. Key traits are omitted.
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, which is very concise. However, it sacrifices necessary details for brevity. It is front-loaded but incomplete.
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?
With 3 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain the return format, behavior on invalid paths, or error handling, making it insufficient for correct tool 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?
Schema description coverage is only 33% (only 'path' has a description). The tool description adds no parameter information, failing to compensate for the missing schema descriptions of 'recursive' and 'showHidden'.
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 the resource 'directory', which distinguishes it from sibling tools like write_file, file_info, and run_command. The purpose is unambiguous.
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, nor any prerequisites or context. It only states the basic function without exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List currently running processes
| 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 only states the action without disclosing what information is returned (e.g., PID, name, memory). The agent cannot infer the output structure or possible limitations.
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, clear sentence with no wasted words. It is front-loaded and appropriately sized for a tool with no 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?
For a tool with no parameters, no output schema, and no annotations, the description is minimal. It does not specify the format or contents of the returned list, which is needed for the agent to process the output. Sibling tools likely provide more detail.
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. The description adds value by stating the purpose, which implies no parameters are needed. Baseline for 0 parameters is 4.
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 'List' and a clear resource 'currently running processes', distinguishing it from sibling tools like list_directory or file_info.
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 explicit guidance on when to use this tool versus alternatives. The context of sibling tools suggests different domains (files vs. processes), but no exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a shell command and return stdout/stderr
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory | |
| env | No | Additional environment variables | |
| command | Yes | Shell command to execute | |
| timeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It fails to disclose potential side effects, security implications, or execution context (e.g., permissions, sandboxing), which is critical for a command execution 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 concise at one sentence, but could be slightly more informative without sacrificing brevity. No front-loading issues.
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 (potential for side effects), lack of output schema, and no annotations, the description is incomplete. It omits information on return format, error handling, and safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 4 parameters (75% coverage), including default and constraints for timeoutMs. The description adds no additional meaning; 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 'execute' and the resource 'shell command', and specifies that it returns stdout/stderr, distinguishing it from sibling tools like file and git operations.
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 write_file or git commands. The description does not indicate prerequisites or best practices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write or overwrite a file with given content
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path to write | |
| content | Yes | Content to write | |
| createDirs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so full burden on description. It says 'overwrite' implying destruction, but lacks detail on whether it truncates existing files, handles binary vs text, permissions, or how the createDirs parameter affects behavior. Agent cannot assess safety or 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?
Single sentence is very concise and front-loaded with the core action. No unnecessary words, but could improve by mentioning the optional createDirs parameter briefly.
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?
With no output schema and no annotations, the description is insufficient for a 3-parameter tool. It lacks details on return values, error handling, whether content is appended or truncated, and the role of createDirs. Agent needs to guess or infer from other contexts.
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 covers 67% of parameters with descriptions, but description adds no extra meaning for any parameter. The 'createDirs' parameter is missing from description and schema lacks a description, leaving its purpose unclear. Agent must infer from name.
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 identifies the verb 'write' and resource 'file', indicating creation or overwriting. It distinguishes from sibling tools like list_directory and file_info, but doesn't specify the exact behavior (e.g., creates new file if missing).
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 on when to use this tool vs alternatives, such as choosing between write and other file operations. No mention of prerequisites or side effects like needing directory existence (though createDirs parameter exists in schema but not described).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clear, distinct purpose: file operations (write, list, info), system operations (run command, env, processes), and git operations (log, diff, branches). No overlap between categories or within categories.
Most tools follow a verb_noun pattern in snake_case (write_file, list_directory, run_command, get_environment, git_log, git_diff, git_branches), but file_info and process_list are noun_noun, causing minor inconsistency.
9 tools is a reasonable size for a dev tools server covering file, system, and git operations. Not too few to be trivial nor too many to be overwhelming.
Significant gaps exist: missing file read, file delete, git add/commit/push, and other common dev operations. The set covers only a subset of typical workflows, likely causing agent failures for common tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
An MCP server that gives your AI access to the source code and docs of all public github repos
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lucaskristina/mcp-dev-tools'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
