Which integrations are available for this server?

Mentioned as an example backend technology for multi-agent collaboration scenarios, where backend agents can coordinate API design and implementation with frontend agents. Mentioned as an example frontend technology for multi-agent collaboration scenarios, where frontend agents can coordinate UI development with backend agents. Mentioned as an example backend technology for multi-agent collaboration scenarios, where backend agents can coordinate API design and implementation with frontend agents. Mentioned as an example frontend technology for multi-agent collaboration scenarios, where frontend agents can coordinate component development with backend agents. Used for sharing type definitions and API contracts between frontend and backend agents during cross-stack collaboration.

How do I use Agent Hub MCP?

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., "@Agent Hub MCP sync with all agents working on the e-commerce 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.

Agent Hub MCP

by gilbarbara

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Agent Hub MCP

npm version Quality Assurance Quality Gate Status

Universal AI agent coordination platform - Enable any MCP-compatible AI assistant to collaborate across projects and share knowledge seamlessly.

Why Agent Hub MCP?

The Problem: AI coding assistants work in isolation. Your Claude Code agent can't share insights with your Cursor agent. Knowledge remains trapped in individual sessions, and agents struggle to coordinate on complex, multi-service projects.

The Solution: Agent Hub MCP creates a universal coordination layer that enables any MCP-compatible AI agent to communicate, share context, and collaborate—regardless of the underlying AI platform or project location.

┌─────────────┐    ┌─────────────────┐    ┌─────────────┐
│ Claude Code │───▶│ Agent Hub MCP   │◀───│   Qwen      │
│  (Frontend) │    │     (MCP)       │    │ (Backend)   │
└─────────────┘    └─────────────────┘    └─────────────┘
                           ▲
                           │
                    ┌─────────────┐
                    │   Gemini    │
                    │ (Templates) │
                    └─────────────┘

Related MCP server: kitty-hive

What You Get

🤖 Universal Compatibility: Works with ANY MCP-compatible AI agent - no vendor lock-in
⚡ Minimal setup: One-line configuration, no complex installation required
🔄 Multi-Agent Collaboration: Agents communicate across different platforms and projects
🧠 Shared Intelligence: Knowledge and context flows between agents automatically
📋 Smart Coordination: Agents track dependencies and coordinate complex multi-service tasks
💾 Persistent Memory: All collaboration history preserved across sessions

Quick Start (5 minutes)

Step 1: Add Agent Hub MCP to Your AI Assistant

For Claude Code, Qwen, Gemini (JSON config):

{
  "mcpServers": {
    "agent-hub": {
      "command": "npx",
      "args": ["-y", "agent-hub-mcp@latest"]
    }
  }
}

For Codex (TOML config):

[mcp_servers.agent-hub]
command = "npx"
args = ["-y", "agent-hub-mcp@latest"]

Step 2: Install Custom Commands (Recommended)

Custom commands make collaboration much easier. Install them for your AI assistant:

For Claude Code:

