Andru

Prepare with buyer role-play

simulate_buyer_persona

Use this only when the person asks to talk with, or play out the meeting with, the buyers who'll be in the room. Andru writes a brief of what each person likely thinks going in (10 briefs a day), then plays them, one or several at once, in a Deal Prep session of 25 turns, asking what real buyers ask. Say "End role-play. How did I do?" for a scored debrief and what to take into the meeting. For the written brief alone, use get_pre_brief; it writes the same brief this session starts from.

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": "simulate_buyer_persona"
  }
}

Input Schema

Name	Required	Description
`mode`	No	meetings = the user's calendar meetings in the next 7 days. brief = the brief for a meeting (10 a day). opening = open a Deal Prep session from a brief_id, or with one buyer. reply = the founder's next message; speaker picks who answers. list = the user's six buyers.
`room`	No	Who's in the room, 1–8 people, each with persona (one of the six buyers) and an optional title and name.
`stage`	No	The deal's stage, 0–7.
`meeting`	No	The meeting in a sentence, when it isn't on the calendar.
`message`	No	mode=reply: what the seller says to the buyer. "End role-play. How did I do?" ends with a debrief.
`persona`	No	Which of the user's six buyers to simulate (mode=list shows them, from their buying committee). Pick based on who the user is preparing to meet.
`quoteId`	No	Optional: the quote_id from quote, to pay the quoted price (held for 30 minutes).
`speaker`	No	Who answers this turn (p1, p2…, from the brief).
`stageId`	No	Buyer journey stage (1=Researching, 2=Quantifying, 3=Exploring, 4=Comparing, 5=Business Case, 6=Implementing, 7=Advocating). Default: 3 (Exploring).
`brief_id`	No	The brief to open a session from.
`situation`	No	discovery, deal or customer_review.
`meeting_id`	No	A meeting from mode=meetings.
`session_id`	No	The Deal Prep session to continue (returned by mode=opening). Required for mode=reply.
`productName`	No	Product name. Defaults to the product in their ICP.
`session_key`	No	Optional idempotency key for opening a session: retrying with the same key never charges twice.
`idempotencyKey`	No	Optional: any unique string for this call. Retrying with the same key returns the first result and never charges twice.
`maxAmountCents`	No	Optional: the most this call may cost, in cents. If the price is higher, nothing runs and nothing is charged.
`productDescription`	No	What the user's product does. Defaults to the product in their ICP.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / mode / description

Previous value: -"meetings = the user's calendar meetings in the next 7 days (free). brief = the free brief for a meeting (10 a day). opening = open a session ($5) from a brief_id, or with one buyer. reply = the founder's next message; speaker picks who answers. list = the user's six buyers (free)."New value: +"meetings = the user's calendar meetings in the next 7 days. brief = the brief for a meeting (10 a day). opening = open a Deal Prep session from a brief_id, or with one buyer. reply = the founder's next message; speaker picks who answers. list = the user's six buyers."

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / maxAmountCents

Added value: +{
+  "description": "Optional: the most this call may cost, in cents. If the price is higher, nothing runs and nothing is charged.",
+  "minimum": 0,
+  "type": "integer"
+}

First observedOct 23, 2026

TDQS

A4/5.0

Behavior3/5

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

Adds real context beyond the annotations: a quota ('10 briefs a day'), a hard session length ('25 turns'), and the exact phrase that ends a session into a scored debrief. However, it never states that the call is metered/paid, even though quoteId, idempotencyKey, and maxAmountCents imply charging — that is the most consequential behavior for an agent to know before invoking.

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?

Front-loaded with the activation condition and then the flow, and every sentence maps to a distinct behavior (quota, turns, debrief trigger, alternative tool). Some sentences are dense run-ons that pack several facts together, costing a little readability.

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?

For an 18-parameter, five-mode tool, the description covers the canonical session flow well but never mentions mode selection at all — no guidance on meetings/brief/opening/reply/list — and says nothing about charging despite three payment-related parameters. Adequate for the happy path, incomplete for the tool's actual breadth.

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 schema already documents all 18 parameters, including the mode enum. The description adds no parameter-level meaning beyond a loose reference to the brief that a session 'starts from'; baseline 3 applies when the schema does the work.

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?

A specific verb+resource: Andru writes a brief on each buyer and then role-plays them in a Deal Prep session, with a scored debrief at the end. It also names the sibling it is not (get_pre_brief) and the boundary between them, so an agent can route without opening either schema.

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?

Opens with an explicit trigger condition ('only when the person asks to talk with, or play out the meeting with, the buyers') and closes with an explicit alternative for the adjacent need ('For the written brief alone, use get_pre_brief'). Both the when and the when-not are stated.

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.