sentvia-mcp

Server Quality Checklist

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

Latest release: v0.2.1
Disambiguation5/5
Each tool targets a distinct resource and action: webhooks, inboxes, address rules, domains, messages, threads, and drafts are all clearly separated. The send/reply/forward trio is differentiated by their descriptions, so there is no ambiguity in tool selection.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_inbox, list_drafts, delete_webhook). The occasional use of 'add' instead of 'create' (add_domain, add_address_rule) is a minor synonym variation, not a structural inconsistency.
Tool Count4/5
With 21 tools, the server is slightly larger than the typical 3-15 range, but this is justified by the breadth of the email platform (inboxes, domains, messages, threads, drafts, webhooks, and rules). Every tool has a clear purpose, so the count feels appropriate rather than bloated.
Completeness4/5
The tool surface covers core CRUD for inboxes and webhooks, plus sending, searching, threads, and drafts. Minor gaps exist, such as no delete for drafts or domains, but these can be worked around (e.g., by recreating resources). No major lifecycle dead ends are present.
Average 3.6/5 across 21 of 21 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 9 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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description gives no insight into whether the deletion is permanent, what happens to existing matching rules, or any side effects, leaving the agent without critical behavioral context for a destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of a single clear sentence. However, it is so brief that it sacrifices useful operational 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?
For a delete operation with no output schema and no annotations, this description is under-specified: it omits prerequisites, effects, and expected return values, making it incomplete for an agent to use reliably.
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 specifies rule_id as a required string, but the description ignores it entirely; with 0% schema coverage, the description should have explained the parameter's meaning and source but did not.
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 'Delete an allow/block rule' clearly states the action (delete) and resource (allow/block rule), distinguishing it from sibling tools like add_address_rule and list_address_rules.
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 explicit guidance on when to use this tool, nor does it mention that rule_id should be obtained from list_address_rules, so the agent receives no usage context beyond the obvious.
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 'Delete' which implies destructiveness, but does not disclose side effects, idempotency, auth requirements, or impact on associated resources.
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 that directly communicates the core action. However, it is somewhat under-specified for a tool that could benefit from additional context, making it not fully sufficient as a standalone description.
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 and output schema, the one-sentence description is insufficient. It fails to explain when to use the tool, what happens on deletion, or any error conditions. For a destructive operation, more context is needed for an AI agent to select and 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% and the description adds no meaning to the webhook_id parameter beyond its name. The parameter name is self-explanatory, but the description does not compensate for the lack of schema-level explanation, leaving the agent without additional context about format or constraints.
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 (delete) and the resource (webhook endpoint). It directly differentiates from sibling tools like create_webhook and list_webhooks by indicating the destructive 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?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or consequences. The description merely states the function without any contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing side effects (e.g., whether the draft is deleted after sending), required permissions, reversibility, or return behavior. The 'immediately' adds slight context but 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 sentence with clear structure and no filler. It is appropriately concise, though it could include more actionable guidance without losing efficiency.
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 is incomplete given no annotations, no output schema, and a 0% schema description coverage. It fails to mention side effects, prerequisites, or return values, and does not address overlapping sibling tools, making it insufficient for an agent to safely 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 input schema has one parameter (draft_id) with no description (0% coverage), and the description does not explicitly explain the parameter. It only implies via 'existing draft' that draft_id identifies which draft to send, adding minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send') and the resource ('an existing draft'), with the adverb 'immediately' adding specificity. It distinguishes from siblings like send_message, reply_to_message, forward_message, and create_draft by targeting an already-created draft.
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 vs alternatives. It implies usage with a draft_id but does not mention prerequisites, exclusions, or compare with send_message or create_draft.
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 for behavioral disclosure. It does reveal one important effect (mail stops being accepted), but it omits other critical traits for a destructive action: whether deletion is irreversible, what happens to existing messages, permission requirements, or whether the inbox ID becomes invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary action and followed by a meaningful consequence. Every word earns its place, and there is no redundancy or filler.
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, the absence of annotations and an output schema means the description should cover more than the basic delete action. It does not state whether deletion is permanent, what happens to the inbox's messages, or what the operation returns, leaving significant gaps for an agent to safely invoke the 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?
The schema has one required parameter, inbox_id, with 0% schema description coverage. The description does not mention inbox_id at all, nor does it explain how to obtain or format it. This leaves the parameter entirely undefined beyond its name and type.
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 a specific verb ('Delete') and resource ('an inbox'), distinguishing it from other sibling tools like create_inbox or list_inboxes. The added consequence, 'Mail to its address stops being accepted,' reinforces the operation's effect.
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 consequence that mail stops being accepted implies the tool should be used when you no longer want an inbox to receive mail. However, there is no explicit guidance about when to use it versus alternatives, no mention of prerequisites, and no exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses ordering behavior ('in order') but says nothing about side effects, error conditions, rate limits, authentication, or return format. 'Fetch' implies read-only but isn't explicit.
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?
Single sentence with no redundant words. All information is front-loaded and purposeful.
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 fetch tool, the description covers the core action and result scope, but lacks detail on return structure, missing-thread behavior, or pagination. No output schema exists to compensate.
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 parameter, thread_id, with 0% description coverage. The description adds no meaning beyond the parameter name; it doesn't explain the format or constraints of thread_id.
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 ('Fetch') and identifies the resource ('a thread') while also noting the returned scope ('all its messages in order'). It distinguishes from siblings like get_message (single message) and list_threads (list of threads), though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance about when to use this tool versus alternatives. The description implies usage—fetching a thread's messages—but lacks any exclusions or mention of sibling 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 bears the full burden of behavioral disclosure. It fails to mention important aspects such as whether the email is sent immediately, whether inbox verification is required, what happens on failure, or any rate limits. The single sentence adds no transparency beyond the obvious act of sending.
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 unnecessary words. It communicates the core purpose at a glance, which is ideal for conciseness. No structural issues.
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 8 parameters, no annotations, and no output schema, the description is too sparse. It does not explain what the function returns, whether recipients are validated, or how sending behaves in different scenarios. This incompleteness could lead to incorrect usage by an agent.
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 no parameter-level information. Schema coverage is 63%, leaving some parameters (cc, bcc, subject) without descriptions. While these are self-explanatory, the tool description does not clarify relationships between text and html, or whether attachments can be combined with body types, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send a new email from one of your inboxes' clearly states the verb (send), resource (email), and scope (from an inbox). It distinguishes from siblings like reply_to_message and forward_message by specifying 'new email', and from create_draft/send_draft by implying an immediate send 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 usage guidance is provided. The description does not mention when to use this tool versus alternatives like reply_to_message, forward_message, or create_draft/send_draft. It only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It indicates a read-only operation ('Get') and what the result will include, but it does not mention authentication requirements, error behavior, or whether the operation is safe. For a simple getter, this is adequate but not comprehensive.
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 purpose without any filler. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description provides the core return information but omits context such as prerequisites (e.g., domain must already exist via add_domain) or what happens if the domain is not found. It is 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?
Schema description coverage is 0%, and the description does not explain the meaning or format of 'domain_id' beyond the schema's bare type string. It does not say whether the ID is a UUID, a domain name, or how to obtain it, 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 uses the specific verb 'Get' with the resource 'domain' and specifies the exact information returned: 'verification status and required DNS records.' This clearly distinguishes it from sibling tools like add_domain, which creates a domain.
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 use when you need to check a domain's verification status or DNS records, but it does not explicitly state when to use this tool versus alternatives (e.g., after adding a domain via add_domain) or any exclusions. It provides clear context but no explicit guidance.
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 core action and tenant scope, but fails to disclose important behaviors such as pagination, ordering, whether full message content is returned, or the read-only nature of the operation beyond the obvious 'list' keyword.
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 that is front-loaded with the action and resource. There is no redundant information, fluff, or repetition of the tool name, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with zero parameters and no output schema, the description is minimally viable but missing some context. It states the tenant scope, which is useful, but it does not mention what fields are returned, whether drafts are sorted, or if pagination is supported. Given the lack of annotations and output schema, a bit more detail would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema does not describe any, so there are no parameter semantics to explain. Per the rubric, a baseline of 4 is appropriate when there are no parameters, and the description does not need to compensate for missing parameter 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 'List drafts for this tenant' uses a specific verb ('list') and a clear resource ('drafts'), making the tool's purpose immediately obvious. It also distinguishes itself from sibling tools like create_draft and send_draft by specifying the read-only listing operation, which is unique among 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or scenarios where another tool would be more appropriate. The only hint is the implicit 'list' verb, but no explicit usage context 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. However, it does not mention whether the listing is read-only, paginated, ordered, or if it requires any permissions. The verb 'list' implies safety, but no explicit behavioral details are 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 a single, front-loaded sentence with no filler or redundant information. It perfectly captures the tool's purpose in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, no output schema, no annotations), the description is sufficiently complete. It tells the agent exactly what the tool does and the scope (tenant-level). It could arguably add more details like 'returns all rules', but for a simple list operation, this suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline for this dimension is 4. The description has no need to explain parameter semantics since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'allow/block rules' scoped to 'this tenant'. It distinguishes itself from sibling tools like add_address_rule and delete_address_rule by indicating a read-only enumeration 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 versus alternatives, no exclusions, and no context about prerequisites. It simply states what it does, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that block rules are enforced on both send and receive, which adds meaningful insight beyond the schema. However, it does not clarify behavior for allow rules, idempotency, error handling, or permissions, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and includes a key behavioral detail. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with no output schema, the description covers the core purpose and an important behavioral trait. However, it leaves ambiguity about the 'both' direction default and whether block rules are always both, potentially confusing agents. More details about idempotency or duplicate handling would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (pattern and direction have descriptions, kind does not). The description reinforces the pattern format and kind values ('allow' or 'block'), but adds little beyond the schema. The behavioral note about block rules does not directly clarify parameter semantics. Overall, the description contributes marginal 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 clearly states the action ('Add') and the resource (an allow or block rule for an email address or bare domain). It distinguishes from siblings like list_address_rules and delete_address_rule by specifying the creation operation and the rule types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need to add allow/block rules. It provides behavioral context (block rules enforced on both send and receive) but does not explicitly contrast with alternatives or mention exclusions such as 'use list_address_rules to check existing rules.' Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the tool does not send and that scheduling/reply are optional, which is useful. But it omits other important behaviors like permissions, idempotency, what happens with a future scheduled_at, or what the response contains.
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 contains only necessary information. It is concise and structured in a clear order: create, optional behavior, and explicit limitation.
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 7 parameters, no output schema, and no annotations, the description is too sparse. It doesn't explain return values (e.g., draft ID), clarify whether both html and text are needed, or detail how scheduled drafts behave, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (2 of 7 parameters). The description adds meaning for scheduled_at ('optionally scheduled') and reply_to_message_id ('optionally a reply'), but provides no context for html, text, subject, to, or inbox_id, forcing agents to rely solely on parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Create') and resource ('a draft'), and explicitly mentions optional scheduling and reply behavior. It also says 'Does not send,' which differentiates it from sibling tools like send_message and send_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you want to create a draft rather than send a message immediately, with optional scheduling or reply. However, it does not explicitly name alternative tools for sending, such as send_message or send_draft, so the guidance is implicit rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the default domain but does not disclose potential side effects, permissions required, reversibility, or what the response contains. For a creating/mutating 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, focused sentence that delivers the core purpose without unnecessary words. It is front-loaded and directly actionable.
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 two-parameter creation tool with a well-described schema, the description is adequate but missing important context: what the tool returns, any prerequisites (e.g., domain ownership), and possible side effects like DNS changes. These gaps lower completeness, but the tool's simplicity mitigates the impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both parameters. The description adds the context that the domain is managed (mail.sentvia.ai), which slightly enhances understanding of local_part, but the schema already explains the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Create') and resource ('email inbox'), and adds the default domain context. It distinguishes itself from sibling tools like list_inboxes and delete_inbox.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to create a new inbox) and provides context about the default domain, but it does not explicitly mention exclusions or alternatives. Since this is the only create_inbox tool among siblings, the usage context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the response includes body and attachment links, and the verb 'fetch' implies a read-only operation. It does not mention potential errors or permission requirements, but for a simple read tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the core action, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with one parameter and no output schema, the description is sufficiently complete: it states what is returned and the primary use case. It could mention behavior when the ID is invalid, but this is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no extra meaning beyond the parameter name 'message_id' and the phrase 'by id'. The schema already declares message_id as a required string, so the description does not 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a single message by its ID, specifying the resource (message) and the action (fetch). It also mentions the return includes body and attachment links, which distinguishes it from sibling tools like get_thread or search_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you have a message ID and need the full message content. However, it does not explicitly mention when to prefer it over alternatives like get_thread or search_messages, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavior. It states the scope ('for this tenant'), which is good, and the verb 'List' implies a read-only operation. However, it does not mention any potential limitations like pagination, ordering, or what constitutes an 'inbox,' so the transparency is adequate but not rich.
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 redundant words. It front-loads the core action and resource immediately. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless read-only list tool, the description is mostly complete. It states the resource and scope, and there is no output schema to worry about. However, it does not explicitly state what is returned (e.g., a list of inbox objects), though this is strongly implied by 'List all inboxes.' A complete description for a CRUD suite might benefit from one extra clause.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (empty schema). The description adds no parameter details because none are needed. Baseline for zero params is 4, and the description does not detract from that.
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 (List) and the resource (all inboxes) with a scope qualifier ('for this tenant'). It distinguishes from sibling tools like create_inbox and delete_inbox because the verb and resource are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention that this is for viewing existing inboxes before creating one, or contrast with list_address_rules. The description is purely declarative with no 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, the description carries the full burden. It discloses the sort order ('most recently active first') but does not detail return format, pagination behavior, or potential side effects. It is accurate but minimal, lacking richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word earns its place, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, two optional parameters, and no output schema, the description is adequate. It clearly states the core functionality and ordering, and the schema covers parameter details. It could mention the absence of mandatory filters or return type, but is reasonably complete for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as both 'limit' and 'inbox_id' have descriptions in the schema. The description itself adds no extra parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists conversation threads, using the specific verb 'List' and identifying the resource 'conversation threads'. It also adds ordering context ('most recently active first') and distinguishes from siblings like get_thread and search_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a listing operation but does not explicitly state when to use it over alternatives like get_thread or search_messages. There is no mention of exclusions or preferred contexts, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the important behavioral detail of setting In-Reply-To/References automatically. However, it omits other behavioral aspects such as whether it sends immediately, permissions required, or potential side effects, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose and the key threading nuance without any filler or repetition. It is well-structured for quick comprehension.
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 tool with three parameters and no output schema, the description covers the main purpose and a critical behavior, but it lacks parameter-level details and any discussion of return values or edge cases. The low annotation coverage makes it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (message_id is described but html and text are not). The description adds no extra meaning about the html and text parameters, leaving the agent with weak guidance on how to use them or which is preferred.
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 ('Reply to a message') and the key distinguishing feature ('staying in its thread'), which separates it from siblings like send_message or forward_message. It specifies the resource and the threading behavior explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (replying within an existing thread) and mentions the automatic header setting. However, it does not explicitly reference alternatives or state when not to use it, though the thread-staying detail provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the semantics of the three modes and the fallback behavior when query is absent ('No query returns recent messages'). Since no annotations are provided, this is valuable behavioral context. It does not cover response format or pagination, but the core behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core purpose. Every sentence provides useful information: the operation, the mode options, and the no-query default. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description gives a reasonable overview but omits details like response format, how limit acts, and any sorting/pagination. The inclusion of mode semantics and no-query behavior is helpful, but more details would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the mode parameter ('keyword (default), semantic (by meaning), or hybrid') beyond the schema's terse 'Search mode,' and explains query behavior when omitted. However, it does not explain the limit parameter, and only half of the schema parameters have descriptions. Thus it partially compensates for the schema coverage 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 states the tool's function: 'Search messages across the tenant.' It identifies the resource (messages) and scope (tenant). It does not explicitly differentiate from sibling tools like get_message or list_threads, so it falls short of the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides guidance on search modes: keyword, semantic, hybrid, with keyword as default. It also notes the no-query behavior, which helps the agent know when to use it without filters. However, it does not discuss when to choose this over get_message or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that the tool returns DNS records to add and that verification is automatic after propagation, which is useful. However, it does not mention potential side effects, such as behavior if the domain already exists, or any permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action ('Add a custom sending domain'), and every sentence provides value. There is no wasted text, and the structure is straightforward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without an output schema, the description explains the return value (DNS records) and the follow-up behavior (automatic verification after propagation). It lacks details on input format or error conditions, but it is adequate given the tool's simplicity and the presence of only one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, hostname, with no description in the schema (0% coverage). The description's phrase 'custom sending domain' implies that hostname is the domain being added, adding meaning beyond the raw string type. This compensates for the lack of schema-level descriptions, though it could be more explicit about the expected format (e.g., should it include a protocol or subdomain?).
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 adds a custom sending domain, with 'add' as the verb and 'custom sending domain' as the resource. This distinguishes it from siblings, particularly the read-only get_domain tool, by specifying the creation/registration 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 the tool is used when adding a sending domain, and mentions the follow-up DNS setup and automatic verification. However, it does not explicitly state when not to use it or how it differs from alternatives like get_domain, though the action is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical behavioral trait: the signing secret is returned only once on creation and must be stored. Since no annotations are provided, this is essential context that helps the agent understand a one-time output. However, it does not mention other behaviors such as URL validation, rate limits, or what else the response contains, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, with the first front-loading the main action and the second adding a crucial one-time secret warning. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the main purpose and the most important output (the signing secret). It could mention the webhook ID or other response fields, but given the simplicity and the absence of an output schema, the description is reasonably complete and provides enough context 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for both parameters ('url' and 'events'), so the description does not need to explain them. The description adds no extra parameter semantics beyond what the schema already provides, but it does not repeat or contradict anything either, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb and resource: 'Register a webhook endpoint for delivery events.' It distinguishes from sibling tools like list_webhooks and delete_webhook by indicating the creation aspect, and the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to set up webhooks for receiving delivery events, but it does not explicitly state when to use it versus alternatives or mention any prerequisites or exclusions. The context is somewhat implied via the verb 'Register' and the reference to delivery events, but no clear alternatives or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait: signing secrets are omitted from the response, which sets expectations about output. The verb 'List' implies a safe, read-only operation. However, it does not mention pagination or error behavior, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action. Every word adds value, including the parenthetical about signing secrets. There is no unnecessary detail or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and no output schema, the description is mostly complete. It covers the purpose and an important output detail (secrets omitted). However, it does not mention potential pagination or authentication requirements, which could be relevant for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, giving a baseline of 4. Since there are no parameters to describe, the description does not need to add parameter meaning. The note about signing secrets relates to output, not parameters, which is acceptable given the input schema is empty.
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 ('List') and the resource ('webhook endpoints'), with an important qualifier that signing secrets are omitted. This distinguishes it from sibling tools like create_webhook and delete_webhook, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 simply states what it does, but does not mention any context, prerequisites, or alternatives such as list_inboxes or list_address_rules. There is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the original is quoted and its files re-attached, and that the forward begins a fresh thread. This goes beyond the tool name and adds useful behavioral context, though it does not mention permissions or edge cases (e.g., large attachments, failure modes).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Forward' and the resource 'a message'. It conveys all key distinctions without waste, making it easy for an agent to quickly understand the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters fully documented in the schema and no output schema required, the description provides the essential behavioral context (fresh thread, quoting, file re-attachment) that an agent needs to select and invoke the tool. It lacks explicit return-value or permission details, but these are not critical for a simple forward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (to, text, message_id, from_inbox_id) already has a clear description. The tool description adds no extra parameter-level detail; it only restates that text is an optional note, which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (forward), the resource (a message), and the specifics: new recipients, a fresh thread, quoting the original, and re-attaching files. This strongly distinguishes it from sibling tools like reply_to_message (which continues the existing thread) and send_message (which composes without quoting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you want to send an existing message to new recipients as a new thread. It does not explicitly name alternatives or exclusions, but the phrase 'new recipients in a fresh thread' provides clear contextual guidance vs. replying or sending. Sibling tool names reinforce the distinction.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/samuelar2/sentfromai-mcp'

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