instantly-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action, and the analytics tools are clearly separated by campaign/account/step scope. Even at 40 tools, no two tools appear to do the same thing.
Naming Consistency5/5
All tool names follow a consistent snake_case verb-first pattern with clear object nouns, such as list_campaigns, create_lead_list, pause_account, and delete_webhook. The naming remains predictable across all resource domains.
Tool Count3/5
At 40 tools this is a heavy surface, but it maps cleanly onto Instantly's broad API scope and has little redundancy. The count exceeds the ideal compact size for an MCP server, though it is justifiable for a full platform wrapper.
Completeness4/5
Core workflows are well covered: campaign lifecycle, lead management, email reply/forward, account controls, blocklist CRUD, verification, and webhooks. Minor gaps exist, such as no campaign deletion, no lead-list deletion/removal, and only single-address email verification.
Average 3.6/5 across 40 of 40 tools scored. Lowest: 2.6/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 is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior itself. It only says 'List blocked contacts/domains' and gives a v2 path note. It does not describe the response format, pagination behavior, whether a limit is applied by default, or any side effects. The endpoint note is mildly useful but not a substitute for behavioral 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 short and front-loaded with the action and resource. The v2 path note is an extra but brief detail, and there is no unnecessary prose. It earns a high score for conciseness, even though it sacrifices some informative depth.
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 is simple, but the absence of an output schema and any description of the response contents leaves an agent without important runtime context. The path note helps but does not cover pagination, what fields are returned, or how this relates to add_to_blocklist and remove_from_blocklist. The description is below the minimum viable level for full standalone use.
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 contains one parameter, limit, with 0% description coverage. The description does not mention the limit parameter or explain its meaning, so it adds no semantic value beyond the raw schema. For a tool with such low schema coverage, the description needed to compensate and did not.
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 and resource: 'List blocked contacts/domains.' It clearly identifies a read/list operation, though it does not explicitly contrast with sibling tools like add_to_blocklist or remove_from_blocklist. The purpose is still unambiguous enough to distinguish it from the mutating blocklist tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. It does not state typical use cases, mention when it should not be used, or reference the sibling add/remove tools. Usage must be inferred entirely from the tool name and the one-line description.
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. 'List' implies a read-only operation and the description names the returned fields, which covers the core behavior. However, it does not mention pagination behavior, ordering, filtering semantics, or any authentication requirements, leaving key behavioral details undisclosed.
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 wasted words. It is concise and easy to parse, though it leaves out important parameter context that would make it fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no output schema or annotations, the description is minimal. It clarifies what is returned but omits parameter semantics and any guidance on search behavior or pagination, so an agent is not fully equipped to use the tool beyond a bare default call.
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 'limit' or 'search' parameters at all. An agent cannot learn what 'search' matches against or how 'limit' affects results from either the description or the schema field titles, beyond the default values.
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 ('sender email accounts'), and names the key output attributes (status, warmup status, daily limit). It is clearly distinct from singular get_account and list_emails, though it does not explicitly name any 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?
There is no guidance on when to use list_accounts versus get_account, pause_account, or update_account. The intended comparison context is absent, so an agent must 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 provided, the description must carry the behavioral burden. 'HIGH_WRITE' at least signals a high-impact mutation, but the description does not explain what pausing does to the campaign, whether it is reversible, or whether confirmation is required. This leaves significant behavioral ambiguity.
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 short and front-loaded: one purpose sentence and one warning label. No filler words exist, though 'Pause/stop' is somewhat redundant and the overall description is terse to the point of under-specifying.
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 mutateive nature and lck of annotations or output schema, the description is not complete. It does not clarify the confirm parameter, the campaign state transition, reversibility, or any consequences of the high-write action. An agent would still nave to guess at important invocation details.
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 needed to compensate. The campaign_id parameter is reasonably inferable from the name, but the confirm parameter is not explained at all — an agent cannot tell whether confirm=true is mandatory, what it confirms, or what happens if false. The description adds no parameter-level meaning.
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 a specific verb ('Pause/stop') and resource ('campaign'), so an agent knows what the tool does. It does not explicitly contrast itself with sibling tools like launch_campaign or update_campaign, but the action name itself is distinct enough.
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 given about when to use this tool versus alternatives such as launch_campaign or update_campaign. There is also no mention of prerequisites, side effects, or situations where pausing is appropriate vs. stopping entirely.
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. 'HIGH_WRITE' signals a high-impact mutation but is undefined jargon and does not explain whether confirmation is required, whether changes are reversible, or what side effects may occur.
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 compact and front-loaded, with every phrase contributing either the action, examples, or a risk signal. However, the cryptic 'HIGH_WRITE' tag is not self-explanatory and could be replaced with plain-language guidance.
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, no output schema, and zero parameter descriptions, this description is insufficient. It omits the purpose of the confirm flag, the meaning of 'fields', and any return or error behavior, leaving an agent to guess at important invocation details.
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 adds value by listing example field keys like name and campaign_schedule, but it does not explain the 'fields' object structure or the 'confirm' parameter, which is left entirely ambiguous.
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 'Patch' with a clear resource 'campaign settings' and provides concrete examples of updatable fields. This distinguishes it from lifecycle tools like launch_campaign and pause_campaign, though it could more explicitly state that this is for existing campaigns only.
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 implies a usage context—modifying campaign settings—but gives no explicit guidance on when to prefer this tool over create_campaign, launch_campaign, pause_campaign, or update_account. No exclusions, prerequisites, or alternative tool routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'LOW_WRITE' hints at a write operation but does not explain creation semantics, the meaning of the confirm parameter, idempotency, permissions, or any side effects. The agent cannot infer whether confirmation is required or what happens if confirm is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The core action is front-loaded, and 'LOW_WRITE' is compact if cryptic. Every element is brief and deliberate, making the description highly concise.
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 2-parameter tool with no annotations and no output schema, the description is too sparse to be complete. The confirm parameter is unexplained, there is no indication of return values, and behavioral details are absent. The tool is simple, but the description still leaves important gaps for an agent deciding whether 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 names no parameters. The confirm boolean is left entirely unexplained (confirm what? when is it required?), and name is only implied by the tool name. The schema's property titles 'Name' and 'Confirm' are the only hints, providing no meaningful semantic value.
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 exactly what the tool does: 'Create a new lead list.' The verb+resource is specific and distinct from sibling tools like list_lead_lists (read) and add_leads (which likely populates an existing list). The 'LOW_WRITE' suffix does not obscure the core 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?
There is no guidance about when to use this tool versus alternatives, nor any exclusions or prerequisites. The description is purely imperative ('Create a new lead list') and does not clarify whether the agent should first create a list and then add leads, or how this relates to add_leads.
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 that the analytics are per sequence step and variant, but it does not mention time range, aggregation basis, pagination, sorting, or whether the operation is read-only. The description is not misleading, but it is nearly silent about behavior beyond the obvious data scope.
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 compact and front-loaded with the distinguishing scope, 'per-sequence-step,' and contains no filler words. It loses one point because it is an incomplete fragment without an explicit verb, though it is still very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter analytics tool, the description gives enough to know the target campaign and the granularity of results. However, with no output schema and no annotations, it should clarify what the analytics contain and what 'variant' means so an agent can correctly interpret the result after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the only parameter, campaign_id, has just a title. The phrase 'for one campaign' adds the useful meaning that campaign_id identifies the campaign whose step analytics are returned. Since this is a single self-explanatory parameter, the description is minimally adequate, but it provides no format or example.
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 identifies the resource as per-sequence-step and variant analytics for a campaign, which distinguishes it from the sibling get_campaign_analytics. However, it is a noun phrase rather than an explicit action statement with a verb like 'retrieves' or 'returns,' so it reads more like a label than a full purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 get_campaign_analytics, get_campaign, or get_account_analytics. The only contextual hint is 'for one campaign,' which implies a campaign_id is needed, but no selection criteria or exclusion cases are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It labels the operation 'LOW_WRITE,' which hints at low impact, but it does not disclose whether updates are partial or full overwrites, whether confirm is ever required, or what side effects occur. 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 fluff. The field list is dense and useful, and 'LOW_WRITE' is a compact behavioral tag. It is concise, though the trailing '...' and bare LOW_WRITE tag are slightly informal.
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, no output schema, and an opaque fields object, this description is not complete. It does not specify confirm semantics, which fields are truly editable, whether values are replaced or merged, or any prerequisites. An agent would likely need to infer important call details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It usefully lists example property names inside the fields object, which adds meaning to that opaque nested parameter. However, it does not explain the confirm parameter or the behavior of the fields object beyond examples, so compensation is only partial.
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 ('Update'), the resource ('a lead'), and enumerates the editable fields. It is specific enough to distinguish from add/delete/move lead operations, though it does not explicitly contrast with set_lead_interest_status, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus siblings like set_lead_interest_status or move_lead. The only usage cue is implicit in 'Update editable fields,' which restates the purpose rather than providing context 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. The 'HIGH_WRITE' label signals high-impact mutation, but the description does not explain consequences, side effects, reversibility, or whether the confirm flag is required for safe execution.
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 short and front-loaded: the operation is stated first, followed by the risk label. There is no redundant prose, though the brevity comes at the cost of important 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 no annotations, no output schema, and a high-impact write operation, the description is incomplete for safe autonomous invocation. It lacks parameter semantics, behavioral effects, and prerequisites.
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 'confirm' boolean with default false is critical for a HIGH_WRITE action, but its meaning and necessity are entirely unexplained.
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 'Resume' and the resource 'paused sending account', making the core operation immediately understandable. It is distinct from siblings like pause_account, though it does not explicitly name or contrast alternatives.
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?
'Paused sending account' provides clear context for when to use the tool: when a sending account is paused and needs to be resumed. However, it offers no explicit exclusions or comparison to alternative 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?
The description adds 'LOW_WRITE (low risk)', which is useful safety context, but no annotations are present and the description does not explain the behavior of the optional 'confirm' parameter. It also does not disclose whether the operation is reversible, idempotent, or has side effects beyond changing read status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The action and scope are front-loaded, and the risk label is compactly appended. It is highly efficient for its size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a non-obvious optional parameter, this description is incomplete. The confirm parameter contract is entirely omitted, and the agent receives no guidance on prerequisites, return behavior, or failure conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies thread_id indirectly through the phrase 'all emails in a thread.' It does not explain the 'confirm' parameter at all, leaving the agent to guess whether confirmation is required or what the default false means.
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 ('mark'), a clear resource ('all emails in a thread'), and the outcome ('as read'). This makes it easy to distinguish from read-only sibling tools like list_emails, get_email, and count_unread.
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 given about when to use this tool versus alternatives, and no sibling tools are mentioned. While the action is implied by the tool name and description, there is no explicit context about preconditions, exclusions, or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and gives no information about return format, side effects, permission requirements, or whether the count is scoped to a specific account or folder. There is no contradiction with annotations because none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It front-loads the action ('Count') and the resource ('unread Unibox messages'), making it maximally concise and directly scannable.
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 there is no output schema or annotations, the description is the only source of context. It clarifies the core purpose but omits the return format and the meaning/scope of 'Unibox'. For a parameterless read-only count this is mostly adequate, but an agent could mis-handle the response or misunderstand the coverage of the count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is already complete (100% coverage by definition). The description does not need to add parameter-specific meaning, and the baseline for zero-parameter tools is 4.
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 'count' and resource 'unread Unibox messages', and it is the only count-related tool among siblings so it is distinguishable from list_emails and mark_thread_read. However, the term 'Unibox' is not defined and the scope (global vs. per-account) is left implicit.
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 list_emails or mark_thread_read. No exclusions, prerequisites, or context clues are provided beyond the obvious 'count unread' use case implied by the 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 burden of disclosure. It does indicate a side effect ('starts sending') and calls out HIGH_WRITE, which warns about mutation severity. Still, it does not explain idempotency, what happens if the campaign is already active, or the role of confirm.
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 short and front-loaded with the core action. The HIGH_WRITE warning and v2 path note add useful context without padding, though the confirm behavior is a notable omission.
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 write operation with no annotations and no output schema, the description is incomplete. It lacks essential guidance on the confirm parameter, the effect of defaulting to false, and what happens if the campaign is already running, leaving an agent unable to safely invoke the tool without additional assumptions.
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, but it explains neither campaign_id nor confirm. The v2 path note hints that campaign_id is used as a path parameter, but the critical confirm parameter's meaning and default behavior are 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 states a specific verb and resource: 'Activate/resume a campaign so it starts sending.' It clearly distinguishes this tool from sibling tools like pause_campaign and update_campaign by naming the exact effect on the campaign.
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 use is implied by 'so it starts sending,' so an agent can infer when to call it. However, there is no explicit guidance about when not to use it, prerequisites, or how it compares to pause_campaign or resume_account.
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 burden of disclosing side effects and call behavior. It adds some transparency by flagging LOW_WRITE and noting the endpoint keying by email, which is meaningful context. However, it does not explain what `confirm` does, whether certain transitions require confirmation, or what the response looks like.
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 tight and front-loaded, with the status vocabulary and keying note adding real value without padding. The formatting is serviceable, though the note block could be slightly more polished. No wasted sentences.
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 4-parameter mutation tool with no annotations, no output schema, and 0% schema descriptions, the description covers only the two required parameters. The role of `confirm` and `campaign_id` is left entirely to guesswork, and there is no indication of success/failure feedback. This is incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameter meaning. It fully documents `status` by providing the accepted label set and the raw int range, and it explains why `lead_email` is used instead of a lead id. The optional `confirm` and `campaign_id` parameters remain unexplained, keeping this from a 5.
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 opening sentence 'Set a lead's interest status' names a specific verb and resource, making the core purpose clear. It goes on to enumerate the valid status labels, which sharpens the intent. It does not explicitly distinguish itself from the sibling update_lead, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a useful operational note — the endpoint is keyed by lead_email rather than lead id — but it does not say when to choose this tool over update_lead or other lead-related siblings. No explicit when-to-use or exclusions are present, leaving the agent to infer the context from the 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 disclosure burden and does reveal that this is a HIGH_WRITE operation, that omitting body includes the original message, and that eaccount/subject default from the original. However, the `confirm` parameter is never explained, and the NOTE's reply_to_uuid is absent from the input schema, leaving the agent unsure what it must actually supply.
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 definition is compact and front-loaded: purpose, write warning, and default behaviors appear in the first three lines. The trailing '# NOTE' block is formatted like code trivia and introduces a non-schema identifier, adding mild noise and confusion.
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 covers purpose, write severity, and defaulting behavior, which is substantial for a 6-parameter tool. But it omits the semantics of `confirm` on a HIGH_WRITE tool, leaves the schema-to-API mapping (email_id → reply_to_uuid) unexplained, and with no output schema or annotations, an agent lacks enough guidance for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
At 0% schema coverage, the description is the only source of parameter meaning, and it does clarify `to` (comma-separated), `body` (omitting it includes the original), and `eaccount`/`subject` (default from the original). Yet `confirm`, a boolean defaulting to false on a write path, is completely undocumented, and `email_id` is never formally tied to the required reply_to_uuid.
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 first sentence, 'Forward a Unibox email to `to` (comma-separated addresses),' states a specific verb and resource with an operational detail about recipient format. The action is inherently distinct from its closest sibling, reply_to_email, so an agent can disambiguate without inspecting either schema.
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 sentence tells the agent when to choose forward_email over reply_to_email or the other email tools. The description provides defaults and an API note, but no selection criteria, prerequisites, or exclusions — usage is only implied by the verb 'forward.'
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 or output schema are present, so the description carries the burden of describing behavior. It does disclose the returned fields (id, name) and implies a read-only list operation, but it omits details such as ordering, pagination, and the effect of the limit parameter.
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. The parenthetical adds compact, useful return-shape 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?
For a simple list operation with only one optional parameter, the description is mostly usable, but it is thin. It does not explain limit semantics, result ordering, or how the response is structured beyond naming two fields, leaving gaps for an agent that must invoke the tool 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 does not mention the 'limit' parameter at all. The parameter name and default value are somewhat self-explanatory, but the description adds no meaning and fails to 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific: 'List lead lists' names the exact verb and resource, and the parenthetical '(id, name)' states what each result contains. This clearly distinguishes it from sibling tools like list_leads and create_lead_list.
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 about when to use this tool vs. alternatives. An agent may infer from the tool name that it is for reading lead lists, but there is no explicit context, prerequisite, or contrast with sibling tools such as create_lead_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds 'HIGH_WRITE (affects deliverability)', which signals a consequential side effect. However, it does not disclose whether changes are reversible, whether confirmation is required, or what the response looks like.
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 compact sentence with concrete examples and the important HIGH_WRITE warning front-loaded. There is no filler or redundant restatement of the tool name.
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, no output schema, and 0% schema parameter documentation, this description is incomplete. It leaves the 'confirm' parameter unexplained, says nothing about return values, and provides limited detail about side effects beyond deliverability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It meaningfully clarifies the 'fields' parameter with examples and the possibility of a nested warmup object. However, it does not explain the semantics of 'email' or the 'confirm' boolean, which remain opaque.
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 and resource ('Update account settings') and gives concrete examples like daily_limit, sending_gap, signature, and a nested warmup object. It is clear enough to distinguish from account retrieval or pause/resume operations, though it doesn't explicitly contrast with siblings.
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 use is implied: update account settings by supplying fields. However, the description does not explicitly say when to use this tool versus alternatives, when not to use it, or what preconditions might apply.
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. The verb 'Get' clearly indicates a read-only operation, which is helpful. However, it does not disclose error behavior, permission requirements, or whether the returned data has any side effects, though for a simple getter this is less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It immediately conveys the action, resource, scope, and lookup mechanism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and input for this simple one-parameter tool, but with no output schema and no annotations, it leaves the return structure and error behavior unspecified. An agent can call it correctly, but may be uncertain about what exactly 'status/settings' includes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It does add meaning by stating the email is the lookup key ('by email'), but it does not provide format details, validation rules, or what kind of email address is expected beyond the schema's generic string 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 uses a specific verb ('Get') and resource ('status/settings for one sending account'), and explicitly scopes it by email. The qualifier 'one' helps distinguish it from list_accounts and get_account_analytics without needing to inspect those tools.
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 explicit guidance on when to use this tool versus alternatives like list_accounts or get_account_analytics. It only implies a single-account lookup via 'by email', with no mention of prerequisites such as the account existing or being active.
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, but the description only states what is retrieved and adds no detail about errors, missing IDs, authentication, or output shape. 'Get' weakly implies read-only, but the description does not substantiate that behavioral profile.
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 short, front-loaded sentence conveys the tool's core purpose with no filler. Under-specification is a completeness concern, not a conciseness one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter this is enough to invoke correctly, but with no output schema and no annotations it omits expected return shape and not-found behavior. A brief note about what the tool returns or errors on 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?
With one parameter and 0% schema description coverage, the description should carry more of the semantic burden. It ties lead_id to the lookup via 'by id', adding minimal meaning beyond the parameter 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?
States a specific verb ('Get'), resource ('lead'), and selection criterion ('by id'). It is immediately distinct from sibling tools like list_leads or search_leads_by_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by id' implies this tool is for retrieving a single lead when the caller already has the lead_id. No explicit comparison to alternatives like list_leads or search_leads_by_email is provided, so usage guidance is left to inference.
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 disclosure burden. The NOTE adds genuinely useful behavioral context — v2 uses POST /leads/list rather than GET, and the API campaign field is `campaign`, not the schema's `campaign_id`. Still, it leaves read-only guarantees, pagination, and return format undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One precise sentence plus a compact, clearly flagged NOTE. Every element earns its place, and the critical version/field caveat is visually separated so the agent cannot miss it.
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 4-parameter tool with zero annotations and no output schema, the description covers the core operation and a key failure-mode pitfall. But it omits limit semantics and any return-shape or pagination guidance, leaving an agent to guess at the response format. It is minimally viable, not 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 description coverage is 0%, so the description must compensate. It does clarify that campaign_id, list_id, and search act as optional filters and warns that the API expects `campaign` rather than `campaign_id`. But `limit` is never mentioned, leaving its units and pagination meaning undocumented anywhere.
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?
States a specific verb and resource — 'List leads' — with precise optional filter dimensions (campaign, list, search text). The scope is clear and it is obviously distinct in kind from single-item getters like get_lead and from search_leads_by_email, though it never names a sibling explicitly.
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?
Communicates the intended use — listing leads with optional filters — and the NOTE gives an explicit invocation rule (use POST, use `campaign`). However, it offers no when-not-to-use guidance and never routes the agent to alternatives such as search_leads_by_email or get_lead, so the context is clear but exclusions are absent.
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 behavioral burden and does add a key trait: 'Makes ZERO HTTP calls,' which is valuable and not inferable from the schema. Still, it does not disclose what the preview returns, whether required fields are validated, or how invalid input is handled.
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 with no filler. The first sentence states the tool's full scope, and the second delivers the critical no-HTTP-calls behavior. Every sentence earns its place and is 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 nine parameters, no annotations, and no output schema, the description is too thin for an agent to invoke the tool reliably. It does not explain parameter semantics, required fields beyond their names, or what a successful preview produces, leaving substantial gaps for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter meaning. It mentions schedule, senders, tags, and lead-list mapping, but not the required name, subject, body fields or any semantics, constraints, or relationships between 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 the specific verb 'Preview' and names the exact resources: campaign, variants, schedule, senders, tags, and lead-list mapping. It distinguishes itself from sibling tools like create_campaign or launch_campaign by explicitly stating 'Makes ZERO HTTP calls,' which signals a non-executing preview behavior.
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 word 'Preview' and the guarantee 'Makes ZERO HTTP calls' imply this tool should be used for safe, side-effect-free validation before actually creating or launching a campaign. However, the description does not explicitly state when to use it versus alternatives, nor does it mention any when-not-to-use conditions 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 behavioral disclosure. It adds useful context by flagging LOW_WRITE and identifying the exact v2 endpoint and request body shape, but it does not explain side effects, duplicate handling, or what the `confirm` flag changes. The mutation intent is clear, yet operational behavior remains incomplete.
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 compact and front-loaded: the plain-language action, a risk/type marker, and the exact endpoint/body note each earn their place. There is no filler or redundant restatement of the schema.
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 two-parameter tool with no output schema, the description covers the main payload and endpoint, but the undocumented `confirm` parameter leaves a real invocation gap and there is no mention of return/response behavior. It is usable for a simple bulk-add operation, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description was expected to explain both parameters. It clarifies that entries are plain strings and maps them to the `bl_values` array, but it completely omits `confirm`, an optional boolean whose semantics and default behavior are opaque. The core parameter is only partially covered and the second parameter is 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 first sentence uses a specific verb and resource ('Add emails/domains to the blocklist') and scopes values to plain strings, so the tool's job is immediately recognizable. It is readily distinguishable from sibling tools such as remove_from_blocklist and list_blocklist.
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?
There is no explicit when-to-use/when-not-to-use statement or mention of the alternative removal tool; intended usage is only inferred from the verb 'Add' and resource 'blocklist'. This rises above no guidance but stops short of explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It explains the status filter semantics and lists returned fields, which is useful, but it does not mention pagination, ordering, limit behavior, or explicitly confirm the read-only nature of the 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?
The description is short, front-loaded with the core purpose, and every sentence adds value. The status enum mapping is compact and directly useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description gives the essential return fields and the status filter values. It lacks limit/pagination details, but the schema provides the limit default, and no output schema exists to require extra explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully documents the status parameter with all integer codes, but the limit parameter is not mentioned at all, leaving its semantics to the schema default and name.
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 and resource, 'List campaigns', and enumerates the returned fields (id, name, status, created). It is clearly a listing operation versus the singular get_campaign, but it does not explicitly call out that differentiation.
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 a list of campaigns. It gives the optional status filter values, but it does not state when to prefer alternatives like get_campaign or get_campaign_analytics, nor any exclusion criteria.
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 the return contents (schedule, sequences, status) but does not mention potential errors, authentication needs, or response format. For a read-only getter, this 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 sentence that front-loads the verb and resource, includes useful detail in parentheses, and contains no filler or redundancy. It is appropriately sized for the simplicity of the tool.
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 single-parameter getter with no annotations and no output schema, the description provides the essential purpose and return scope (full configuration with schedule, sequences, status). It does not mention error handling or id format, but these are minor gaps for a straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the campaign_id parameter beyond the schema's title 'Campaign Id'. It does not explain the parameter's format, origin, or how to obtain it, leaving the agent to rely on the tool name for 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 states a specific verb ('Get'), a specific resource ('one campaign's full configuration'), and the scope ('one') that distinguishes it from list_campaigns and the analytics sibling tools. The parenthetical '(schedule, sequences, status)' further clarifies what is included, leaving no ambiguity about 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the singular 'one campaign' and the focus on configuration, which suggests it should be used when retrieving a specific campaign's setup rather than listing campaigns or fetching analytics. However, there is no explicit mention of when not to use it or which sibling tool to use instead, so the guidance is only implicit.
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 burden of behavioral disclosure. It usefully states that the response includes subject, body, and thread, and 'Get' implies a read-only operation. It does not mention edge-case behavior such as not-found handling, authentication requirements, or whether the email is marked as read, but for a simple read tool this is a moderate 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. Every word contributes meaning by identifying the action, target, and returned 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 one-parameter read tool with no output schema, the description provides the essential information: what object is retrieved and what parts of it are returned. It does not cover error behavior or alternative usage, but those are minor for this simple tool and the description otherwise allows correct invocation.
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 a single required parameter, email_id, with no description and 0% schema description coverage. The tool description does not elaborate on this parameter beyond naming the resource, so the description adds little semantic value. The parameter name and tool name make the meaning inferable, but the description does not compensate for the missing 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 uses a specific verb ('Get'), a specific resource ('one email'), and defines the content scope ('full subject/body/thread'). This clearly distinguishes it from list-oriented siblings like list_emails and from action-oriented siblings like reply_to_email or forward_email.
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 use is implied by the singular 'one email' and the mention of full content: an agent can reasonably infer this tool is for retrieving a single email's details rather than listing or acting on emails. However, there is no explicit guidance about when to prefer this over list_emails or search_leads_by_email, nor any stated exclusions.
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 behavioral burden. It clearly signals a read-only listing operation and constrains scope to 'configured' webhooks, which is useful. However, it does not mention pagination, authentication requirements, or response shape—though none of these omissions are 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?
A single, front-loaded sentence that states exactly what the tool does with no wasted words. It is appropriately sized for such a simple, parameterless operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool, the description is minimally sufficient for invocation. However, there is no output schema and no description of the returned webhook objects, pagination, or ordering, leaving an agent without full context for consuming the result.
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 takes zero parameters, and schema coverage is vacuously 100%. Per the zero-parameter baseline, the description need not explain parameter semantics, and the absence of parameters makes invocation unambiguous.
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 the resource 'configured webhooks,' clearly identifying the tool's purpose. It is semantically distinct from siblings like list_webhook_event_types, create_webhook, and delete_webhook, even without explicitly naming 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 such as list_webhook_event_types, create_webhook, or delete_webhook. The context is inferable from the sibling names, but the description itself offers no explicit usage direction or exclusions.
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 explicitly discloses a side effect (verification credit consumption) and the asynchronous behavior (returns 'pending' after >10s, call again to poll). With no annotations provided, this is valuable transparency beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core purpose appears first, followed by a concise note about credit and polling. Every sentence adds necessary operational information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description covers purpose, side effects, and polling behavior. It omits details like the exact response format or how to identify the stored result when polling, but the low complexity keeps this from being a major gap.
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 needed to clarify the email parameter. It only adds 'single email address,' which conveys singular use but provides no format, validation rules, or constraints beyond the parameter name itself.
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 ('Verify') with a clear resource ('a single email address') and defines the result categories ('valid / invalid / catch-all'). This clearly differentiates the tool from siblings like search_leads_by_email or get_email, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. There is no mention of when to prefer verify_email over search_leads_by_email, get_email, or list_emails, nor any exclusion criteria or prerequisites.
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 behavioral disclosure burden. It flags HIGH_WRITE, states that the operation is asynchronous, returns a BackgroundJob, and advises polling for completion status. This adds substantial behavioral context beyond the schema, though side effects of copy/confirm remain unclear.
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 compact and front-loaded with the core purpose, followed by a critical async note. Every sentence carries meaningful information, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the most important operational quirk—the asynchronous BackgroundJob return and source requirement. However, with no output schema and no explanation of copy/confirm or how to choose between list and campaign destination/source parameters, an agent may still struggle to invoke it correctly in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It usefully identifies the source requirement via from_campaign_id or from_list_id, but it does not explain the copy and confirm booleans, nor clearly map the destination parameters. Seven parameters are left largely 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 opens with a specific verb and resource: 'Move (or copy) one lead to another campaign or list.' This unmistakably states what the tool does and distinguishes it from update_lead, delete_lead, and add_leads by focusing on relocating a lead between containers.
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 use is implied by the purpose statement, and the note clarifies that a source is required. However, there is no explicit guidance on when to choose move_lead over similar tools like add_leads, nor any exclusion criteria or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and delivers the critical traits: destructive (HIGH_WRITE), platform-enforced hard block, and confirm=true requirement. This goes beyond the schema, which misleadingly shows confirm defaulting to false. It doesn't state irreversibility or failure behavior, but the essential safety profile is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste: the purpose is front-loaded first, followed immediately by the one operational constraint that matters most. 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 2-parameter destructive tool with no output schema, the description covers purpose, severity, blocking behavior, and the confirmation requirement. The main gaps are explicit wording about what happens when confirm is absent and what a successful response signals, but these are minor for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate — and it does for the most important parameter by clarifying that confirm must be true despite its default of false in the schema. webhook_id is not elaborated, but its meaning is self-evident from the parameter name and tool purpose.
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?
'Delete a webhook' states a specific verb and resource, clearly distinguishing the operation from sibling tools like create_webhook and list_webhooks. It doesn't explicitly name a sibling for differentiation, but the delete semantics are unambiguous on their own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong invocation context — HIGH_WRITE, hard-blocked, and mandatory confirm=true — which tells the agent how to call it successfully. However, it offers no explicit when-to-use vs alternatives guidance or exclusion conditions; the when is implied by 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 burden of explaining behavior. It states the tool returns current workspace info and plan ids, which implies a read-only, non-mutating operation. It does not explicitly guarantee no side effects, describe error behavior, or mention authentication requirements, but for a simple getter with no parameters the disclosed behavior is reasonably sufficient.
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 result and the practical use case without filler. Every word adds value, and the parenthetical is a compact justification for why an agent would call this tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description provides the essential return topics ('workspace info and plan ids') and the intended interpretation ('what the key can reach'). It could be more explicit about exact fields returned, but the simplicity of the tool makes the high-level description adequate for selecting and invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add parameter-level meaning. The input schema is already complete with no properties. The description does not need to compensate for missing parameter docs, and the baseline for zero-parameter tools is 4.
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 resource as the current workspace and adds specific return content (plan ids), so an agent knows it is a retrieval tool for workspace-level metadata. It does not use an explicit verb like 'retrieve', but the tool name and 'current workspace info' make the purpose unambiguous. The workspace scope also distinguishes it from sibling account/campaign tools, though no contrast is explicitly made.
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 parenthetical '(useful to see what the key can reach)' gives a clear use case: call this when you need to understand the API key's access scope. There are no sibling tools that provide workspace info, so alternatives are not needed. It does not list exclusions or when-not-to-use, but the context is clear for a zero-parameter utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a HIGH_WRITE operation, that campaigns are created in a PAUSED state, and that a sensible schedule and single-step sequence are auto-generated. These are meaningful behavioral traits beyond the schema. It does not explain confirmation or error behavior, but the core write and side-effect profile is clear.
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 compact and front-loaded: key facts (HIGH_WRITE, created PAUSED) come first, followed by convenience and full-control usage in a tight structure. Every sentence earns its place and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core creation flow and side effects well, but it leaves the `confirm` parameter unexplained, which could be operationally important for a high-write tool. It also does not describe the return value or error conditions, though there is no output schema to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates well by explaining the role of name, subject, and body, and by giving inline shapes for schedule and sequences. However, the `confirm` and `timezone` parameters are not explained; `confirm` is especially ambiguous given the HIGH_WRITE label.
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 operation with a specific verb and resource ('Create a campaign') and adds distinguishing behavioral detail ('Created PAUSED — launch separately'). It does not explicitly contrast itself with siblings like preview_campaign_build or update_campaign, but the create semantics 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: the convenience path for minimal arguments versus the full-control path with schedule and sequences. It also explicitly instructs that creation is separate from launching. It does not name alternative siblings for when not to use this tool, but the guidance is sufficient for the common decision.
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. The verb 'List' implies a read-only operation, and the description discloses workspace-specific scoping along with representative values. However, it does not explicitly describe the return format or any behavior such as whether the list is static per workspace, so disclosure 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, front-loaded sentence that states the action, the resource, the scope, and concrete examples. Every element contributes meaning, and there is 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?
This is a simple zero-parameter list tool with no output schema, and the description covers its purpose and examples sufficiently for an agent to know when to call it and what it returns. It stops short of explicitly stating that the result is an array of strings, but 'List' plus examples make that clear enough.
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 there is no parameter ambiguity to explain. The description still adds value by enumerating example event types, which helps the agent understand what kind of values to expect from the 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 uses the specific verb 'List' with the resource 'webhook event types' and scopes it to 'this workspace'. It distinguishes itself from sibling list_webhooks by focusing on event types rather than webhook configurations, and the examples make the resource concrete.
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 useful for discovering valid webhook event type values, especially before creating a webhook, but it does not explicitly state when to use it over list_webhooks or create_webhook. The usage context is inferable from the examples but not directly stated.
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 behavioral burden and makes the critical side effect explicit: 'HIGH_WRITE (sends mail from your account).' It also discloses that omitted eaccount/subject are derived on execute and how html controls body formatting. It does not cover the confirm parameter or return/error behavior, so it is not a 5.
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 compact and front-loaded with the most important facts: purpose and write side effect. The v2 note at the end is useful but somewhat confusingly worded and slightly undermines the earlier derived-default statements, so it does not earn full marks.
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 write action with no output schema and no annotations, the description covers the core invocation path: required email_id/body, optional html, and eaccount/subject defaults. It is not fully complete because confirm is unexplained and the v2 note introduces endpoint-level requirements that are not reconciled with the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining eaccount as the sending account, subject derivation, html formatting, and body content. However, it leaves confirm completely unexplained and the final v2 endpoint note introduces reply_to_uuid/body-object terminology that does not map cleanly to the schema's email_id/body string fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Reply to an inbound Unibox email,' which clearly identifies the verb and resource. It also states the key consequence, 'sends mail from your account,' and the word 'reply' differentiates it from sibling forward_email without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool applies: replying to an inbound Unibox email, and explains derived defaults for eaccount and subject. It does not explicitly name alternatives or exclusions, so it stops short of a 5, but the usage context is 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?
With no annotations, the description carries the behavioral burden. It adds useful scope ('across campaigns/lists') and expected output ('who is this and which campaign(s) are they in'), and 'Find' implies a non-mutating read. However, it does not disclose whether matching is exect/partial/case-insensitive, whether multiple matches are possible, or the result shape.
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 with the action and scope front-loaded, followed by a short explanatory clause that tells an agent what to expect. Every part earns its place, and nothing is redundant.
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 one-parameter lookup with no output schema and no annotations, the description gives sufficient context to select and invoke the tool: the email input, the search scope, and the conceptual return. It could be more complete with exact-match behavior and result formatting, but the tool's simplicity makes those non-blocking.
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 provides only a required email string with zero description coverage, so the description must compensate. It clarifies that the email is the search key and that matching happens across campaigns/lists, adding purpose beyond the parameter name. It doesn't specify format or validation, but for a single-string email parameter this is not a significant 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?
States a specific verb and resource: 'Find leads matching an email', explicitly scoped 'across campaigns/lists', and clarifies the output intent as lead identity plus their campaign(s). This distinguishes it from broader lead tools like list_leads or get_lead by centering the search on email and campaign context.
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 usage scenario—use it when you have an email and want to identify the lead and their campaigns—but it does not explicitly state when to prefer this over list_leads/get_lead or any when-not conditions. No alternatives are named.
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 of behavioral disclosure. It discloses the underlying endpoint, the v2 API caveat, and the response shape (per-day rows plus a computed totals+rates roll-up). It does not mention pagination or date-boundary behavior, but these are minor for a read-only analytics 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 efficiently structured with a front-loaded summary, followed by a relevant endpoint note and a concise description of the return value. Every sentence adds useful information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, two-optional-parameter tool with no output schema, the description covers the endpoint, aggregation scope, and response structure. It is slightly incomplete around date parameter format and metric definitions, but overall adequate for correct invocation.
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 start_date or end_date semantics, date format, or inclusive bounds. The parameter names are somewhat self-explanatory, but the description does not compensate for the lack of schema-level 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 states a specific verb and resource: workspace-level daily sending analytics aggregated across accounts. This clearly distinguishes it from campaign-specific siblings like get_campaign_analytics. The note about the underlying endpoint reinforces the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for workspace-level analytics, not account- or campaign-level analytics. It does not explicitly name alternatives or state when not to use it, but the scope is clear enough to guide selection.
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 behavioral disclosure burden. It explicitly discloses a rate limit (20 req/min by Instantly) and clarifies the scope of emails returned. It does not describe response shape or pagination behavior, but the rate-limit note is valuable and the list operation is inherently non-mutating.
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 focused sentences with no filler. The core purpose and filters are front-loaded, and the rate-limit note is appended cleanly as a useful operational warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential list-and-filter behavior and the rate limit, and all parameters are optional so a minimal call is easy to construct. However, it omits the 'limit' parameter behavior and provides no output/return shape, which an agent would have to infer given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by mapping filters to meaningful concepts: campaign, lead email, sending account, and unread. This is especially helpful for the cryptic eaccount parameter. However, the 'limit' parameter is not mentioned at all, leaving one parameter without semantic guidance.
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 ('Unibox emails'), and adds scoping details ('sends, replies, manual') plus the main filter dimensions. This makes it clearly distinct from sibling tools like get_email, count_unread, and list_leads.
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 gives clear context for when to use the tool: to list Unibox emails with optional filters. However, it does not explicitly state when not to use it or point to alternatives such as get_email for a single email or count_unread for counts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and handles it well: it flags HIGH_WRITE, explains prerequisites, and discloses the significant behavior that one webhook is created per event type because the API takes a singular event_type. It also states that all created webhooks are returned.
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 compact, front-loads the core purpose, and follows with prerequisites and a behavioral caveat. Every sentence earns its place; there is no filler or repetition of structured schema data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is solid for the required workflow and prerequisites, but gaps remain: no output schema exists and the return shape is only vaguely described as 'returns them all', and optional parameters are left unexplained. For a mutating tool with no annotations, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain `url` and `event_types` well, especially the one-webhook-per-event-type behavior, but it provides no guidance for `name`, `confirm`, or `campaign_id`, leaving these opaque, with `confirm` being especially ambiguous.
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 ('Create webhook(s)'), the target resource (`url`), and the selector (`event types`). It also distinguishes the tool from siblings like list_webhooks, list_webhook_event_types, and delete_webhook by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for proper use, including the need for a publicly reachable URL and a plan tier supporting webhooks. It also gives an important exclusion ('not local stdio'), though it does not explicitly name alternatives or say when to prefer a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly lists the returned metrics and computed rates, which is meaningful behavioral detail for a read-only analytics tool. It does not mention error handling or date-range edge cases, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core scope ('ONE campaign') followed by the return details. Every sentence contributes necessary information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by enumerating the returned counts and rates. For a simple analytics read tool, the invocation context (one campaign, optional date range) is sufficiently clear, though it could be even stronger with explicit guidance on sibling 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?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds the date format (YYYY-MM-DD) and clarifies that the date range is optional, which helps, but it does not explain campaign_id explicitly or the exact semantics of start_date/end_date beyond being a range. Partial compensation only.
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 provides analytics for ONE campaign, distinguishing it from account-level or campaign-steps analytics siblings. It specifies the return content (counts and computed rates), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for ONE campaign over an optional date range' gives clear context for when this tool is appropriate: retrieving aggregate analytics for a single campaign. It does not explicitly name alternatives or exclusions, but the single-campaign scope is enough to guide selection among siblings like get_account_analytics or get_campaign_steps_analytics.
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 burden and discloses that the operation is HIGH_WRITE, hard-blocked, and requires confirm=true. The note about the under-documented bulk-delete body shape also tells the agent to verify the request shape before first use, which is a useful caveat. It does not mention response behavior or reversibility, but the safety-relevant 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 compact and front-loaded: action and safety requirement appear in the first sentence, with a focused caveat in the note. Every sentence adds value, and the note earns its place by flagging documentation uncertainty.
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 a mutating operation with no annotations and no output schema, so the description should describe the result or failure behavior; it does not. It does provide necessary safety and endpoint context, but an agent still lacks information about what happens when confirm=false or what a successful removal returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by tying 'entries' to emails/domains and overriding the schema's confirm default with 'always requires confirm=true.' It does not explicitly map 'entries' to the noted 'bl_values' array or specify exact string formats, but the core semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Remove emails/domains from the blocklist.' This unambiguously distinguishes the tool from its siblings add_to_blocklist and list_blocklist, despite not naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context by labeling the operation HIGH_WRITE, hard-blocked, and by stating that it 'always requires confirm=true,' so an agent knows the mandatory precondition. It does not explicitly contrast with add/list alternatives or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses key behaviors: bulk operation, deduplication of duplicate emails, the effect of skip_if_in_workspace, and the LOW_WRITE label. It does not explain what `confirm` does or what happens if both/neither target is specified, 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 core purpose is front-loaded in the first sentence, with supporting details compactly organized in a single paragraph using backticks for clarity. Every sentence adds value and there is no filler.
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 write tool with no annotations and no output schema, the description covers purpose, target constraints, lead field semantics, deduplication behavior, and re-run safety. Missing details about `confirm` and target-conflict errors are notable but the description is still largely adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by detailing the `leads` array structure, required email for campaigns, optional fields, and custom_variables as a dict. It also implies the roles of campaign_id and list_id. However, `confirm` remains unexplained, preventing a perfect score.
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 leads in bulk to a campaign or list, with a specific verb and resource. It also explicitly requires exactly one target, which distinguishes it from sibling lead management tools like update_lead or move_lead.
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 says when to use the tool: bulk adding leads to a campaign or list, with the 'provide exactly one target' constraint. It also notes that skip_if_in_workspace makes it safe for scheduled re-runs. It does not explicitly list alternatives for single-lead operations, but the usage context is clear.
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?
Since no annotations are supplied, the description carries the safety burden, and it discloses the high-write/hard-blocked risk plus the mandatory confirmation flag. It also names the primary side effect, stopping sends. It could explain the 'hard-blocked' term more, but it is far more transparent than a bare mutation 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?
Three short, dense fragments deliver purpose, risk, requirement, and domain context with no redundancy. The most important constraint, confirm=true, is positioned prominently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter action with no output schema, the description covers what the tool does, the required confirmation, and the risk profile. It does not mention an explicit resume path or return value, but nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does for the critical confirm parameter by stating it always needs to be true, going beyond the schema's default false. The email parameter is left implicit, but the parameter name and the tool's purpose make its role obvious.
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?
States the exact verb and resource ('Pause a sending account') and clarifies the observable effect ('stops it sending'), so it is easily distinguished from pause_campaign or resume_account. The resource scope 'sending account' removes ambiguity at a glance.
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?
Provides clear operational guidance: always requires confirm=true, framed by HIGH_WRITE and hard-blocked risk. It does not explicitly name alternatives like resume_account or pause_campaign, but the resource scope and 'Deliverability control' signal the intended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the safety burden. It discloses that the operation is permanent, destructive, high-write, hard-blocked, and the exact confirmation requirement. This is strong behavioral transparency for a delete 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?
One dense, front-loaded sentence communicates the destructive nature, the permanence, the write level, and the confirmation requirement without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter destructive tool with no annotations, this is nearly complete. It could add a note about what response to expect or consequences beyond the lead record, but the agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds essential semantics for confirm by stating it must always be true, overriding its default false. lead_id is not explained, but that parameter is self-evident from its name and required status.
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 and resource: permanently delete a lead. The leading 'DESTRUCTIVE' flag clearly differentiates this from non-destructive lead operations like update_lead or move_lead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear invocation guidance by requiring confirm=true in all modes, including autonomous. It does not explicitly mention alternatives or exclusions, but the destructive context makes the intended use obvious.
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:

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

Score Badge

Copy to your README.md:

[![instantly-mcp MCP server](https://glama.ai/mcp/servers/katekruger/instantly-mcp/badges/score.svg)](https://glama.ai/mcp/servers/katekruger/instantly-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/katekruger/instantly-mcp'

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