What can you do with this server?

The CodeRide MCP server enables AI assistants to comprehensively manage tasks and projects within the CodeRide platform, providing structured context and automating development workflows. Task Management: * Retrieve the first task of a project using start_project * Get detailed task information using get_task * Fetch task-specific prompts and instructions with get_prompt * Update task descriptions and statuses with update_task Project Management: * Retrieve comprehensive project details via get_project * List all available projects * Update project knowledge graphs and system architecture diagrams using update_project All operations use unique identifiers (project slugs and task numbers) for precise resource management.

Which integrations are available for this server?

Enables storing and updating project architecture using Mermaid diagrams within CodeRide projects, allowing visualization of system design. Runs as an npm package that connects Node.js environments to CodeRide, enabling AI agents to interact with CodeRide's task management system.

How do I use coderide?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@coderide what's the next task in my current project?" 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.

coderide

by PixdataOrg

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Supercharge Your AI Assistant or IDE with CodeRide Task Management

npm version

Give your AI coding sidekick the power of CodeRide! CodeRide MCP connects your favorite AI development tools (like Cursor, Cline, Windsurf, and other MCP clients) directly to CodeRide, the AI-native task management system.

Imagine your AI not just writing code, but truly understanding project context, managing its own tasks, and collaborating seamlessly with you. No more endless copy-pasting or manual updates. With CodeRide MCP, your AI becomes a first-class citizen in your CodeRide workflow.

🚀 Why CodeRide MCP is a Game-Changer

Deep Project Understanding for Your AI: Equip your AI agents with rich, structured context from your CodeRide projects and tasks. Let them see the bigger picture.
Seamless AI-Powered Task Automation: Empower AIs to fetch, interpret, and update tasks directly in CodeRide, automating routine project management.
Bridge the Gap Between Human & AI Developers: Foster true collaboration with smoother handoffs, consistent task understanding, and aligned efforts.
Optimized for LLM Efficiency: Compact JSON responses minimize token usage, ensuring faster, more cost-effective AI interactions.
Secure by Design: Workspace-scoped API key authentication ensures your data's integrity and that AI operations are confined to the correct project context.
Plug & Play Integration: Effortlessly set up with npx in any MCP-compatible environment. Get your AI connected in minutes!
Future-Proof Your Workflow: Embrace an AI-native approach to development, built on the open Model Context Protocol standard.

Related MCP server: switchyard

✨ Core Capabilities

The CodeRide MCP server provides your AI with the following capabilities:

Task Management: Fetch specific tasks, list all tasks in a project, and get the next task in sequence.
Task Updates: Modify task descriptions and statuses.
Prompt Access: Get tailored prompts and instructions for specific tasks.
Project Management: List all projects, retrieve project details, and manage project knowledge.
Project Knowledge Management: Update a project's knowledge graph and architecture diagrams.
Project Initiation: Get the first task of a project to kickstart work.
Workflow Automation: Navigate through task sequences with smart next-task suggestions.

⚙️ Getting Started

Installing via Smithery (Recommended)

To install Coderide MCP Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @PixdataOrg/coderide --client claude

Smithery Deployment Modes

CodeRide MCP supports dual-mode operation for both development and production use:

🔧 Development/Testing Mode (Mock)

Perfect for exploring features, testing integrations, or contributing to the project without needing a real CodeRide account.

How to activate: In the Smithery playground or configuration, either:

Leave the CODERIDE_API_KEY field empty
Provide any placeholder value (e.g., mock-key, test, etc.)

What you get:

All 9 tools available with realistic mock data
Sample projects (ABC, XYZ) and tasks (ABC-1, ABC-2, etc.)
Full MCP functionality for testing and development
No real API calls - completely safe for experimentation

🚀 Production Mode (Real API)

For actual CodeRide users who want to integrate with their real projects and tasks.

How to activate: Provide a valid CodeRide API key that starts with CR_API_KEY_

What you get:

Full integration with your CodeRide workspace
Real project and task data
Ability to update tasks and projects
Complete workflow automation

Traditional MCP Configuration

For non-Smithery deployments, add this configuration to your MCP client:

{
  "mcpServers": {
    "CodeRide": {
      "command": "npx",
      "args": ["-y", "@coderide/mcp"],
      "env": {
        "CODERIDE_API_KEY": "YOUR_CODERIDE_API_KEY_HERE"
      }
    }
  }
}

Prerequisites:

Node.js and npm: Ensure you have Node.js (which includes npm) installed.
CodeRide Account & API Key (Production only): For production use, you'll need an active CodeRide account and API key from app.coderide.ai.

Once configured, your MCP client will automatically connect to the CodeRide MCP server with the appropriate mode based on your configuration.

🤖 Who is this for?

CodeRide MCP is for:

Developers using AI coding assistants: Integrate your AI tools (Cursor, Cline, Windsurf, etc.) deeply with your CodeRide task management.
Teams adopting AI-driven development: Standardize how AI agents access project information and contribute to tasks.
Anyone building with MCP: Leverage a powerful example of an MCP server that connects to a real-world SaaS platform.

If you're looking to make your AI assistant a more productive and integrated member of your development team, CodeRide MCP is for you.

🔨 Available Tools

Here's a breakdown of the tools provided by CodeRide MCP and how they can be used:

`get_task`

Retrieves detailed information about a specific task by its number (e.g., "TCA-3").

Input Schema:

{
  "number": "task-number (e.g., 'TCA-3')",
  "status": "to-do|in-progress|done", // Optional: filter by status
}

Example Use Case:

User Prompt: "Hey AI, what are the details for task APP-101?"
AI Action: Calls get_task with arguments: { "number": "APP-101" }.
Outcome: AI receives the title, description, status, priority, and other context for task APP-101.

`update_task`

Updates an existing task's description, status, or other mutable fields.

Input Schema:

{
  "number": "task-number-identifier",
  "description": "updated-task-description", // Optional
  "status": "to-do|in-progress|done"   // Optional
}

Example Use Case:

User Prompt: "AI, please mark task BUG-42 as 'done' and add a note: 'Fixed the off-by-one error.'"
AI Action: Calls update_task with arguments: { "number": "BUG-42", "status": "done", "description": "Fixed the off-by-one error." }.
Outcome: Task BUG-42 is updated in CodeRide.

`get_prompt`

Retrieves the specific prompt or instructions tailored for an AI agent to work on a given task.

Input Schema:

{
  "number": "task-number (e.g., 'TCA-3')"
}

Example Use Case:

User Prompt: "AI, I'm ready to start on task ETF-7. What's the main objective?"
AI Action: Calls get_prompt with arguments: { "slug": "ETF", "number": "ETF-7" }.
Outcome: AI receives the specific, actionable prompt for FEAT-7, enabling it to begin work with clear direction.

`get_project`

Retrieves details about a specific project using its slug.

Input Schema:

{
  "slug": "project-slug (e.g., 'TCA')",
  "name": "optional-project-name" // Can also retrieve by name
}

Example Use Case:

User Prompt: "AI, can you give me an overview of the 'Omega Initiative' project?"
AI Action: Calls get_project with arguments: { "slug": "omega-initiative" }.
Outcome: AI receives the project's name, description, and potentially links to its knowledge base or diagrams.

`update_project`

Updates a project's high-level information, such as its knowledge graph or system architecture diagram.

Input Schema:

{
  "slug": "project-slug-identifier",
  "project_knowledge": { /* JSON object representing the knowledge graph */ }, // Optional
  "project_diagram": "/* Mermaid diagram string or similar */"             // Optional
}

Example Use Case:

User Prompt: "AI, I've updated the user authentication flow. Please update the project diagram for project 'APB'."
AI Action: (After generating/receiving the new diagram) Calls update_project with arguments: { "slug": "APB", "project_diagram": "/* new mermaid diagram */" }.
Outcome: The 'AlphaProject' in CodeRide now has the updated architecture diagram.

`start_project`

Retrieves the first or next recommended task for a given project, allowing an AI to begin work.

Input Schema:

{
  "slug": "project-slug (e.g., 'TCA')"
}

Example Use Case:

User Prompt: "AI, let's get started on the 'MobileAppV2' project. What's the first task?"
AI Action: Calls start_project with arguments: { "slug": "MBC" }.
Outcome: AI receives details for the initial task in the 'MBC' project, ready to begin.

`list_projects` ✨ NEW

Lists all projects in the user's workspace, providing an overview of available projects with intelligent workflow guidance.

Input Schema:

{
  // No input required - automatically uses workspace from API key
}

Example Use Case:

User Prompt: "AI, show me all my projects."
AI Action: Calls list_projects with no arguments.
Outcome: AI receives a list of all projects in the workspace with their slugs, names, and basic details, plus intelligent guidance for project selection and workflow initiation.

`list_tasks` ✨ NEW

Shows all tasks within a specific project, organized by status with smart numerical sorting and workflow optimization.

Input Schema:

{
  "slug": "project-slug (e.g., 'CRD')"
}

Example Use Case:

User Prompt: "AI, what tasks are available in the CRD project?"
AI Action: Calls list_tasks with arguments: { "slug": "CRD" }.
Outcome: AI receives all tasks in the CRD project, sorted numerically (CRD-1, CRD-2, CRD-3...) and organized by status columns, with intelligent task selection guidance.

`next_task` ✨ NEW

Retrieves the next task in sequence for workflow automation, perfect for continuous development flows with intelligent sequencing.

Input Schema:

{
  "number": "current-task-number (e.g., 'CRD-1')"
}

Example Use Case:

User Prompt: "AI, I just finished CRD-1. What's next?"
AI Action: Calls next_task with arguments: { "number": "CRD-1" }.
Outcome: AI receives details for CRD-2, enabling seamless workflow continuation with prerequisite validation and contextual guidance.

👩‍💻 For Contributors & Developers

Want to add new tools or modify existing ones? Check out our comprehensive Tool Development Guide which covers:

Naming conventions for consistent tool design
Description guidelines (what + when pattern)
Input schema best practices with detailed property descriptions
Metadata structure for enhanced tool discoverability
Complete examples to get you started quickly

The guide ensures all tools follow Anthropic's tool search best practices while maintaining backwards compatibility.

💡 Technical Highlights

