Skip to main content
Glama
Sign In
geter-andru

Andru

by geter-andru
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Score fit to a buyer's needs

get_evaluation_criteria
Read-only

Score how well your product matches a buyer's stated pain points and required capabilities, returning dimension-level and overall fit scores.

Instructions

After discovery, checking what the buyer said they need against what the person offers: use this when the person knows what a buyer needs and wants to see how well their product matches. Pass the buyer's buyerPainPoints and requiredCapabilities. Returns 0-100 for pain coverage, outcome clarity, capability fit and 3 more dimensions, plus an overall score. To check whether a company is a fit at all, use get_icp_fit_score.

Input Schema

NameRequiredDescriptionDefault
verticalNoThe industry the user sells into (e.g., "fintech", "healthcare", "defense"). Infer from conversation context — the user's product description, company name, or the companies they're asking about. If unclear, ask.
buyerSizeNoBuyer company size
targetRoleNoThe buyer role being evaluated (e.g., "CFO", "CTO", "VP Sales"). Infer from context — often explicit in the user's question. If not mentioned, default to the most senior relevant role for their vertical.
buyerIndustryNoBuyer's industry
buyerPainPointsNoPain points the buyer has expressed or you expect them to have
productDescriptionNoA brief description of what the user's product does and who it's for. Infer this from the conversation if the user has already described their product. If the user hasn't mentioned their product yet, ask them: "What does your product do, and who do you sell to?" before calling this tool.
requiredCapabilitiesNoCapabilities the buyer needs from a solution

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations cover the read-only and open-world traits, and the description adds the return structure: 0-100 sub-scores for pain coverage, outcome clarity, capability fit plus three more dimensions and an overall score. That is real value beyond annotations and there is no output schema. It does not describe failure modes or what to do with low scores.

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?

Three sentences, front-loaded with the situation and the core inputs, then the return value, then the alternative. Slightly dense in the return sentence but every clause carries 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?

No output schema exists, so the description's summary of the returned sub-scores is necessary and mostly sufficient. For a 7-parameter read-only scoring tool with full schema coverage and read-only annotations, this is close to complete; only interpretation guidance is missing.

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 coverage is 100%, so all seven parameters are already documented in the schema. The description only calls out two of them (buyerPainPoints, requiredCapabilities) by name, adding at most emphasis rather than meaning. Baseline 3 applies.

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?

States a specific verb and resource ('checking what the buyer said they need against what the person offers') and describes the output shape. The comparison to the get_icp_fit_score sibling makes the boundary clear without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicit trigger ('after discovery', 'when the person knows what a buyer needs') and an explicit alternative ('To check whether a company is a fit at all, use get_icp_fit_score'). An agent can route to the correct tool on that alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools