Which integrations are available for this server?

Enables pipelines that interact with GitHub, such as opening pull requests from issues.

How do I use project-hub-mcp?

1. Click on "Deploy 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., "@project-hub-mcp Run the Issue to PR pipeline on issue #42" 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.

project-hub-mcp

by atikahjapry

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

project-hub-mcp

Run AI agent pipelines from Devin, Claude, and Cursor — via MCP.

Project Hub MCP is a Model Context Protocol server that lets your AI tools run multi-step agent pipelines directly from a conversation.

Built on top of Project Hub — the open-source AI agent pipeline desktop app.

What it does

Once installed, your AI assistant can:

list_pipelines — see all your pipelines
run_pipeline — execute a pipeline (Issue Analyst → Code Writer → Test Runner → PR Opener)
get_run_status — check logs and output of a run
list_agents — see all available agents (Devin, shell, Python, HTTP)
run_agent — run a single agent step with any input
create_pipeline — define a new pipeline on the fly
get_usage — check your monthly run count

Related MCP server: jt-mcp-server

Install

Devin

Add to your Devin MCP settings:

{
  "mcpServers": {
    "project-hub": {
      "command": "npx",
      "args": ["-y", "project-hub-mcp"],
      "env": {
        "PROJECT_HUB_API_KEY": "phub_your_key_here"
      }
    }
  }
}

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "project-hub": {
      "command": "npx",
      "args": ["-y", "project-hub-mcp"],
      "env": {
        "PROJECT_HUB_API_KEY": "phub_your_key_here"
      }
    }
  }
}

Cursor

Add to .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "project-hub": {
      "command": "npx",
      "args": ["-y", "project-hub-mcp"],
      "env": {
        "PROJECT_HUB_API_KEY": "phub_your_key_here"
      }
    }
  }
}

Local mode (no key required)

Set PROJECT_HUB_LOCAL_MODE=1 to run locally with no API key and no run limits:

{
  "mcpServers": {
    "project-hub": {
      "command": "npx",
      "args": ["-y", "project-hub-mcp"],
      "env": {
        "PROJECT_HUB_LOCAL_MODE": "1"
      }
    }
  }
}

Usage examples

Once installed, just talk to your AI:

"List my Project Hub pipelines"

"Run the GitHub Issue → PR pipeline with input: Fix the login bug described in issue #42"

"Check the status of run abc-123"

"Run the Code Writer agent on this task: Add dark mode to the settings page"

Environment variables

Variable	Default	Description
`PROJECT_HUB_API_KEY`	—	Your API key (get one free at https://projecthub.dev/api-key)
`PROJECT_HUB_LOCAL_MODE`	`0`	Set to `1` for unlimited local runs, no key needed
`PROJECT_HUB_DATA`	`~/.project-hub-mcp`	Directory where agents, pipelines, and run history are stored
`DEVIN_MODEL`	—	Default Devin model (e.g. `claude-sonnet-4`)
`DEVIN_PERMISSION_MODE`	`auto`	Devin permission mode: `auto`, `smart`, or `dangerous`
`DEVIN_WORKING_DIR`	`$HOME`	Default working directory for Devin agent runs

Pricing

Plan	Price	Runs/month
Free	£0	10
Pro	£19/mo	Unlimited

Get your free API key: https://projecthub.dev/api-key

Run from source

git clone https://github.com/atikahjapry/project-hub-mcp
cd project-hub-mcp
npm install
npm run build

# Run in local mode (no key, no limits)
PROJECT_HUB_LOCAL_MODE=1 node dist/index.js

Security

Data stored locally

Agents, pipelines, and run history are stored in ~/.project-hub-mcp/store.json on your own machine. The directory is created with mode 0700 and the file with mode 0600 — readable only by your user account.

API keys are hashed with SHA-256 before being stored. The raw key is never written to disk.

Secrets in `envVars`

When creating a shell or Python agent, the envVars field sets environment variables for the spawned process. Use $VARIABLE_NAME references, not literal values — the reference is stored, and the real value is resolved from your shell environment at runtime and never written to disk.

// Bad — literal token stored in store.json in plaintext
{ "GITHUB_TOKEN": "ghp_actualtoken123" }

// Good — reference stored; real value read from host env at runtime
{ "GITHUB_TOKEN": "$GITHUB_TOKEN" }

The server enforces this: saveAgent will throw if it detects a known secret pattern (GitHub tokens, OpenAI keys, AWS keys, long hex strings, etc.) in an envVars value. If you try to save such an agent you will get a clear error pointing to the offending key and showing the correct $REF form.

Put real secrets in your shell profile (~/.bashrc, ~/.zshrc) or your MCP host's env config block, then reference them by name.

Shell commands

Shell and Python agents run bash -c <your-command>. The user input passed to the agent is not interpolated into the command string — it is passed via the AGENT_INPUT environment variable to prevent shell injection.

Reference it in your command like this:

# Access user input safely via $AGENT_INPUT
echo "$AGENT_INPUT" | some-tool

Logs

All stdout/stderr captured during agent runs is scrubbed for common secret patterns (token=, password=, Bearer, etc.) before being stored. If you need to ensure sensitive output is never logged, set outputParser: "last_line" or "json_field" on the agent to capture only structured output.

How it works

Agents and pipelines are stored locally in ~/.project-hub-mcp/store.json
The server runs via stdio — your AI tool spawns it as a subprocess
Devin agents call the devin CLI — you need Devin installed (https://devin.ai/download)
Shell agents run via bash -c; user input passed via AGENT_INPUT env var (never interpolated into the command)
All run logs and outputs are persisted locally with secret scrubbing applied

Project Hub desktop app — the full GUI for building and running pipelines
Project Hub landing page — marketing site and agent marketplace

MIT License · Built by Atikah Japry

Available Tools

7 tools

create_pipelineA

Create a new pipeline by specifying an ordered list of agent IDs. Agents run in sequence, each receiving the previous agent's output as input.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	A short name for the pipeline.
`description`	Yes	What this pipeline does.
`agent_ids`	Yes	Ordered list of agent IDs to run in sequence (max 20). Use list_agents to find agent IDs.
`api_key`	No	Your Project Hub API key.

TDQS

A3.7/5.0

Behavior3/5

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

Discloses that agents run in sequence and each receives previous output. However, with no annotations, missing details on idempotency, uniqueness constraints, or error behavior (e.g., duplicate name).

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, front-loaded with purpose. No extraneous information. Efficient and clear.

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 no annotations and no output schema, description omits return value (likely pipeline ID) and error scenarios. Adequate for creation but not fully complete for agent decision-making.

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 descriptions cover all 4 parameters (100% coverage). The tool description adds minimal extra: only the sequential chaining behavior. Baseline 3 is appropriate as schema already provides meaning.

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 'Create a new pipeline' with specific verb and resource. It distinguishes from siblings like run_pipeline (execution) and list_pipelines (listing) by focusing on creation.

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 usage for creating a pipeline, but lacks explicit when-to-use vs alternatives like run_pipeline. No prerequisite guidance (e.g., agents must exist, listing via list_agents is hinted in schema but not description).

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

get_run_statusB

Get the current status and full logs of a pipeline run by its run ID.

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	Yes	The run ID returned by run_pipeline.

TDQS

B3.2/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 mentions returning 'status' and 'full logs', but fails to specify if the operation is read-only, requires authentication, or the format of logs (e.g., paginated). This leaves behavioral gaps for an agent.

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

Conciseness4/5

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

The description is a single, concise sentence with no redundant words. It is front-loaded with the action and resource. While it lacks depth in other dimensions, for conciseness alone it is efficiently structured.

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 tool has one parameter and no output schema. The description explains what the tool does but does not clarify the structure of the returned status or logs, or whether any error handling is involved. It is minimally complete for simple use but leaves the agent guessing about output 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?

Schema coverage is 100% with the parameter 'run_id' described as 'The run ID returned by run_pipeline'. The description adds no additional nuance beyond restating that the tool uses a run ID. Baseline 3 is appropriate as the schema already defines it.

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 verb 'Get' and the resource 'status and full logs of a pipeline run', along with the key identifier 'by its run ID'. This distinguishes it from sibling tools like 'run_pipeline' (which creates a run) and 'list_pipelines' (which lists pipelines).

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, such as indicating it should be used after 'run_pipeline' to check the run outcome. No explicit exclusions or prerequisites mentioned.

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

get_usageB

Check how many pipeline runs you've used this month and what plan you're on.

ParametersJSON Schema

Name	Required	Description	Default
`api_key`	No	Your Project Hub API key.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, and the description lacks disclosure of behavioral traits like idempotency, rate limits, or side effects; only implies a read 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?

Single sentence, front-loaded with purpose, no wordiness; 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?

For a simple read tool with no output schema, the description adequately states purpose but does not hint at output format or additional details like pagination or data freshness.

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 covers the single parameter (api_key) with a description; the tool description adds no additional meaning beyond this, meeting baseline expectations.

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 checks pipeline run usage and plan, which is a distinct function from sibling tools like create_pipeline or get_run_status.

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; simply states what it does without context such as prerequisites or recommended scenarios.

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

list_agentsB

List all available agents. Each agent is a single execution unit: a Devin AI session, shell script, Python script, or HTTP API call.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits like side effects or authentication. It only lists examples of agent types but fails to mention that the operation is read-only, return format, or any constraints.

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 exceptionally concise with two front-loaded sentences. It defines the action and provides clarifying context without unnecessary words.

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

Completeness2/5

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

Without an output schema, the description should explain what the response contains (e.g., list of agent names, IDs, status). It only states 'list all available agents' but omits return value details, making it incomplete.

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?

There are zero parameters with 100% schema coverage. According to guidelines, baseline for 0 parameters is 4, and the description appropriately adds no redundant parameter info.

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 'List all available agents' with a specific verb and resource, and elaborates on what constitutes an agent (Devin AI session, shell script, etc.), effectively distinguishing it from sibling tools like list_pipelines.

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 is provided on when to use this tool versus alternatives such as list_pipelines or run_agent. The description only states the function without contextual usage advice.

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

list_pipelinesA

List all available AI agent pipelines. Shows name, description, trigger type, and number of agents in each pipeline.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/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 states the tool lists pipelines and shows specific fields, which is adequate for a simple read operation, but lacks details on pagination, rate limits, 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.

Conciseness5/5

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

The description is two concise sentences, front-loading the action and result, 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 no parameters and no output schema, the description covers the primary information: what it lists and what fields are shown. Minor gap: no mention of whether all pipelines are returned or if there is any default ordering.

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 tool has zero parameters, and schema coverage is 100%. The description adds value by specifying the output fields, which is more than the schema provides, meeting the baseline for a no-parameter tool.

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 uses a specific verb 'list' and resource 'AI agent pipelines', and details the fields returned (name, description, trigger type, number of agents). It clearly distinguishes from sibling tools like list_agents and run_pipeline.

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 implies usage when needing to see available pipelines, but provides no explicit guidance on when to use or not use this tool, nor any comparisons to alternatives like list_agents or run_pipeline.

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

run_agentA

Run a single agent with a given input. Useful for quick one-off tasks without a full pipeline.

ParametersJSON Schema

Name	Required	Description
`agent_id`	Yes	The agent ID to run. Use list_agents to see available options.
`input`	Yes	The input to pass to the agent.
`api_key`	No	Your Project Hub API key. Free plan: 10 runs/month.

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 carries full responsibility for behavioral disclosure. It does not mention side effects, idempotency, rate limits, authentication requirements, or what happens on failure. The description is too brief given the lack of annotations.

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 sentences with no wasted words. The first sentence states core purpose, the second adds usage context. Efficient and front-loaded.

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 is adequate for understanding the basic operation but lacks information on output, errors, and behavioral aspects (e.g., whether runs are synchronous). Given the simplicity of the tool and rich schema, it is sufficient but not fully 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 100%, so the baseline is 3. The description adds no additional semantics beyond what the schema already provides (e.g., 'with a given input' is redundant with the schema's 'input' description). No extra 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 verb 'Run' and the resource 'a single agent', and distinguishes from sibling tools like 'run_pipeline' by adding 'without a full pipeline'. This is specific and unambiguous.

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 says 'Useful for quick one-off tasks without a full pipeline', which gives context and implies when to use this tool versus alternatives like run_pipeline. It does not explicitly list when not to use or prerequisites (e.g., call list_agents first), but the schema does provide that for agent_id. Overall clear but not exhaustive.

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

run_pipelineA

Execute an AI agent pipeline with an initial input. The pipeline will run each agent in sequence, passing output between them. Returns a run ID you can use to check status.

ParametersJSON Schema

Name	Required	Description
`pipeline_id`	Yes	The pipeline ID to run. Use list_pipelines to see available options.
`input`	Yes	The initial input passed to the first agent (e.g. a GitHub issue URL, task description, or any text).
`api_key`	No	Your Project Hub API key (phub_...). Free plan: 10 runs/month. Get one at https://projecthub.dev/api-key

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It indicates the tool is asynchronous (returns run ID) and runs agents sequentially, but lacks details about error handling, blocking behavior, rate limits, or side effects. For a mutation tool, more transparency is expected.

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

Conciseness4/5

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

The description is concise (two sentences) and front-loaded with purpose. It could be slightly more structured (e.g., listing steps), but overall efficient and clear.

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?

The description explains the return value (run ID) and indicates status checking is possible. However, it doesn't mention how to check status (e.g., get_run_status tool) or what happens on failure. For an async pipeline, this is good but not fully comprehensive.

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 description coverage is 100%, so baseline is 3. The description adds valuable context: pipeline_id references list_pipelines, input gives examples, and api_key explains where to obtain it. This goes beyond the schema alone.

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 verb 'execute', the resource 'AI agent pipeline', and the behavior (sequential agent execution with output passing). It also mentions the return value (run ID) and distinguishes from siblings implicitly by specifying 'pipeline' vs 'agent'.

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 a clear use case but does not explicitly state when not to use this tool or guide towards alternatives like run_agent for single agents. It does mention using list_pipelines to get pipeline IDs, which is helpful.

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.

7 tool updatesv1.0.0Jun 23, 2026
- First observedcreate_pipeline
- First observedget_run_status
- First observedget_usage
- First observedlist_agents
- First observedlist_pipelines
- First observedrun_agent
- First observedrun_pipeline

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-06-23 15:36 across 7 tools

Disambiguation5/5

All 7 tools have clearly distinct purposes: creating vs running pipelines, running a single agent, checking run status, checking usage, and listing agents/pipelines. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_pipeline, get_run_status, list_agents). No deviations or mixed conventions.

Tool Count5/5

7 tools is appropriate for the server's purpose of managing pipeline runs and agents. Each tool serves a distinct function without excess or deficiency.

Completeness4/5

The tool set covers the core lifecycle: create, run, monitor (status), list, and usage check. Minor gaps exist, such as missing update/delete for pipelines or agent management, but the surface is sufficient for common workflows.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

mcp-server-subagent
Agent Orchestration Coding Agents
dvcrn
A
license
Not graded
quality
D
maintenance
An MCP server that allows a planning agent to delegate tasks to executor agents (e.g., Claude Code, Aider) with bi-directional communication and real-time log streaming.
Updated a year ago (2025-05-30 07:48 UTC)
19 npm
15
AGPL 3.0
jt-mcp-server
Developer Tools Project Management Knowledge & Memory
HoukasaurusRex
A
license
Not graded
quality
C
maintenance
MCP server that equips AI agents with dev workflow tools including GitHub project management, conventional commits, visual regression testing, Jira/Confluence integration, and a persistent memory knowledge graph.
Updated 4 months ago (2026-05-13 18:32 UTC)
5 npm
MIT
agent-comm
Autonomous Agents Agent Orchestration
keshrath
A
license
Not graded
quality
D
maintenance
MCP server that enables AI coding agents to communicate, share state, and coordinate work in real time via MCP tools or REST API.
Updated 5 months ago (2026-04-17 08:01 UTC)
123 npm
5
MIT
agentloop
Agent Orchestration Autonomous Agents
luckeyfaraday
A
license
Not graded
quality
B
maintenance
MCP server that enables AI agents to run a deterministic orchestration loop with decomposition, subagent execution, and review feedback across multiple LLM backends.
Updated 2 months ago (2026-07-08 17:43 UTC)
60
MIT

project-hub-mcp

What it does

Install

Devin

Claude Desktop

Cursor

Local mode (no key required)

Usage examples

Environment variables

Pricing

Run from source

Security

Data stored locally

Secrets in envVars

Shell commands

Logs

How it works

Related

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Secrets in `envVars`