Jelly-FastMCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct conversation actions or resources, but 'list_comments' is a duplicate alias of 'list_conversation_comments', creating ambiguity. Additionally, 'create_draft_conversation' and 'create_draft_reply' could be confused without careful reading, though descriptions mostly clarify.
Naming Consistency4/5
Tool names follow a consistent verb_noun snake_case pattern, with clear use of prefixes like list_, get_, create_, update_, and un- for reversible actions. The alias 'list_comments' deviates from the standard 'list_conversation_comments' and 'upsert_contact' uses a less conventional verb, but overall the pattern is predictable.
Tool Count2/5
With 38 tools, the server is heavily over-scoped for its purpose. Many tools are narrowly defined state changes (e.g., unarchive, unspam, unsnooze) that inflate the count beyond what is typically manageable, making the toolset feel bloated.
Completeness3/5
The conversation lifecycle is well covered, but there are notable gaps: no send-message operation, no ability to list or retrieve drafts, no CRUD for saved replies or mailboxes, and minimal attachment handling. These missing operations would require agents to work around incomplete functionality.
Average 2.8/5 across 38 of 38 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'listing conversation comments' and fails to reveal pagination, auth requirements, side effects, or any other behavioral traits, leaving the agent completely uninformed.
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?
The description is extremely brief, essentially a single phrase 'Alias for listing conversation comments.' While not a tautology, it is under-specified and lacks structure, providing minimal value beyond the tool name.
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?
Given the tool has 4 parameters, many sibling tools, and no annotations, this description is completely inadequate. It does not cover pagination, auth, the alias relationship, or any operational context, making it impossible for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. The agent gets no explanation of conversation_id, limit, cursor, or api_token, so parameter semantics are entirely missing.
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 lists conversation comments, providing a clear verb and resource. However, it does not differentiate from the sibling tool list_conversation_comments; it only identifies itself as an alias, which does not fully clarify when to choose it over its sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that conversation_id is required, any prerequisites, or provide any context for choosing this tool over list_conversation_comments.
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 alone must disclose behavioral traits such as permanence, side effects, or required permissions. 'Delete a label' reveals nothing about irreversible consequences, whether the label can be deleted if in use, or any other operational behavior. This is a minimal mutation description with zero added transparency.
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?
The description is a single short sentence with no wasted words, but it is under-specified to the point of unhelpfulness. It lacks necessary context, so the brevity is more a sign of missing information than effective conciseness.
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's simple nature and the presence of an output schema, some return-value information is unnecessary. However, the description fails to provide essential context that would help an agent select and use this tool correctly, such as distinguishing it from remove_conversation_label and explaining the permanence of the action. Overall, the description is incomplete for safe and effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. 'Delete a label' implies the label_id identifies the label, but it does not explain the format, required context, or the purpose of api_token. The description fails to compensate for the lack of schema descriptions.
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 action ('Delete') and the resource ('a label'), making the basic purpose obvious. However, it does not differentiate from the sibling tool 'remove_conversation_label', which could also be interpreted as deleting a label from a conversation rather than deleting the label definition itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like remove_conversation_label. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only hints at a custom search syntax but fails to explain what that entails, whether pagination or cursors are used, or what the response structure looks like. This is a significant gap for a query tool.
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?
The single sentence is concise but severely under-specified for a tool with 8 parameters and a custom search syntax. It front-loads the purpose but omits all operational details, making it more an under-specification than a well-structured description.
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?
Given the complexity (8 parameters, no schema descriptions, no annotations), the description is far too incomplete. The presence of an output schema does not compensate because the agent cannot even construct a valid query without knowing the search syntax and parameter meanings.
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% for 8 parameters, and the description adds no parameter explanations. The meaning of 'q', 'limit', 'status', 'label_id', 'mailbox_id', etc. is entirely undocumented, forcing the agent to guess or fail. This is a critical deficiency.
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 action 'search' and the resource 'conversations', which immediately distinguishes it from sibling tools like list_conversations. However, it relies on 'Jelly's search syntax' without elaboration, which weakens clarity for agents unfamiliar with that specific syntax.
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 search versus list or get conversations. There is no mention of alternatives, exclusions, or typical use cases, leaving the agent to infer the intended context.
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?
No annotations are provided, and the description does not disclose any behavioral traits such as whether existing settings are overwritten, permission requirements, or side effects. It is equivalent to a one-line summary and adds no transparency beyond the tool name.
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?
The description is a single short sentence, which is concise in word count but under-specifies the tool's behavior. It lacks essential context, so it is not appropriately sized for the complexity of a mutation tool with three parameters.
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 lacks information about return values, error conditions, or authentication, and with no annotations, the agent has little to go on. Given the tool mutates settings and has an api_token parameter, the description 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?
The description does not explain any of the three parameters (enabled, message, api_token) and schema description coverage is 0%. It does not compensate for the schema's bare structure, leaving the agent without semantic guidance on how to fill in values.
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 updates the team's autoresponder settings, using a specific verb ('Update') and resource ('autoresponder settings'). It distinguishes from the sibling 'get_autoresponder' tool by implying a write operation versus a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives like get_autoresponder, no prerequisites, and no exclusions. It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action, with no mention of idempotency, error behavior, permissions, or what happens when a label is already applied. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the verb. It is appropriately concise, though it could be more informative without losing conciseness.
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?
With no annotations, 0% schema coverage, and a vague one-line description, the tool is severely under-specified. Even though an output schema exists, the description omits usage context, behavior, and parameter semantics, leaving an AI agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter details. It adds no meaning beyond the names conversation_id and label_id, and does not mention the optional api_token. The description fails to compensate for the lack of schema descriptions.
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 action ('Apply') and resource ('a label to a conversation'), and the tool name reinforces it. It is unambiguous but does not explicitly differentiate from sibling tools like remove_conversation_label or create_label.
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. It does not mention prerequisites, such as whether the label must already exist, nor contrast with remove_conversation_label or create_label. Usage is entirely implied by the description.
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 full responsibility for disclosing behavioral traits. It only states the creation action without mentioning side effects, required fields, authentication dependencies, or the nature of the operation (e.g., mutation).
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 concise with a single sentence, but it is under-specified for a tool with 9 parameters. The word 'brand-new' adds little value, and the brevity sacrifices necessary detail.
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?
Given the tool's complexity (9 parameters, 1 required) and complete lack of schema descriptions, this description is severely incomplete. An output schema exists, but the description does not provide enough context about what a draft conversation is, what inputs are needed, or how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter information. It fails to even highlight that 'body' is required, and offers no guidance on how to format fields like 'to', 'cc', or 'subject', leaving the agent without sufficient semantic context.
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 ('create') and resource ('draft conversation'), clearly indicating the action. It is distinguishable from sibling tools like create_draft_reply by the resource term 'conversation,' but doesn't elaborate on what a draft conversation entails.
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 like create_draft_reply or update_draft. No context is provided about prerequisites, ideal use cases, or situations to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states the action without mentioning side effects, permissions, idempotency, or error handling. Nothing is disclosed beyond what the name implies.
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 extremely concise, but it is under-specified rather than appropriately concise. It lacks essential context, though the one sentence is clear 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 0% schema coverage and no annotations, the description is far from complete. It does not explain the label concept, parameter meanings, or output expectations, leaving too much to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the three parameters. The agent must guess what 'color' and 'api_token' mean, especially the api_token parameter which could be critical for authentication.
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 'Create a new label' uses a specific verb and resource, clearly distinguishing it from sibling tools like update_label and delete_label. However, it lacks any additional scope or context about what a label is or how it relates to conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as update_label or add_conversation_label. No context about workflow, prerequisites, or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Load' implies a read-only retrieval, but the description does not mention authentication, error conditions, or the structure of the returned message. It adds minimal behavioral context beyond the basic operation.
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 short sentence with no wasted words, and it is front-loaded with the action. However, it is under-specified, which is not true conciseness. It earns partial credit for being brief and readable, but lacks necessary detail.
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's simplicity, the description is barely adequate. It lacks any mention of return values (though an output schema exists, it isn't visible to the agent in this context), prerequisites, or what distinguishes it from similar retrieval tools. Complete for a trivial getter only if the name and schema are sufficient, which they are not given the sparse text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining parameters like message_id and api_token. The description provides no parameter information whatsoever. message_id is inferable from the name, but api_token's purpose and format are entirely undocumented.
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 'Load a single message' clearly identifies a specific verb ('load') and resource ('message'), and the word 'single' distinguishes it from list-style operations like list_conversation_messages. However, it does not explicitly name alternatives or contrast with get_conversation, 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?
The description provides no context about when to use this tool versus the many sibling tools, such as get_conversation or list_conversation_messages. There are no exclusions, prerequisites, or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core action of unarchiving, but omits potential side effects, idempotency, or requirements. Without annotation support, this is insufficient for a state-changing tool.
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?
The description is brief but under-specified. It is a single sentence without elaboration, which crosses the line from conciseness to inadequacy for a tool with multiple parameters and complex behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description lacks essential context about when to use the tool and parameter semantics. It is not complete enough for an agent to reliably invoke this tool among 36 siblings handling similar state changes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. The schema only provides names and types, leaving 'api_token' and 'conversation_id' unexplained. The description does nothing to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unarchive a conversation' uses a specific verb and names the resource clearly. It distinguishes the action from siblings like 'restore_conversation_from_trash' or 'unsnooze_conversation', though it does not elaborate on what unarchiving entails (e.g., returning to inbox).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites (e.g., conversation must be archived), or contrast with similar state-change tools in the sibling list.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Update an existing draft message' without revealing whether fields are overwritten independently, what happens to omitted fields, or any permission requirements. This is severely insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically simple sentence with no wasted words. However, it is under-specified for a tool with 7 parameters, and the brevity comes at the expense of necessary detail. It is concise but not appropriately sized.
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?
Given the tool's complexity (7 parameters, mutation operation), the absence of annotations, and the lack of output schema details, the one-sentence description is critically incomplete. It omits parameter semantics, safety/behavioral context, and usage situations, making it nearly useless for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. It fails to explain that cc, to, bcc, body, subject are optional and independent fields, or how message_id is used. The description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Update') and the resource ('existing draft message'). This distinguishes it from sibling creation tools like create_draft_conversation and create_draft_reply, even though it does not explicitly name them.
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. With over 35 sibling tools including create_draft_conversation and create_draft_reply, the description offers no decision criteria, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Archive a conversation' with no detail about effects (e.g., moving out of inbox), reversibility, or permissions. For a state-changing action, this is insufficient 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 description is a single, clear sentence without redundancy. It is front-loaded and concise. However, it is arguably under-specified and could include necessary context while remaining concise, so it does not earn a 5.
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's simplicity, the description is still too minimal. It lacks context about the operation's place among siblings, any caveats, or return behavior. The presence of an output schema is noted, but the description doesn't address it. Overall, it is just barely adequate for a basic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not mention conversation_id or any other parameter. The parameter names in the schema are somewhat self-explanatory, but the description adds no semantic value beyond the raw 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 clearly states the action: 'Archive a conversation.' It uses a specific verb and resource, making its purpose obvious. However, it does not distinguish this operation from sibling tools like trash_conversation or ignore_conversation, which limits its clarity for tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool compared to alternatives. There is no mention of archiving vs. trashing, ignoring, or other conversation state changes. This leaves the agent without decision-support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the ordering behavior (newest first), but omits key behaviors such as pagination via cursor, filtering by status/label/mailbox, and any authentication requirements. This is a significant transparency gap for a tool with six optional parameters.
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 extremely concise, consisting of a single sentence. It is front-loaded with the core action and ordering. However, it is so brief that it sacrifices necessary detail, though conciseness itself is well-handled relative to the minimal content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (so return values are documented), the description is incomplete given the tool's complexity. It does not mention the filtering capabilities, pagination mechanisms, or authentication requirements, and provides no context to distinguish it from sibling tools. For a list operation with six optional parameters, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 6 parameters with 0% description coverage, and the description does not mention any of them. It adds no meaning beyond the raw schema field names. The description fails to explain what limit, cursor, status, label_id, api_token, or mailbox_id control, leaving the agent to infer their purposes without guidance.
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 function: listing conversations, and adds a specific ordering detail ('newest activity first'). However, it does not differentiate from sibling tools like 'search_conversations' or 'get_conversation', which also deal with conversation retrieval, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'search_conversations'. The description gives no context about its intended use case, exclusions, or prerequisites. It simply states what it does without any situational advice.
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 available, the description carries the full burden of behavioral disclosure. It implies a state-changing mutation but does not explain side effects (e.g., removal from inbox), reversibility, permission requirements, or any other consequences. This is sparse 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 description is a single sentence with no wasted words, effectively front-loaded. It is concise and direct, though it could be richer in content without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks essential context: no usage guidelines, no parameter semantics, and no behavioral side effects. For a mutation tool with no annotations, this is insufficient to give an agent complete confidence in when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter. The names conversation_id and api_token are self-explanatory to some extent, but no additional meaning is added, and the description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'mark' and resource 'conversation' with target 'as spam', making the action unambiguous. It does not explicitly distinguish from siblings like ignore_conversation or trash_conversation, but the core purpose is clear.
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 such as ignore_conversation or trash_conversation. There are no prerequisites, exclusions, or contextual cues, leaving tool selection entirely to the agent.
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?
Annotations are absent, so the description carries the full burden for behavioral transparency. It only states the action without disclosing side effects, permissions, reversibility, or what happens if the conversation is not currently snoozed. This is insufficient for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy, making it well-structured for quick reading. However, it is under-specified, missing important details that would be expected for a mutation 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?
Although the tool is simple and an output schema exists, the description is incomplete for a mutation tool with no annotations. It lacks preconditions (e.g., conversation must be snoozed), potential side effects, or behavior in edge cases, leaving the agent with insufficient context to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter explanations. It does not mention conversation_id as the target nor explain the optional api_token, leaving the agent to infer parameter usage from names and schema alone.
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 action: 'Remove a conversation's snooze.' It uses a specific verb ('remove') and resource ('conversation's snooze'), making the tool's purpose explicit. However, it essentially restates the tool name without additional context, which slightly reduces its value.
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. While the purpose implies usage (to undo a snooze), there is no mention of preconditions, exclusions, or relative to sibling tools (e.g., snooze_conversation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the mutation but does not explain how upsert determines existing records, whether partial updates merge or overwrite omitted fields, or whether api_token is required. This is a significant gap for an upsert operation.
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 concise sentence that is front-loaded, but it is under-specified for a tool with six parameters and an upsert behavior. It earns its place but leaves the reader needing much more information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description is inadequate for a 6-parameter mutation tool with no annotations. It does not cover upsert semantics, authentication via api_token, or behavior with respect to optional fields, making it incomplete in context.
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 adds no parameter information. While some parameter names like 'email' and 'name' are self-explanatory, others like 'api_token' and 'links' are ambiguous and the description does not compensate for the lack of schema-level descriptions.
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 verb 'Create or update' with resource 'contact', which is specific and distinguishes it from read-only sibling tools like find_contact_by_email. However, it does not mention that the email field is the unique key determining whether a create or update occurs, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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, such as find_contact_by_email for looking up contacts or create_label for label management. There is no mention of appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'assign' without mentioning whether it overwrites an existing assignment, what permissions are required, or whether a null assignee is possible. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is concise, but the brevity comes at the cost of necessary detail, so it does not earn a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and may cover return values, the description leaves a critical gap: how to identify the team member. With no annotations, no usage guidance, and a 0% schema coverage, an agent cannot confidently invoke this tool based solely on the description.
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 adds almost no parameter meaning. It does not clarify that `email` or `member_id` is the intended assignee, that one of them should be supplied despite only `conversation_id` being required, or the role of `api_token`. This leaves the agent unsure how to invoke the tool correctly.
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 action and object: 'Assign a conversation to a team member.' It implicitly contrasts with sibling `unassign_conversation`, making the core purpose unambiguous. However, it does not explain how the assignee is specified, which keeps it from being fully specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as `unassign_conversation` or other conversation actions. No prerequisites, such as needing the conversation to be unassigned first, 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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It merely states the action and does not mention side effects, permissions, return behavior, or whether the draft is stored pending further edits, leaving the agent without critical context.
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 single sentence is brief and front-loaded, but it is under-specified for a tool with 8 parameters and no schema descriptions. It lacks vital details that would make the description self-sufficient, so while it is concise, it is not appropriately sized for the tool's complexity.
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 is incomplete given the tool's complexity: 8 parameters, no annotations, and zero schema descriptions. Although an output schema exists, the description does not provide the necessary context for parameter usage, behavioral expectations, or selection among sibling tools, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. The tool has 8 parameters, including ambiguous ones like api_token, member_id, and message_id, but neither the schema nor the description explains their purpose or relationships, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (create), the object (draft reply), and the scope (existing conversation). It distinguishes the tool from siblings like create_draft_conversation, which creates a new conversation, and update_draft, which modifies existing drafts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as add_comment or create_draft_conversation. There are no explicit exclusions or preferred contexts, forcing the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention whether the action is reversible, what happens when the future datetime arrives, or how snoozing interacts with other conversation states. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no wasted words. It is concise but under-specified, which is more a completeness concern than a conciseness flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no annotations, and zero schema descriptions. The description covers only the core action and omits side effects, return values, parameter formats, and relationships to sibling tools. Even with an output schema present, the description lacks the necessary context for a state-changing 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?
The schema has 0% description coverage. The description adds that snooze_until must be a future datetime, which is helpful, but it does not explain the auth-related parameters (email, api_token, member_id) or provide format details for snooze_until. Most parameters are left unspecified.
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 action ('Snooze a conversation') and the temporal constraint ('until a future datetime'). It is specific enough to distinguish from many sibling tools, though it does not explicitly name alternatives like unsnooze_conversation.
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 such as archive_conversation or unsnooze_conversation. There are no prerequisites, context signals, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It hints that 'optional comment and timeline embeds' affect the response shape, but it does not clarify whether the operation is read-only, whether authentication via api_token is required, or any rate limits or side effects. The agent cannot judge safety or side effects from this description.
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, directly front-loaded with the primary action ('Load a conversation') and relevant modifiers. No waste, and it is appropriately sized for the tool's apparent simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (one obscure), no annotations, and a large sibling list, the description is too sparse. It fails to explain api_token, provide usage context, or disclose whether the operation is safe. The output schema exists but does not compensate for missing behavioral and parameter guidance.
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 clarifies that include_comments and timeline are optional embeds, but it leaves api_token completely unexplained. conversation_id is self-evident from the name, but the lack of explanation for a non-obvious parameter is a significant gap.
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 operation as loading a single conversation and mentions optional comment and timeline embeds, which distinguishes it from list-oriented siblings like list_conversations. However, it does not explicitly contrast with other conversation fetch tools (e.g., list_conversation_messages) to fully eliminate ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, no prerequisites, and no context about typical scenarios. It merely states what it does, leaving the agent to infer usage from the name and schema.
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 full burden. It only says 'List team labels' without disclosing any behavior such as pagination, ordering, permissions, or whether the api_token is required to access team-specific labels. The description adds little beyond the tool name.
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 one short sentence with no filler or redundancy. It is front-loaded with the verb and resource. However, it is so terse that it may be under-specified, but that is more a completeness issue than a structure issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values need not be explained. However, the description lacks context about what 'team labels' encompasses, how the optional api_token factors in, and whether there are any limitations. This is minimally adequate for a simple read operation but leaves gaps for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter, api_token, with 0% schema description coverage. The description does not mention this parameter or clarify its purpose or effect on the results. The schema itself is somewhat self-explanatory (an optional string token), but the description adds no value beyond the 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 a specific verb ('List') and resource ('team labels'), clearly identifying the tool's function. It is distinguishable from sibling tools like create_label and delete_label, though it does not explicitly differentiate itself from other list operations.
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 or how it relates to alternatives. No prerequisites, exclusions, or alternative tool names are mentioned, leaving the agent to infer usage purely from the tool 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 must fully disclose behavioral traits. It only says 'List mailboxes,' with no mention of authentication requirements, read-only nature, pagination, or any side effects. This leaves the agent without crucial context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with zero unnecessary words. It is front-loaded and efficient, perfectly concise for what it says.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool with an output schema, the description is too sparse to be considered complete. It does not distinguish from related tools like list_mailbox_members, describe the scope of mailboxes returned, or mention any special behavior. Given the existing context, a richer description would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter, api_token, with 0% schema description coverage. The description does not mention this parameter at all, leaving the agent to guess its purpose from the name alone. The description adds no value beyond the schema in this regard.
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 action ('List') and the resource ('mailboxes'), which is a distinct resource from the siblings (e.g., list_conversations, list_labels). However, it lacks any elaboration on scope or what constitutes a mailbox, so it is not as informative as 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?
No guidance is provided on when to use this tool versus alternatives like list_mailbox_members or list_conversations. There is no mention of use cases, prerequisites, or conditions under which this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the action without explaining whether the action is reversible, what permissions are needed, or how it affects related data. The sibling 'restore_conversation_from_trash' implies reversibility, but this is not stated here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is easy to parse and not verbose. It is appropriately concise for stating the core action, though it leaves out important details which are penalized in other dimensions.
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 lack of annotations, incomplete parameter information, and the existence of sibling tools with overlapping functions, this description is too sparse. It does not explain the consequences of trashing a conversation, reversibility, or any side effects, making it incomplete for a tool with a 2-parameter schema.
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 input schema has two parameters (conversation_id and api_token) with zero description coverage. The description does not mention either parameter, so it adds no semantic meaning beyond the raw schema. Since schema coverage is 0%, the description was expected to compensate, but it fails to do so.
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 ('Move') and identifies both the resource ('a conversation') and the target state ('to trash'). This clearly distinguishes it from sibling tools like 'archive_conversation' and 'spam_conversation' by naming the exact destination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'archive_conversation' or 'spam_conversation'. It does not mention any use cases, prerequisites, or exclusions, leaving the agent without decision-support information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only says 'for one team member' but does not explain what ignoring entails (e.g., hiding, muting, reversibility), whether it affects other members, or what side effects occur. This is insufficient for a mutation-like 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 a single, clear sentence with no wasted words, making it concise and front-loaded. However, it may be too brief for the tool's complexity, missing essential operational details, but it still earns its place for stating the core purpose.
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 4 parameters, no annotations, an output schema, and a large set of sibling tools, the description is severely under-specified. It does not explain how to specify the team member, what the tool actually does to the conversation, or what the response looks like, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 hints at a team member but does not identify which parameter (email, member_id, or api_token) corresponds to that member, nor does it explain the role of conversation_id. The description adds minimal 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 uses a specific verb ('Ignore') and resource ('a conversation') with a clear scope ('for one team member'), distinguishing it from sibling tools like archive, trash, and spam. It clearly states the tool's function in a single, unambiguous phrase.
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 such as archive, spam, or snooze. It does not mention any exclusions, prerequisites, or typical scenarios, leaving the agent without context on how to choose this over similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It only states the action (list) without noting that it is read-only, requiring authentication (api_token), or any pagination or filtering behavior. This is minimal and leaves the agent to infer safety and 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, short sentence with no redundant information. It is front-loaded with the action and resource, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool, the description is incomplete for an agent to confidently invoke it: no mention of authentication, return value structure, or potential errors. An output schema exists, but its content is unknown, and without annotations the description must do more to convey the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter details. mailbox_id is implied by 'a mailbox' but not explicitly explained, and api_token is entirely unmentioned. The description fails to compensate for the lack of schema descriptions.
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 ('List') and resource ('members who can see a mailbox'), clearly distinguishing it from sibling tools like list_mailboxes (lists mailboxes) and list_members (lists all members). It precisely identifies the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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, such as list_members or list_mailboxes. There is no mention of context, prerequisites, or cases where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states the basic action. It does not explain what 'active' means, whether pagination is used, or any authentication details. The description adds no depth beyond the tool's name.
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, direct sentence that communicates the core function without unnecessary words. It is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks completeness—no annotations, no clarification of 'active,' no mention of the api_token parameter, and no relationship to similar list operations. The presence of an output schema reduces the need to explain return values, but the description still leaves significant ambiguity.
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 input schema has one parameter (api_token) with 0% description coverage, and the description does not mention or clarify it. Since schema coverage is low, the description must compensate but fails to provide any parameter-level meaning.
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 'active team members,' which clearly distinguishes it from siblings like list_mailbox_members (mailbox members) and list_conversations. The qualifier 'active' adds a clear filtering 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. The description merely states the function without any context, prerequisites, or exclusions, leaving the agent to infer its applicability.
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 available, the description carries the full burden of disclosing behavior, but it only states the action without explaining consequences. It fails to clarify whether removing a label deletes the label itself or merely detaches it from the conversation, or whether any permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of six words. It is front-loaded with the action and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple operation, the description lacks essential context: no annotations, no parameter explanations, and no clarification of whether the label is deleted or just unlinked. The presence of an output schema does not compensate for the absence of behavioral and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not mention any parameters, leaving even the purpose of 'api_token' unexplained. The parameter names are somewhat self-explanatory, but the description adds no value to the structured 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 uses a specific verb ('remove'), a resource ('label'), and a target ('conversation'), making it immediately clear what operation is performed. It also distinguishes itself from the sibling tool 'add_conversation_label' which performs the opposite action.
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 regarding when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or how it differs from related tools like 'add_conversation_label' or 'delete_label'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only restates the basic operation. It doesn't disclose behavior like whether null values clear the attribute, auth requirements (api_token), or side effects beyond mutation.
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 front-loaded sentence; however, it omits useful details, so it's concise but not under-specified to the point of being a tautology.
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 mutation tool with no annotations and no parameter descriptions, the one-line description is insufficient for safe use. It lacks information on required fields (though schema has them), auth token handling, and behavior when only label_id is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only mentions 'name' and 'color' without clarifying that they are optional/nullable, the role of label_id and api_token, or how to clear a value. This leaves the agent to infer parameter semantics from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'rename' and 'recolor' to indicate updating an existing label's mutable attributes, clearly distinguishing it from sibling tools like create_label or delete_label.
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; it simply states what it does without indicating prerequisites, exclusions, or scenarios where create/delete would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states 'List saved replies' and does not mention pagination, ordering, authorization requirements, rate limits, or any side effects. As a read operation, the verb implies safety, but no additional behavioral context is given.
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 exceptionally concise and front-loaded, consisting of a single sentence with no unnecessary words. It states the action and resource directly, making it appropriately sized for a simple listing operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description does not address the optional api_token parameter or any behavioral details such as pagination or access restrictions. For a tool with no annotations and 0% parameter coverage, this one-liner is underspecified and leaves the agent with limited context.
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 schema description coverage is 0%, and the description does not explain the 'api_token' parameter at all. With only one parameter, the description fails to compensate for the low schema coverage, leaving the parameter's purpose and usage completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource 'saved replies', clearly distinguishing it from sibling tools like list_conversations, list_comments, and list_labels. The purpose is immediately clear and 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?
No explicit usage context or alternatives are provided. However, since there are no sibling tools that mention saved replies, the intended usage is implied from the tool's name and one-line description. It does not mislead, but also does not offer guidance on when to choose this over other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it simply restates the action with no additional context. It doesn't mention permissions, idempotency, side effects, what happens if the conversation isn't trashed, or any other behavioral trait beyond what the name already conveys.
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: 'Restore a conversation from trash.' Every word is necessary and there is no wasted information. It is exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, an output schema exists, and the core action is clear. However, the description lacks important contextual details such as prerequisites (conversation must be in trash), authentication requirements, and error behavior. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it doesn't explain any parameters. conversation_id is implicitly the target conversation, but api_token is completely unexplained. The description adds no value over the schema's property names and types.
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 'restore' with a specific resource 'conversation' and source 'from trash', which clearly distinguishes it from siblings like unarchive_conversation, unspam_conversation, or unsnooze_conversation. The action is unambiguous and exactly matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. It doesn't state that it should be used for trashed conversations only, nor does it mention any alternatives or exclusions. The context is implied by the name but not explicitly explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word 'replace' explicitly communicates destructive overwriting of the current mailbox set, which is a meaningful behavioral trait. However, it does not disclose permissions, reversibility, or side effects beyond the replacement.
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, clear sentence with no verbose or redundant content. It is appropriately front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and an output schema exists so return values need not be described. The description conveys the core action ('replace the set'), which is essential. However, it lacks broader context such as when to use this compared to other conversation actions, and it does not clarify behaviors like whether the conversation or mailboxes must pre-exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no parameter details. It implicitly connects 'mailboxes' to mailbox_ids and 'conversation' to conversation_id, but it doesn't explain how to use the parameters, their constraints, or the api_token field. The schema alone carries all parameter information.
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 ('Replace') and clearly identifies the resource ('the set of mailboxes a conversation belongs to'). It distinguishes this tool from siblings like assign_conversation or archive_conversation, which operate on different aspects of a conversation.
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. It simply states the action without mentioning exclusions, prerequisites, or comparing to other conversation/mailbox tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic action without disclosing side effects, prerequisites, reversibility, or behavior on already-unspammed conversations. This is minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence conveys the core action without waste. It is front-loaded and entirely relevant, fitting the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are covered. However, the description lacks behavioral context (e.g., effect on conversation state, edge cases) and no annotations to compensate. It is minimally adequate but has clear gaps.
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 schema description coverage is 0%. The description does not mention the conversation_id parameter or any parameter semantics. The agent must rely solely on parameter names, which is insufficient for a mutation tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark a conversation as not spam' clearly states the tool's purpose with a specific verb and resource. It is directly contrasted with the sibling tool 'spam_conversation', making the action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (undoing a spam marking) but does not explicitly mention alternatives or when-not-to-use. Sibling tools like spam_conversation are implied by the name, but no direct guidance is 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 are provided, so the description carries the full burden. It only says 'Add an internal comment' without disclosing side effects, authentication needs, or what 'internal' implies (e.g., visibility to customer). This is a mutation tool, and no behavioral context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no padding. It is front-loaded with the action and resource.
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 simple add operation, the description is sufficient in terms of purpose but lacks usage guidance and behavioral context. An output schema exists, so return values are covered, but the description does not address potential side effects or when to use it over similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explicitly map parameters. However, the parameter names 'conversation_id' and 'body' are self-explanatory, and the description implies body is the comment text. This adds minimal value beyond the schema but does not fully compensate for the lack of schema descriptions.
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 ('Add'), the resource ('an internal comment'), and the target ('a conversation'). This distinguishes it from sibling tools like list_conversation_comments or add_conversation_label.
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, nor any mention of prerequisites or exclusions. The description only states what the tool does, not when it should 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Remove') but does not disclose side effects, permissions, idempotency, reversibility, or what happens if the member is not assigned. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to the meaning, making it highly 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?
Given the tool has 3 parameters, no annotations, and no parameter descriptions, the description is incomplete. It does not provide context on when to use the tool, what the response will be, or any edge-case behavior. The description does not adequately round out the tool's semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It does not mention 'api_token' at all, and only implicitly references 'member' and 'conversation' without mapping them to the actual parameters 'member_id' and 'conversation_id'. The description adds minimal semantic value over 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 'Remove a member assignment from a conversation' uses a specific verb ('Remove') and clearly identifies the resource ('member assignment') and the object ('conversation'). It distinguishes itself from the sibling tool 'assign_conversation' by indicating the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to unassign a member), but it does not explicitly mention when to use this tool over alternatives or provide exclusions. There is no mention of prerequisites or comparisons with sibling tools like 'assign_conversation'.
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 present, so the description carries the full burden of behavioral disclosure. It only says 'look up', which suggests a read operation but does not mention auth requirements, not-found behavior, or non-destructive guarantees.
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 unnecessary words. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema is present, so return values likely do not need description. However, the omission of api_token semantics and the lack of any usage context leave moderate gaps for an agent deciding when and how to invoke the 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?
The description adds meaning to the 'email' parameter by mentioning 'email address', but the 'api_token' parameter is completely unaddressed. With 0% schema description coverage, the description should compensate for all parameters but only covers one.
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 ('look up') and identifies the resource ('contact') and lookup key ('email address'). It clearly distinguishes the tool from siblings like upsert_contact, which is for creating or updating contacts.
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 intended usage is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives. No comparisons to search_conversations or other lookup tools 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?
No annotations are provided, so the description carries the full burden. 'Read' indicates a non-mutating operation, but the description does not elaborate on any side effects, authentication quirks, or other behavioral details. It is minimal but not misleading.
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 action and fully scoped. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema, so the description is mostly adequate. However, the complete omission of parameter semantics and lack of explicit usage guidance make it less than fully complete for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives no information about the api_token parameter, and the schema description coverage is 0%. Since the description must compensate for the schema's lack of param details, its silence leaves the parameter's purpose entirely unexplained.
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 reads the team's autoresponder settings, using the specific verb 'read' and identifying the resource. This distinguishes it from siblings like update_autoresponder, which performs a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the verb 'read' (i.e., use when you need to view settings), but it does not explicitly mention when not to use it or point to alternatives like update_autoresponder. No exclusionary or alternative guidance is 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. It does disclose that the URL is 'short-lived', which is important. However, it doesn't disclose authentication requirements, failure behavior, or whether this is a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 8 words, front-loaded with the action and resource. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits usage context and parameter details. While the output schema covers return values, the lack of guidelines and API token semantics leaves gaps for a straightforward tool. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. 'attachment' loosely maps to attachment_id, but api_token is completely unaddressed, leaving the agent with no insight into when the token 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 uses a specific verb 'Resolve' and clear resource 'attachment' with outcome 'short-lived storage URL'. It clearly differentiates from sibling tools, which deal with conversations, labels, and messages, not attachments.
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 or alternatives. It doesn't state prerequisites like needing the attachment_id from a message, or that this URL should be used immediately due to expiry. The description solely focuses on the action, not the 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?
With no annotations provided, the description carries the full burden. It discloses pagination behavior (page through) and ordering (oldest first), which is useful. However, it does not mention read-only nature, authentication requirements (api_token), error behaviors, or the meaning of 'internal comments.' It adds some behavioral context but remains 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, front-loaded sentence that conveys the essential action, scope, and ordering without any redundant words. Every word earns its place, making it extremely concise and well-structured.
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?
Although the output schema covers return values, the description lacks sufficient context about when to use this tool, parameter semantics, and behavioral details like authentication. It is adequate for a simple pagination tool, but gaps exist in usage guidance and parameter explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for explaining parameters. It neither defines the parameters nor adds semantic detail to them. The phrase 'Page through' implicitly suggests limit and cursor usage, but it does not explain cursor semantics, api_token role, or default behavior. This under-compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Page through'), the resource ('a conversation's internal comments'), and the ordering ('oldest first'). It distinguishes from sibling tools like list_conversations and list_comments by focusing on internal comments of a specific conversation, and the 'oldest first' adds precise 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 implies the tool is for paginating internal comments of a conversation, but it does not explicitly state when to use this tool versus alternatives such as list_comments or list_conversation_messages. There is no mention of when not to use it or any exclusions. The context of 'internal comments' offers some implied differentiation, but no direct guidance is 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 must disclose behavioral traits. It adds pagination behavior and ordering (oldest first), but does not mention auth requirements (api_token parameter), error behavior, or whether it is read-only (though 'page through' implies a read operation). This is a gap but not a contradiction.
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 directly to the point, with no filler. It front-loads the primary purpose (pagination) and adds a useful ordering detail without wasting 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?
The tool is relatively simple and an output schema exists, so return values may be documented there. However, the lack of parameter explanations and any mention of cursor/limit usage leaves the agent partially in the dark about how to perform pagination beyond the phrase 'Page through'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention any parameter names or semantics—conversation_id, limit, cursor, and api_token are all undocumented in the description. The agent gets no help understanding how to use these 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?
The description uses specific verb 'Page through' plus resource 'a conversation's sent messages' and ordering 'oldest first'. This clearly distinguishes it from siblings like list_conversations (lists conversations) and get_message (fetches a single message).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this is for paginating through sent messages of a specific conversation, which implies when to use it. However, it does not explicitly mention alternatives or when not to use it, such as using list_conversation_comments for comments or get_message for a single message.
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:

[![Jelly-FastMCP MCP server](https://glama.ai/mcp/servers/js-cohn/Jelly-FastMCP/badges/card.svg)](https://glama.ai/mcp/servers/js-cohn/Jelly-FastMCP)

Score Badge

Copy to your README.md:

[![Jelly-FastMCP MCP server](https://glama.ai/mcp/servers/js-cohn/Jelly-FastMCP/badges/score.svg)](https://glama.ai/mcp/servers/js-cohn/Jelly-FastMCP)

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/js-cohn/Jelly-FastMCP'

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