Andru

Put your story in each buyer's terms

get_messaging_framework

Read-only

Use this when the person needs to put their story in one buyer's terms: a first note to an executive about what they could change, or the same point for the CFO and the IT lead. Returns what that buyer responds to, the problem in their words, and the concerns they need answered, for a channel and funnel stage. Built from the account's ICP. To learn who the buyer is, use get_persona_profile; to prepare for one specific meeting, use get_pre_brief.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_messaging_framework"
  }
}

Input Schema

Name	Required	Description
`stage`	No	Where the buyer is in their journey
`channel`	No	Channel (email, linkedin, phone, etc.)
`segment`	No	Target segment or vertical
`vertical`	No	The industry the user sells into (e.g., "fintech", "healthcare", "defense"). Infer from conversation context — the user's product description, company name, or the companies they're asking about. If unclear, ask.
`targetRole`	No	The buyer role being evaluated (e.g., "CFO", "CTO", "VP Sales"). Infer from context — often explicit in the user's question. If not mentioned, default to the most senior relevant role for their vertical.
`personaType`	No	Target buyer title
`productDescription`	No	A brief description of what the user's product does and who it's for. Infer this from the conversation if the user has already described their product. If the user hasn't mentioned their product yet, ask them: "What does your product do, and who do you sell to?" before calling this tool.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

removedInput schema / properties / mbtiCategory

Removed value: -{
-  "description": "Communication style to adapt the message to",
-  "enum": [
-    "Analytical",
-    "Driver",
-    "Expressive",
-    "Amiable"
-  ],
-  "type": "string"
-}

First observedOct 23, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds that output is generated from the account's ICP and enumerates the returned components (buyer triggers, problem framing, objections). It does not contradict the annotations and adds genuine context about the derivation of the result.

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 sentences, front-loaded with the usage trigger, then the return contents, then the sibling routing. Every sentence carries information, though the leading phrase is somewhat verbose given the examples that follow.

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?

No output schema exists, so the description appropriately summarizes the return shape (buyer preferences, problem framing, concerns) and states the ICP basis. Seven optional parameters with 100% schema coverage plus sibling routing leave little unexplained, though the description doesn't clarify whether any parameter is effectively required.

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 is already documented in the schema, including inference guidance for vertical, targetRole, and productDescription. The description only echoes that results are keyed to channel and funnel stage, adding little beyond the structured fields — 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?

The description names the concrete output ('what that buyer responds to, the problem in their words, and the concerns they need answered') and illustrates it with two distinct scenarios (executive first note, CFO vs IT lead). It also explicitly contrasts itself with get_persona_profile and get_pre_brief. The core verb phrase 'put their story in one buyer's terms' is a bit abstract, but the examples resolve it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

It opens with an explicit 'Use this when...' trigger describing the situation (translating one story for one buyer role at a given channel/stage). It then names the two nearest siblings and the conditions that select them ('to learn who the buyer is, use get_persona_profile; to prepare for one specific meeting, use get_pre_brief').

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

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