Skip to main content
Glama

Draft outreach emails

draft_outreach_emails
Read-only

For up to 10 companies find the named decision-maker on each company's own site and write a first email to them. Nothing is sent and nothing is saved: the founder reads and edits the drafts. Takes 10-60 seconds.

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": {
      "seller": "<seller>",
      "leads": "<leads>"
    },
    "name": "draft_outreach_emails"
  }
}

Input Schema

NameRequiredDescriptionDefault
leadsYesCompanies to research
sellerYesThe product being offered

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / seller / description
      Previous value: -"The product being offered (scan_domain returns these fields)"New value: +"The product being offered"
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description still adds real value beyond them: it asserts no sending and no persistence ('nothing is saved: the founder reads and edits the drafts') and discloses expected latency of 10-60 seconds, which lets the agent plan for a slow call. It omits failure modes (e.g., no decision-maker found) and any allowance/rate considerations.

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 clauses, front-loaded with what the tool produces, then the critical no-side-effect guarantee, then the timing expectation. Every sentence carries information an agent needs; nothing is redundant with the title or annotations.

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?

There is no output schema, but the description tells the agent the return is editable drafts rather than a sent message, which is the key contract for a nested-input tool. What remains unspecified is the shape of each draft (subject/body, missing-contact behavior), a minor gap given the tool's simplicity.

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

Parameters3/5

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

Schema description coverage is 100%, so the nested leads and seller fields are already fully documented; baseline is 3. The description only adds that the per-company 'email' is used to identify the named decision-maker and that the 10-company cap matches maxItems, which is marginal value over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb pair ('find the named decision-maker', 'write a first email') against a concrete resource (outreach email drafts) and states scope ('up to 10 companies'). It also clarifies the research method ('on each company's own site'), which distinguishes it from bulk import/export siblings without needing their schemas.

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 rather than stated: 'write a first email' plus 'Nothing is sent' suggests this is the drafting/preview step before a sending tool, but no alternative is named and no explicit when/when-not condition is given. An agent can infer the workflow but must reason about it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources