Skip to main content
Glama
Sign In
Andru

Andru

by geter-andru
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Put your story in each buyer's terms

get_messaging_framework
Read-only

Generates buyer-specific messaging from your ICP: what a target role responds to, the problem in their words, and concerns to answer for a given channel and funnel stage.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
stageNoWhere the buyer is in their journey
channelNoChannel (email, linkedin, phone, etc.)
segmentNoTarget segment or vertical
verticalNoThe 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.
targetRoleNoThe 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.
personaTypeNoTarget buyer title
productDescriptionNoA 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.

  1. Changed1 schema field changedv1.4.10
    • removedInput schema / properties / mbtiCategory
      Removed value: -{
-  "description": "Communication style to adapt the message to",
-  "enum": [
-    "Analytical",
-    "Driver",
-    "Expressive",
-    "Amiable"
-  ],
-  "type": "string"
-}
  2. Changed1 schema field changedv1.4.1
    • changedInput schema / properties / mbtiCategory / description
      Previous value: -"MBTI communication category for message adaptation"New value: +"Communication style to adapt the message to"
  3. First observedv1.4.0

TDQS

A4.4/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 and external-context traits are covered. The description adds useful behavior context: output is buyer-responsive messaging derived from the account's ICP, but it does not discuss limitations, generation variability, or auth/rate details.

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?

Four sentences, front-loaded with the use case and followed by output, source, and alternatives. The examples are brief and help disambiguate multi-buyer use, with no obvious padding.

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?

The tool is read-only/open-world with no output schema, so the description needs to explain likely returns; it does by naming the buyer-specific messaging components. It leaves some optional-parameter interplay and output structure to the rich schema, making it strong but not exhaustive.

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?

With 100% schema description coverage, the schema carries defaults, enums, and inference instructions for all seven parameters. The description only mentions channel, funnel stage, and buyer in passing, adding no syntax or precedence details beyond the schema, so baseline 3 is appropriate.

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 gives a concrete job—turning an account's story into one buyer's terms—and lists the returned components: what the buyer responds to, the problem in their words, and the concerns they need answered. It explicitly separates this from get_persona_profile and get_pre_brief, so an agent can identify the resource and its role.

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 the triggering condition ('when the person needs...'), includes example scenarios such as a first executive note or the same point for the CFO and IT lead, and routes the agent to get_persona_profile for buyer identity or get_pre_brief for meeting prep. This is explicit when-to-use and alternative guidance.

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

Deploy Server

Other Tools