Andru

Profile a buyer

get_persona_profile

Read-only

Use this when the person asks what a specific buyer role cares about (a CFO, a VP of Operations) or why that person isn't responding. Returns Andru's starting picture of that buyer from the account's ICP: what they're measured on, what worries them, the concerns they need answered before they say yes, and what they need to hear. Treat it as something to confirm with the real person, not a conclusion. To prepare for one specific meeting, use get_pre_brief.

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": {
      "title": "<title>"
    },
    "name": "get_persona_profile"
  }
}

Input Schema

Name	Required	Description
`title`	Yes	Job title of the person you're meeting (e.g., "VP Engineering", "CTO", "Head of Sales")
`industry`	No	Their industry
`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.
`companySize`	No	Their company size range
`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.

First observedOct 23, 2026

TDQS

A4.2/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 real context on provenance and reliability: the output is 'Andru's starting picture... from the account's ICP' and should be treated as 'something to confirm with the real person, not a conclusion' — a valuable epistemic caveat an agent would otherwise miss. It stops short of noting staleness, coverage limits when ICP data is thin, or response shape.

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?

Roughly 75 words in three tight sentences: trigger first, return payload second, caveat plus alternative last. Each sentence earns its place. The enumerated return list is slightly long, but it is the highest-value information here.

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?

Six parameters, one required, no output schema — so the description must explain what comes back, and it does so item by item. Combined with the 'treat as hypothesis' caveat and the sibling routing, an agent has everything needed to decide and call correctly.

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 all six parameters (including infer-from-context guidance for vertical, targetRole, productDescription) are already well documented. The description adds no parameter-level detail of its own, only the implicit signal that ICP/account context feeds the result. Baseline 3 applies when the schema carries the load.

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?

Concrete verb+resource: it profiles a specific buyer role and enumerates the return content (what they're measured on, what worries them, objections, what they need to hear). It draws a clear line against get_pre_brief, but says nothing about how it differs from the closely-named siblings simulate_buyer_persona and get_icp_profile, leaving some ambiguity in a crowded namespace.

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?

Explicit triggering conditions: 'when the person asks what a specific buyer role cares about (a CFO, a VP of Operations) or why that person isn't responding.' It names the alternative explicitly ('To prepare for one specific meeting, use get_pre_brief'), which is a textbook when-not clause.

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.