mcp-agent-collaboration

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.2/5 across 8 of 8 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
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 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
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 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior1/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
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 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-agent-collaboration MCP server](https://glama.ai/mcp/servers/vkolotov/mcp-agent-collaboration/badges/card.svg)](https://glama.ai/mcp/servers/vkolotov/mcp-agent-collaboration)

Score Badge

Copy to your README.md:

[![mcp-agent-collaboration MCP server](https://glama.ai/mcp/servers/vkolotov/mcp-agent-collaboration/badges/score.svg)](https://glama.ai/mcp/servers/vkolotov/mcp-agent-collaboration)

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/vkolotov/mcp-agent-collaboration'

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