MentionAgent

Edit the offer, goal, style, sender name and email template

set_email_settings

DestructiveIdempotent

Change how first emails are framed: 'offerTerms' (what this site offers in return, up to 400 characters, stated word for word), 'offerInFirstTouch' (put the offer in the first email, or hold it for the reply), 'outreachGoal' ('link' asks for a link, 'mention' asks for a brand mention only), 'emailStyle' ('default' is a one-sided ask, 'exchange' offers to feature them too), 'pricingDetails' (the price, up to 200 characters; the only figure the emails may quote) and 'fromName' (the sender name on every email). 'draftTemplate' with 'ownTemplate' true makes every first email this exact text, with only the greeting, subject and one opening line about their post written per site. Slots: {{greeting}}, {{opener}}, {{intro}}, {{offer}}, {{site_name}}, {{from_name}}; {{opener}} is required. Paragraphs are separated by a blank line, and {a|b} picks one wording per email so sends are not identical. A template that comes out over 90 words or uses a dash or a word the emails may not use is refused. 'ownTemplate' false goes back to AI-written emails and keeps the text. 'audienceTemplate' with 'audienceLabel' (for example 'students') is a second whole email, same rules, sent instead when the opening-line writer judges the post is written for that audience; only used while ownTemplate is on. An empty audienceTemplate removes it. Pass only the fields to change. Offer terms with a dash or a word the emails may not use are refused. Sends nothing.

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": {
      "workspaceId": "<workspaceId>"
    },
    "name": "set_email_settings"
  }
}

Input Schema

Name	Required	Description
`fromName`	No	Sender name, for example 'Matt Wilson'.
`emailStyle`	No	'default' (one-sided) or 'exchange' (mutual).
`offerTerms`	No	What the site offers in return. Empty string clears it.
`ownTemplate`	No	true to send draftTemplate as every first email, false to go back to AI-written emails.
`workspaceId`	Yes	Which site to act on. Call get_status with no arguments to list them.
`outreachGoal`	No	'link' or 'mention'.
`audienceLabel`	No	Who the second version is for, in a few words, for example 'students'.
`draftTemplate`	No	The whole first email with {{greeting}}, {{opener}} and {{from_name}} slots and blank lines between paragraphs, up to 2000 characters.
`pricingDetails`	No	The price, for example 'from $99/mo'. Empty string clears it.
`audienceTemplate`	No	The second whole first email, same slots and rules as draftTemplate. Empty string removes it.
`offerInFirstTouch`	No	true to state the offer in the first email.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 3, 2026

addedInput schema / properties / audienceLabel

Added value: +{
+  "description": "Who the second version is for, in a few words, for example 'students'.",
+  "type": "string"
+}

addedInput schema / properties / audienceTemplate

Added value: +{
+  "description": "The second whole first email, same slots and rules as draftTemplate. Empty string removes it.",
+  "type": "string"
+}

Changed2 schema fields changedOct 28, 2026

addedInput schema / properties / draftTemplate

Added value: +{
+  "description": "The whole first email with {{greeting}}, {{opener}} and {{from_name}} slots and blank lines between paragraphs, up to 2000 characters.",
+  "type": "string"
+}

addedInput schema / properties / ownTemplate

Added value: +{
+  "description": "true to send draftTemplate as every first email, false to go back to AI-written emails.",
+  "type": "boolean"
+}

First observedOct 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, it discloses validation behavior (templates over 90 words, or containing a dash or a forbidden word, are refused; offer terms with a dash or forbidden word are refused), clearing semantics for empty strings, that only the greeting, subject and one opening line are written per site, and that the tool 'sends nothing'. It is consistent with destructiveHint=true since empty values and ownTemplate=false overwrite existing template state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the field list, but the remainder is a single dense block of prose that mixes validation rules, slot syntax and audience-template conditions without paragraph breaks or bullets. Nothing is wasted exactly, yet the repetition of 'same rules' and the interleaving of independent constraints makes it harder to scan than it needs to be.

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 an 11-parameter mutation tool with no output schema and a destructive hint, the description covers what changes, what gets cleared, validation failures, template slot mechanics and the guarantee that no email is sent. An agent has essentially everything needed to invoke it 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?

With 100% schema coverage the baseline is 3, but the description adds substantial meaning beyond the schema: the per-slot purpose of {{greeting}}, {{opener}}, {{intro}}, {{offer}}, {{site_name}}, {{from_name}}, the fact that {{opener}} is required, blank-line paragraph separation, and the {a|b} alternation syntax for varying wording per email. These are constraints an agent could not infer from the schema alone.

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 the specific verb and resource ('Change how first emails are framed') and then enumerates the exact settings affected: offerTerms, offerInFirstTouch, outreachGoal, emailStyle, pricingDetails, fromName, draftTemplate, audienceTemplate. That is clearly distinguishable from sibling settings tools like set_profile, set_run_settings and set_sending.

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 concrete usage rules: 'Pass only the fields to change' establishes partial-update semantics, 'ownTemplate' false is described as the way back to AI-written emails, and audienceTemplate is scoped to 'only used while ownTemplate is on'. It does not explicitly contrast with sibling configuration tools like set_profile, but the conditions for each mode are clear.

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

All MentionAgent tools Inspect

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.