🧠 AI-Native Workflow Optimization: Advanced agent instruction system with MCP 2025 structured tool output and intelligent workflow orchestration for enhanced AI productivity.
🔄 Intelligent Task Sequencing: Prerequisite validation, status-aware guidance, and automated workflow phases (Discovery → Context → Analysis → Implementation → Completion).
Security-First Design: Comprehensive input validation, secure API client with retry logic, and workspace-scoped authentication ensure data integrity and safe AI operations.
Production-Ready Reliability: Exponential backoff retry mechanisms, 90-second timeouts, and stable MCP SDK version (^1.0.3) provide enterprise-grade stability.
Workspace-Centered Authentication: API keys are tied to specific workspaces. All operations are automatically scoped, simplifying requests and enhancing security. No need to pass workspaceId!
User-Friendly Identifiers: Interact with tasks and projects using human-readable numbers (e.g., "TCA-3") and slugs (e.g., "TCA") instead of internal UUIDs.
Optimized for AI Efficiency: Compact JSON responses minimize token usage, while smart error handling prevents unnecessary retries on validation errors.
Robust API Interaction: Uses the official CodeRide API (https://api.coderide.ai by default) with comprehensive logging and error handling for all operations.

🛡️ Security

CodeRide MCP takes security seriously. We welcome responsible security research and have established a comprehensive bug bounty program with rewards ranging from €9 to €119.

For security vulnerabilities, please see our Security Policy for reporting guidelines and reward information.

🔧 Recent Improvements

v0.9.3 - Interactive Installation Wizard 🧙

🎯 CLI Installation Wizard: Interactive setup with npx @coderide/mcp add for easy configuration
🔍 Auto-Detection: Automatically detects installed MCP clients (Cursor, Claude Desktop, Claude Code, VS Code, Codex CLI)
🎨 Enhanced UX: Clean wizard output with status indicators and brand colors
⚙️ Smart Config Management: Detects unchanged configs to avoid unnecessary writes, creates backups automatically
🚀 CLI Flags: --no-open to skip browser opening, --force to show all clients
📝 Multi-Format Support: Handles both JSON (most clients) and TOML (Codex CLI) configuration formats
🔒 Secure by Default: Config files written with restrictive permissions (0o600), API key validation

v0.9.0 - Comprehensive Agent Workflow Enhancement 🚀

🧠 NLP Recognition System: Smart detection of project references and user intent in natural language for improved agent understanding
🧪 Mandatory Testing Verification: Comprehensive testing pipeline with unit + integration test support, coverage validation (80% unit, 90% integration)
📝 Automatic Git Commits: Full Conventional Commits 1.0.0 compliance with semantic versioning and automated commit generation
🎯 Project Knowledge Optimization: Intelligent project knowledge management with consistency validation and standardized schemas
⚡ Enhanced Agent Instructions: MCP 2025 structured tool output with workflow intelligence and phase-based guidance
🔒 Security & Performance: Input validation, command injection prevention, singleton patterns, and comprehensive error handling
🔄 Complete Workflow Automation: Discovery → Context → Analysis → Implementation → Completion phases with intelligent sequencing

v0.8.0 - Agent Workflow Optimization

🧠 Intelligent Agent Instructions: Implemented comprehensive agent instruction system with MCP 2025 structured tool output
🔄 Workflow Orchestration: Added prerequisite validation, status-aware guidance, and automated workflow phases
📁 Enhanced Tool Organization: Renamed tools for consistency (project_list → list_projects, task_list → list_tasks)
⚡ AI Productivity Boost: All 9 tools now include contextual guidance, automation hints, and workflow intelligence
🔒 Maintained Compatibility: 100% backward compatibility with existing integrations and security systems

Previous Improvements

Enhanced Reliability: Implemented exponential backoff retry logic for improved connection stability
Optimized Timeouts: Increased API timeouts to 90 seconds for better handling of complex operations
Stable Dependencies: Pinned MCP SDK to stable version (^1.0.3) for consistent behavior
MCP Protocol Optimizations: Reduced timeout errors (-32001) and SSE stream disconnections

🔥 About CodeRide

CodeRide is where AI and human developers unite to build better software, faster.

It's more than just task management; it's an AI-native platform built from the ground up to support the unique workflows of AI-assisted software development. CodeRide provides the essential structured context, project knowledge, and external memory that AI agents require to understand complex projects, contribute meaningfully, and collaborate effectively with their human counterparts.

Transform your development process with a tool that truly understands the synergy between human ingenuity and artificial intelligence.

Discover the future of software development at coderide.ai.

🔧 Troubleshooting

Common Issues

Connection Timeouts or MCP Error -32001:

The recent improvements have significantly reduced these issues
Ensure you're using the latest version: npx -y @coderide/mcp@latest
Check your API key is correctly set in the environment configuration

Authentication Errors:

Verify your CodeRide API key is valid and has the correct permissions
Ensure the API key is properly set in your MCP client configuration
API keys are workspace-scoped - make sure you're using the right workspace

Tool Not Found Errors:

Restart your MCP client after configuration changes
Verify the server is properly configured in your MCP client settings

For additional support, please open an issue with detailed error information.

🤝 Contributing

Contributions are welcome! Please feel free to submit issues, fork the repository, and create pull requests.

For security-related contributions, please see our Security Policy.

🔖 License

🤗 Support & Community

Have questions or need help with @coderide/mcp? Open an issue on our GitHub repository.
Want to learn more about CodeRide? Visit coderide.ai or join our community (Link to community forum/Discord if available).

Available Tools

9 tools

get_projectAInspect

Retrieves detailed information about a specific project using its unique 'slug' (three uppercase letters, e.g., 'CRD').

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry behavioral disclosure. Only states 'retrieves detailed information' without covering error conditions, data freshness, or whether operation is read-only (assumed but not stated). Minimal for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, concise, front-loads purpose and identifier format. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with no output schema, description covers purpose and parameter format adequately. Missing details like return structure or error cases, but acceptable given simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% coverage, but description explains slug meaning: unique identifier, three uppercase letters with example. Adds context beyond pattern regex, clarifying it's a project-specific identifier.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'retrieves', resource 'project', and identifier 'slug' with format details. Distinguishes from siblings like list_projects (which lists) and get_prompt (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies use when slug is known, but no explicit guidance on when to use versus list_projects or other project tools. No exclusion criteria mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_promptBInspect

Retrieves the specific instructions or prompt for a given task, identified by its unique task number (e.g., 'CRD-1'). This is typically used to understand the detailed requirements or context for an AI agent to work on the task.

ParametersJSON Schema

Name	Required	Description	Default
`number`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description must carry the full burden. It only says 'retrieves' but does not state if it is read-only, safe, or if it requires any permissions. There is no mention of side effects or idempotency, which is a notable gap for a retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. The first sentence defines the tool's primary purpose, and the second provides typical usage context. Information is front-loaded and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only one parameter and no output schema, the description is fairly complete. It explains what the tool does, the input format, and typical usage. However, it could hint at the return value format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for the parameter, but the description clarifies that the parameter is a unique task number (e.g., 'CRD-1') and matches the pattern. This adds some semantic value beyond the schema pattern, but does not fully describe the parameter's purpose or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it retrieves specific instructions/prompt for a task, using a unique task number. It clearly identifies the resource and action, and the example number format helps. However, it does not explicitly differentiate from sibling tools like get_task, which might retrieve task details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'typically used to understand the detailed requirements' which gives some context. But it does not provide when to use vs. alternatives (e.g., get_task) or when not to use it. No exclusion criteria are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_taskAInspect

Retrieves detailed information for a specific task using its unique task number (e.g., 'CRD-1').

ParametersJSON Schema

Name	Required	Description	Default
`number`	Yes

TDQS

A3.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry full burden. Only states 'retrieves' implying read, but omits any details on side effects, permissions, rate limits, or what 'detailed information' entails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no unnecessary words, front-loaded with action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple tool with one parameter, but lacks description of return value details (since no output schema) and potential errors. Not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning by explaining the 'number' parameter as a task number with example 'CRD-1', clarifying pattern. Schema coverage is 0%, so description compensates well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'Retrieves' and resource 'detailed information for a specific task', with an example (CRD-1) that distinguishes it from siblings like list_tasks or get_project.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage when needing detailed info for a specific task by number. Does not explicitly exclude alternatives or state when not to use, but context from sibling names provides some guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_projectsAInspect

Lists all projects in the user workspace. No input parameters required as the workspace is automatically determined from the API key authentication.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It describes listing all projects but does not disclose output format, pagination, limits, or any behavioral nuances beyond the basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no superfluous information. It efficiently covers purpose and a notable usage detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless list tool with no output schema, the description is mostly complete. It explains the scope and authentication context. Lacking output format details, but acceptable for a simple list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, baseline is 4. The description adds value by explaining why no parameters are needed (workspace determined from API key), which clarifies the intended use beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all projects in the user workspace, with a specific verb and scope. It distinguishes from siblings like get_project and start_project by implying this is the broad list operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives. However, by naming the resource and noting it lists all projects, an agent can infer it is the right choice for getting an overview, while get_project is for details.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tasksAInspect

Lists all tasks within a project using the project slug (e.g., 'CDB'). Returns tasks organized by status columns with their order and current status.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description states it lists tasks and returns them organized by status columns, but does not disclose if it's read-only, safe, or any side effects. With no annotations, the description carries full burden but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that efficiently front-loads the action ('Lists all tasks') and adds output structure details, with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one parameter and no output schema, the description provides adequate context about the return format (organized by status columns). Could mention pagination or limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning to the slug parameter by explaining it's a project slug and providing an example ('CDB'), which supplements the schema's pattern constraint (0% coverage).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists all tasks within a project given a project slug, and distinguishes itself from siblings like list_projects (which lists projects) and get_task (which retrieves a single task).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 alternatives like get_task or next_task. The description does not mention prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

next_taskAInspect

Retrieves the next task in sequence based on the current task number (e.g., CDB-23 → CDB-24). This is useful for finding the next task that needs to be done in a project workflow.

ParametersJSON Schema

Name	Required	Description	Default
`number`	Yes

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It does not disclose behavior when no next task exists, how the sequence is determined, or whether the operation is read-only. For a tool with no annotations, more detail is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the verb and resource, and includes a concrete example. Every sentence adds value with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter retrieval tool without an output schema, the description is mostly complete. It explains the purpose and usage example, but could mention the expected return format or edge cases like a missing next task.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter 'number' has a regex pattern in the schema, and the description adds meaning by explaining its format (e.g., CDB-23) and how it is used to find the next task. However, it does not specify what happens on invalid input or describe the return value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the next task in sequence based on a current task number (e.g., CDB-23 → CDB-24), and explains its utility in project workflows. This distinguishes it from siblings like get_task and list_tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context that it is useful for finding the next task to be done, but does not explicitly state when not to use it or compare it to alternative tools like get_task or list_tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

start_projectBInspect

Retrieves the project details and the prompt for the very first task of a specified project using the project's unique slug (e.g., 'CRD'). This is useful for initiating work on a new project or understanding its starting point.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes

TDQS

B3.4/5.0

Behavior2/5

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 'retrieves', implying read-only, but does not explicitly state there are no destructive actions or side effects, nor does it mention authorization or edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the action, and contains no unnecessary words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description adequately covers the tool's purpose and usage. It could be improved by describing the return format, but it is sufficient for a simple retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for the slug parameter. The description adds context by giving an example ('CRD') and explaining it's a unique slug, but does not go beyond what the pattern already conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool retrieves project details and the prompt for the first task using a slug. It uses specific verb and resource, but does not explicitly differentiate from siblings like get_project or get_prompt.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it is useful for initiating work or understanding a project's starting point, providing clear context. However, it lacks explicit guidance on when not to use it or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_projectAInspect

Updates a project's knowledge graph data and/or its structure diagram (in Mermaid.js format). The project is identified by its unique 'slug'. At least one of 'project_knowledge' or 'project_diagram' must be provided for an update to occur.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes
`project_knowledge`	No
`project_diagram`	No

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that updates can be partial (only knowledge or diagram or both) and that slug is the identifier. However, it does not specify whether updates are additive or overwrite existing data, what happens on failure (e.g., invalid slug or diagram format), or any authentication/authorization requirements. For a mutation tool, this is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, directly states the purpose and required conditions, and contains no redundant or irrelevant information. Every word earns its place, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has three parameters (one a nested object) and no output schema, the description covers the core action and constraints (slug requirement, at least one update field). However, it omits important context such as the return value/response format, error handling (e.g., if slug does not exist or diagram is invalid), and whether updates are incremental or replacement. This leaves gaps for an AI agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has three parameters with 0% description coverage, so the description adds meaning: it explains that slug identifies the project, project_knowledge is graph data, and project_diagram is in Mermaid.js format. It also clarifies that at least one of the two optional parameters must be provided. However, it does not specify the internal structure of the project_knowledge object or the expected formatting of the diagram string, which would improve clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool updates a project's knowledge graph data and/or its structure diagram in Mermaid.js format. This specific verb and resource, along with the explicit mention of two updatable components, distinguishes it from sibling tools like get_project (read-only) and list_projects (listing).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: the project is identified by a unique slug, and at least one of the two optional fields must be provided for the update to occur. However, it does not explicitly compare this tool to alternatives (e.g., when to use update_project vs update_task), nor does it state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_taskAInspect

Updates an existing task's 'description' and/or 'status'. The task is identified by its unique 'number' (e.g., 'CRD-1'). At least one of 'description' or 'status' must be provided for an update.

ParametersJSON Schema

Name	Required	Description	Default
`number`	Yes
`description`	No
`status`	No

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It fails to mention side effects, error handling (e.g., when task not found), permissions needed, or whether the update is reversible. This is a significant gap 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise with only two sentences, no fluff, and front-loads the key action and constraints. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic purpose and parameters but omits return values or success/failure indications. For an update operation with no output schema, the lack of any mention of what the tool returns or how to confirm success is a gap, making it only minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description clarifies that 'number' is a unique identifier with an example format, and that 'description' and 'status' are optional but at least one must be provided. It does not add additional meaning beyond the schema for the status enum or description type, but the usage constraint is helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the action (updates), resource (task), and the specific fields that can be updated (description and/or status), distinguishing it from sibling tools like get_task or list_tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states that at least one of 'description' or 'status' must be provided, giving a clear constraint. However, it does not explicitly mention when not to use or provide alternatives, which would have earned a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv1.0.0Jan 3, 2026

Changedget_project3 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / slug / description

Removed value: -"The unique three-letter uppercase identifier for the project (e.g., 'CRD')."

changedInput schema / properties / slug / pattern

Previous value: -"^[A-Z]{3}$"New value: +"^[A-Za-z]{3}$"

Changedget_prompt3 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / number / description

Removed value: -"The unique identifier for the task (e.g., 'CRD-1'). Must follow the format: three uppercase letters, a hyphen, and one or more digits."

changedInput schema / properties / number / pattern

Previous value: -"^[A-Z]{3}-\\d+$"New value: +"^[A-Za-z]{3}-\\d+$"

Changedget_task3 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / number / description

Removed value: -"The unique task number identifier (e.g., 'CRD-1'). Must be in the format: three uppercase letters, a hyphen, and one or more digits."

changedInput schema / properties / number / pattern

Previous value: -"^[A-Z]{3}-\\d+$"New value: +"^[A-Za-z]{3}-\\d+$"

Addedlist_projects
Addedlist_tasks
Addednext_task

Changedstart_project3 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / slug / description

Removed value: -"The unique three-letter uppercase identifier for the project (e.g., 'CRD') for which the first task's prompt is to be retrieved."

changedInput schema / properties / slug / pattern

Previous value: -"^[A-Z]{3}$"New value: +"^[A-Za-z]{3}$"

Changedupdate_project5 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / project_diagram / description

Removed value: -"Optional. A string containing the project's structure diagram in Mermaid.js format. If provided, this will update the existing diagram."

removedInput schema / properties / project_knowledge / description

Removed value: -"Optional. A JSON object representing the project's knowledge graph. If provided, this will update the existing knowledge data."

removedInput schema / properties / slug / description

Removed value: -"The unique three-letter uppercase identifier for the project to be updated (e.g., 'CRD')."

changedInput schema / properties / slug / pattern

Previous value: -"^[A-Z]{3}$"New value: +"^[A-Za-z]{3}$"

Changedupdate_task6 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

removedInput schema / properties / description / description

Removed value: -"Optional. The new description for the task. If provided, it will replace the existing task description."

removedInput schema / properties / number / description

Removed value: -"The unique identifier for the task to be updated (e.g., 'CRD-1'). Must follow the format: three uppercase letters, a hyphen, and one or more digits."

changedInput schema / properties / number / pattern

Previous value: -"^[A-Z]{3}-\\d+$"New value: +"^[A-Za-z]{3}-\\d+$"

removedInput schema / properties / status / description

Removed value: -"Optional. The new status for the task. Must be one of: 'to-do', 'in-progress', 'completed'. If provided, it will update the task's current status."

changedInput schema / properties / status / enum

Previous value: -[
-  "to-do",
-  "in-progress",
-  "completed"
-]New value: +[
+  "to-do",
+  "in-progress",
+  "done"
+]

6 tool updatesJun 23, 2025
- First observedget_project
- First observedget_prompt
- First observedget_task
- First observedstart_project
- First observedupdate_project
- First observedupdate_task

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a distinct purpose: getting, listing, updating, or starting projects/tasks. No two tools overlap in functionality, making it easy for an agent to select the right one.

Naming Consistency4/5

Tools mostly follow a verb_noun pattern (get_project, list_tasks, update_task), but 'next_task' deviates by using a noun phrase instead of a verb. This minor inconsistency is still clear.

Tool Count5/5

With 9 tools, the set is well-scoped for a project/task management server. Each tool serves a clear purpose without being excessive or too sparse.

Completeness2/5

The domain appears to be project and task management, but there is no way to create or delete projects or tasks. Only update and list/get operations are provided, which is a significant gap for a complete workflow.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

RideDesk Developer Docs A
app.ridedesk
Developer docs for building on RideDesk: booking API, widgets, per-account booking MCP. No auth.
Documentation Access Travel & Transportation
51
Joules — AI Cycling CoachOAuth
cc.joules
Turn Claude or ChatGPT into a cycling coach that plans your week, grades it, and adapts. Free beta.
Fitness Tracking Health & Wellness Sports
2
Bikefuchs — Bike Parts Price Comparison A
com.bikefuchs
Price comparison & cart optimizer for bike parts across German & Austrian shops
E-commerce & Retail Search
72
Etapa — Cycling Coach MCP A
io.github.rhoneybul
AI cycling coach — training plans and beginner guidance via the Etapa API.
Health & Wellness Fitness Tracking Education & Learning Tools
2

Related MCP Servers

LocalLama MCP Server
AI & Machine Learning Coding Agents
Heratiki
F
license
Not graded
quality
C
maintenance
Routes coding tasks to local and remote LLMs with intelligent cost-quality optimization, supports benchmarking and code search.
Updated 3 months ago (2026-06-08 04:46 UTC)
43
-
switchyard
Agent Orchestration Coding Agents Command Line
timjensgrossinger
A
license
C
quality
B
maintenance
Routes coding tasks across multiple AI CLIs (Copilot, Claude Code, Gemini, etc.) with cost-aware tier routing and parallel wave orchestration.
Updated 10 days ago (2026-08-27 15:04 UTC)
55
2
Apache 2.0
tsgram-mcp
Communication Developer Tools
areweai
A
license
Not graded
quality
D
maintenance
Connects Claude Code sessions to Telegram, enabling AI-powered code assistance and file management directly from Telegram chats.
Updated a year ago (2025-06-26 04:55 UTC)
89
MIT
Claude Code Orchestrator MCP
Agent Orchestration Coding Agents Developer Tools
chu459
A
license
Not graded
quality
A
maintenance
Enables Codex to orchestrate multi-agent coding by routing tasks to local Claude Code workers via CCSwitch, managing cost and model selection for planning, execution, and review.
Updated 3 months ago (2026-06-16 12:04 UTC)
7
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/PixdataOrg/coderide-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Supercharge Your AI Assistant or IDE with CodeRide Task Management

🚀 Why CodeRide MCP is a Game-Changer

✨ Core Capabilities

⚙️ Getting Started

Installing via Smithery (Recommended)

Smithery Deployment Modes

🔧 Development/Testing Mode (Mock)

🚀 Production Mode (Real API)

Traditional MCP Configuration

🤖 Who is this for?

🔨 Available Tools

get_task

update_task

get_prompt

get_project

update_project

start_project

list_projects ✨ NEW

list_tasks ✨ NEW

next_task ✨ NEW

👩‍💻 For Contributors & Developers

💡 Technical Highlights

🛡️ Security

🔧 Recent Improvements

v0.9.3 - Interactive Installation Wizard 🧙

v0.9.0 - Comprehensive Agent Workflow Enhancement 🚀

v0.8.0 - Agent Workflow Optimization

Previous Improvements

🔥 About CodeRide

🔧 Troubleshooting

Common Issues

🤝 Contributing

🔖 License

🤗 Support & Community

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`get_task`

`update_task`

`get_prompt`

`get_project`

`update_project`

`start_project`

`list_projects` ✨ NEW

`list_tasks` ✨ NEW

`next_task` ✨ NEW