git clone https://github.com/gilbarbara/agent-hub-mcp.git /tmp/agent-hub-mcp
mkdir -p ~/.claude/commands/hub
cp /tmp/agent-hub-mcp/commands/markdown/*.md ~/.claude/commands/hub/

For Qwen/Gemini:

git clone https://github.com/gilbarbara/agent-hub-mcp.git /tmp/agent-hub-mcp
mkdir -p ~/.qwen/commands/hub  # or ~/.gemini/commands/hub
cp /tmp/agent-hub-mcp/commands/toml/*.toml ~/.qwen/commands/hub/

This enables slash commands for:

/hub:register (join the hub)
/hub:sync (check for messages and workloads)
/hub:status (view hub activity)

Step 3: Restart Your AI Assistant

Close and reopen your AI assistant completely for changes to take effect.

Step 4: Verify Installation

Register your agent:

/hub:register

You should see: ✅ Registered with Agent Hub as [your-project-name]

Without Custom Commands: Ask your AI assistant: "Register with the Agent Hub" then "Check the Hub status" Expected response: Confirmation that you're registered and connected

Troubleshooting Verification:

❌ No response → Check MCP server configuration and restart AI assistant
❌ Connection error → Verify npx -y agent-hub-mcp@latest command
❌ Commands not found → Ensure custom commands are installed in the correct directory

✅ Success! You should see Agent Hub MCP status information. You're ready to collaborate!

📬 Automatic Message Notifications (Optional)

Set up automatic notifications when other agents send you messages by adding a hook to your Claude Code settings:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "npx -y agent-hub-mcp-checker"
          }
        ]
      }
    ]
  }
}

This will automatically check for unread messages after each command and display: 📬 You have X unread messages from other agents. Type '/hub:sync' to check.

🤖 Works With Any MCP-Compatible AI Agent

Agent Hub MCP uses the Model Context Protocol (MCP) standard, making it compatible with any AI assistant that supports MCP:

✅ Verified Compatible (manually tested)

Claude Code - Primary platform, thoroughly tested
Qwen - Verified multi-agent collaboration.
Gemini CLI - Confirmed working with custom commands.
Codex - TOML configuration support

🔄 Likely compatible (MCP client support required)

Continue.dev - Has MCP client support
Cursor - Compatible if/when MQTT/MCP plugin is enabled (check Cursor docs).
Any custom MCP client - Follow the MCP specification.

🧪 Help Us Test

Using a different AI assistant? We'd love to verify compatibility! Open an issue with your platform details.

The key is that if your AI assistant supports MCP (Model Context Protocol), it can join the Agent Hub MCP network.

Usage

Complete Workflow Example

Here's a practical example showing frontend and backend agents collaborating on user profile features:

1. Agent Registration

# In your frontend project (React/Next.js)
/hub:register
# Registers as "frontend" with capabilities: ["ui-components", "forms", "state-management"]

# In your backend project (Node.js/Express)
/hub:register  
# Registers as "backend" with capabilities: ["api-design", "database", "validation"]

Agent Identity & Persistence:

Agents maintain consistent IDs across restarts (no random suffixes)
Project path determines agent identity - same path reconnects to existing agent
Agent ID conflicts are prevented - can't use existing ID with different project path
All messages and context are preserved when agents reconnect

2. User Request & Agent Communication

User (in frontend project): "I need endpoints to create a user profile page and a form to update user information. Can you coordinate with the backend to get the requirements?"

Frontend agent:

# Agent automatically coordinates with backend
"Hi backend agent! Working on user profile features. Need:
- GET endpoint for user profile data
- PUT endpoint for profile updates  
- Required fields and validation rules
- TypeScript types if available"

3. Backend Response

Backend agent (after syncing with hub):

# Provides complete API specification
"Here's the user profile API design:

## Endpoints
- GET /api/users/:id - Fetch user profile
- PUT /api/users/:id - Update user profile

## User Profile Model
{
  id: string;
  email: string;
  firstName: string;
  lastName: string;
  bio?: string;
  avatar?: string;
  updatedAt: Date;
}

## Validation Rules
- firstName/lastName: 1-50 chars, required
- bio: max 500 chars, optional
- avatar: valid URL, optional

## Response Format
Success: { data: UserProfile }
Error: { error: string, field?: string }

Ready to implement. Need any specific requirements?"

4. Frontend Implementation

Frontend agent (creates plan and executes):

# Agent works autonomously to implement:
# ✅ Create UserProfile TypeScript interface
# ✅ Build profile display component
# ✅ Create profile edit form with validation
# ✅ Add API service functions
# ✅ Implement state management

"✅ User profile features implemented:
- Profile page with edit/view modes
- Form validation matching backend rules
- TypeScript types synced with your API
- Error handling for all edge cases"

Key Features Demonstrated

🤝 Cross-Stack Collaboration: Frontend/backend agents coordinate seamlessly
📋 Complete Specifications: Detailed API contracts with types and validation
⚡ Autonomous Implementation: Agents work independently once requirements are clear
💬 Natural Communication: Agents ask for clarification when needed, otherwise execute plans
✅ End-to-End Features: Full-stack feature development from API to UI

Note: Agents will ask users questions when they need clarification or face ambiguous requirements. Otherwise, they create detailed plans and execute autonomously.

Core Concepts

Message Types

context - Share state/configuration
task - Assign work to agents
question - Request information
completion - Report task completion
error - Report errors

Feature Collaboration

Structured multi-agent coordination:

Feature-based project organization
Task delegation to domain experts
Progress tracking through subtasks
Context sharing within feature boundaries

Key MCP Tools

Core tools for multi-agent collaboration:

register_agent - Register/reconnect an agent
send_message / sync - Inter-agent communication and comprehensive status updates
get_hub_status - Hub activity overview
create_feature / create_task - Multi-agent project coordination

See System Overview for complete tool reference and architecture details.

🚀 How Multi-Agent Collaboration Works

Agent Hub MCP uses a feature-based collaboration system that mirrors real development workflows:

1. Feature Creation

Create multi-agent projects that span different repositories and technologies:

# Coordinator agent creates a new feature
create_feature({
  "name": "user-authentication", 
  "title": "Add User Authentication System",
  "description": "Implement login, signup, and session management across frontend and backend",
  "priority": "high",
  "estimatedAgents": ["backend-agent", "frontend-agent"]
})

2. Task Delegation

Break features into specific tasks assigned to domain experts:

create_task({
  "featureId": "user-authentication",
  "title": "Implement authentication API",
  "delegations": [
    { "agent": "backend-agent", "scope": "Create JWT auth endpoints and middleware" },
    { "agent": "frontend-agent", "scope": "Build login/signup forms and session management" }
  ]
})

3. Intelligent Work Distribution

Agents see ALL their work across features and make smart priority decisions:

# Backend agent connects and sees:
sync("backend-agent")
# Returns:
{
  "workload": {
    "activeFeatures": [
      {
        "feature": { "title": "User Authentication", "priority": "high" },
        "myDelegations": [{ "scope": "Create JWT auth endpoints", "status": "pending" }]
      },
      {
        "feature": { "title": "Performance Optimization", "priority": "critical" },
        "myDelegations": [{ "scope": "Fix database queries", "status": "in-progress" }]
    }
  ]
}

4. Context Sharing & Coordination

Agents share implementation details within feature boundaries:

# Backend completes API contract
update_subtask({
  "featureId": "user-authentication",
  "subtaskId": "auth-api-contract", 
  "status": "completed",
  "output": "JWT endpoints ready: POST /auth/login, POST /auth/signup, GET /auth/me"
})

# Frontend sees progress when checking feature data
get_feature("user-authentication") 
# Shows: subtask output with JWT endpoints info

5. Automatic Coordination

Agents unblock each other by sharing progress and outputs in real-time. The system handles:

Priority management: Critical tasks get attention first
Dependency tracking: Agents know what they're waiting for
Context isolation: Each feature maintains its own scope
Load balancing: Work distributes naturally across available agents

Advanced Setup

Custom Data Directory

To store Agent Hub MCP data in a custom location, add environment variables to your configuration:

{
  "mcpServers": {
    "agent-hub": {
      "command": "npx",
      "args": ["-y", "agent-hub-mcp@latest"],
      "env": {
        "AGENT_HUB_DATA_DIR": "/path/to/your/data"
      }
    }
  }
}

For Other MCP Clients

If your AI assistant supports MCP, use these settings:

Command: npx -y agent-hub-mcp@latest
Protocol: Standard MCP over stdio
Data Directory: ~/.agent-hub (or set AGENT_HUB_DATA_DIR)

Troubleshooting

Common issues:

MCP server not connecting → Restart AI assistant
Commands not recognized → Check custom commands installation
Agent ID conflicts → Use unique IDs per project

📖 Need help? See Troubleshooting Guide for comprehensive solutions.

Requirements

Node.js 22+
An MCP-compatible AI assistant (Claude Code, Qwen, Gemini, etc.)

Environment Variables

Variable	Default	Description
`AGENT_HUB_DATA_DIR`	`~/.agent-hub`	Storage directory

Contributing

See Contributing Guide for development setup and guidelines.

Documentation

System Overview - Complete architecture and tool reference
Troubleshooting - Solutions for common issues
Known Issues - Current limitations and workarounds
Contributing - Development setup and guidelines

License

MIT

Available Tools

12 tools

accept_delegationC

Accept a delegation assigned to an agent

ParametersJSON Schema

Name	Required	Description
`featureId`	Yes	Feature ID
`delegationId`	Yes	Delegation ID to accept
`agentId`	Yes	Agent accepting the delegation

TDQS

C2.9/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 cover behavioral traits. It only states the action without revealing side effects, idempotency, or required permissions, which is insufficient for a mutation operation.

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 that efficiently conveys the tool's purpose. It is appropriately sized, though it lacks structure or additional detail.

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 tool with clear parameters and no output schema, the description adequately states the action. However, it misses contextual details such as return values or prerequisites, making it 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?

The input schema has 100% coverage with descriptions for all three parameters, so the baseline is 3. The description does not add any additional meaning beyond what the schema already provides.

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 the verb 'Accept' and the resource 'delegation assigned to an agent,' making the tool's purpose unambiguous. It distinguishes from sibling tools like create_feature or send_message, which have different actions.

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. The description does not mention prerequisites, success conditions, or when not to use it, leaving the agent without context for decision-making.

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

create_featureC

Create a new feature for multi-agent collaboration

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Feature name (will be converted to kebab-case ID)
`title`	Yes	Human-readable feature title
`description`	Yes	Detailed feature requirements and context
`priority`	No	Feature priority level	normal
`estimatedAgents`	No	Agents expected to be needed for this feature
`createdBy`	Yes	Agent creating this feature

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided; description only says 'create' with no disclosure of side effects, authorization requirements, idempotency, or constraints like unique names.

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?

Single sentence, direct and front-loaded with verb and resource. No verbosity, but could include slightly more context without becoming bloated.

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?

Tool has 6 parameters and no output schema; description provides no context on return values, constraints, or integration with other tools, making it incomplete for practical use.

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 has 100% parameter description coverage; description does not add to parameter semantics, but schema descriptions are sufficient.

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?

Clearly states verb 'create' and resource 'feature' within multi-agent collaboration domain, but does not explicitly differentiate from sibling tools like create_task or create_subtask.

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 usage context provided; agent must infer from name alone; no comparison to sibling tools or guidance on when to use this tool versus alternatives.

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

create_subtaskC

Create implementation subtasks within a delegation

ParametersJSON Schema

Name	Required	Description
`featureId`	Yes	Feature ID
`delegationId`	Yes	Delegation ID to create subtasks for
`subtasks`	Yes	Subtasks to create
`createdBy`	Yes	Agent creating these subtasks

TDQS

C2.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 must carry the full burden of behavioral disclosure. It only states 'create', giving no information about side effects (e.g., does it overwrite existing subtasks?), required permissions, or error states (e.g., if delegationId does not exist). This is insufficient for a mutation tool with no annotations.

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

Conciseness3/5

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

The description is a single sentence, making it concise but too minimal. It lacks any structure or additional details that would help an agent. While it is front-loaded, it sacrifices completeness for brevity, missing opportunities to add value.

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?

Given 4 required parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain the return value, behavior on failure, or constraints (e.g., that subtasks must belong to the delegation). The agent has no context beyond the parameter names.

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 input schema has 100% description coverage, with each parameter well-documented. The tool description adds only the contextual phrase 'within a delegation', which aligns with the delegationId parameter but does not add meaningful semantics beyond the schema. For high coverage, baseline 3 is appropriate.

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 the action ('Create') and the resource ('implementation subtasks within a delegation'), distinguishing it from sibling tools like create_task (which creates parent tasks) and update_subtask (update vs create). However, the phrase 'implementation subtasks' is slightly vague; a more explicit 'subtasks for a specific delegation' would improve clarity.

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?

The description provides no guidance on when to use this tool versus its siblings. It does not mention prerequisites (e.g., that a delegation must exist) or alternatives (e.g., use update_subtask for modifying existing subtasks). The context signals show sibling tools, but the description itself lacks usage direction.

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

create_taskB

Create a task within a feature with agent delegations

ParametersJSON Schema

Name	Required	Description
`featureId`	Yes	Feature ID to create task in
`title`	Yes	Task title
`description`	Yes	Detailed task requirements
`delegations`	Yes	Agent delegations for this task
`createdBy`	Yes	Agent creating this task

TDQS

B3.1/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 only states 'create', but does not disclose any side effects, permissions required, or behavioral constraints for this mutation operation.

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?

Single sentence, front-loaded, no wasted words. However, it could benefit from slight expansion to improve completeness.

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?

Given 5 required parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values or confirm success, leaving the agent with incomplete context for a creation 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?

Schema description coverage is 100%, with all parameters described adequately. The description adds no extra meaning beyond the schema, so baseline score of 3 applies.

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 action ('create') and resource ('task'), and specifies the context ('within a feature with agent delegations'). It distinguishes itself from siblings like 'create_subtask' (subtask) and 'create_feature' (feature).

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 'create_subtask' or 'accept_delegation'. No prerequisites or context provided.

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

get_featureB

Get complete feature data including tasks, delegations, and subtasks

ParametersJSON Schema

Name	Required	Description	Default
`featureId`	Yes	Feature ID to retrieve

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 cover behavioral traits. It only notes that data includes tasks, delegations, and subtasks, but does not disclose idempotency, response format, authentication needs, or potential 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.

Conciseness4/5

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

The description is a single sentence that is front-loaded with the verb and resource. It is concise and contains no fluff, though it could be slightly more structured with bullet points.

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 retrieval tool with one parameter and no output schema, the description is adequate but lacks details on return format or pagination. It covers the main contents but leaves some context gaps.

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 100% coverage with clear 'featureId' description. The description adds value by specifying what data is included in the response, but parameter semantics are already clear from 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 retrieves complete feature data including tasks, delegations, and subtasks. It distinguishes itself from siblings like get_features (which likely lists features) and create_feature.

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 for obtaining detailed single feature data, but does not explicitly state when to use this over alternatives like get_features for listing or create_feature for creation. No exclusions or prerequisites are mentioned.

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

get_featuresC

Get list of features with optional filtering

ParametersJSON Schema

Name	Required	Description
`status`	No	Filter by feature status
`priority`	No	Filter by feature priority
`agent`	No	Filter features assigned to this agent
`createdBy`	No	Filter features created by this agent

TDQS

C2.8/5.0

Behavior1/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'with optional filtering' but omits any details about pagination, ordering, return format, error handling, or access requirements.

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

Conciseness3/5

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

The description is a single sentence with no wasted words, but it lacks structure such as bullet points or additional context. For a tool with 4 parameters, it is under-shared but not verbose.

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?

Given no output schema and 4 parameters, the description fails to specify the return format, list size limits, or behavior when multiple filters are combined. It is incomplete for reliable agent use.

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 input schema has 100% description coverage, meaning each parameter already explains its purpose. The description adds no extra semantic value beyond 'optional filtering', so baseline 3 is appropriate.

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 'Get list of features with optional filtering' clearly states the action (retrieve list) and the resource (features), distinguishing it from siblings like get_feature (singular), create_feature, etc.

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 get_feature for a single feature, or which filter combinations are advised. The description does not mention excluded scenarios or prerequisites.

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

get_hub_statusA

Get overview of hub activity, agents, and collaboration opportunities

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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 transparency burden. It does not disclose behavioral traits such as read-only nature, authentication needs, or rate limits. The tool is likely a simple get operation but lacks explicit safety cues.

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 a single concise sentence that front-loads the verb and resource. Every word contributes to clarity with no redundancy.

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 status overview tool with no parameters and no output schema, the description is adequate but vague. It does not specify what kind of overview (e.g., summary vs detailed stats) or potential edge cases.

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 zero parameters, and schema description coverage is 100%. Since there are no parameters, the description does not need to add parameter meaning. Per guidelines, baseline for 0 params is 4.

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's purpose with a specific verb 'Get' and resource 'overview of hub activity, agents, and collaboration opportunities'. It is distinct from siblings like 'get_feature', which target specific items.

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 use for a broad overview, but does not explicitly state when to use this tool versus alternatives like 'get_features' or 'get_messages'. No when-not-to-use or alternative mentions.

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

get_messagesC

Retrieve messages for an agent

ParametersJSON Schema

Name	Required	Description
`agent`	Yes	Agent identifier to get messages for
`markAsRead`	No	Mark retrieved messages as read
`type`	No	Filter by message type
`since`	No	Get messages since timestamp

TDQS

C2.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 bears full responsibility for behavioral disclosure. It does not mention side effects (e.g., marking messages as read via the markAsRead parameter), whether the operation is read-only, or any rate limits or authentication requirements.

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

Conciseness3/5

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

The description is a single short sentence. While not verbose, it is somewhat under-specified for a tool with 4 parameters. It could include brief additional context without becoming wordy.

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?

Given the tool has 4 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what messages are, how filtering works, or the return format, making it incomplete for an agent to invoke correctly.

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%, so the description does not need to add much, but it adds no extra meaning beyond the schema. The description does not clarify the markAsRead default behavior or the expected format for the since parameter.

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 'Retrieve messages for an agent' clearly states the verb (retrieve) and resource (messages), and differentiates from sibling tools like send_message which sends messages. However, it does not distinguish from other retrieval tools like get_features.

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?

The description provides no guidance on when to use this tool versus alternatives such as send_message or get_hub_status. It lacks context about prerequisites or typical use cases.

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

register_agentC

ParametersJSON Schema

Name	Required	Description
`id`	No	Agent identifier (optional - will be generated from project path if not provided)
`projectPath`	Yes	Agent working directory
`role`	Yes	Agent role description
`capabilities`	No	Agent capabilities
`collaboratesWith`	No	Expected collaborators

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided. The description does not disclose behavioral traits such as idempotency, side effects, or authorization needs. For a registration tool, this is inadequate.

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

Conciseness3/5

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

The description is a single concise sentence, but it is too minimal. It could benefit from additional structure without being verbose.

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?

With 5 parameters (some optional), no output schema, and no annotations, the description is incomplete. It does not explain the registration process, return value, or constraints.

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%, so the input schema already describes all parameters. The description adds no extra meaning beyond the schema, justifying a baseline score of 3.

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 'Register an agent with the hub' clearly states the action and resource. It is specific and distinguishes from sibling tools like create_task or send_message, though it does not explicitly differentiate.

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. Lacks any 'when to use' or 'when not to use' context.

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

send_messageB

Send a message to another agent or broadcast to all agents

ParametersJSON Schema

Name	Required	Description	Default
`from`	Yes	Source agent identifier
`to`	Yes	Target agent identifier or "all" for broadcast
`type`	Yes	Message type
`content`	Yes	Message content
`metadata`	No	Additional structured data
`priority`	No	Message priority	normal
`threadId`	No	Optional conversation thread ID

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It does not disclose side effects, delivery guarantees, logging, rate limits, or any behavioral traits beyond the basic action of sending a message. This is insufficient for an agent to understand the impact of invoking this 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 a single sentence with no wasted words. It is front-loaded and efficient, earning its place.

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 7 params (4 required) and no output schema, the description covers the basic action but omits any mention of return value, error handling, or async behavior. While adequate for a simple send, it lacks completeness for an agent to fully understand the interaction pattern.

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%, so parameter descriptions exist for all 7 parameters. The description adds no extra meaning beyond the schema; it merely restates that 'to' can be 'all'. Baseline 3 is appropriate as the schema does the heavy lifting.

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 action (send) and resource (message), and distinguishes between sending to one agent versus broadcasting to all. This is specific and differentiates from sibling tools like get_messages or register_agent.

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 when to broadcast vs. direct message, or how it relates to other communication tools. The description lacks context for proper tool selection.

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

syncA

Comprehensive sync with the hub - get messages, workload, and status in one call

ParametersJSON Schema

Name	Required	Description	Default
`agentId`	Yes	Agent ID to sync for
`markAsRead`	No	Mark retrieved messages as read

TDQS

A3.9/5.0

Behavior4/5

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

No annotations provided, but the description implies a read operation with optional side effect of marking messages as read. This is transparent about the bundled retrieval and optional mutation, though it does not detail error conditions or rate limits.

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 is concise, front-loads the purpose ('Comprehensive sync'), and efficiently communicates the tool's action and bundled outputs.

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 a bundled retrieval tool, but lacks detail on return structure or format. Given no output schema, the description should clarify what 'workload' and 'status' entail. Still, it provides enough context for an agent to infer usage.

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 clear parameter descriptions. The tool description does not add additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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 messages, workload, and status in one call, distinguishing it from sibling tools like get_messages and get_hub_status that only perform single functions.

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 wanting all three data types in one call, but does not specify when not to use it or provide explicit alternatives. The context of sibling tools allows inference, but lacks direct guidance.

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

update_subtaskC

Update subtask status and provide output/context

ParametersJSON Schema

Name	Required	Description
`featureId`	Yes	Feature ID
`subtaskId`	Yes	Subtask ID to update
`status`	No	New subtask status
`output`	No	Output or context for other agents
`blockedReason`	No	Reason if status is blocked
`updatedBy`	Yes	Agent updating this subtask

TDQS

C2.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 must disclose behavior. It implies mutation but does not explain idempotency, permission requirements, or error handling.

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

Conciseness3/5

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

The description is concise (one sentence) but lacks structure and does not include important details like return values or example usage.

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?

Given 6 parameters and no output schema, the description should explain return behavior and parameter interactions. It only states the core action.

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?

Input schema has 100% coverage; baseline is 3. The description adds no additional meaning beyond the schema descriptions.

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 the tool updates subtask status and provides output/context, distinguishing it from create_subtask and accept_delegation. However, it does not explicitly contrast with sibling tools.

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?

The description provides no guidance on when to use this tool versus alternatives. It 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.

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: registration, feature/task/subtask creation and retrieval, messaging, delegation acceptance, and a composite sync tool. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., create_feature, get_messages, accept_delegation). The only exception is 'sync', which is a single verb but serves as a comprehensive operation.

Tool Count5/5

12 tools cover the hub's domain: agent registration, feature/task/subtask management, messaging, delegation, status, and sync. This is well-scoped for a multi-agent collaboration server without being excessive.

Completeness4/5

The toolset covers core workflows: registration, CRUD for features/tasks/subtasks, messaging, delegation, and status. Minor gaps like update for features/tasks or delete operations are absent but not critical for the hub's purpose.

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

aXOAuthDeprecated
io.github.ax-platform
Agent-native collaboration network: orchestrate a team of long-running agents from any MCP client.
Knowledge & Memory Autonomous Agents Agent Orchestration
36
AgentNet
io.github.oxgeneral
Agent-to-agent referral network. Discover, recommend, and refer users between AI agents via MCP.
Agent Orchestration Autonomous Agents Communication
21
llm-bus
com.llm-bus
Coordinate multiple AI agents over MCP: atomic claims, leases, shared ledger, handoffs, tasks.
Agent Orchestration Autonomous Agents
29
memsprout AOAuth
com.memsprout
shared AI-context layer for teams — persistent memory your agents search and update over MCP
Knowledge & Memory RAG Systems
2

Related MCP Servers

Schelling Protocol
Autonomous Agents Agent Orchestration Search
codyz123
A
license
Not graded
quality
C
maintenance
Universal coordination hub for AI agents. Find collaborators, negotiate terms, form contracts, and build reputation through an MCP interface. Supports natural language search across agent networks.
Updated 5 months ago (2026-03-28 14:55 UTC)
4
MIT
kitty-hive
Autonomous Agents Agent Orchestration
seangx
A
license
Not graded
quality
A
maintenance
MCP server for multi-agent collaboration enabling AI agents to communicate, delegate tasks, and share artifacts across clients and machines with federation support.
Updated a month ago (2026-08-04 07:09 UTC)
31
1
MIT
hAIveMind MCP Server
Agent Orchestration Knowledge & Memory Autonomous Agents
lancejames221b
A
license
Not graded
quality
B
maintenance
Enables AI agents to share knowledge, coordinate tasks, and maintain persistent memory across distributed infrastructure with secure vaults and 130+ MCP tools.
Updated 2 months ago (2026-07-17 16:49 UTC)
7
MIT
subhive
Agent Orchestration Knowledge & Memory
Keradd
A
license
Not graded
quality
B
maintenance
A shared context and coordination layer for multiple AI agents over MCP, featuring semantic memory, dependency-aware task DAGs, auto-scheduling, role-based access, real-time push, and a live dashboard.
Updated 2 months ago (2026-07-08 12:25 UTC)
MIT

Appeared in Searches

Multi-agent AI orchestration system with specialized agents for venture capital analysis, McKinsey-style presentations, and financial analysis

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/gilbarbara/agent-hub-mcp'

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

Agent Hub MCP

Why Agent Hub MCP?

What You Get

Quick Start (5 minutes)

Step 1: Add Agent Hub MCP to Your AI Assistant

Step 2: Install Custom Commands (Recommended)

Step 3: Restart Your AI Assistant

Step 4: Verify Installation

📬 Automatic Message Notifications (Optional)

🤖 Works With Any MCP-Compatible AI Agent

✅ Verified Compatible (manually tested)

🔄 ** Likely compatible (MCP client support required)**

🧪 Help Us Test

Usage

Complete Workflow Example

1. Agent Registration

2. User Request & Agent Communication

3. Backend Response

4. Frontend Implementation

Key Features Demonstrated

Core Concepts

Message Types

Feature Collaboration

Key MCP Tools

🚀 How Multi-Agent Collaboration Works

1. Feature Creation

2. Task Delegation

3. Intelligent Work Distribution

4. Context Sharing & Coordination

5. Automatic Coordination

Advanced Setup

Custom Data Directory

For Other MCP Clients

Troubleshooting

Requirements

Environment Variables

Contributing

Documentation

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

🔄 Likely compatible (MCP client support required)