Andru Revenue Intelligence

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.4.0
Disambiguation4/5
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.
Naming Consistency5/5
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.
Tool Count3/5
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.
Completeness5/5
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.
Average 4.1/5 across 23 of 23 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

mcp-server-andru-intelligence MCP server

Copy to your README.md:

[![mcp-server-andru-intelligence MCP server](https://glama.ai/mcp/servers/geter-andru/mcp-server-andru-intelligence/badges/card.svg)](https://glama.ai/mcp/servers/geter-andru/mcp-server-andru-intelligence)

Score Badge

Copy to your README.md:

[![mcp-server-andru-intelligence MCP server](https://glama.ai/mcp/servers/geter-andru/mcp-server-andru-intelligence/badges/score.svg)](https://glama.ai/mcp/servers/geter-andru/mcp-server-andru-intelligence)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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