19 stakeholder understanding tools for technical founders navigating high-stakes B2B interactions. ICP scoring, buyer persona simulation, competitive battlecards, MBTI-adapted messaging, deal classification, sales hiring blueprints, VC thesis matching, founder wellness, and pre-meeting briefs — built on 20 years of B2B sales pattern data.
Works immediately — no pipeline data required. Describe your product and Andru delivers stakeholder understanding in seconds. Run a full pipeline for empathy tuned to your specific market.
npm install -g mcp-server-andru-intelligenceOr run directly:
ANDRU_API_KEY=sk_live_... npx mcp-server-andru-intelligenceRelated MCP server: battlecard
Variable | Required | Default | Description |
| Yes | — | Your Andru Platform API key |
| No |
| API base URL |
Get your API key at platform.andru-ai.com/settings/api-keys.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"andru-intelligence": {
"command": "npx",
"args": ["mcp-server-andru-intelligence"],
"env": {
"ANDRU_API_KEY": "sk_live_your_key_here"
}
}
}
}claude mcp add andru-intelligence npx mcp-server-andru-intelligence \
--env ANDRU_API_KEY=sk_live_your_key_hereTool | What It Does | Latency |
| Tells you in seconds whether a company is worth your time — scores across 5 dimensions against who actually buys from you | <100ms |
| Score up to 50 companies at once — tier and score so you can rank a list in under a second | <500ms |
| Full read on a deal — fit score, persona match, risk flags, disqualification check, and a verdict: pursue, pause, or walk away | <200ms |
| Find out if you're wasting time on a deal that won't close — three layers of signal and a clear recommendation | <200ms |
Tool | What It Does | Latency |
| Look up who you're actually talking to — what they care about at 7 AM, why they'll say no, and exactly how to open | <50ms |
| Get the exact words to use — MBTI-adapted so the analytical CTO and the results-driven VP Sales get different versions | <50ms |
| Battlecard for a specific competitor — where you win, where they'll attack, which questions to plant | <100ms |
| Scores how well you match what a buyer needs — across pain coverage, outcome clarity, capability fit, and 3 more dimensions | <100ms |
Tool | What It Does | Latency |
| Builds the account plan you'd normally spend a weekend on — stakeholder map, MEDDICC gaps, and the unified story | <100ms |
| Returns everything Andru knows about your ideal customer — all 5 intelligence layers and the patterns that predict churn | <100ms |
| Machine-readable snapshot of what your product does and who it's for — designed for buyer-side evaluation | <50ms |
Tool | What It Does | Latency |
| Finds real companies showing the same buying signals your best customers showed — searches the web live | 15-30s |
| Pre-call prep so you don't walk in cold — talk track, discovery questions, anticipated objections, and the one thing to get done | 10-20s |
Tool | What It Does | Latency |
| Shows whether your CRM has your current intelligence or is running on stale data | <200ms |
| Pushes latest intelligence into your CRM — detects which platforms are out of date and updates only what's stale | 5-15s |
Tool | What It Does | Latency |
| First sales hire blueprint — JD, comp model, interview questions, and 90-day ramp plan for the stage you're at | 10-20s |
| Match your company against VC investment theses — top 5 fits with reasoning for why each thesis applies | 10-20s |
| Burnout risk assessment with recovery recommendations — because 54% of founders are severely stressed and 81% hide it | <200ms |
| Practice your pitch against a simulated CFO, CTO, or VP Sales — get the objections before the real meeting | 5-15s |
All 19 tools are also available from the command line via the companion andru-intel package:
npx andru-intel list # see all 19 tools
npx andru-intel score "AI code review" # instant ICP (works offline)
npx andru-intel persona CFO # buyer persona deep dive
npx andru-intel blueprint --stage "Series A" --arr "$2M"
npx andru-intel thesis "AI sales platform" --stage "Seed"
npx andru-intel roleplay CTO
npx andru-intel wellness
npx andru-intel run get_competitive_positioning --companyName "Acme"7 tools work without any pipeline data — just describe your product:
get_icp_fit_score, get_persona_profile, get_messaging_framework, get_competitive_positioning, get_evaluation_criteria, classify_opportunity, get_disqualification_signals
Pass productDescription, vertical, and targetRole parameters, or let Claude infer them from your conversation. The tools use pre-built stakeholder understanding (5 named buyer personas, 3 vertical segment profiles) to deliver results immediately.
Run a full ICP pipeline at platform.andru-ai.com for understanding tuned to your specific product and market.
URI | Description |
| The complete profile of the companies you should actually be selling to — 5 intelligence layers, 7 critical questions, and churn prediction patterns |
| All your pipeline runs and what each one produced — ICP layers, lead gen strategy, account plans, and deck output |
| Your tracked accounts — tier, pipeline value, stakeholder count, and account plan status |
This MCP server is a thin proxy that authenticates with your Andru API key and forwards tool/resource requests to the Andru backend. All intelligence generation, ICP scoring, and data access happens server-side — the MCP server itself is stateless.
Claude Desktop/Code → MCP Server (stdio) → Andru API (HTTPS)Andru also supports the Agent-to-Agent (A2A) protocol for direct agent-to-agent communication. The AgentCard is available at:
https://hs-andru-test.onrender.com/.well-known/agent.jsonChrome Extension — Sales intelligence on LinkedIn profiles, Gmail compose, and any company page. Install from Chrome Web Store.
Free signal reads for the questions technical founders ask at 11 PM:
I've Done 30 Customer Interviews and Still Can't Define My ICP
My Pipeline Is Full of Companies That Like Us But Nobody's Buying Urgently
As a Technical Founder, What Am I Getting Wrong About Sales?
Why Does My Messaging Fall Flat Even When I'm Talking to the Right Companies?
MIT
Score up to 50 companies at once — gives each a tier and score so you can rank a list in under a second. Returns individual scores plus aggregate statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | Companies to score (max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with flexible inputs. The description adds valuable behavioral context beyond annotations: the 50-company limit, performance expectation ('under a second'), and output structure ('individual scores plus aggregate statistics'). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence establishes purpose and scope, second sentence describes output. Perfectly front-loaded with essential information, no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only batch scoring tool with good annotations and full schema coverage, the description provides adequate context about purpose, constraints, and output. The main gap is lack of output schema, but the description compensates by describing return values ('individual scores plus aggregate statistics'). Could be more specific about scoring methodology.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents the single parameter and its nested structure. The description adds minimal parameter semantics beyond the schema, only mentioning the 50-company limit which is already in the schema description. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Score up to 50 companies at once'), the resource ('companies'), and the output ('gives each a tier and score'). It distinguishes from sibling tools like 'get_icp_fit_score' by emphasizing batch processing and ranking capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to rank a list in under a second') and implies it's for batch processing rather than single-company scoring. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a full read on a deal in one call — fit score, persona match, risk flags, disqualification check, and a verdict: pursue, pause, or walk away. Combines multiple scoring engines for a comprehensive assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| companyName | Yes | Company name | |
| contactTitle | No | Primary contact job title | |
| industry | No | Industry | |
| employeeCount | No | Number of employees | |
| revenue | No | Revenue range | |
| geography | No | Location | |
| dealValue | No | Estimated deal value | |
| dealStage | No | Current deal stage | |
| techStack | No | Technologies used | |
| painPoints | No | Known pain points | |
| triggerEvents | No | Trigger events | |
| championIdentified | No | Has a champion been identified? | |
| competitorInvolved | No | Known competitor in the deal | |
| 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, which the description does not contradict. The description adds behavioral context by mentioning it 'combines multiple scoring engines' and outputs a verdict, which goes beyond annotations. However, it lacks details on rate limits, error handling, or performance characteristics that would be useful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and efficiently lists outputs without redundancy. Every sentence adds value by clarifying scope and methodology, making it appropriately sized and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, no output schema) and annotations covering safety, the description adequately explains what the tool does and its comprehensive nature. However, without an output schema, it could benefit from more detail on the return format (e.g., structure of the verdict) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 16 parameters. The description does not add any parameter-specific details beyond what the schema provides, such as explaining relationships between parameters or usage tips. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('run a full read on a deal') and resources ('deal'), listing the comprehensive outputs (fit score, persona match, risk flags, disqualification check, verdict). It effectively distinguishes from siblings by emphasizing it 'combines multiple scoring engines for a comprehensive assessment,' unlike more focused sibling tools like 'get_icp_fit_score' or 'get_disqualification_signals'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it provides a 'full read' and 'comprehensive assessment,' suggesting it should be used for holistic deal evaluation rather than piecemeal analysis. However, it does not explicitly state when not to use it or name specific alternatives among the sibling tools, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds real companies that look like your best customers — searches the web for companies showing the same buying signals your winners showed. Takes 15-30 seconds. Works without prior pipeline data.
| Name | Required | Description | Default |
|---|---|---|---|
| companyName | Yes | Your company name | |
| productDescription | Yes | What your product does and who it's for. Infer from conversation context if the user has already described their product. | |
| coreCapability | No | The single most important thing your product does — the core capability that makes customers buy | |
| industry | No | Target industry to search within | |
| targetMarket | No | Target market segment (e.g., "Series A SaaS companies") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and open-world hints, which the description aligns with by describing a search operation. The description adds valuable behavioral context beyond annotations: it specifies the operation takes '15-30 seconds,' which informs about latency, and clarifies it 'works without prior pipeline data,' indicating no prerequisites. No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by additional context in subsequent sentences. Each sentence adds value: the first defines the tool, the second explains the method and timing, and the third clarifies prerequisites. There is no wasted text, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (external search with multiple parameters) and the absence of an output schema, the description provides good context on what the tool does and its behavior. However, it does not detail the format or content of the results (e.g., what data is returned about companies), which could be helpful for an agent to understand the output. Annotations cover safety aspects, but more on output expectations would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing clear descriptions for all parameters. The description does not add significant meaning beyond the schema, as it focuses on the tool's overall function rather than parameter details. However, it implies that parameters like 'companyName' and 'productDescription' are used to infer buying signals, which slightly enhances understanding, but this is minimal given the comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('finds', 'searches') and resources ('real companies', 'buying signals'), distinguishing it from sibling tools focused on scoring, classification, or data retrieval rather than external discovery. It explicitly mentions searching the web for companies with specific signals, which is unique among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('finds real companies that look like your best customers') and mentions it 'works without prior pipeline data,' which implies it's suitable for initial prospecting. However, it does not explicitly state when not to use it or name specific alternatives among the sibling tools, such as when detailed scoring or classification is needed instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Builds the account plan you'd normally spend a weekend on — stakeholder map, what each person needs to hear, MEDDICC gaps, and the unified story across the buying committee.
| Name | Required | Description | Default |
|---|---|---|---|
| accountName | Yes | Target account/company name | |
| domain | No | Company domain | |
| industry | No | Industry vertical | |
| stakeholders | No | Known stakeholders at the account | |
| dealContext | No | Current deal context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, showing it's a safe, generative operation. The description adds context about generating a comprehensive plan with specific components, which goes beyond annotations. However, it doesn't disclose behavioral traits like rate limits, processing time, or output format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Builds the account plan') and lists key components without unnecessary details. Every part of the sentence adds value, making it appropriately sized and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters with nested objects) and lack of output schema, the description provides a good overview of what the tool generates. However, it could be more complete by hinting at the output format or depth of analysis, especially since no output schema exists to clarify return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description doesn't add specific meaning beyond the schema, such as explaining how parameters influence the plan generation. The baseline score of 3 is appropriate since the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it 'builds the account plan' with specific components like stakeholder map, messaging needs, MEDDICC gaps, and unified story. It uses a specific verb ('builds') and resource ('account plan'), and distinguishes itself from siblings by focusing on comprehensive planning rather than scoring, classification, or profiling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'you'd normally spend a weekend on' and referencing a 'buying committee,' suggesting it's for complex sales scenarios. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_sales_blueprint' or 'get_pre_brief,' nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a machine-readable snapshot of what your product actually does and who it's for — capabilities, verified outcomes, trust signals, pricing model, and integrations. Designed for buyer-side agent evaluation.
| Name | Required | Description | Default |
|---|---|---|---|
| includeOutcomes | No | Include verified outcomes (default: true) | |
| includeTrustSignals | No | Include trust signals (default: true) | |
| forceRefresh | No | Force regeneration even if cached (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world hints, so the agent knows this is a safe, non-destructive query with flexible data. The description adds value by specifying the tool's design intent ('buyer-side agent evaluation') and the snapshot's content scope, but it does not disclose additional behavioral traits like rate limits, authentication needs, or caching behavior beyond the forceRefresh parameter in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and efficiently adds context in the second sentence. Every phrase ('machine-readable snapshot,' 'buyer-side agent evaluation') contributes meaning without redundancy, making it appropriately sized and zero-waste for a tool with clear annotations and schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving a comprehensive product profile) and the presence of annotations (readOnlyHint, openWorldHint) and full schema coverage, the description is mostly complete. It outlines the snapshot's components and the tool's design intent. However, without an output schema, it could benefit from hinting at the return format (e.g., structured data like JSON), but this is a minor gap given the annotations provide safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three optional parameters (includeOutcomes, includeTrustSignals, forceRefresh) with their defaults. The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining the implications of 'verified outcomes' or 'trust signals,' but this is acceptable given the high schema coverage, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Returns a machine-readable snapshot') and resource ('what your product actually does and who it's for'), listing key components like capabilities, outcomes, trust signals, pricing, and integrations. It explicitly distinguishes this tool from siblings by noting it's 'Designed for buyer-side agent evaluation,' which none of the sibling tools mention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Designed for buyer-side agent evaluation'), which helps differentiate it from siblings focused on scoring, classification, or data retrieval. However, it does not explicitly state when not to use it or name specific alternatives among the siblings, such as get_icp_profile or get_persona_profile, which might overlap in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gives you the battlecard for a specific competitor — where you win, where they'll attack, which questions to plant in the buyer's mind, and which landmines to avoid.
| Name | Required | Description | Default |
|---|---|---|---|
| competitorName | Yes | Competitor company name | |
| competitorFeatures | No | Known competitor features or capabilities | |
| context | No | Additional context (e.g., "enterprise deal", "competing on price") | |
| 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with open-ended inputs. The description adds valuable behavioral context by specifying the battlecard's components (where you win, attack points, questions to plant, landmines), which goes beyond what annotations provide about operational safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and immediately details the battlecard's four key components. Every element serves a clear purpose with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with rich annotations and comprehensive schema documentation, the description provides good contextual completeness. The battlecard metaphor effectively conveys the output's structure and utility, though without an output schema, some details about return format remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, all parameters are well-documented in the schema. The description doesn't add parameter-specific semantics beyond the battlecard metaphor, but the schema provides comprehensive parameter descriptions including inference guidance for productDescription, vertical, and targetRole.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('gives you the battlecard') and resource ('for a specific competitor'), and distinguishes it from siblings by focusing on competitive positioning analysis rather than other sales/marketing functions like prospect discovery or account planning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the battlecard metaphor (sales/marketing scenarios), but doesn't explicitly state when to use this tool versus alternatives like 'get_capability_profile' or 'get_messaging_framework'. No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find out if you're wasting time on a deal that won't close. Runs the company through three layers of signal — ICP fit, anti-pattern matching, and churn patterns — and tells you whether to keep investing or walk away.
| Name | Required | Description | Default |
|---|---|---|---|
| companyName | No | Company name to check | |
| industry | No | Industry | |
| employeeCount | No | Number of employees | |
| revenue | No | Revenue range | |
| geography | No | Location | |
| techStack | No | Technologies they use | |
| dealContext | No | Current deal context (if applicable) | |
| 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, exploratory operation. The description adds behavioral context by explaining the three analysis layers (ICP fit, anti-pattern matching, churn patterns) and the actionable outcome ('tells you whether to keep investing or walk away'), which goes beyond annotations. However, it does not disclose details like rate limits, authentication needs, or specific output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by specific analysis details and outcome. It uses two efficient sentences with zero wasted words, each earning its place by clarifying the tool's function and value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, nested objects) and lack of output schema, the description is reasonably complete for a read-only analysis tool. It explains the analysis method and decision outcome, but does not detail the return format (e.g., score, reasons, confidence) or error handling, which could be important given the open-world hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 10 parameters. The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining how 'techStack' influences disqualification or how 'dealContext' affects the analysis. It only implies general usage of company and deal data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('find out', 'runs', 'tells you') and resources ('company', 'three layers of signal'), and distinguishes it from siblings by focusing on disqualification signals rather than scoring, classification, or prospecting. It explicitly answers 'whether to keep investing or walk away', which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('wasting time on a deal that won't close'), but does not explicitly state when not to use it or name alternatives among siblings. It implies usage for deal evaluation but lacks explicit exclusions or comparisons to tools like 'classify_opportunity' or 'get_icp_fit_score'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scores how well you actually match what this buyer needs — across pain coverage, outcome clarity, capability fit, and 3 more dimensions. Returns 0-100 per dimension plus overall alignment score.
| Name | Required | Description | Default |
|---|---|---|---|
| buyerPainPoints | No | Pain points the buyer has expressed or you expect them to have | |
| buyerIndustry | No | Buyer's industry | |
| buyerSize | No | Buyer company size | |
| requiredCapabilities | No | Capabilities the buyer needs from a solution | |
| 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with open-ended inputs. The description adds value by specifying the scoring dimensions (pain coverage, outcome clarity, capability fit, etc.) and output format (0-100 per dimension plus overall score), which aren't covered by annotations. However, it doesn't disclose rate limits, auth needs, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with zero waste. It front-loads the core purpose and immediately states the output format. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema) and rich annotations, the description is minimally complete. It explains what the tool does and the output format, but lacks details on error handling, example usage, or how results should be interpreted. With no output schema, more guidance on return values would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description doesn't add any parameter-specific semantics beyond implying that inputs relate to buyer needs and product context. It mentions dimensions like 'pain coverage' and 'capability fit', which loosely map to parameters like 'buyerPainPoints' and 'requiredCapabilities', but no additional syntax or format details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: scoring how well something matches buyer needs across specific dimensions (pain coverage, outcome clarity, capability fit, and 3 more). It uses specific verbs ('Scores', 'Returns') and identifies the resource (evaluation criteria). However, it doesn't explicitly differentiate from sibling tools like 'get_icp_fit_score' or 'batch_fit_score', which appear related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'get_icp_fit_score', 'classify_opportunity', and 'get_competitive_positioning', there's no indication of context, prerequisites, or exclusions. Usage is implied only through the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a full context dump of everything Andru knows about this founder — organized by memory type (What I Know, Patterns I've Noticed, How You Operate). Used to prime any revenue conversation with accumulated intelligence.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read) and openWorldHint=true (returns varied data). The description adds valuable behavioral context: it specifies the output is 'organized by memory type (What I Know, Patterns I've Noticed, How You Operate)' and that it provides 'accumulated intelligence.' This goes beyond annotations by detailing the structure and nature of the intelligence returned. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise: two sentences that each earn their place. The first sentence defines the tool's purpose and output structure, while the second provides clear usage guidelines. No redundant information, well-structured, and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with readOnly and openWorld annotations, the description is quite complete. It explains what the tool returns (full context dump organized by memory types) and when to use it (priming revenue conversations). The main gap is the lack of output schema, so the description doesn't specify exact return format details, but it provides enough semantic context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%. With no parameters to document, the baseline is 4. The description appropriately doesn't waste space on parameter details, focusing instead on the tool's purpose and output characteristics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a full context dump of everything Andru knows about this founder — organized by memory type.' It specifies the resource (founder context), the verb (get), and the organizational structure (memory types). It also distinguishes from siblings by focusing on comprehensive founder intelligence rather than specific aspects like wellness, capability, or competitive positioning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Used to prime any revenue conversation with accumulated intelligence.' This provides clear context for usage (revenue conversations) and implies it's for preparation rather than real-time analysis. It distinguishes from siblings by focusing on holistic founder context rather than targeted assessments like fit scores or disqualification signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks if you're burning out before you notice — tracks consecutive work days, late nights, and meeting density, then gives you a risk score and specific recovery actions. Because the founder who crashes can't close deals.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | No | The user's Andru account ID. Required for personalized wellness tracking. | |
| mode | No | assessment = burnout risk score + recommendations. dashboard = full wellness data. Default: assessment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, indicating safe read operations with flexible data. The description adds valuable behavioral context beyond annotations: it explains what gets tracked (work patterns), the output format (risk score + recovery actions), and the tool's proactive purpose ('before you notice'). No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first explains the tool's function and output, the second provides motivational context. Every phrase adds value with zero wasted words, and key information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with good annotations and full schema coverage, the description provides adequate context about what the tool does and why. However, without an output schema, the description could be more specific about the exact format of the 'risk score and specific recovery actions' to help the agent interpret results better.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing full parameter documentation. The description doesn't add specific parameter semantics beyond what the schema already explains (userId for personalized tracking, mode for output type). Baseline score of 3 is appropriate since the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('checks', 'tracks', 'gives') and resources ('consecutive work days, late nights, and meeting density', 'risk score and specific recovery actions'). It distinguishes itself from siblings by focusing on founder wellness/burnout assessment, unlike other tools that handle sales, prospecting, or account management functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Because the founder who crashes can't close deals') suggesting it's for founders concerned about burnout, but doesn't explicitly state when to use this tool versus alternatives. No specific exclusions or comparisons to sibling tools are provided, leaving guidance at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tells you in seconds whether the company you're thinking about is worth your time — scores them against who actually buys from you and why, across 5 dimensions. No AI calls, instant results.
| Name | Required | Description | Default |
|---|---|---|---|
| companyName | No | Company name to evaluate | |
| domain | No | Company website domain | |
| industry | No | Industry vertical | |
| employeeCount | No | Number of employees | |
| revenue | No | Revenue range (e.g., "$1M-$5M") | |
| geography | No | HQ location | |
| techStack | No | Technologies the company uses | |
| painPoints | No | Known pain points or challenges they face | |
| triggerEvents | No | Recent trigger events (e.g., "just raised Series B", "new CTO hired") | |
| 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and open-world hints, which the description doesn't contradict. It adds valuable context beyond annotations: 'No AI calls, instant results' clarifies performance characteristics, and 'scores them against who actually buys from you and why' hints at data-driven matching. However, it doesn't detail rate limits, authentication needs, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by clarifying details. Every sentence earns its place: the first defines the tool, the second adds scoring context and performance traits. No wasted words, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose, behavior, and context but could better explain output expectations (e.g., score format) or parameter interdependencies. The absence of an output schema means the description should ideally hint at return values, which it partially does with 'scores them'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description doesn't add meaning beyond the schema, such as explaining how parameters influence the score or which are most critical. It mentions '5 dimensions' but doesn't map them to parameters, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: scoring a company against buyer profiles across 5 dimensions to determine if it's worth pursuing. It specifies the verb ('scores'), resource ('company'), and scope ('against who actually buys from you'), distinguishing it from siblings like 'get_icp_profile' or 'classify_opportunity' by focusing on fit evaluation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it ('whether the company you're thinking about is worth your time') and mentions 'No AI calls, instant results' as a behavioral trait, but it doesn't explicitly state when not to use it or name alternatives like 'batch_fit_score' for multiple companies or 'get_disqualification_signals' for negative filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns everything Andru knows about your ideal customer — all 5 intelligence layers, the 7 critical buyer questions, and the patterns that predict churn. Optionally filter to specific layers.
| Name | Required | Description | Default |
|---|---|---|---|
| layers | No | Specific layers to include (1-5). Omit for all layers. | |
| includeSevenAnswers | No | Include seven critical buyer answers (default: true) | |
| includeAntiPatterns | No | Include anti-patterns and churn predictors (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world characteristics. The description adds valuable context about what information is returned (5 layers, 7 buyer questions, churn patterns) and the optional filtering capability, which goes beyond the annotations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the comprehensive return value, and the second mentions the optional filtering capability. Every element serves a purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with good annotations and full parameter documentation, the description provides adequate context about what intelligence is returned. However, without an output schema, it could benefit from more detail about the return format structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents all three parameters. The description mentions optional filtering to specific layers, which aligns with the 'layers' parameter but doesn't add meaningful semantic context beyond what's already in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns comprehensive ICP information with specific details about 'all 5 intelligence layers, the 7 critical buyer questions, and the patterns that predict churn.' It distinguishes itself from siblings by focusing on complete ICP profiles rather than specific aspects like fit scores, positioning, or disqualification signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining complete ICP intelligence but doesn't explicitly state when to use this tool versus alternatives like get_icp_fit_score, get_competitive_positioning, or get_disqualification_signals. No specific exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the version history of a specific memory — see how a metric, deal stage, or priority has evolved over time. Answers questions like "What was my MRR 3 months ago?" or "When did the Acme deal move to negotiation?"
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Memory category (e.g., "metric", "account"). | |
| key | Yes | Memory key (e.g., "mrr", "acme_deal_stage"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior, which the description does not contradict. The description adds value by specifying that it retrieves 'version history' and 'evolved over time,' providing context about what data is returned, but it does not disclose additional behavioral traits like rate limits, authentication needs, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by illustrative examples that earn their place by clarifying use cases. It is appropriately sized with no wasted words, making it efficient and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (historical data retrieval), annotations cover safety (read-only) and data scope (open-world), and schema coverage is complete. However, without an output schema, the description could better explain return values (e.g., format of version history). It is mostly complete but has a minor gap in output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the parameters. The description adds semantic context by linking parameters to examples (e.g., 'metric' for category, 'mrr' for key), but it does not provide new information beyond what the schema already states. This meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get the version history') and resources ('of a specific memory'), and it distinguishes from siblings by focusing on historical evolution rather than current states or other operations. Examples like 'What was my MRR 3 months ago?' reinforce its unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to see how metrics, deal stages, or priorities have evolved over time), but it does not explicitly mention when not to use it or name specific alternatives among the sibling tools. The examples help guide usage but lack explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the exact words to use — for a specific buyer type, channel, and funnel stage. MBTI-adapted so the analytical CTO and the results-driven VP Sales get different versions. Returns value props, objection responses, voice variants, and outbound templates.
| Name | Required | Description | Default |
|---|---|---|---|
| segment | No | Target segment or vertical | |
| stage | No | Where the buyer is in their journey | |
| channel | No | Channel (email, linkedin, phone, etc.) | |
| personaType | No | Target buyer title | |
| mbtiCategory | No | MBTI communication category for message adaptation | |
| 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation with open-world data. The description adds value by specifying that it returns multiple messaging components (value props, objection responses, etc.) and adapts to MBTI categories, which provides useful behavioral context beyond the annotations. However, it does not disclose details like rate limits, authentication needs, or potential data freshness issues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and output. Every word earns its place, with no redundant information or fluff, making it easy for an AI agent to quickly understand the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema) and rich annotations, the description is mostly complete. It clearly states what the tool does and returns, but it could improve by hinting at the output structure or format, especially since there is no output schema. However, it adequately covers the core functionality for a read-only tool with open-world data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds minimal semantic value beyond the schema by implying that parameters like 'mbtiCategory' and 'stage' drive message adaptation, but it does not elaborate on how they interact or provide examples. This meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get the exact words to use') and resources (value props, objection responses, voice variants, outbound templates). It distinguishes itself from siblings by focusing on MBTI-adapted messaging for specific buyer types, channels, and funnel stages, which is unique among the listed tools that cover broader sales, prospecting, and analysis functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for generating tailored messaging based on buyer type (MBTI-adapted), channel, and funnel stage. However, it does not explicitly state when not to use it or name specific alternatives among the sibling tools, such as 'get_persona_profile' or 'simulate_buyer_persona', which might overlap in persona-related contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up who you're actually talking to before the call — what they care about at 7 AM, why they'll say no, and exactly how to open. Returns persona details including MBTI distribution, empathy map, and messaging angles.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Job title of the person you're meeting (e.g., "VP Engineering", "CTO", "Head of Sales") | |
| industry | No | Their industry | |
| 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. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate read-only and open-world operations, which the description doesn't contradict. The description adds valuable behavioral context about what information is returned (persona details with specific components like MBTI distribution and empathy map) and the timing context (before a call). However, it doesn't mention potential limitations like data availability or freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first clause, followed by specific return details. Every sentence earns its place by providing essential context about timing, use case, and output format without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with comprehensive parameter documentation and no output schema, the description provides good context about what information is returned and when to use it. It could be more complete by mentioning what happens when persona data isn't available or providing more detail about the return format structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. The baseline score of 3 reflects adequate coverage through the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('look up who you're actually talking to') and resources ('persona details including MBTI distribution, empathy map, and messaging angles'). It distinguishes from siblings by focusing on pre-call persona analysis rather than scoring, classification, or other functions listed in the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('before the call') and provides clear context about its purpose ('what they care about at 7 AM, why they'll say no, and exactly how to open'). While it doesn't name specific alternatives, the timing guidance and focus on persona details provide strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Writes your pre-call prep so you don't walk in cold — talk track, discovery questions tuned to this buyer, anticipated objections, and the one thing you need to get done in this meeting. Just say who you're meeting with — Andru checks your calendar automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| companyName | No | Company you're meeting with. Andru finds the matching calendar event and pulls attendee context automatically. | |
| contactName | No | Name of the person you're meeting (optional — helps match the right event and personalize the brief). | |
| eventId | No | Calendar event ID (from Andru calendar integration). If provided, skips calendar search. | |
| dealId | No | Associated deal ID for additional deal intelligence | |
| briefType | No | Type of meeting brief to generate (default: general) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and open-world operations, which the description aligns with by describing a generation/preparation function rather than a destructive action. The description adds valuable behavioral context beyond annotations: it explains the automatic calendar checking feature, mentions personalization based on buyer context, and describes the specific output components (talk track, discovery questions, etc.) that the tool produces.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences that each serve clear purposes: the first explains what the tool generates, the second explains how to use it. There's no wasted language, and key information is front-loaded about the tool's output before mentioning the input mechanism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only generation tool with comprehensive parameter documentation and appropriate annotations, the description provides good contextual completeness. It explains the tool's purpose, usage context, and output format. The main gap is the lack of output schema, but the description compensates by detailing what the brief contains. A perfect score would require more specifics about the generated content format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all 5 parameters thoroughly. The description mentions 'who you're meeting with' which corresponds to companyName/contactName parameters, but doesn't add significant semantic value beyond what's already in the parameter descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating pre-call preparation materials including talk track, discovery questions, anticipated objections, and meeting objectives. It specifies the resource (pre-call prep) and distinguishes itself from siblings by focusing on meeting-specific briefs rather than account plans, competitive positioning, or other sales intelligence functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: before meetings to avoid 'walking in cold.' It mentions the automatic calendar integration feature but doesn't explicitly state when NOT to use it or name specific alternative tools for different scenarios, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query this founder's accumulated stakeholder understanding — metrics, deal patterns, account history, decisions, and behavioral insights Andru has learned over time. Filter by memory type (episodic facts, semantic patterns, procedural habits) or business domain.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter to a specific memory category. Omit to search all. | |
| keyPattern | No | Filter keys matching this pattern (supports * wildcards, e.g., "*mrr*", "acme_*"). | |
| memoryType | No | Filter by memory type. episodic=specific facts, semantic=patterns, procedural=behavioral habits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with potentially incomplete data. The description adds valuable context about what types of memories are available (episodic facts, semantic patterns, procedural habits) and the business domains covered, which goes beyond the annotations. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first clause. The second sentence adds useful filtering context without redundancy. While efficient, it could be slightly more structured for optimal clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (querying accumulated insights with filtering), annotations cover safety and data completeness, and the schema fully documents parameters. The description provides good context about memory types and content, though without an output schema, it doesn't detail return values. It's mostly complete but could benefit from more explicit behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema. The description mentions filtering by memory type and business domain, which aligns with the schema but doesn't add significant meaning beyond it. The baseline of 3 is appropriate given the comprehensive schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries accumulated stakeholder understanding with specific content types (metrics, deal patterns, account history, decisions, behavioral insights) and mentions filtering capabilities. It distinguishes from siblings by focusing on 'revenue memory' rather than other tools like get_account_plan or get_capability_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying learned insights about a founder, but doesn't explicitly state when to use this tool versus alternatives like get_memory_history or get_founder_context. No exclusions or clear alternatives are provided, leaving usage context somewhat implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Builds everything you need to make your first sales hire — job description, comp structure, interview questions that actually reveal sales ability, 90-day ramp plan, and weekly activity targets tied to your ARR goal.
| Name | Required | Description | Default |
|---|---|---|---|
| companyStage | Yes | Current funding stage. Infer from conversation context if the user has mentioned it. | |
| arrTarget | Yes | Annual recurring revenue target (e.g., "$2M", "$5M", "$10M"). Ask the user if not mentioned. | |
| dealSize | No | Average deal size (e.g., "$15K ACV", "$50K ACV"). Infer from context or ask. | |
| avgCycleLength | No | Average sales cycle length (e.g., "30 days", "60 days", "90+ days"). Infer or ask. | |
| teamSize | No | Current team size. Infer from context if mentioned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and open-world hints, but the description adds valuable behavioral context: it's a comprehensive generator tool that creates multiple artifacts (not just a single document). The description doesn't contradict annotations and provides insight into the scope and output nature beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the tool's comprehensive output. Every word contributes to understanding the tool's purpose without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generative tool with read-only/open-world annotations but no output schema, the description adequately conveys what will be produced. However, it doesn't specify format (e.g., document type, structure) or whether outputs are editable/templates, leaving some implementation details unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, so it meets the baseline expectation without providing extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Builds everything you need') and the comprehensive output (job description, comp structure, interview questions, ramp plan, activity targets). It distinguishes itself from siblings by focusing on sales hiring infrastructure rather than prospecting, classification, or other sales-related functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('to make your first sales hire') but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided about prerequisites, timing, or comparison to other tools like 'get_icp_profile' or 'simulate_buyer_persona' that might be related to sales planning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows whether your CRM has your current intelligence or is running on stale data. Checks sync status across HubSpot, Salesforce, and Pipedrive.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with flexible data. The description adds valuable context about what gets checked (sync status across three specific platforms) and the tool's diagnostic nature, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first establishes the purpose and value, the second specifies the scope. No wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with openWorldHint, the description provides sufficient context about what it checks and why. The main gap is the lack of output schema, so the description doesn't specify what format the status information will be returned in, though this is partially mitigated by the clear purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately explains that no inputs are needed for this status check, which aligns perfectly with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('shows', 'checks') and resources ('CRM', 'sync status across HubSpot, Salesforce, and Pipedrive'). It distinguishes itself from siblings by focusing on data freshness verification rather than scoring, profiling, or triggering actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('whether your CRM has your current intelligence or is running on stale data'), suggesting it should be used when data accuracy verification is needed. However, it doesn't explicitly state when not to use it or name specific alternatives among siblings like 'trigger_syndication'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds the 5 VCs whose investment thesis best matches your company — scores each on fit, explains why they'd be interested, and tells you how to approach them. Saves weeks of investor research.
| Name | Required | Description | Default |
|---|---|---|---|
| productDescription | Yes | What the company does and who it serves. Infer from conversation context if the user has already described their product. | |
| stage | Yes | Current funding stage. Infer from context if mentioned. | |
| arrRange | No | Current ARR range (e.g., "$0-$500K", "$500K-$2M", "$2M-$10M"). Infer or ask. | |
| vertical | No | Industry vertical (e.g., "AI/ML", "FinTech", "HealthTech", "SaaS"). Infer from product description. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and open-world hints, but the description adds valuable behavioral context: it specifies the output includes 5 VCs with fit scores, explanations of interest, and approach guidance. This goes beyond annotations by detailing what the tool returns and its practical benefits, though it lacks explicit rate limits or data source disclosures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core functionality in the first sentence, followed by a benefit statement. Every sentence earns its place by conveying essential information without redundancy, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (matching VCs with scoring and explanations) and lack of output schema, the description provides a good overview of what to expect. However, it could be more complete by specifying output format details or error handling, though annotations cover safety aspects adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all parameters well. The description does not add meaning beyond the schema, as it doesn't explain how parameters like 'productDescription' or 'arrRange' influence the matching process. Baseline score of 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Finds', 'scores', 'explains', 'tells') and resources ('5 VCs', 'investment thesis', 'your company'). It distinguishes itself from siblings by focusing on VC matching with fit scoring and approach guidance, unlike tools like 'get_icp_fit_score' or 'discover_prospects' which have broader or different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('Saves weeks of investor research'), implying it's for startup fundraising preparation. However, it does not explicitly state when not to use this tool or name alternatives among siblings, such as 'get_syndication_status' for post-investment tracking or 'classify_opportunity' for general opportunity assessment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a revenue insight, decision, metric, or pattern into Andru's memory so it compounds over time. Use after any deal decision, ICP refinement, metric update, or strategic pivot. The system automatically versions previous values.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | What kind of memory this is. | |
| key | Yes | Unique identifier for this memory (lowercase_underscored, e.g., "current_arr", "acme_deal_stage"). | |
| value | Yes | The memory content — a concise, specific fact or insight. | |
| memoryType | No | episodic=time-bound fact, semantic=general pattern, procedural=behavioral habit. Default: episodic. | |
| domain | No | Business domain this memory relates to. Default: general. | |
| confidence | No | How confident this memory is (0.0-1.0). Default: 1.0 for founder-stated facts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains that the system 'automatically versions previous values,' which clarifies persistence and versioning behavior. Annotations indicate this is a write operation (readOnlyHint: false) with open-world data (openWorldHint: true) and non-destructive (destructiveHint: false), and the description aligns with this by describing saving/compounding without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and concise with two sentences that efficiently convey purpose and usage without wasted words. Every sentence adds value: the first defines the tool's function, and the second provides context and behavioral insight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, write operation) and rich annotations, the description is mostly complete but lacks details on output or error handling. It covers purpose, usage, and key behavior (versioning), but without an output schema, it could benefit from mentioning what happens after saving (e.g., confirmation).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not provide additional parameter semantics beyond what the input schema already covers. With 100% schema description coverage, the schema fully documents all parameters, so the baseline score of 3 is appropriate as the description adds no extra parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Save a revenue insight, decision, metric, or pattern into Andru's memory') and resources ('memory'), and it distinguishes from siblings by specifying this is for saving/compounding insights rather than retrieving them (unlike get_memory_history or get_revenue_memory).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with 'Use after any deal decision, ICP refinement, metric update, or strategic pivot,' giving clear context for when to invoke this tool. It implicitly distinguishes from retrieval-focused siblings by emphasizing saving/compounding rather than getting data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Practice your pitch against a realistic buyer — pick a CFO, CTO, COO, VP Sales, or VP Engineering and get their opening challenge. They'll push back the way real buyers do, so you can sharpen your story before the actual meeting.
| Name | Required | Description | Default |
|---|---|---|---|
| persona | Yes | Which buyer to simulate. Pick based on who the user is preparing to meet. | |
| stageId | No | Buyer journey stage (0=Unaware through 7=Advocating). Default: 3. | |
| productDescription | No | What the user's product does. Infer from conversation context. | |
| productName | No | Product name. Infer from context. | |
| mode | No | opening = buyer's opening message. list = available personas. Default: opening. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, indicating safe, exploratory use. The description adds valuable behavioral context beyond annotations: it explains the tool simulates realistic buyer pushback, provides opening challenges, and helps users practice. However, it doesn't specify response format or whether the simulation is interactive or single-response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded and concise - two sentences that efficiently convey purpose, scope, and value. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simulation with multiple parameters), rich annotations, and 100% schema coverage, the description provides strong context about what the tool does and why to use it. The main gap is lack of output format information (no output schema), but the description compensates well by explaining the behavioral outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 5 parameters thoroughly. The description doesn't add parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate but not enhanced parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('practice your pitch', 'get their opening challenge') and resources ('realistic buyer', 'CFO, CTO, COO, VP Sales, or VP Engineering'). It distinguishes from siblings by focusing on simulation and practice rather than analysis or data retrieval like most other tools on the server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('practice your pitch', 'sharpen your story before the actual meeting'), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. The guidance is practical but lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pushes your latest intelligence into your CRM — detects which platforms are out of date and updates only what's stale. Use get_syndication_status first to see what needs updating.
| Name | Required | Description | Default |
|---|---|---|---|
| platforms | No | Only sync these platforms (e.g., ["hubspot"]). If omitted, syncs all stale platforms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains the tool's intelligent behavior ('detects which platforms are out of date and updates only what's stale') and the default behavior when platforms parameter is omitted ('syncs all stale platforms'). While annotations cover read/write and destructive hints, the description provides operational details about selective updating and stale detection that aren't captured in structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve distinct purposes: the first explains what the tool does, and the second provides usage guidance. There's zero wasted language, and the most important information (the core functionality) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (mutation operation with intelligent behavior), good annotations, and 100% schema coverage, the description is mostly complete. It explains the tool's purpose, usage guidelines, and key behavioral aspects. The main gap is the lack of output information (no output schema and no description of return values), which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description enhances parameter understanding by explaining the default behavior when the 'platforms' parameter is omitted ('If omitted, syncs all stale platforms'), which adds semantic context beyond the schema's technical description. However, it doesn't provide additional format examples or constraints beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('pushes', 'detects', 'updates') and resources ('latest intelligence', 'CRM', 'platforms'). It distinguishes itself from sibling tools by focusing on syndication/updating rather than retrieval or analysis, and explicitly mentions a specific sibling (get_syndication_status) for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives: 'Use get_syndication_status first to see what needs updating.' This clearly indicates a prerequisite workflow and distinguishes it from the sibling tool for checking status before performing updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, such as 'get_icp_fit_score' for instant scoring versus 'classify_opportunity' for comprehensive deal assessment. However, some overlap exists, like 'get_disqualification_signals' and 'classify_opportunity' both handling deal viability, which could cause minor confusion. Overall, descriptions help clarify boundaries, but a few tools share similar domains.
Tool names follow a highly consistent verb_noun pattern throughout, such as 'get_account_plan', 'log_revenue_insight', and 'trigger_syndication'. All tools use snake_case with clear action-object pairs, making them predictable and readable. There are no deviations in naming conventions across the set.
With 23 tools, the count is borderline high for a revenue intelligence server, potentially overwhelming for agents. While the domain is broad, covering areas like scoring, planning, and CRM integration, it feels heavy and could benefit from consolidation. This number approaches the upper limit of what is manageable without clear segmentation.
The tool set provides comprehensive coverage for revenue intelligence, including scoring, planning, messaging, CRM integration, and founder wellness. It supports full CRUD-like operations with tools for logging insights and retrieving memories, ensuring no obvious gaps. Agents can handle end-to-end workflows from prospecting to deal closure and maintenance.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Sales intelligence for B2B SMEs — lead scoring, ICP fit, CRM enrichment & writeback.
Cold engine for B2B founders. Detects buying signals, drafts outreach, books qualified meetings.
AI-native GTM OS for B2B SaaS — account health, pipeline, renewals, territories, and benchmarks.
AI sales — prospect discovery, ICP scoring, outreach generation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/geter-andru/mcp-server-andru-intelligence'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
