Iris

generate_content

generate AI outreach content (email or DM draft) for a contact/campaign. the contact's tags + enrichment_data feed the generation context automatically. requires generate scope.

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": {
      "generation_type": "<generation_type>",
      "tone": "<tone>"
    },
    "name": "generate_content"
  }
}

Input Schema

Name	Required	Description
`tone`	Yes	tone (e.g. professional, friendly, casual, formal, persuasive, informative)
`format`	No	dm = short platform-native message text with empty subject. defaults to email
`prompt`	No	additional freeform instructions
`contact_id`	No	target contact - its tags + enrichment_data are used automatically
`campaign_id`	No	campaign to scope the generation to
`include_cta`	No	include a clear call-to-action
`generation_type`	Yes	type of content to generate

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries real weight here. It adds two useful behavioral facts: generation context is pulled automatically from the contact's tags and enrichment_data, and the call requires the generate scope. It still doesn't say whether the resulting draft is persisted or just returned, which matters for a non-read-only 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?

Three short clauses, front-loaded with the verb and output type, followed by the context-feeding behavior and the auth requirement. No filler, though the fragmented lowercase style is slightly harder to scan than a full sentence.

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?

With 7 parameters, no output schema, and minimal annotations, the description covers the essentials (what is generated, what feeds context, auth scope). It leaves open whether a draft is returned vs stored, how campaign_id and contact_id interact when both or neither are supplied, and what tone/generation_type combinations yield.

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 every parameter including tone, format, and generation_type is already documented in the schema. The description's notes about auto-fed contact context and the email default restate what the schema already says, adding little new meaning. Baseline 3 is appropriate.

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+resource: 'generate AI outreach content (email or DM draft) for a contact/campaign'. An agent can tell this produces outreach copy rather than analysis or sending. It does not explicitly distinguish itself from the sibling generate_campaign_content, 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'for a contact/campaign' and the note that tags + enrichment feed context automatically, which hints at when this tool is appropriate. However, there is no explicit when-to-use/when-not guidance and no mention of how it differs from generate_campaign_content or where approve_message fits in the workflow.

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

All Iris 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.

Resources

Need Help?