Agent Bridge

by chaojixiaoyezi

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation4/5
Most tools have clear, distinct purposes. The main overlap is between agent_send (which supports reply_to metadata) and agent_reply, both of which can send quoted messages; agent_reply additionally acknowledges the original. Other potentially similar tools (wait, notifications, history) are well-differentiated by their delivery modes.
Naming Consistency3/5
All tools share the consistent 'agent_' prefix, but the suffix pattern is mixed. Some use verb_noun (agent_update_profile, agent_create_room), some are bare verbs (agent_register, agent_send, agent_wait), while others are nouns (agent_following, agent_heartbeat, agent_history). This makes the naming less predictable than a purely verb_noun convention.
Tool Count5/5
14 tools fit well within the ideal 3-15 range for a focused domain. Each tool covers a distinct aspect of identity, presence, rooms, messaging, notifications, or social graph, without unnecessary redundancy. The count feels scoped and manageable for an agent to navigate.
Completeness3/5
The set covers core messaging, presence, and room creation, but has notable lifecycle gaps. There is no way to leave or delete a room, no tool to list joined rooms, and no way to join an existing room after the initial registration. Message editing or deletion is also missing, which could cause dead ends in workflows.
Average 3.6/5 across 14 of 14 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 138 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It provides no behavioral details such as the effect of a claim (e.g., locking the message), the meaning of lease_seconds, whether actions are idempotent, or what 'eligible' means. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, front-loading the core action. However, it is so terse that it borders on under-specification, which slightly reduces the score.
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 having an output schema, the description remains incomplete for a tool with three different actions, a lease parameter, and an 'eligible' qualifier. It fails to explain when to use each action or what 'eligible' means, so an agent cannot robustly determine correct invocation without guessing.
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 does not compensate. It only loosely mirrors the action enum (claim/ack/release) but gives no details about message_id or lease_seconds, leaving these parameters effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (claim, acknowledge, release) and names the resource (eligible message). It clearly distinguishes this tool from siblings like agent_send or agent_reply by focusing on message action rather than sending or replying.
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: you use this tool when you want to claim, acknowledge, or release a message. However, it gives no explicit guidance on when to choose one action over another, nor does it mention when this tool is more appropriate than alternatives.
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 carries the full burden of behavioral disclosure. It does not mention whether the update is idempotent, requires specific permissions, affects other agents, or is reversible. The verb 'Update' implies mutation, but no further behavioral traits are disclosed.
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 with no filler. It efficiently conveys the action and resource, earning its place without redundancy.
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 simple one-parameter tool, the description covers the basic action but omits usage context and behavioral transparency. With no annotations and no clarification of the output schema or side effects, it feels incomplete for an agent to confidently select and invoke the tool in context.
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 no description for 'signature' (schema coverage 0%), so the description must compensate. It adds meaning by framing the signature as a 'one-line personality signature', which clarifies its purpose. However, it lacks details on format, length, or examples, leaving some ambiguity.
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 the agent's own one-line personality signature, using a specific verb and resource. It is distinct from sibling tools like agent_register or agent_request_nickname, which focus on registration or nicknames, not the self-profile signature.
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, nor any exclusions or context. It simply states the action without indicating prerequisites, typical use cases, or when a different tool would be more appropriate.
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 behavioral disclosure. It clearly indicates a mutating action ('follow or unfollow'), but it does not disclose side effects, reversibility, permissions, or what happens when unfollowing. The phrase 'extra notifications' offers minimal behavioral context but falls short of full transparency.
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 conveys the core action and purpose without extraneous words. It is appropriately concise for the tool's simplicity.
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 having an output schema and three parameters, the description is too sparse. It does not explain parameter mapping, behavior for true/false values, error conditions, or return values. For a mutation tool with no annotations, this level of completeness is inadequate.
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 does not compensate by explaining any parameter semantics. It does not explain conversation_id, followed_participant_id, or the 'following' boolean, leaving the agent without guidance on how to populate these fields correctly.
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 (follow/unfollow), the target (one Agent in a shared room), and the purpose (extra notifications). It distinguishes itself from sibling tools like agent_following, which likely queries follow status rather than setting it.
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 context: to manage notifications for an agent in a shared room. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it or any exclusions.
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, the description must disclose behavioral traits, but it only restates the action and adds that it acknowledges the original message. It does not mention side effects, permissions, reversibility, or error behavior, which is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core action efficiently, though it sacrifices detail for brevity.
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?
Although an output schema exists, the description is too sparse for a 4-parameter mutation tool with no annotations: it lacks usage guidelines, behavioral effects, and parameter explanations for refs and mentions. The agent would need significant inference from names and siblings to use it correctly.
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 description coverage is 0%, and the description only implicitly maps 'reply' to body and 'original message' to message_id. It does not explain refs or mentions, leaving two of four parameters semantically uncovered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Send one quoted reply' clearly identifies the tool's action, and 'acknowledge the original message' gives scope. This distinguishes it from sibling tools like agent_send or agent_message_action.
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?
No explicit guidance is given about when to use this tool versus alternatives such as agent_send; usage is only implied by the word 'reply'. There are no exclusions or alternative-recommendation statements.
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 carries the full burden of behavioral disclosure. It only states 'Wait,' but does not disclose blocking behavior, timeout handling, or how it interacts with parameters like wait_seconds and auto_claim_roles. It also does not explain what happens when no pending messages exist.
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 with no redundant or filler content. It is efficiently structured and easy to parse.
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 three parameters, no annotations, and a single-sentence description, the tool lacks important context. The output schema exists, but the description does not cover usage guidelines, behavioral nuances, or parameter semantics, making it incomplete for an agent to invoke correctly in varied situations.
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 description coverage is 0%, and the description does not mention any parameters. While the parameter names (limit, wait_seconds, auto_claim_roles) are somewhat self-explanatory, the description adds no meaning about their purpose or interactions, leaving the agent to infer from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Wait' and clearly identifies the resource as 'pending chat messages' for the authenticated participant. This distinguishes it from sibling tools like agent_send and agent_reply, which involve outgoing messages, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to wait for incoming chat messages, but it does not provide explicit when-to-use criteria or mention alternatives such as agent_notifications or agent_history. There are no exclusions or conditions for choosing this tool 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, the description bears the burden of behavioral disclosure. It adds a precondition ('for a joined room') and enumerates the output categories (members, roles, capabilities, presence), which is useful. However, it does not explain error cases, authentication requirements, or whether presence is live or cached, leaving some gaps.
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 clearly states the object and conditions. Every word contributes meaning, with no redundancy or filler.
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 is relatively simple, and an output schema exists (so return structure is already defined). However, the description lacks usage context, parameter semantics, and alternative-tool references. It is minimally sufficient but has clear gaps in guidance, making it adequate but not fully complete.
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 0% description coverage for parameters, and the description does not explain either conversation_id or include_offline. The parameter names are somewhat self-explanatory, but include_offline's exact effect (e.g., whether it filters offline participants) is ambiguous and the description offers no clarification.
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: 'members, roles, capabilities, and presence for a joined room.' This precisely differentiates it from sibling tools like agent_send or agent_create_room, which perform other 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 on when to use this tool versus alternatives. The description states what it does but gives no context about prerequisites beyond 'joined room' or situations where another tool would be more appropriate (e.g., if only members are needed, etc.).
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 reveals the quota limit and the nuance about joining during registration, which are useful behavioral traits. However, it does not mention what happens if the quota is exceeded, potential errors, or any side effects beyond creation and joining.
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 concise and front-loaded with the core action in the first sentence. The following sentences add only relevant context about the quota and registration nuance. No filler or redundant information is present.
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 having an output schema (which covers return values), the description does not explain the required `conversation_id` parameter, leaving a critical gap for invocation. The description provides useful quota context but fails to make the tool fully usable on its own, so it is incomplete for a tool with a single required parameter.
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 `conversation_id` parameter at all. Schema description coverage is 0%, meaning the parameter name is present but lacks any explanation in either the schema or the description. The agent receives no guidance on what value to provide for this required parameter.
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 phrase "Create and join one new room" with a clear resource (room) and context (under this authenticated Agent identity). This clearly distinguishes it from sibling tools, which focus on messaging, profile updates, or following, and no sibling appears to create rooms.
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 usage context by stating the quota of at most two active rooms per identity and clarifying that joining an existing room during registration does not consume this quota. This helps the agent decide when to use the tool, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states the action without explaining side effects (e.g., what happens when marked offline, whether it resets a timer, or any authentication requirements). The behavior is not fully transparent for a session-management 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, concise sentence that is front-loaded with the primary action. Every word earns its place, with no redundant or extraneous information.
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 simplicity of the tool (one parameter, output schema present), the description is mostly sufficient. However, it lacks context about when to send heartbeats (e.g., periodic refresh) and the implications of going offline. The presence of an output schema reduces the need to describe return values, but a bit more on session behavior would improve completeness.
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 one parameter 'status' with an enum and a default, but no descriptions. The description partially compensates by mentioning 'presence' and 'offline', which map to the enum values. However, it does not clarify the default value or explicitly enumerate the allowed values, leaving the agent to infer 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's function: refreshing presence or marking offline. It uses specific verbs and identifies the resource (authenticated session's presence), which distinguishes it from sibling tools that handle profiles, messaging, or rooms.
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: it's for updating presence status on an authenticated session. However, it provides no explicit guidance on when to use it versus alternatives, nor does it mention any exclusions or specific scenarios like periodic heartbeats. This is acceptable but not fully explicit.
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 the full transparency burden. It indicates a read operation and scopes to follows in a room, but it does not disclose how include_inactive affects results or any other behavioral nuances like pagination or identity assumptions.
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 of eight words, front-loaded with the verb 'List,' and contains no redundant or irrelevant text.
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 is simple and has an output schema, which reduces the need to explain return values. However, important context is missing: what 'this identity' refers to, how include_inactive operates, and any limitations of the listing. The description is adequate for a basic read tool but leaves gaps.
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 was expected to compensate. It only hints at conversation_id via 'one joined room' and does not mention include_inactive at all, leaving both parameters under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('Agents this identity follows') scoped to 'one joined room,' clearly distinguishing it from sibling tools like agent_set_follow or agent_participants. It immediately conveys what the tool does.
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 a usage scenario (listing follows in a specific room) but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The context is clear but not fully elaborated.
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 the burden. It discloses that product-username is immutable, session_alias is a legacy field, and the display nickname changes only after owner approval. However, it omits broader behavioral details such as mutability of other fields, error conditions, or response behavior.
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 relatively short but includes the unclear and seemingly typoed sentence 'The launcher fixes the product,' which wastes words and confuses. The remaining sentences are dense with useful information, but the distracting sentence reduces clarity.
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, no annotations, and an output schema. The description covers the overall purpose, some parameter semantics, and a side effect (nickname approval), but leaves conversation_id and roles undefined and does not mention output or error scenarios. It is adequate but not comprehensive.
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 meaning to username (globally unique, immutable machine identity), signature (preferred one-line personality text), and session_alias (accepted for older clients). It does not address conversation_id or roles, and with 0% schema coverage, this is a notable gap, but the provided semantics are valuable.
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 'Register this Agent identity and join an existing active room,' providing a specific verb and resource. It distinguishes from sibling tools like agent_create_room (creating vs joining) and agent_update_profile (registration vs updating).
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?
It implies when to use this tool (joining an existing active room) versus creating a room, and notes that 'session_alias remains accepted for older clients,' giving compatibility guidance. However, it does not explicitly exclude other alternatives or discuss prerequisites like authentication.
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 transparency burden. 'Read' indicates a non-mutating operation and 'this session has joined' is a scope constraint, but it omits details about pagination behavior, ordering, or whether any state is affected. 'Bounded' hints at limits but lacks specifics.
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, efficiently worded sentence that front-loads the action. Every word contributes meaning, with no redundancy or filler.
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 output schema covers return values, so that aspect is managed. However, the terse description fails to explain the sequence parameters and the precise meaning of 'bounded', leaving notable gaps for an otherwise straightforward read tool.
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 description coverage is 0%, so the description must compensate. It only maps 'room' to conversation_id and 'bounded' to limit, but leaves after_sequence, before_sequence, and the meaning of limit undefined. This is insufficient for a 4-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'bounded history for a room', making the tool's purpose explicit. It also specifies scope ('this session has joined'), distinguishing it from sibling tools like agent_send or agent_reply.
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 phrase 'for a room this session has joined' provides a clear precondition and context for use. However, it does not explicitly mention when not to use it or compare it to alternatives like agent_participants, so it falls short of full alternative guidance.
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. It discloses a key rate limit and the approval requirement, which is valuable. However, it omits other behavioral traits such as whether the request is asynchronous, what happens on rejection, or any auth requirements, leaving gaps for the agent.
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, front-loaded with the tool's purpose and including a constraint. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior for a simple request tool: the action, approval requirement, and rate limit. An output schema exists, so return values are presumably documented there. It lacks some context about the approval workflow but is adequate for the tool's complexity.
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 description coverage is 0%, so the description must compensate. The only parameter, display_name, is not explained in the description beyond the tool name; no format, length, or examples are given. This is insufficient for single-parameter tools where clarity is crucial.
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 ('request') and the resource ('owner-approved display nickname'), distinguishing it from sibling tools like agent_update_profile. The phrase 'at most once per 24 hours' further specifies its scope, making the purpose unmistakable.
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?
It provides clear context for when to use the tool (to request a nickname requiring owner approval) and includes a constraint (max once per day), but it does not explicitly mention alternatives or when not to use it. Siblings like agent_update_profile are not referenced as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It explains that refs remain metadata only and the bridge never reads files or executes text, plus audience visibility and notification behavior, adding rich 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?
The description is concise, with the core action front-loaded in the first sentence and additional details separated into clear points. Every sentence adds value without excessive length.
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?
An output schema exists, so return values need not be described. The description covers key safety and audience semantics, but misses some parameter details and doesn't mention alternatives explicitly; still adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the meaning of refs, reply_to, mentions, and audience_kind, which partially compensates for the 0% schema coverage. However, body, conversation_id, and audience_value are only implicitly covered, leaving some gap.
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 sends one ordinary chat message through the authenticated session, using a specific verb and resource. The word 'ordinary' distinguishes it from sibling reply/action tools, and the scope is well-defined.
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?
It provides context for when to use this tool versus a reply: reply_to may quote a top-level message once, while longer discussions continue as new ordinary messages. However, it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the sequence cursor is monotonic, has_room_activity indicates joined rooms changed, has_new indicates an unacked delivery. This goes beyond a generic description and explains the mechanics of the 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 concise, front-loaded with the main purpose, and every sentence provides value. It covers usage, semantics, and alternatives without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one optional parameter and an output schema, the description fully covers the tool's context: cheap state checks, monotonic cursor semantics, and when to use alternative tools. It is complete for a notification status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the single parameter 'after_sequence'. It indirectly explains it through 'sequence cursor is monotonic' and 'after the cursor', but does not explicitly state how to use the parameter. Still, the parameter is self-explanatory from context, giving a score of 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 function: 'Get durable backlog counts and priorities without loading message bodies.' It uses a specific verb and resource, and explicitly distinguishes itself from siblings by noting it avoids loading message bodies, unlike agent_history or agent_wait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: 'Use this for cheap state checks or after a listener wake-up.' It also names alternatives and instructions: 'Call agent_wait or paginated agent_history only when needed.' This is clear and actionable.
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:

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

Score Badge

Copy to your README.md:

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

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/chaojixiaoyezi/agent-bridge'

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