mailnotmilk
Server Quality Checklist
Latest release: v1.4.0
- Disambiguation2/5
Multiple tools have unclear boundaries: post_message vs chat_say vs browser_send_message all send messages but to different targets; check_inbox, list_history, and chat_history all retrieve messages but with different scopes. The many list/send variants make it hard for an agent to pick the right tool.
Naming Consistency3/5There are consistent clusters (e.g., browser_* prefixed tools, verb_noun like check_inbox, read_message), but the overall set mixes conventions: chat_link and chat_history are noun phrases, mailbox_stats is noun_noun, and relay_tick is noun_verb. Still readable, but not uniform.
Tool Count2/5With 36 tools, the server is overloaded, far beyond the typical well-scoped range. Even though it covers messaging, browser automation, and presence, the sheer number makes it unwieldy and suggests too many responsibilities for a single MCP server.
Completeness3/5The messaging and presence lifecycle is fairly complete (send, read, reply, search, archive, react, status), but missing obvious operations like editing or deleting messages. Chat management is also thin (no leave/delete/rename), and browser automation is limited to AI pages. Notable gaps exist, but core workflows work.
Average 3.2/5 across 36 of 36 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 85 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 failing
This repository is licensed under MIT License.
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.jsonto 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?
No annotations exist, so the description must disclose side effects and semantics. 'Remember interest' implies a state change and 'roster metadata' suggests modification of metadata, but there is no statement about idempotency, reversibility, authentication needs, or the impact on the room. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with no unnecessary words, but it is underspecified rather than appropriately structured. The phrase 'Remember interest' is a fragment and is not front-loaded with the clearest action; overall, it reads as a title more than a helpful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and no annotations, this description is far from complete. It fails to clarify the effect of subscribing, the expected return value, or how 'agent_id' is used. The extensive sibling list increases the need for disambiguating context, which is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters, 'room' and 'agent_id', with no descriptions. The description only uses the word 'room' as part of the prepositional phrase 'in a room' and never explains the parameters, their roles, formats, or the significance of 'agent_id'. With 0% schema description coverage, no parameter meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a resource ('room') and an action ('remember interest'), but the verb is vague and does not clearly convey a subscription operation. It does not differentiate from sibling tools like join_chat or mark_unread, and the parenthetical 'roster metadata' is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description is a single clause without context, prerequisites, or exclusions, leaving the agent to infer the use case from the tool name 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?
With no annotations, the description must carry the burden of behavioral disclosure. It mentions 'priority-sorted' and 'optional short wait,' but does not explain what 'wait' does (e.g., poll for new messages), whether messages are marked as read, or any side effects or access requirements. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It is efficient and reads well, though 'optional short wait' is vague and takes away slightly from the overall clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description is far too minimal to enable correct invocation: it does not explain return format, paging behavior, parameter semantics, or how it relates to sibling tools. This is completely inadequate for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the absence of parameter docs. It only hints at wait_ms via 'optional short wait' and says nothing about room, limit, agent_id, or priority, leaving five parameters without meaningful explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists unread messages, specifying message types (DMs, broadcasts, @mentions). This is a specific and identifiable purpose, though it does not explicitly name sibling tools to distinguish itself from them, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like chat_history, read_message, or search_messages. The description implies usage for viewing unread messages but offers no exclusions or alternative suggestions, leaving the agent without clear selection criteria.
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. It discloses the sequence and the optional wait, which is useful, but it omits critical behavioral details: whether the tool blocks, side effects on browser/chat state, failure modes, or whether it requires an existing browser connection. The vague 'mailnotmilk chat' further obscures the actual action performed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core purpose ('One relay cycle') and uses a clear step-by-step arrow notation. It is appropriately short, though the 'mailnotmilk' oddity and lack of punctuation reduce polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five optional parameters, no output schema, and no annotations, the description is insufficient for an agent to fully understand the tool's behavior and expected outcomes. It does not explain what the cycle returns, when to call it, or what 'mailnotmilk' refers to. The complexity of a relay orchestration demands more context than a one-line pipeline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only peer has a description). The tool description adds minimal parameter meaning: it references a 'coding-agent' which likely maps to the peer param, but it doesn't explain site, title, chat_id, or wait_peer_ms. The optional wait is mentioned, but without linking to wait_peer_ms. The description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description outlines a specific multi-step process (extract browser messages, chat, wait, send back), which goes beyond a tautology. However, the phrase 'mailnotmilk chat' is ambiguous and likely a typo or obscure reference, weakening clarity. It does somewhat distinguish from simpler sibling tools like browser_extract_messages or chat_say by describing a combined cycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use relay_tick versus composing the individual steps manually. The description implies it is a higher-level orchestration, but it doesn't state prerequisites (e.g., browser connection, active chat) or mention alternatives like using browser_extract_messages + chat_say separately.
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 provided, the description carries the full burden of behavioral disclosure, but it reveals nothing beyond the obvious 'post' action. It does not mention side effects, permissions, reversibility, return format, or any other behavioral characteristics, making it impossible for the agent to anticipate the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff or redundant information. It is front-loaded with the verb and object, but it is too terse to serve as a complete guide, though conciseness itself is not a fault.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity (4 parameters, no output schema), the description is still incomplete. It omits guidance on the optional parameters, any return value, and usage context, leaving significant gaps for an agent attempting to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 implicitly explains chat_id ('by chat id') and text ('message'), but the optional 'to' and 'from' parameters are completely unaddressed, leaving the agent with only names to guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Post a message') and the target resource ('a chat room'), with the key parameter ('by chat id'). It is unambiguous, though it does not distinguish from sibling tools like post_message or browser_send_message, which could overlap in function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It only states what it does; there is no mention of context, prerequisites, or exclusions, leaving the agent without a basis for tool selection among several messaging-related tools.
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, but it only states the action. It does not disclose whether the operation is read-only, what the response format is, or any additional behavioral constraints such as pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to the meaning, making it exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is far too sparse to provide adequate context for an agent. It lacks essential information about parameter semantics, expected behavior, and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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. It does not explain the roles of 'query', 'to', 'from', 'room', or 'limit', 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Full-text search over message bodies.' This distinguishes the tool from sibling retrieval tools like chat_history and read_message, which do not perform full-text search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 whether it searches across all chats or within a specific context, nor does it exclude any sibling tools.
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?
The description discloses that only visible chat turns are parsed and that it relies on the open browser page, which are useful behavioral constraints. However, it does not mention whether the tool is read-only, how it handles missing browser context, or the structure of returned data. With no annotations, more detail is needed to fully understand its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and immediately states the action, making it concise and front-loaded. However, it is succinct to the point of omitting key operational details that would help the agent invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too minimal. It does not explain the 'limit' parameter, the return format, or what constitutes 'visible' chat turns, leaving the agent to infer essential behavior. The tool is relatively simple, but the description does not cover its full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'limit' is not mentioned in the description, and the input schema provides only type and min/max, leaving its purpose ambiguous. The description fails to add any meaning to this parameter, making it unclear whether it controls message count, timeout, or something else.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses visible chat turns from the open browser AI page, using the specific verb 'Parse' and specifying both the resource (chat turns) and source (open browser page). It distinguishes itself from sibling chat/browser tools by focusing on extraction from the current page view, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like chat_history or browser_screenshot. The description implies a use case but offers no exclusions or prerequisite conditions, leaving the agent to infer appropriate usage.
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?
The description is minimal and only states the primary action. It does not disclose the meaning of 'recent', the effect of the optional limit parameter, the response structure, or any authentication or rate-limit requirements. With no annotations to supplement, this is a significant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or unnecessary words. It immediately conveys the core action, achieving maximum conciseness with minimal effort.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simple nature, the description omits critical context such as the definition of 'recent', the response format (no output schema), and the semantics of the limit parameter. This incompleteness could lead to incorrect usage or misinterpretation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single optional 'limit' parameter with no description (0% schema_description_coverage), and the tool description does not mention this parameter at all. The agent gains no information about how 'limit' controls the number of returned chats, making the parameter essentially opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function using the verb 'List' and the resource 'recent chat sessions', distinguishing it from similar tools like chat_history which likely handle individual messages. However, it does not explicitly mention alternative scenarios or compare itself to siblings, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as chat_history or list_history. It neither states appropriate contexts nor exclusions, leaving the agent without decision-making information.
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, but it only says 'Screenshot the current browser page.' It does not disclose whether a live browser session is required, where the screenshot is saved, what the output format is, or whether the optional 'path' parameter controls the save location.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, lean sentence with no wasted words, making it concise and easy to parse. However, it is so terse that it omits important context that would not hurt conciseness if added.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter documentation, the description is too sparse for reliable invocation. An agent would need to guess the meaning of 'path,' whether the browser must already be connected, and what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines one optional 'path' parameter, but the description never mentions it. With 0% schema description coverage and no explanatory text, an agent cannot infer what 'path' means or how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Screenshot') and the target resource ('current browser page'). This clearly differentiates it from sibling browser tools like browser_connect or browser_extract_messages, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or the context in which a screenshot would be 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, the description must disclose behavioral traits but does not. It does not mention side effects, error behavior, authentication requirements, or what 'presence' entails. The agent cannot infer if this is a safe read or what happens for invalid agent IDs, leaving a significant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. Every word earns its place, and it avoids redundancy. For a simple getter, this length is appropriate, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations, placing the burden on the description. It fails to explain the return value, the meaning of 'presence,' or any constraints. The agent is left without enough context to confidently invoke the tool and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 undocumented parameter. It only says 'for an agent id,' which adds minimal semantic value beyond the schema's type and required flag. It doesn't explain the format, scope, or how the ID is used, so the parameter remains under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource ('presence' for an agent). It distinguishes from sibling tools like set_status, which implies a read vs. write distinction. However, it doesn't explicitly differentiate from other status-related tools, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description merely states what it does without any context, prerequisites, or exclusions. In a large sibling set that includes many read tools, this omission leaves the agent uncertain about the appropriate selection.
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 disclosing behavior. The verb 'list' implies a read-only operation, but the description does not state whether authentication is required, whether the roster is global, or what happens if there are no agents. No side effects or safety characteristics are disclosed beyond the minimal verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action. It contains no redundant words or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter) but lacks annotations and an output schema. The description does not specify return values, the meaning of 'roster,' or any behavioral caveats. This leaves important gaps for an agent attempting to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the only parameter, since_minutes, is not explained in the description. The parameter name is self-explanatory (a time window), but the description does not confirm that it filters results by recency, nor does it clarify the default behavior when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists agents, with the scope of 'seen recently on the roster.' This clearly identifies the action and resource, and it distinguishes from sibling tools like list_chats or list_rooms. However, 'roster' and 'recently' are not fully defined, leaving some 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/5Does 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 does not mention any prerequisites, typical use cases, or exclusions, and sibling tools like get_status or register_agent are not referenced.
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 full burden for behavioral disclosure. It reveals that both read and unread messages are included, but does not state whether the tool modifies message state, how 'recent' is defined, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It earns its place by stating core functionality concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters with no descriptions, no output schema, and no annotations, the description is too sparse. It lacks details on ordering, default limit, return format, and behavior when multiple parameters are supplied, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 implies room and agent_id are filters (for an agent or room), but does not explain their relationship, whether they are exclusive, or the meaning of the limit parameter. This leaves significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns 'Recent messages (read or unread) for an agent or room,' providing a clear resource and scope. It is not a tautology and conveys useful distinction from siblings like chat_history or read_message, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives such as read_message, search_messages, or chat_history. The description only states what it returns, without context for selection or 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 convey behavioral traits (e.g., read-only, output format, permissions). It only says 'human-readable status board' without any detail on what the board returns or any side effects, leaving the agent uninformed about implications of invoking it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core concept. It is concise without being minimalistic, though it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is the only source of information. It lists content categories but omits critical context such as read-only status, how data is aggregated, or what 'urgent' and 'recent' refer to. This leaves the agent with an incomplete understanding for a tool with no structured field support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers the empty property set completely. The description correctly avoids explaining parameters, and the absence of parameters sets a baseline of 4; no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('status board') and content categories ('agents, rooms, urgent, recent'), but lacks an explicit verb (e.g., 'get', 'show'), making it less clear as an actionable tool. It implies an aggregated view distinct from sibling tools, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as `list_agents`, `list_rooms`, or `mailbox_stats`. The description does not mention typical use cases, prerequisites, or 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 provided, the description carries the full burden of disclosing behavioral traits. It only mentions chronological ordering, but does not explicitly state that it is a read-only operation, how it handles limits, or what happens if the chat_id is invalid. 'List' implies a read, but safety and edge-case behaviors are not 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded phrase: 'List messages in a chat (chronological).' Every word adds meaning, with no filler or redundancy. It is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description should provide a bit more context about return values, pagination, or limit behavior. It is a minimum viable description but leaves gaps regarding what the caller should expect in response or how to control result size. It adequately covers the core purpose but is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meanings. The phrase 'in a chat' hints at the chat_id parameter, but it does not explain the 'limit' parameter, its optionality, range, or default behavior. The description provides minimal additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists messages within a chat, with a specific verb ('List') and resource ('messages in a chat'). It also notes chronological ordering. However, it does not explicitly distinguish itself from similar sibling tools like 'list_history', though it does differentiate from 'list_chats' and 'read_message'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention exclusions or provide context for choosing it over similar tools like 'search_messages' or 'get_thread'. The description simply states what it does without usage direction.
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 must carry the full burden of behavioral disclosure, but it only states the action without mentioning side effects, permission requirements, or how the reaction appears to others. It does not indicate whether the operation is reversible or what happens on failure, leaving the agent without critical behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately conveys the action. It is appropriately sized and front-loaded, containing no filler or repetition, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a minimal one-liner with no output schema or annotations, the description omits essential context such as which messaging platform this applies to, how to format the emoji, and whether agent_id is needed for attribution. This leaves significant gaps that may lead to incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (emoji, agent_id, message_id) with no descriptions, and the tool description does not elaborate on their meaning, format, or required values. Since schema description coverage is 0%, the description offers no compensatory detail for agents to understand how to correctly fill in these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Add' and clearly identifies the resource as 'an emoji reaction to a message,' distinguishing it from related tools like reply_message or post_message. The tool name react_message aligns perfectly with the description, leaving no ambiguity about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 chat_say, reply_message, or post_message. There is no mention of prerequisites like needing an active chat or a valid message, nor any exclusions or preferred contexts.
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 carry the full burden. It discloses the in-thread routing behavior but omits effects such as whether a thread must already exist, who the reply is sent as, error behavior, or whether it mutates state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loading the core action and routing behavior. It has no wasted words, though it sacrifices detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 4 undocumented parameters, the description is too sparse to enable confident tool invocation. It provides no return expectations, prerequisites, or parameter formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain the meaning of from, text, priority, or message_id. 'Reply' and 'original sender' vaguely imply text and message_id, but the optional parameters and their constraints are left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reply') and identifies the resource/context ('in-thread') plus a behavioral outcome ('routes back to the original sender'). This clearly distinguishes it from generic messaging siblings like post_message or chat_say.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance or alternatives are provided. The description implies a reply scenario but does not state when to prefer this over post_message or browser_send_message, leaving the AI to infer.
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 names the core action but omits potential side effects, prerequisites, or what happens when the composer isn't open.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is appropriately sized for a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description lacks context about prerequisites, return values, and the optional submit parameter. It is minimal and does not fully cover the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, and the description only implies 'text' as the message content. The 'submit' boolean parameter is unexplained, leaving the agent to guess its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Type a message into the browser AI composer and send it,' specifying the verb and resource. It distinguishes from sibling browser tools by referencing the 'AI composer' context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like chat_say or post_message. No prerequisites or exclusions are mentioned.
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 full responsibility for disclosing behavior. It only states 'Fetch', implying a read-only operation, but does not mention any side effects, auth requirements, or whether the thread includes ordering or pagination. No contradictions exist, but the information is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb 'Fetch'. It contains no fluff and efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse. It does not mention what the returned thread looks like, how it is ordered, or any limitations. The tool has two parameters, but the description only hints at one, leaving the context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 explicitly mentions 'message id' which maps to the 'message_id' parameter, but it does not explain the 'limit' parameter at all. The description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('full conversation thread for a message id'). It is specific and distinguishes from siblings like 'read_message' or 'chat_history' by focusing on the entire thread for a given message ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, exclusions, or comparisons to similar tools like 'chat_history' or 'read_message'.
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 disclose behavioral consequences. It states that the tool announces completion to peers, but does not explain persistence, message visibility, required permissions, or response behavior, leaving important side effects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the action and purpose. Every word contributes to conveying the tool's role, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has multiple optional parameters, an enum, no annotations, and no output schema, yet the description only provides a one-line summary. This is insufficient for an agent to fully understand invocation behavior, parameter roles, and possible side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 6 parameters and 0% schema description coverage, the description was expected to compensate. It only echoes the word 'summary' and provides no meaning for optional fields like to, from, room, files, or the outcome enum, leaving the agent to guess their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('announce') and identifies the resource ('what this agent just finished') with an explicit end-of-turn context. This distinguishes it from sibling messaging tools like post_message, though it does not name alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'when this agent just finished' and 'end-of-turn summary' clearly indicates the appropriate timing. It lacks explicit when-not-to-use guidance or alternative tool references, but the context is unambiguous enough for an agent to select 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 provided, the description must carry the full burden of behavioral disclosure. It states the action but does not describe side effects such as whether the status change is broadcast to others, whether it persists for a duration, or if it can be undone. The optional agent_id parameter raises questions about whether this tool can change another agent's presence, which is not addressed. This leaves significant behavioral ambiguity 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, composed of a single clause and an enumeration. It contains no filler or redundant information, and the core action and valid values are presented immediately. It is an excellent example of front-loaded, efficient description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters, one required, and the core functionality is clear from the description and schema. However, the optional agent_id is unexplained, and there is no indication of return values or side effects. The description is adequate for basic use cases but leaves edge cases and optional parameter behavior under-specified, so it is not complete enough for a complex invocation scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It lists the enum values for 'status', which adds some semantic context beyond the raw schema, but it omits any explanation of the 'agent_id' parameter entirely, leaving its purpose, optionality, and default behavior unclear. The description provides minimal added value for the status parameter and none for agent_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Set presence') and enumerates the allowed values (idle, working, waiting), using a specific verb and resource. It distinguishes from the sibling tool 'get_status' which reads presence rather than modifying it. However, it does not explicitly clarify whether the status applies to the current agent or a specified agent via the optional agent_id parameter, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the name and description—this tool is used to update presence status. There is no explicit guidance on when to use it versus alternatives, no mention of prerequisites, and no exclusions. For a simple setter, the implied usage is understandable, but the lack of any situational guidance prevents a higher score.
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, and the description does not disclose behavioral traits beyond the basic action of sending. It does not mention whether this is a persistent record, whether it requires authentication, whether it delivers asynchronously, or any side effects. The description offers only a restatement of the tool's name and intent, leaving the behavioral burden unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core purpose and field structure. It is free of repetitive schema metadata and contains no idle words, making it efficient and easily readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 9 parameters and no output schema or annotations, the description provides only a minimal outline. It omits expected return values, error conditions, delivery semantics, and any relationship to other tools. For a tool of this complexity, the description is under-specified and leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 11%, the description adds meaning by naming four key parameters (title, objective, acceptance, files) and framing them as components of a structured handoff. However, it leaves the remaining five parameters (from, room, context, priority, etc.) unexplained, and the schema itself only documents 'to'. The description partially compensates but is not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a structured task handoff with specific fields (title, objective, acceptance, files) to another agent. This distinguishes it from generic messaging tools like post_message or relay_tick, as it is explicitly structured and task-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, target audience, or contrast with sibling tools like post_message or post_turn, so the agent receives no explicit decision-making support.
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 full responsibility for disclosing side effects, idempotency, auth requirements, or overwrite behavior. It only states the action without explaining what happens under the hood, leaving the agent uncertain about the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded, with no unnecessary words. It effectively communicates the core purpose in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, this description is severely under-specified. It lacks parameter semantics, behavioral details, and any mention of effects or return values, making it inadequate for reliable agent use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters (id, role, status, display_name). The agent receives no semantic guidance beyond the parameter names, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('register', 'refresh') and identifies a clear resource ('this agent's identity in the shared mailbox roster'). It clearly distinguishes from sibling tools like list_agents or set_status, as it focuses on identity registration rather than reading or status updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'register or refresh' provides clear context for when to use the tool: initially register or update an existing agent identity. It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear for an agent to recognize the appropriate use case.
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?
The description discloses the key side effect of marking the message as read (ack), which is beyond the tool name. However, with no annotations provided, it doesn't disclose the return format, permission requirements, or error behavior. It adds some context but leaves significant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, directly states the action and side effect. No fluff, front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too thin. It omits what the tool returns (e.g., message content) and what agent_id is used for. The side effect is clear, but the overall context is incomplete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description doesn't mention either parameter at all. It doesn't explain the purpose of agent_id or the format/requirements for message_id, so the agent must rely solely on the schema, which has no descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('fetch') and the resource ('a message'), and adds a precise side effect ('mark it read (ack)'). This distinguishes it from siblings like get_thread (which fetches without ack) and mark_unread (which reverses the read state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching a message while also acknowledging it, but it doesn't explicitly mention alternatives or when not to use it. Sibling tools like get_thread or search_messages could serve for reading without the ack side effect, but no comparison is given.
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 must carry the burden of behavioral disclosure. It adds useful context like 'active' and 'with message counts,' implying a read-only operation, but it does not explicitly state that it makes no modifications, nor does it describe any permissions or limitations. This is adequate for a simple list tool but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It efficiently conveys the tool's purpose without unnecessary elaboration, making it ideal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is mostly sufficient but lacks details on what constitutes an 'active room' and what other fields might be returned beyond message counts. This leaves some ambiguity for an AI agent deciding whether this tool meets its needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain argument semantics. The baseline for zero parameters is 4, and the description adds no conflicting or redundant information about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists active rooms and includes message counts, using the specific verb 'list' with a defined scope. It is concise and unambiguous, though it does not explicitly differentiate from sibling tools like list_chats, which could be a potential source of confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparison with sibling tools such as list_chats or list_history, leaving the agent to infer the appropriate 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?
Since no annotations are provided, the description carries the full burden. It discloses the two behavioral modes (launch persistent profile, CDP attach) but omits important details like starting a new browser instance, requirements for CDP, side effects on existing state, or return value behavior. The disclosure is minimal but not entirely 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It front-loads the primary action ('Connect') and quickly lists the key modes and browser support. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no annotations, and no output schema. The description is too sparse: it fails to mention prerequisites (e.g., Chrome installed, remote debugging port), what happens after connecting, how to verify the connection, or error conditions. A connection tool with side effects requires more context for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only cdp_url has a description). The description adds meaning by clarifying the mode and browser via 'launch persistent profile' and 'Chrome or Firefox', but it does not explain the 'headless' parameter. With low schema coverage, the description must compensate more; it only partially does so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Connect' with a clear resource ('Chrome or Firefox via Playwright') and details two distinct connection modes (launch persistent profile or CDP attach). This distinguishes it from sibling tools like browser_screenshot or browser_disconnect by establishing it as the connection step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the connection options and the browser types, but it does not explicitly state when to use this tool versus alternatives or mention prerequisites. There is no exclusion guidance, such as 'use CDP only if Chrome is already running with remote debugging.'
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 indicates navigation (a state-changing action) but does not mention whether it opens a new tab, overwrites the current page, waits for page load, or what side effects occur. For a tool that modifies browser state, this minimal disclosure 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence starting with the verb 'Navigate'. It lists all relevant destinations without any filler or redundant information, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two optional parameters and no output schema. The description gives the essential action and destinations, but it lacks clarity on parameter constraints and behavioral outcomes (e.g., what the tool returns, error conditions). Given the tool's simplicity, the description is moderately complete but not fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 maps 'site' to the enum values and 'url' to a custom URL, adding meaning to both parameters. However, it does not clarify whether one parameter is required, whether they are mutually exclusive, or what happens if both are provided, leaving ambiguity in parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Navigate' and clearly names the resource (connected browser) and the destinations (ChatGPT, DeepSeek, Claude, Gemini, Copilot, or a custom URL). This distinguishes it from sibling tools like browser_connect (which manages the connection) and browser_send_message (which sends messages), making the tool's 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (whenever you need to direct the browser to one of these AI sites or a URL), but it does not explicitly state when to use it over alternatives or provide exclusions. There is no mention of prerequisites such as requiring an active browser connection, though the phrase 'connected browser' indirectly suggests it.
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 disclosing behavior. It states the primary effect (hides from default inbox/history), which is useful, but does not mention whether the operation is reversible, whether the message remains searchable, or any permission requirements. This is adequate for a simple archive operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the action ('Archive a message') and immediately providing the key consequence in parentheses. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the main functional effect but omits details about return values, error conditions, or reversibility. With no annotations or output schema to fill gaps, a bit more context would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, message_id, with 0% description coverage. The tool description does not mention the parameter at all, leaving the schema to fully define it. While the parameter name is self-explanatory, the description adds no extra meaning, such as the format or origin of the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Archive' and the resource 'a message', clearly distinguishing this from sibling tools like read_message or react_message. The parenthetical 'hides from default inbox/history' further clarifies the exact scope of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for decluttering or hiding messages from the default view, but does not explicitly state when to use this tool versus alternatives like mark_unread, nor does it mention any exclusions or prerequisites. It provides clear context (hiding from inbox/history) but no 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. It states the action 'join' but does not disclose potential side effects (e.g., adding the user to the chat, sending notifications, or idempotency). The description only covers the mechanism (invite_token) and not the behavioral implications, which is a significant gap for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, and contains no filler words. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should provide more context. It explains how to join but does not mention what the tool returns (e.g., chat details, success/failure), the effect of joining, or any prerequisites. The missing agent_id explanation and lack of return value information leave the agent with insufficient context for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explains 'invite_token' and its origin (shared link/prompt), but the optional 'agent_id' parameter is not mentioned at all. The partial coverage leaves the agent guessing about agent_id's purpose, making the semantics incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Join a chat via invite_token', clearly identifying the resource (chat) and method (invite token from a shared link/prompt). This distinguishes it from sibling tools like create_chat (create new) and list_chats (list existing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use: when there is an invite_token from a shared link/prompt. This implies using this tool to join an existing chat rather than creating one, but it does not explicitly exclude alternatives like create_chat. The hint is clear enough for most cases.
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 full burden, but it does not disclose whether the tool is read-only, whether it modifies mailbox state, or what side effects might occur. 'Aggregate' suggests computation but does not explicitly state safety or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys purpose and scope without unnecessary words. It is appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should explain what the tool returns and any limitations, but it only lists a few stat types without describing the output format or scope (e.g., all mailboxes vs. filtered). This is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so schema coverage is 100% and there is no need for parameter explanations. The description adds context about the kinds of stats returned (counts, priorities, live agents), which is helpful but not required for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('aggregate') and resource ('mailbox stats') and further specifies the stats included (counts, priorities, live agents). This clearly distinguishes it from sibling tools like list_chats or mark_unread, which are action- or list-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when aggregate mailbox statistics are needed, but it does not explicitly state when to use this tool over alternatives such as list_chats or mailbox_board. There is no mention of exclusions or when not to use it, so guidance is only implied.
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 full burden for disclosing behavioral traits. It does not mention permissions, side effects, or what happens on failure, only listing supported features like mentions and tags. This is a significant gap for a mutation side-effect 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no waste. It front-loads the core action and lists relevant features efficiently, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, and only 0% schema coverage, the description provides a useful overview but leaves gaps about parameter relationships and expected behavior. It is minimally viable but not fully complete for a 7-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning to several parameters: `to` (agent vs room), `priority`, `tags`, and `attachments` (as file path attachments). However, it does not clarify the roles of `from` or `room`, nor how `room` interacts with `to`, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: sending markdown messages to an agent (DM) or broadcasting to a room by omitting the `to` parameter. This distinguishes it from sibling tools like reply_message or chat_say by specifying the DM vs broadcast behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use this tool and how to choose between direct messaging and room broadcast via the `to` parameter. However, it does not explicitly name alternatives or exclusions, so it falls short of a full 5.
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. It discloses the output (URL and prompt) and implies read-only behavior via 'Get', but it does not mention auth requirements, error handling, or side effects. No contradictions with annotations since none 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 11 words, front-loaded with the verb. It is direct and to the point, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool, the description covers the main purpose and output. However, it lacks any note about prerequisites (e.g., chat existence) or the output structure, and without an output schema, more detail would help the agent use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 references 'a chat id' without adding format, constraints, or examples beyond the property name. This provides minimal added semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function (Get), the resource (shareable join URL + peer prompt), and the scope (for a chat id). It distinguishes itself from sibling tools like join_chat or chat_say by its specific output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need a shareable link and prompt for a chat. It does not explicitly mention exclusions or alternatives, but the context is clear enough for a simple retrieval tool.
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 must carry the transparency burden. It adds a meaningful behavioral caveat ('Mail does NOT auto-open the other app') and describes the return value. However, it does not disclose side effects, permissions, or persistence requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence captures the primary purpose and output; the second adds a valuable caveat. Both earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value (join link + peer prompt) and one caveat, but lacks guidance on when to use versus siblings and doesn't address the roles of members and created_by. With no output schema and no annotations, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (title and peer have descriptions, members and created_by do not). The description adds no parameter information, leaving members and created_by unexplained and not clarifying their impact on the created chat.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a shared chat session') and specifies the output ('return a join link + peer prompt'). This differentiates it from siblings like join_chat and chat_link by focusing on creation and the unique return artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating new shared chats, which is clear from the verb 'Create'. It does not explicitly mention alternatives or when-not conditions, but the context is unambiguous.
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, and the description covers the primary effect (removing read receipt) but does not disclose side effects, permission requirements, or behavior on already-unread messages. Additional context would improve 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, every word earns its place; front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but without an output schema or param descriptions, the description leaves gaps: no mention of return value, error cases, or the optional agent_id. Still, the core behavior is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the description does not explain message_id or agent_id. The param names are somewhat self-explanatory but the description adds no explicit semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('read receipt'), and explains the outcome ('shows up in inbox again'), clearly distinguishing it from siblings like read_message or archive_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage when the user wants to revert a read message to unread so it appears in the inbox. However, it does not explicitly compare to alternatives or spell out when not to use (e.g., for archived messages).
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 present, so the description must disclose behavior. It does state the action is to close the session, which implies termination of the browser. However, it omits any side effects like freeing resources or affecting other tools, though these may be inferred.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the one-sentence description fully covers its purpose and necessary information. Nothing else is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema confirms this with an empty properties object. The description adds nothing about parameters, but none are needed, so the baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Close' and identifies the target resource 'Playwright browser session,' clearly distinguishing it from other browser tools like browser_connect or browser_status. This is a precise purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention that it should be used after finishing browser operations or that it will invalidate other browser-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a key behavioral trait: the tool creates a chat and returns pasteForPeer for the human to paste into Claude Code, explicitly noting 'Nothing auto-opens Claude'. This sets correct expectations for an interactive, non-automated process, though it does not cover potential side effects or permission needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the bridge concept, and every word contributes to understanding the tool's purpose and behavior. No redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three optional parameters and no output schema, the description adequately covers the main action, the return value (pasteForPeer), and a critical caveat (nothing auto-opens). It is complete enough for an agent to invoke the tool correctly, even if additional side effects are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (from, title, message) already described inline. The description adds no meaningful parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'creates a chat' and returns 'pasteForPeer', clearly identifying the tool as a bridge to Claude Code. This distinguishes it from sibling tools like create_chat or chat_say, which serve general chat purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage context (bridging DeepSeek/Cursor to Claude Code) but does not explicitly state when to use it over alternatives or provide exclusion criteria. No sibling tool comparisons are mentioned.
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 adds value by noting the id is 'auto-detected' and scoped to the MCP process, indicating a read-only operation. However, it omits details about output format or potential errors, which would improve 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no extraneous words. It is exceptionally concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no output schema), the description is functionally complete. It lacks explicit mention of the return type, but for such a simple tool, this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description correctly adds no parameter details, and none are needed since the schema already reflects an empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Show' and clearly identifies the resource as 'auto-detected agent id' with scope 'for this MCP process.' It distinguishes itself from sibling tools, none of which relate to identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing the agent id), but provides no explicit context, exclusions, or alternatives. For a zero-parameter identity tool, this implied usage is sufficient.
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 carries the full burden. 'Show' strongly implies a read-only operation, but it doesn't explicitly state that the tool has no side effects or that it doesn't require special permissions. Minimal behavioral context beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence precisely describes the tool's output. No filler or redundant information, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with no output schema, the description covers the essential contextual information: what state it reports and what data is returned. Nothing missing for the agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty schema fully documents everything. The baseline for 0 params is 4, and the description doesn't need to add any parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is clearly stated with the specific verb 'Show' and a well-defined resource ('browser session') plus the exact information provided (connection status and open site). It naturally distinguishes itself from mutating browser tools like browser_connect and browser_disconnect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The usage is reasonably implied by its status-query nature, but it doesn't explicitly say 'use this before connecting' or mention any exclusions.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/jrb00013/mailnotmilk'
If you have feedback or need assistance with the MCP directory API, please join our Discord server