Skip to main content
Glama
Sign In

Sightkick

by so.sightkick
OverviewDiscussionsAdmin

Send outreach email

send_outreach
Destructive

A real email to a stranger from the workspace's inbox, in the owner's name. Any time, whatever Auto outreach says. Not on the free trial. action:

  • pitch(id, force?): Book a prepared pitch into the send queue: out in the next business-hours slot, then Sightkick runs the follow-ups and replies. One scoring under the Opportunity floor (which steers Sightkick's own pitches and the app's buttons) goes with force: true.

  • reply(id, body?, to?): One reply now, threaded under their mail, on a thread mail went out on (a first email is a pitch): body, or the waiting draft (an offer's answer included). To whoever wrote last, or any address in to. Refused for an address on the do-not-contact list, or when the thread's inbox is gone. Can't be undone.

  • follow_up(id, body?): Send the owed follow-up at the send window's next opening.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "send_outreach"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoA prospect's id (get_outreach)
toNo
bodyNo
forceNo
actionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the destructive annotation by explaining that this sends a real email from the workspace inbox under the owner's name, how queued pitches and follow-ups behave, that replies cannot be undone, and that replies are refused for do-not-contact addresses or missing inboxes. This is strong disclosure for a destructive 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 action-bullet structure is useful and the main purpose is front-loaded. Some phrasing is awkward or dense, such as 'Any time, whatever Auto outreach says' and the Opportunity floor explanation, but most sentences carry operational meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive outreach tool with five parameters and three action modes, the description covers the essential invocation behavior, restrictions, timing, and irreversibility. No output schema exists, and the description provides enough context to call each action correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is only 20%, the description compensates by explaining the action enum and the role of id, force, body, and to across the three modes. It clarifies optional behavior such as using the waiting draft when body is omitted and sending to the last writer by default.

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 that this sends a real outreach email from the workspace inbox in the owner's name, and it breaks the operation into pitch, reply, and follow_up modes. It is specific enough to distinguish this from read-only outreach tools, though it does not explicitly name sibling 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?

It gives meaningful usage context: available any time regardless of Auto outreach, not available on the free trial, and each action has an indicated timing behavior such as next business-hours slot or immediate reply. It also notes refusal conditions for replies. It lacks explicit guidance on when to use this versus update_outreach or get_outreach.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Sightkick toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources