Preview deleting an SDR outreach campaign
sdr_preview_delete_outreachShow what would happen. The Signal Search ITSELF is NOT deleted, only the outreach campaign.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| search_id | Yes |
sdr_preview_delete_outreachShow what would happen. The Signal Search ITSELF is NOT deleted, only the outreach campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| search_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does disclose one important behavioral trait: the Signal Search is not deleted, only the outreach campaign. However, it says nothing about what the preview returns, whether it is read-only/side-effect free, or whether any permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no padding. Slightly suboptimal ordering in that the vague 'Show what would happen' leads while the decisive scope constraint trails, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter preview tool with no annotations and no output schema, the scope clarification is valuable but the definition omits what the preview actually returns (e.g., the campaign/recipients that would be removed) and any safety statement, leaving the agent to guess at the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single search_id parameter has 0% schema coverage, so the description must compensate and does not. It never states that search_id identifies the search whose outreach would be deleted, and the mention of the Signal Search concerns deletion scope, not the parameter's meaning or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It is a dry-run of deleting an SDR outreach campaign, and the second sentence crisply distinguishes this from deleting the underlying Signal Search, which separates it from sdr_delete_search. The first sentence ('Show what would happen') is vague on its own, but the title plus the scope clause make the verb and resource identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The preview/dry-run framing implies this should be consulted before invoking sdr_delete_outreach, but the description never states that condition, lists prerequisites, or names the delete tool it precedes. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.