Skip to main content
Glama
Sign In
Andru

Andru

by geter-andru
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Profile a buyer

get_persona_profile
Read-only

Retrieve a buyer role's ICP-based priorities, metrics, worries, objections, and messaging to understand what they care about and why they may not respond; confirm it with the real person.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
titleYesJob title of the person you're meeting (e.g., "VP Engineering", "CTO", "Head of Sales")
industryNoTheir industry
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.
companySizeNoTheir company size range
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. First observedv1.4.0

TDQS

A4.3/5.0
Behavior4/5

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

Beyond readOnlyHint/openWorldHint, the description discloses the data source (the account's ICP) and, importantly, the epistemic status: it is a starting hypothesis to confirm with the real person, not a conclusion. That is genuinely useful context the annotations cannot convey. It stops short of 5 because it doesn't say what happens when the ICP is thin or unknown.

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?

Front-loaded with the trigger, then the return payload, then the caveat, then the routing alternative — four short, non-redundant sentences with no filler. Every sentence changes how an agent would use the tool.

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?

With no output schema, the description carries the return-value burden and does so by enumerating the four content classes it produces. Combined with 100% parameter coverage and the safety annotations, an agent has everything needed to call it correctly and interpret the result.

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 parameters carry their own semantics, including inference instructions for vertical, targetRole, and productDescription. The description only echoes the ICP framing ('that buyer from the account's ICP') and adds no format or precedence guidance beyond the schema. Baseline 3 applies.

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 a specific verb and resource ('Returns Andru's starting picture of that buyer from the account's ICP') and enumerates the returned content (metrics, worries, objections, message), so an agent knows exactly what it gets. It differentiates from get_pre_brief but leaves the very similar siblings simulate_buyer_persona and get_evaluation_criteria unaddressed, keeping it 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 Guidelines5/5

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

Explicit trigger ('when the person asks what a specific buyer role cares about... or why that person isn't responding') plus an explicit alternative and its selecting condition ('To prepare for one specific meeting, use get_pre_brief'). Nothing about when to reach for this tool is left to inference.

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