CocoInbox MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools map to distinct actions across auth, email, folders, security, ideas, and CRM, but there are explicit aliases (login/connect, request_missing_tool/submit_idea, list_my_tool_requests/list_my_ideas) and create_folder overlaps with create_folder_for_email. Descriptions clarify intent, but the boundaries are not always crisp.
Naming Consistency3/5
The majority use a readable snake_case verb_noun pattern like list_emails and crm_update_lead, but bare verbs (login, connect, logout), noun-style names (auth_status, crm_summary), and alias variants break the convention. It is not chaotic, but it is a mixed pattern.
Tool Count2/5
35 tools is above the 25-tool comfort threshold, and at least three are aliases while auth could be consolidated from seven variants. The multi-domain scope justifies some breadth, but the set would benefit from trimming to canonical tools.
Completeness3/5
Core email, security, and CRM prospect workflows are covered, but lifecycle coverage is uneven: CRM groups cannot be updated or deleted after creation, folders have no delete/rename, and ideas only support submit/list. These are notable gaps rather than severe failures.
Average 3.8/5 across 35 of 35 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, auth requirements, or limitations. It only says 'Fetch' which implies read-only, but doesn't mention any behavioral details like rate limits, error cases, or what happens if emailId is invalid. Extremely sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, which is concise. However, it is under-specified to the point of being unhelpful, so while it's not verbose, it's not appropriately sized given the tool's complexity (2 parameters, no annotations).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to provide essential context: what the thread contains, how inboundLimit works, what the returned data looks like, or any caveats. Given the lack of annotations and output schema, this is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It mentions 'one mailbox address' but does not explicitly map that to emailId, and inboundLimit is completely unexplained. No additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (fetch) and the resource (message thread) and specifies the scope (one mailbox address). It is specific enough to differentiate from list_emails (which lists emails) and select_email (which selects an email), though the exact meaning of 'mailbox address' vs the emailId parameter could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_emails or select_email. The description doesn't mention when a thread fetch is appropriate or any exclusions or prerequisites.
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 discloses one side effect (automatic movement of the sent message to 'MCP' dossier), but it does not mention other behavioral aspects such as required permissions, rate limits, error handling, or potential side effects on the email state. Without annotations, the description carries the full burden, and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of two clear sentences without unnecessary elaboration. It is well-structured and directly addresses the core functionality and a key behavior, making it easy to read and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context about the outcome of the operation, such as return values, success/failure indicators, or consequences beyond the auto-move. It also does not explain when this tool is appropriate to use. While it mentions the auto-move, it fails to provide a complete picture of the tool's behavior and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds almost no meaning to the parameters. It indirectly references 'fromEmailId' via 'using the selected From address' but does not explain it, nor does it clarify the purpose of fields like 'to', 'subject', 'body', 'html', 'text', 'isGhostMode', or 'isTrackingEnabled'. The only parameter mentioned is 'folder' via the auto-move statement, but the schema already describes that. Overall, the description fails to enhance understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action ('Send an email') and even specifies the HTTP method and endpoint. It also mentions the auto-move to 'MCP' dossier, which adds context. However, the phrase 'using the selected From address' is ambiguous and could be clearer, but overall the purpose is distinct from sibling tools like list_emails or login.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites (e.g., authentication, prior selection of a From address). It lacks any indication of appropriate contexts or conditions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It says nothing about the tool's effects, side effects, permissions, or safety. Saying it's an alias implies similar behavior to submit_idea, but that is not explicitly stated, leaving the agent without useful behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is not appropriately sized for usefulness. The two sentences are essentially redundant ('Alias for submit_idea' and 'Prefer submit_idea' both convey the same directive), and they provide no substantive value for an agent evaluating the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it is an alias with a simple schema and no output schema, the description could still be enough to direct the agent to submit_idea, but it lacks any functional description of what the tool does. If an agent were to invoke this tool, it would have no idea of its purpose or behavior, making the definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (title, description) well-documented in the schema. The description adds no additional meaning or context beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Alias for submit_idea' without explaining what the tool actually does. It does not specify a verb+resource or distinguish it from siblings beyond naming the primary tool. The name hints at requesting a missing tool, but the description itself is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Prefer submit_idea.', giving clear guidance to use the alternative tool instead. This is direct and unambiguous, though it lacks any context for when this alias might be used.
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 disclose behavioral traits. It mentions 'ephemeral' and the auto-select option, which adds some context. However, it does not state whether login is required, what the tool returns, whether the current address is replaced, or any side effects. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short sentences with no redundancy. It front-loads the primary action and includes the key optional behavior. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a creation tool with no output schema, no annotations, and four parameters. The description does not explain what the created address looks like, how to use it, whether prior authentication is needed, or any follow-up actions. It is not complete enough for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the four parameters. It only addresses the auto-select behavior (matching selectAfterCreate) without naming the parameter, and provides no explanation for aliasName, isBlackbox, or durationMinutes. This is minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new ephemeral CocoInbox address, which is a specific resource and action. It distinguishes itself from sibling tools like send_email and get_email by clarifying it creates an address, not an email message. However, it does not explicitly contrast with any sibling, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The phrase 'Optionally auto-select it as From' explains a behavior but does not provide usage context, prerequisites, or exclusions. No alternative tools 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?
There are no annotations, so the description carries the full burden of disclosing side effects and behavior. It does not state that selection is persisted or affects subsequent send_email calls, what happens on invalid ids, whether 'fixed' is a literal accepted value, or any output/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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence and gets to the point quickly. It could be clearer, especially around 'fixed' and emailAddress, but there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutable/stateful selection tool with no annotations and no output schema, the description is too thin. It lacks the tool's side effects, prerequisites, accepted special values, and parameter meanings, leaving important gaps for an agent trying to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for emailId by saying it can be an id from list_emails or 'fixed'. However, the optional emailAddress parameter is left completely unexplained, and the relationship between the two parameters is unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Select') and identifies the target resource ('mailbox address to send from'), which clearly distinguishes it from sibling tools like list_emails or send_email. However, the meaning of the quoted 'fixed' value is ambiguous and not fully explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to send from' implies this tool is used before sending email, and the reference to list_emails suggests where the id comes from. But there is no explicit when-to-use/when-not-to-use guidance, no mention of prerequisites like authentication, and no direct comparison to 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 behavioral burden. It only states that the action is a POST to /api/folders and provides example names; it does not disclose duplicate-folder behavior, permissions, side effects, or the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that clearly covers the operation, endpoint, and representative naming examples. There is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter creation tool, the description is mostly sufficient and includes a helpful endpoint and naming example. It is not fully complete because it omits expected response behavior, duplicate handling, and whether any authentication or existing-folder checks are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'name' parameter, so the baseline is 3. The description adds useful meaning with examples: 'Work' shows a simple folder name, while 'mail/aze-walid' suggests slash-separated hierarchical folder paths are accepted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Create a new mail dossier/folder (POST /api/folders)' clearly states the action and resource, and includes the exact endpoint. It is understandable on its own, but it does not explicitly differentiate this from the sibling tool 'create_folder_for_email'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of 'list_folders', 'create_folder_for_email', or 'move_email_to_folder'. Prerequisites such as authentication or checking for an existing folder are also not mentioned, so an agent gets little decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds the meaningful behavioral fact that ownership is enforced server-side, which is useful. However, it does not disclose whether updates are partial or full, side effects, or error behavior, leaving 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the purpose and a key constraint. There is no redundant or verbose content, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters, no output schema, and no annotations, this one-sentence description is insufficient. It omits details about partial updates, error conditions, return values, and parameter-specific behavior, making it incomplete for such a versatile mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate but only mentions a few example fields ('status, email, notes, etc.'). This adds no meaning beyond what the schema already provides for those fields and leaves the other 10 parameters entirely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a lead, listing example fields like status, email, and notes. This distinguishes it from sibling tools that create or list leads, though it does not explicitly name alternatives or contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use this when you need to modify an existing lead. However, the description provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools or prerequisites beyond ownership.
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 mentions the operation 'scan' but does not state whether it is read-only, requires specific permissions, or produces any lasting 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information (verb and scope) and includes the endpoint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description covers the basic purpose and scope. However, it omits usage context (when to prefer this over `scan_dark_web`) and does not disclose any behavioral traits beyond the operation itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, giving a baseline of 4. The description adds value by specifying the scope (account email plus ephemeral addresses), which clarifies what the scan covers beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool scans the account email plus all ephemeral addresses, which clearly identifies the verb and resource. It mentions the endpoint but does not explicitly differentiate from the sibling tool `scan_dark_web`, though the 'plus all ephemeral addresses' implies broader scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like `scan_dark_web`. The description only states what it does, not the context or prerequisites for use.
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 some behavioral aspects such as not outputting raw JSON and handling empty results, but it omits important traits like side effects (read-only nature), permissions, or rate limits. This is a significant gap for a potentially read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-organized, with a brief introductory sentence followed by clear presentation instructions. It avoids unnecessary verbosity and maintains focus. The length is appropriate for the tool's simplicity, though the bullet points add a bit of extra detail that could be merged, but it remains efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no output schema, the description should compensate by explaining the return format and possible edge cases. It mentions 'token-friendly table' and instructs how to present results, but lacks specifics on the actual data structure (e.g., columns of the table) and error handling. The description is not fully self-contained for a user unfamiliar with the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema details parameters (limit and status) with types and constraints, but the description adds meaning only for the status parameter by explaining it as a filter with allowed values. The limit parameter is not elaborated, leaving its purpose implicit. Thus, the description adds moderate value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List CRM lead groups'. It also mentions the token-friendly table aspect, which hints at output formatting but does not obscure the primary purpose. The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning the filtering options (status) and presentation instructions. However, it does not explicitly indicate when to use this tool over alternatives like crm_get_group, nor does it clarify prerequisites or typical scenarios. The guidance is partial but not fully comprehensive.
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 says 'Move' but doesn't disclose side effects, permissions, failure modes, or reversibility. Minimal behavioral info beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and target. No fluff, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the toolerial, minimal description is okay, but it lacks any return value information or prerequisites. Schema covers params, so it's adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both params. The description adds the context 'inbound or sent' and the API endpoint, but doesn't add substantial meaning beyond the schema's param descriptions (e.g., 'Message id from get_email thread'). Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (move), the resource (message), and the target (dossier), and specifies that it works for inbound or sent messages. This distinguishes it from sibling tools like list_folders or create_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives, nor any prerequisites or exclusions. The schema mentions 'Message id from get_email thread' but the description doesn't provide usage 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?
No annotations are present, so the description must convey behavior. It explains formatting rules (render as Markdown table, show 'sans site' based on has_website) and empty-result handling, but does not disclose whether the operation is read-only, requires authentication, or handles errors. This adds some transparency but not comprehensive 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action, followed by a bulleted list of presentation rules. It is well-structured, though the bullet points focus on output formatting rather than tool usage, keeping it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It covers presentation but not parameter details, error handling, or prerequisites. The lack of information about the 'limit' parameter and potential side effects makes it insufficient for full comprehension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions three of the four parameters (group_id, with_email, status) as optional filters, without explaining valid values or effects. The 'limit' parameter is completely omitted. The description provides partial meaning but leaves significant gaps, especially for limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List CRM leads as a table' with optional filters (group_id, with_email, status). It distinguishes from sibling tools like crm_summary or crm_list_groups by explicitly focusing on listing leads, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to list leads) but provides no explicit guidance on alternatives or exclusions. It does not mention when to prefer crm_summary or other list tools, leaving the user to infer based on the name.
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 alone must disclose the tool's side effects, permissions, and idempotency. However, it only mentions updating 'status or draft' without explaining what happens to other fields, whether existing data is overwritten, or if any authentication is required. The example only hints at setting status to done but does not describe the full behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that directly convey the tool's function and a typical use case. There is no redundant information or verbose explanations, making it easy to read and understand. The structure is clear: first states the general capability, then provides a specific example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a basic understanding of what the tool does (updates status or draft) and includes a practical example, which is helpful. However, it does not mention error handling, return values, or the complete set of supported operations (e.g., whether it can set other statuses or update drafts partially). Given the simplicity of the tool, the completeness is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lists parameters (brief, title, status, task_id, draft_body, draft_subject) but provides no descriptions. The description mentions 'status' and 'draft' but does not map these to the actual parameters or explain the purpose of fields like brief, title, task_id, draft_body, or draft_subject. Consequently, users are left guessing what each parameter does, and the description fails to compensate for the lack of schema-level annotations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool updates a CRM task's status or draft. It provides a specific verb ('Update') and resource ('CRM task'), and includes an example ('After sending prospect email via send_email, set status=done') that illustrates a concrete use case, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool: after sending a prospect email via send_email, the status should be set to done. This serves as a practical usage example, though it does not explicitly mention alternative tools or when not to use this 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 carries the burden. It states the HTTP endpoint (GET /api/folders), which implies a read-only operation, but doesn't disclose details like whether it requires authentication, pagination, or what happens if no folders exist. The endpoint hint adds some transparency but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and includes the endpoint for clarity. No wasted words; it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description is adequate but not rich. It doesn't mention return format, authentication requirements, or any filtering options, but given the simplicity, it's minimally complete. The endpoint reference helps, but more context on the response would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (vacuously). The description adds the endpoint and the concept of 'mail dossiers/folders', which is useful context beyond the empty schema. With no parameters, the baseline is 4, and the description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists mail dossiers/folders for the user, with a specific verb and resource. It distinguishes from siblings like create_folder and list_emails, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the user's folders, but provides no explicit guidance on when to use this versus alternatives like list_emails or create_folder. The context is clear enough for a simple list operation, but no exclusions or alternatives are mentioned.
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 reveals the return shape (content.columns/rows), empty-result handling (content.empty), and presentation constraints (Markdown table, no raw JSON). It also provides a follow-up action. It does not cover auth or rate limits, but for a list operation this is solid additional behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in one sentence, followed by concise bullet instructions for presenting results and a useful workflow note. The tool description is compact and structured, though the 'After sending a prospect email' bullet is arguably a tangential workflow tip rather than a listing description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 optional parameters, no output schema), the description covers important usage context: output format, empty state, and a downstream workflow. It lacks detail on parameter values such as limit semantics or group_id origins, but it is still contextually adequate for most list-listing cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions group_id and status with allowed values, but it does not explain what group_id means or where to find it, and it omits the limit parameter entirely. This leaves meaningful gaps in parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List CRM tasks as a table', providing a specific verb and resource. It is clearly distinguishable from sibling tools like crm_update_task and crm_generate_prospect_tasks, and the optional group_id/status filters clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives, but it implies usage context by describing the task table and including a workflow note about marking tasks done after sending emails. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The 'GET' method and endpoint indicate a read-only retrieval, but the description does not mention response shape, authentication needs, or any caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the action and includes the endpoint. Every element is useful and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, no-argument getter, so the sparse description is mostly adequate. However, with no output schema and no annotations, a bit more context about what the score looks like would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the description does not need to elaborate on parameter semantics. The baseline for a no-parameter tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('user privacy / security score'), and includes the exact endpoint. Among security-related siblings like scan_dark_web and auth_status, this clearly identifies what is being retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as scan_dark_web, auth_status, or get_current_user. No exclusions, context, or alternative tool mentions are provided.
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 or output schema are provided, so the description carries the full behavioral disclosure burden. It confirms the operation and endpoint but fails to disclose whether this scan is read-only, whether it can initiate external/exposed operations, whether results are returned immediately, or if auth is required. For a scan tool, this leaves important behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence delivers the action, target, purpose, and HTTP endpoint with zero redundancy. Every element is functional and no unnecessary context inflates the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, single-parameter tool, the description is adequately complete: it tells the agent what the tool does and what input it expects. It loses the final point because it does not describe the result shape or confirm whether the scan creates a background operation or returns a synchronous result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single email parameter with 100% coverage, including 'account or ephemeral'. The description adds the one-address scope but provides no additional semantic details about expected input format or edge cases. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Scan'), a precise resource ('one email address on the dark web for breaches'), and the endpoint: POST /api/security/dark-web-scan. It also differentiates itself from the sibling tool 'scan_dark_web_all' by limiting scope to a single email address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one email address' clearly signals this tool is for targeted, single-address scans. Combined with the sibling name 'scan_dark_web_all', the intended usage context is understandable. However, the description does not explicitly tell users to prefer a different tool for scanning multiple or all addresses.
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 transparency burden. It discloses that the tool is an alias for login and is intended for unauthenticated users, which is useful. However, it does not mention side effects like session creation, redirects, or error conditions, leaving some behavioral aspects unexplained. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long, front-loads the most important information ('Alias for login'), and every word contributes meaning. It is a model of conciseness with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no complex behavior), the description covers the essential context: it's a login alias with a specific usage scenario. It could mention what happens after invocation (e.g., whether it returns a URL or initiates a redirect), but the low complexity makes the current level acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (vacuously). Per the rubric, 0 parameters corresponds to a baseline score of 4. There is nothing more the description could add about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies it as an 'Alias for login' and specifies that it 'open[s] the CocoInbox secure connect portal,' which conveys its function effectively. It also mentions the use case 'log me in' / 'get user' when not authenticated, which slightly differentiates it from siblings like 'login' and 'get_current_user'. However, the exact behavior of 'opening the portal' remains somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: it is 'Preferred for "log me in" / "get user" when not authenticated.' This gives a clear context and implies that alternative tools (e.g., get_current_user) are more appropriate after authentication, even though it doesn't name them. It doesn't explicitly state when not to use it, but the 'when not authenticated' qualifier is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a key side effect ('Regenerates an AI report used to refine CRM prospect emails') but omits mutation semantics such as whether omitted fields are overwritten, auth requirements, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no filler. The purpose, side effect, requirements, and preferences are all front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no output schema or annotations, the description provides the essential purpose, required fields, and side effect. However, it lacks details about successful update behavior, error handling, or partial update semantics, leaving moderate ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 57%, leaving website, industry, and location undocumented. The description adds useful guidance by marking name OR description as required and prioritizing name, description, and offer, but it does not clarify the remaining parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Save/update the sender company profile,' a clear verb+resource statement. It also distinguishes itself from the sibling read tool get_company_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Required: name OR description' and advises preferring name, description, and offer, giving the agent actionable input guidance. It also mentions the AI report refinement context, implying use when updating profile for CRM prospect emails, though it does not explicitly contrast with alternatives.
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 behavioral burden. It reveals that the tool finishes browser login only when the user provides a code, and that this is a fallback path. It doesn't specify post-conditions, error behavior, or whether it logs the user into an existing auth state, though those are less critical for a one-time login completion flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the main verb and then efficiently explains the only required trigger condition and fallback context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity one-parameter auth fallback, the description provides enough context to invoke correctly: when to call it, what input should be supplied, and why it exists. It could mention what success/errors look like after completion, but that gap is minor given the simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already explains that `code` is the one-time auth code from the CocoInbox login success page. The description adds the 'user pastes' interaction context, but that does not materially change the parameter's meaning or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Finish browser login' by consuming the user's one-time auth code. It also clearly distinguishes itself as the fallback when OAuth/portal auto-connect did not succeed, which separates it from related sibling auth tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger condition with 'only when the user pastes the one-time auth code' and context as a fallback after failed auto-connect. It doesn't explicitly name an alternative tool for the normal flow, but the automatic vs fallback distinction is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions the default naming rule and custom name option, which adds useful context beyond the schema. However, it does not disclose side effects like behavior if the folder already exists, permission requirements, or error handling, leaving gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero redundancy. It states the primary action, default behavior, and optional customization in a clear, front-loaded manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with high schema coverage and no output schema, the description is sufficient to convey its purpose and basic behavior. It could mention edge cases like conflicting folders, but given the low complexity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, each with descriptions. The tool description adds no new meaning beyond the schema—it merely restates the default name pattern. Since the schema already explains the parameters, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a folder (dossier) specifically for a mailbox email address, with a default naming convention (mail/<local-part>). This specific verb+resource pairing distinguishes it from the sibling create_folder tool, which is generic. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a folder tied to an email address, and the default naming scheme gives context. It does not explicitly state when to use it over create_folder, but the name and description make the distinction clear. No exclusions are mentioned, but given the clear scope, this is adequate.
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 disclosure burden and does state the create action, mandatory inputs, and returned group id. However, it does not cover prerequisites like authentication or the effect of omitting source_ai, leaving the behavioral contract only partially 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences pack the action, required fields, an example, optional fields, and the return-value contract with no filler. The description is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-output-schema creation tool, it adequately covers required inputs, an example, optional fields, and the return value needed for the next step. It falls short of mentioning prerequisites such as login and does not address the notes field, though notes are optional and not essential for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the baseline is 3; the description adds a concrete outreach example for why and enumerates source_ai values, but it mostly repeats schema information and omits the notes parameter. The 'Also set source_ai' wording is slightly ambiguous because source_ai is optional in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a lead group (campaign)', a specific verb and resource, and clarifies the required inputs and the downstream crm_add_leads step. This clearly differentiates it from CRM list/get/update siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It prescribes required fields (name + why), recommends source_ai, and links the returned group id to crm_add_leads, giving an agent a clear creation workflow. It does not explicitly name alternatives or exclusions, but the intended use is evident from the CRM sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Get' implies a read-only operation and the listed return fields add context, but it does not mention authentication requirements, error behavior, or explicitly confirm no 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every part adds value: the action, the target, the lookup key, and the included fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description is sufficient: it states what is retrieved and highlights key included fields. It could mention not-found behavior, but that is not essential for basic selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter group_id is already described as coming from crm_create_group or crm_list_groups. The description adds no additional parameter meaning beyond what the schema provides, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the resource ('lead group'), and scopes it to a single item by ID. It also lists the included fields (why / source_ai / location), clearly distinguishing it from sibling tools like crm_list_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for retrieving one specific lead group when its ID is known. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it over list-style siblings.
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 full burden. The verb 'List' implies a read-only operation, which is transparent. However, it does not disclose behaviors such as pagination, ordering, or handling of empty results, which a more thorough description might include.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly states the action, object, and scope, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description provides adequate context: it specifies what is listed and for whom. It could be improved by mentioning the return format or behavior with no results, but overall it is sufficiently complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (vacuously). The baseline for 0 parameters is 4, and the description's scope ('for the logged-in user') adds context beyond the empty schema, though no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('ephemeral email addresses') with a scope ('for the logged-in user'). This clearly distinguishes it from sibling tools like get_email or send_email, and the 'ephemeral' qualifier prevents confusion with regular email listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to list ephemeral email addresses) but does not explicitly provide alternatives or exclusions. It notes the logged-in user context, which is helpful, but lacks a direct comparison to similar list tools like list_folders.
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 bears the burden of disclosure. It mentions the tool is a 'fallback programmatic login' but does not describe side effects, session behavior, or security implications. The fact that it is a login implies authentication, but details like whether it overwrites existing sessions are absent. This is a minimal but acceptable disclosure for a simple login.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with purpose and guidance, and contains zero filler. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple login tool with two parameters and no output schema, the description provides sufficient context: it covers when to use it, the type of login, and the preferred paths. However, it lacks any mention of return values or post-login state, which could be useful but is not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention the parameters 'email' and 'password' at all. While the schema provides format and minLength, the description adds no extra meaning, such as what valid credentials look like or any constraints beyond the schema. This is a shortfall given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as a fallback programmatic login using email and password, and it distinguishes itself from sibling tools like 'login' and 'connect' by explicitly noting preferred alternatives (login/connect portal or MCP OAuth).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: it is a fallback method, should be used only when the user explicitly pastes credentials, and it names preferred alternatives (login/connect portal or MCP OAuth). This clearly tells the agent when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states it lists data for the authenticated account, which is a behavioral constraint, but doesn't disclose details like pagination, ordering, or whether it requires an active session beyond the implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and result, and includes a useful reference to the UI equivalent. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description is quite complete: it names the fields, the scope (authenticated account), and the UI equivalent. It could mention if there's a limit or ordering, but given the simplicity, it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to explain parameters. The baseline for 0 params is 4, and the description adds value by specifying the exact fields returned (title, description, status) and the data source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ideas (title + description + status) for the authenticated account, which is specific and distinguishes it from siblings like submit_idea and list_my_tool_requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for viewing previously submitted ideas, and the mention of 'authenticated account' implies a prerequisite of authentication. It doesn't explicitly state when not to use it, but the context is clear enough.
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?
No annotations are provided, so the description carries the burden. It clearly states it clears the in-memory session and selected sender email, which are the key behavioral effects. It does not describe side effects on other sessions or external state, but for a simple logout tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded with the core action. Every word serves a purpose, and it is clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description is complete for its purpose. It explains what gets cleared and that it's in-memory. Could mention persistence or auth implications, but for a logout tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to describe. Baseline of 4 is appropriate since schema coverage is 100% (trivially) and no additional param info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: clear the auth session and selected sender email. This is specific and distinguishes from sibling tools like login (create session) and auth_status (check status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you want to log out) but does not explicitly mention any alternatives or conditions. Since this is a standard logout tool, the context of sibling tools provides enough implicit guidance, but explicit exclusions are absent.
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 provided, the description carries the transparency burden. It discloses key behavior: tasks are created, drafts use group.why, email is never sent, and tasks must be separately marked done. This is more informative than typical minimal descriptions, though it does not mention permissions, error cases, or whether tasks persist beyond the draft stage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and scope, then immediately gives the workflow and alternatives. Every clause adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, scope, workflow, and non-sending behavior, which is substantial for a tool with no annotations and no output schema. It falls short only in not describing the return format in detail or edge cases like groups with no emails or limit behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate. It indicates group_id targets a group and that only leads with emails are included, but it does not explain the limit parameter or clarify how only_with_email relates to the schema default. The parameter-level guidance is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates email_prospect tasks for leads with emails within a group, using a specific verb and resource. It also differentiates itself from send_email and crm_update_task by clarifying it only produces drafts, not sending them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly explains when to use this tool ('For a group: create email_prospect tasks'), what it does not do ('Never sends email — returns drafts'), and what to do instead ('After review, send with send_email and mark task done via crm_update_task'). This provides both exclusions and named alternatives.
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?
No annotations are provided, so the description carries the full burden. It discloses a key behavior: if not authenticated, it returns a login_portal card and suggests next steps. It doesn't describe the success-case response format, but for a simple status check this is reasonably 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence states the core function, and the second provides a conditional outcome and actionable next step. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is nearly complete: it defines the purpose, gives the negative-case output, and points to recovery actions. The only gap is the lack of detail on what the success response looks like, though 'whether authenticated' implies a simple status response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly focuses on behavior rather than parameter details, and there is no schema information to repeat or clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Show whether this MCP process is authenticated') and clearly distinguishes this status-check tool from sibling auth actions like login/connect/logout. It also adds a useful conditional outcome, making its 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (check auth status) and provides direct guidance for the non-authenticated case by naming alternatives (call connect/login or open the URL). It lacks an explicit 'when not to use' statement, but the context is clear enough for the tool's simplicity.
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?
No annotations are provided, so the description carries the full burden. It discloses a batch limit, an ownership requirement, and privacy behavior ('Private to this user — no cross-user leak'). It does not detail error handling or idempotency, but the key behavioral traits are communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and every phrase adds relevant detail. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and lack of annotations or output schema, the description covers the essential invocation context: batch limit, owned group, privacy, and field guidance. It does not explain the return format, but this may be inferred as typical. Overall adequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description compensates by listing important fields (name, email, phone, company, address, city, map_url, website) and provides a concrete default instruction: 'has_website=false when no site.' This adds practical semantics beyond the raw schema, though not all parameters (e.g., tags, notes) are mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add up to 25 leads to a group you own.' It specifies the action (add), the resource (leads), and the target (group), distinguishing it from sibling tools like crm_list_leads or crm_update_lead. The limit of 25 is also explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when adding leads to an owned group) and notes a prerequisite (ownership). It lacks explicit comparisons to alternatives, but the context is clear enough for basic selection.
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 of explaining behavior. It communicates that this is a lightweight, user-scoped summary and avoids loading full lists, but it does not explicitly state read-only/no side effects, auth expectations, or return format. This is adequate but not richly 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences. The first sentence states the primary output and scope; the second adds actionable guidance without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter summary tool, the description is sufficiently complete: it identifies the resource (CRM counts), the scope (this user), the entities included (groups, leads, tasks), and the intended usage position ('start here'). It could clarify output shape or freshness, but the lack of an output schema makes the current level reasonably adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to explain input semantics. The baseline for a zero-parameter tool is 4, and the description adds no conflict with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing compact CRM counts for the current user, covering groups, leads, and tasks. It distinguishes itself from full list-loading sibling tools by presenting a summary/overview rather than detailed records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Start here to see state without loading full lists' explicitly tells users when to use this tool: as an initial overview before diving into list tools. It implies the alternative is to load full lists and frames this as the lighter-weight entry point.
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 available, the description carries the behavioral disclosure burden. It explains the not-connected flow: automatic login portal opening, login_portal card return, and the imperative to present that card without inventing multi-step instructions. This is valuable beyond the schema, though it does not enumerate all possible profile fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action, and every clause earns its place. The conditional login behavior is clearly separated and actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, this description is largely complete: it names the resource, notes company inclusion, and covers the unauthenticated edge case with direct agent guidance. A full field list would be nice but is not necessary for the agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per rubric. The description adds relevant semantic context about the return value (authenticated user profile, company when set), which is sufficient for a parameterless call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'Return the authenticated user profile.' The parenthetical '(includes company when set)' differentiates it from sibling get_company_profile and clarifies exact scope. This is specific and immediately usable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear conditional guidance for the not-connected case and instructs the agent to present the returned login_portal card rather than improvising steps. It does not explicitly compare with auth_status or login siblings, but the intended use is strongly implied by 'authenticated user profile.'
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 must carry the burden of behavioral disclosure. It clearly indicates a mutation ('Save') scoped to the user's account, and references the website's Ideas page as known behavior. However, it does not mention response format, required authentication state, or side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that front-load the core action, then give usage context and an anti-hallucination warning. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter create tool, the description covers purpose, usage timing, and constraints. It lacks explicit return-value information, but the reference to the Ideas page and the existence of list_my_ideas partially mitigate this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both title and description with length constraints, so the description's minimal mention of 'title + description' adds no new semantics. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves an idea to the user's CocoInbox account with title and description, and equates it to the website's Ideas page. This distinguishes it from siblings like list_my_ideas and request_missing_tool, which serve listing and tool-requesting purposes respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when the user wants to note a product/feature wish, or when no existing MCP tool covers their need' and instructs not to invent fake tools. This provides clear decision criteria for tool selection, though it doesn't name specific alternatives.
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?
No annotations are provided, so the description carries the burden. It discloses the conditional behavior of configured=false and instructs on presenting the data. However, it doesn't specify auth requirements or exact return format, but the core behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. Three focused sentences plus bullets, every sentence provides actionable guidance without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description supplies the main return fields and usage scenario. It could clarify what 'configured' means or list more edge cases, but it is adequate for this simple getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter semantics are needed. The description adds value by explaining what data the report contains, which compensates for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the user's company profile and generated report, listing the contents (name, what they do, offer, audience). This specific verb+resource structure distinguishes it from siblings like update_company_profile and crm_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use before creating CRM groups or prospect tasks, and instructs to call update_company_profile if configured=false. This gives clear when-to-use context and mentions an alternative tool.
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?
No annotations are provided, but the description discloses key behaviors: it opens a browser portal, mentions the portal_opened boolean, and instructs not to write multi-step auth instructions. It also notes the alternative OAuth flow. Slightly short on side effects (e.g., whether it invalidates existing sessions) but adequate for a login initiation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action. The presentation instructions are bulleted for clarity, and the OAuth alternative is mentioned without extra fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers the essential behavioral details: opening the portal, preferred usage, presentation rules, and follow-up via complete_login. It could mention what to do if login fails or if portal_opened is false, but overall it's quite complete for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. Baseline 4 is appropriate since the description does not need to explain parameters. It adds context about output behavior (portal_opened) which is useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Open the CocoInbox secure login portal) and specifies it's browser-basedlint. It distinguishes from siblings like complete_login (for code entry) and login_with_password by emphasizing the portal flow and OAuth alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to prefer this over asking for passwords in chat, and gives when-not to use it (if MCP OAuth is available). It also directs subsequent steps (call complete_login after code paste), providing clear contextual guidance.
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?
No annotations exist, so the description carries the full burden. It discloses that the tool behaves exactly like list_my_ideas (by being an alias), which is a transparent statement of its behavior. It does not detail side effects, but for an alias none are expected beyond the target tool's 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is perfectly concise and front-loaded with the essential purpose. It wastes no words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple alias with no parameters, output schema, or complex behavior, the description fully covers what an agent needs: it identifies the tool as an alias and directs to the preferred option. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100% (trivially). The description adds nothing about parameters, but with no parameters, it cannot add value. The baseline of 4 is appropriate as there is nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states it is an alias for list_my_ideas, clearly identifying its function and distinguishing it from the preferred tool. This is a specific and unambiguous 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to prefer list_my_ideas, providing a clear directive on when to use this tool (only as a fallback) and naming the alternative. This is explicit guidance for tool selection.
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:

[![cocoinbox-mcp MCP server](https://glama.ai/mcp/servers/WalidMoultamiss/cocoinbox-mcp/badges/card.svg)](https://glama.ai/mcp/servers/WalidMoultamiss/cocoinbox-mcp)

Score Badge

Copy to your README.md:

[![cocoinbox-mcp MCP server](https://glama.ai/mcp/servers/WalidMoultamiss/cocoinbox-mcp/badges/score.svg)](https://glama.ai/mcp/servers/WalidMoultamiss/cocoinbox-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/WalidMoultamiss/cocoinbox-mcp'

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