Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-agent-collaboration Coordinate a code review: create topic 'pr-42', add reviewer agent"
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.
In-memory MCP server for cooperative collaboration between separate agents.
The intended workflow is:
A coordinator/main agent starts this MCP server as a dedicated Streamable HTTP process.
The coordinator creates a topic and joins it.
Secondary agents join the same topic with friendly names such as builder or reviewer.
Agents exchange direct and broadcast messages through MCP tools.
Idle agents long-poll with read_messages.
Working agents use check_in to report progress and read messages in one call.
Messages are held only in memory. Restarting the server clears all topics, members, and messages.
After a restart, old join_token values are invalid and agents must re-join.
python3 -m venv .venv
. .venv/bin/activate
pip install -e .Related MCP server: agent-comm
mcp-agent-collaboration --host 127.0.0.1 --port 8000The MCP endpoint is:
http://127.0.0.1:8000/mcpFor Codex, add a Streamable HTTP MCP server in config.toml:
[mcp_servers.agent_collaboration]
url = "http://127.0.0.1:8000/mcp"
tool_timeout_sec = 600Set tool_timeout_sec high enough for your preferred long-poll duration. The server itself does not impose a maximum wait; the MCP client/tool runtime may still have its own timeout.
For Codex, the preferred setup is the stdio autostart proxy. Codex launches the proxy as a normal stdio MCP server; the proxy starts the shared Streamable HTTP server on localhost if it is not already running, then forwards tool calls to it.
From this source checkout:
codex mcp add agent_collaboration \
--env PYTHONPATH=/home/vkolotoff/projects/mcp-agent-collaboration/src \
-- python3 -m mcp_agent_collaboration.autostart_stdioAfter installing the package, this shorter form is enough:
codex mcp add agent_collaboration -- mcp-agent-collaboration-stdioDefaults:
MCP_AGENT_COLLAB_HOST=127.0.0.1
MCP_AGENT_COLLAB_PORT=8000
MCP_AGENT_COLLAB_PATH=/mcp
MCP_AGENT_COLLAB_LOG=/tmp/mcp-agent-collaboration.log
Override them with --env only when needed.
To install the package into your user-level Python environment:
python3 -m pip install --user /home/vkolotoff/projects/mcp-agent-collaboration
codex mcp add agent_collaboration -- mcp-agent-collaboration-stdiocodex mcp add writes to the global Codex MCP config by default, so the server
is available to future Codex sessions after restart.
create_topicCreate a topic by string name.
{
"topic": "build-123"
}join_topicJoin a topic with a friendly agent name. The returned join_token is required for message operations.
{
"topic": "build-123",
"agent_name": "reviewer",
"role": "secondary",
"create_if_missing": true
}Agent names are unique within a topic. The literal name all is reserved for broadcast messages.
send_messageSend a direct message to one agent or a broadcast to all agents currently joined.
{
"join_token": "opaque-token",
"recipient": "reviewer",
"body": {
"type": "review_request",
"task_id": "task-001",
"summary": "Implementation is ready for review."
}
}Use "recipient": "all" for broadcast. Broadcast recipients are snapshotted at send time, so agents who join later do not receive older broadcasts. The sender receives its own broadcast by default because it is also a joined agent; set include_self to false to opt out.
Compact output is the default:
{
"id": "msg_123",
"stored": true
}Pass "verbosity": "full" only when you need topic, sender, and recipient metadata.
read_messagesRead and consume pending messages for the joined agent.
{
"join_token": "opaque-token",
"timeout_ms": 600000,
"max_messages": 20
}Compact output is the default:
{
"timed_out": false,
"messages": [
{
"id": "msg_123",
"from": "reviewer",
"body": {
"type": "review_result",
"status": "approved"
}
}
]
}Pass "verbosity": "full" only when you need topic, recipient, timestamp, or broadcast snapshot metadata.
Long-poll behavior:
If messages are already pending, return immediately.
If no messages are pending and timeout_ms > 0, hold the request open until a relevant message arrives or the requested timeout elapses.
If timeout_ms is 0, return immediately with pending messages or an empty timeout response.
The server does not impose its own maximum timeout.
Returned messages are consumed.
Deletion behavior:
Direct messages are deleted after the recipient reads them.
Broadcast messages are deleted after every send-time recipient has read them.
If an agent leaves a topic, it is removed from unread recipient sets so old broadcasts can be cleaned up.
check_inOptionally send a message and read pending messages in one tool call. This is
the preferred work-loop tool for secondary agents because it avoids a separate
send_message call followed by read_messages.
{
"join_token": "opaque-token",
"timeout_ms": 0,
"recipient": "coordinator",
"body": {
"type": "progress",
"task_id": "task-001",
"done": "Added compact read tests.",
"next": "Update docs.",
"blockers": []
}
}Compact output:
{
"sent": {
"id": "msg_123",
"stored": true
},
"timed_out": true,
"messages": []
}Omit body to use check_in as a compact read. Use a long timeout_ms when
idle, and timeout_ms: 0 or a short timeout between work chunks.
body: null is treated the same as omitting body, so it cannot be used as a
sent message payload. If body is provided with a large timeout_ms, the send
confirmation is returned only when the read side wakes or times out; use
timeout_ms: 0 for fire-and-return progress updates.
leave_topicLeave a topic and stop receiving future messages.
{
"join_token": "opaque-token"
}list_topicsList topics with member and pending-message counts.
list_topic_membersList members in a topic.
This MCP does not forcibly interrupt running agents. Messages wake agents that are currently blocked in read_messages; agents that are actively working see messages at their next check-in.
Secondary agents must:
Join with a clear role name.
Send a readiness message to the coordinator.
Work in bounded chunks.
Use check_in to send progress to the coordinator and read messages at reasonable intervals.
Always poll after completing a work chunk, after sending a review result, and after reporting task completion.
Treat urgent or cancellation messages as priority instructions when seen.
Send task_complete when done.
Ask the coordinator for more work, then enter idle long-poll mode.
The coordinator must:
Start the server.
Create the topic.
Join as coordinator or another clear main-agent name.
Assign tasks to secondary agents.
Watch progress, blockers, completion messages, and requests for more work.
Poll after sending assignments, clarifications, cancellations, or follow-up work so queued replies are not missed.
Recommended message body types:
presence
task_assignment
progress
task_complete
request_more_work
review_request
review_result
cancel_task
interrupt
interrupt is cooperative. It is not forced preemption.
python3 -m unittest discover -s testsOptionally send a message, then read pending messages in one tool call.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| recipient | No | coordinator | |
| verbosity | No | compact | |
| join_token | Yes | ||
| timeout_ms | Yes | ||
| include_self | No | ||
| max_messages | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It transparently states the two main operations (optional send followed by read pending messages) but omits behavioral details such as whether pending messages are marked as read, behavior on timeout, or side effects. Basic transparency exists, but it is not comprehensive for a tool with timeout and messaging semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the core action: optional send followed by reading pending messages in one call. It is front-loaded with the main purpose and contains no filler words, though this brevity comes at the expense of parameter clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and an output schema, this description is incomplete. It lacks details on parameter semantics, usage context, and behavioral specifics like timeout handling. While the output schema may define return values, the description provides insufficient operational context for an agent to decide when and how to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain any of the 7 parameters. Terms like 'send a message' hint at body/recipient but do not connect to specific parameters such as join_token, timeout_ms, verbosity, include_self, or max_messages. The description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's dual function of optionally sending a message and then reading pending messages in a single call. It distinguishes itself from sibling tools like send_message and read_messages by emphasizing the combined one-call nature. It could be more explicit by naming those alternatives, but it is not ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus calling send_message and read_messages separately. The description implies a combined use case but does not state preferred conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a collaboration topic by name.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not mention side effects, idempotency, error conditions, or permissions. This is a bare statement of intent with no additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that directly states the verb and object, making it highly concise and front-loaded. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema exists, the description still lacks essential context such as usage guidance and behavioral outcomes. Given no annotations and a sibling set, the description is too thin to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds 'by name,' indicating that the 'topic' parameter is the name of the topic, which the schema does not specify. However, it lacks details like formatting, uniqueness, or expectations, so the compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a collaboration topic, using the specific verb 'create' and the resource 'topic'. It distinguishes it from sibling tools like join_topic or list_topics, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use create_topic versus alternatives such as join_topic or list_topics. The description only states the action, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Join a topic with a friendly agent name and receive a join_token.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | secondary | |
| topic | Yes | ||
| agent_name | Yes | ||
| replace_existing | No | ||
| create_if_missing | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the action and a token response. It doesn't mention side effects such as creating the topic if missing (create_if_missing), role assignment, or replacement behavior (replace_existing), nor does it clarify the purpose of join_token. This lack of detail limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it omits important parameter semantics and context, making it under-specified relative to the tool's complexity. It's concise but not adequately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and an output schema, the description is too sparse. It doesn't explain the function of key parameters, usage context, or behavior when topics are missing. The output schema may cover return values, but behavioral and semantic details are incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It references 'topic' and 'friendly agent name' (agent_name), but provides no meaning for role, replace_existing, or create_if_missing. It adds some value for agent_name but leaves most parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: joining a topic with an agent name and receiving a join_token. It uses the specific verb 'join' and references a resource ('topic'), distinguishing it from sibling tools like create_topic or leave_topic, though it doesn't explicitly contrast itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use join_topic versus create_topic or check_in. The description doesn't mention prerequisites, whether the topic must exist, or how it differs from creating a topic. There's no 'when to use' or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Leave the joined topic.
| Name | Required | Description | Default |
|---|---|---|---|
| join_token | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states the action 'leave' but does not disclose side effects, prerequisites, required permissions, or whether the action is reversible. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it extremely concise and front-loaded. Every word is essential, but its brevity sacrifices necessary context, so it is not as effective as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity and the presence of an output schema, the description is incomplete. It lacks any context about when to leave a topic, what happens after leaving, or any dependencies on prior actions like joining. The agent is left to infer the tool's role from the parameter and siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the join_token parameter at all. Schema coverage in the description is 0%, so the agent receives no help understanding what the token is, how to obtain it, or its role in leaving the topic. The parameter name alone is not sufficient to convey its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Leave the joined topic' uses a clear verb+resource structure, indicating the action of leaving a topic. It is distinct from sibling tools like join_topic, though it does not explicitly clarify whether 'joined topic' refers to the current session or the topic identified by join_token, leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used after joining a topic, nor does it note any exclusions or conditions. There are no references to sibling tools or when to prefer this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active members in a topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states a read-only action ('List...') which is transparent about not mutating data, but it does not define what 'active' means, whether the caller must be a member, or any other behavioral traits. The core action is clear, but meaningful details are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that states the action and scope with no filler words. It is appropriately sized for the tool's simplicity and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with one parameter and an output schema (so return values need not be described), the description leaves gaps around the 'topic' parameter format and the definition of 'active.' It is minimally sufficient for a basic list operation but could be more complete with explicit parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required string parameter 'topic' with zero description coverage. The description repeats 'in a topic' but does not clarify whether the value should be a topic ID, name, or other identifier. No additional meaning is added beyond the parameter name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with resource 'topic members,' clearly distinguishing from siblings like list_topics (which lists topics) and create_topic/join_topic/leave_topic. It also adds the modifier 'active' to specify the scope of members, making the purpose precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_topics or read_messages. It lacks any mention of prerequisites, exclusions, or a context where this tool is preferred, leaving the agent to infer from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List topics with member counts and pending in-memory message counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It adds useful context about the data returned, but it does not explicitly state that the operation is read-only or mention any potential side effects, rate limits, or performance characteristics. This leaves a moderate transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that front-loads the action and resource. Every word contributes meaning, with no redundancy or filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an existing output schema, the description effectively covers the core purpose and provides relevant detail about the returned data. It could be slightly more explicit about the read-only nature, but overall it is sufficiently complete for such a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers parameter semantics. The baseline score of 4 applies, and the description correctly avoids inventing parameter details that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource 'topics', while also specifying the exact data returned (member counts and pending in-memory message counts). This distinguishes it from sibling tools like list_topic_members and read_messages, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_topic_members or read_messages. The description does not provide any context about when this tool is the appropriate choice, leaving the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Long-poll, read, and consume pending messages for the joined agent.
| Name | Required | Description | Default |
|---|---|---|---|
| verbosity | No | compact | |
| join_token | Yes | ||
| timeout_ms | Yes | ||
| max_messages | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of transparency. It reveals that the tool blocks via long-polling and consumes (likely deletes) messages, which are important behavioral traits. However, it omits details about timeout handling, idempotency, or what happens when no messages are available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately communicates the core behavior. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no annotation support, and no parameter descriptions. The description fails to explain how to use the parameters, the meaning of consuming messages, or how this fits with joining topics. The output schema exists but is not shown, so the description is insufficient for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description mentions no parameters. The only indirect hint is 'joined agent', which relates to join_token, but timeout_ms, verbosity, and max_messages are entirely unexplained. The description adds minimal value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies concrete actions (long-poll, read, consume) on a clear resource (pending messages) for the joined agent. This clearly distinguishes it from send_message and other topic management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for receiving/consuming pending messages, which implicitly tells when to use it versus send_message. It lacks explicit exclusions, but the intent is obvious from the verb and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a direct or broadcast message in the joined topic.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| recipient | No | all | |
| verbosity | No | compact | |
| join_token | Yes | ||
| include_self | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 states 'send' without explaining side effects, prerequisites (such as having a valid join_token), or consequences of sending. The phrase 'in the joined topic' hints at the requirement but lacks explicit detail about what happens if not joined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. It is front-loaded with the action and object, making it easy to grasp quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and an output schema, but the description is minimal. While the output schema covers return values, the description omits necessary context like the role of join_token, the meaning of verbosity, and the behavior for include_self. It is adequate for a simple send action but leaves gaps for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It adds meaning to 'recipient' via 'direct or broadcast', but it does not explain the required 'join_token', 'body', or the optional 'verbosity' and 'include_self'. This leaves most parameters semantically under-defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (send), the object (message), and the scope (in the joined topic). It distinguishes between direct and broadcast modes, which aligns with the 'recipient' parameter and differentiates from sibling tools like read_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for sending messages within a joined topic, providing context for when to use it. However, it does not explicitly state alternatives or situations where it should not be used, leaving usage guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: topic lifecycle (create, join, leave), messaging (send, read, check_in), and listing (topics, members). check_in is a convenience combination but its description clarifies its dual role.
All tool names follow a consistent verb_noun pattern (create_topic, join_topic, send_message, read_messages, list_topics, list_topic_members). Minor phrasal verb 'check_in' still fits the style.
Eight tools cover the domain of topic-based collaboration without redundancy or bloat. Each tool serves a distinct function and the count is well within the ideal range.
The surface covers topic creation, joining/leaving, messaging, and listing topics/members. A delete_topic operation is missing but might be intentionally omitted for ephemeral in-memory topics, so minor gap only.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Remote MCP server for The Colony — a social network for AI agents (posts, DMs, search, marketplace).
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Agent-native collaboration network: orchestrate a team of long-running agents from any MCP client.
Hosted MCP memory and agent control plane for durable conversations, jobs, and operations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vkolotov/mcp-agent-collaboration'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
