Skip to main content
Glama
Sign In
Andru

Andru

by geter-andru
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Check whether a buyer is ready

get_disqualification_signals
Read-only

Checks whether a stalled buyer fits your ICP and disqualification profile, returning one of four fit levels with reasons so you can decide next steps.

Instructions

Use this when a deal has stalled or the person wonders whether this buyer is ready for them. Checks the company against the account's ICP and the profile of companies that aren't a fit, and returns one of four fit levels with the reasons. When the answer is no, help the person tell the buyer kindly who fits them better today.

Input Schema

NameRequiredDescriptionDefault
revenueNoRevenue range
industryNoIndustry
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.
geographyNoLocation
techStackNoTechnologies they use
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.
companyNameNoCompany name to check
dealContextNoCurrent deal context (if applicable)
employeeCountNoNumber of employees
productDescriptionNoA brief description of what the user's product does and who it's for. Infer this from the conversation if the user has already described their product. If the user hasn't mentioned their product yet, ask them: "What does your product do, and who do you sell to?" before calling this tool.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context by stating that the tool returns one of four fit levels with reasons and by guiding how to handle a negative result.

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?

It is front-loaded with the usage trigger, followed by a precise explanation of the check and return shape, then a short guidance sentence for negative outcomes. Every sentence contributes.

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 10-parameter, read-only tool with no output schema, the description gives the trigger, core mechanism, and return cardinality. It still leaves the four level names unspecified and does not differentiate from overlapping sibling scoring tools, but the complete schema and annotations fill most remaining gaps.

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 already documents all 10 parameters in detail, including inference guidance. The description adds no parameter-level semantics beyond referring generally to checking the company.

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 uses a specific verb and resource: it checks the company against the account's ICP and an anti-fit profile, then returns one of four fit levels with reasons. This clearly states what the tool does, though it does not explicitly distinguish itself from sibling scoring tools such as assess_company_readiness or get_icp_fit_score.

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?

It gives a clear trigger: use when a deal has stalled or the person wonders whether the buyer is ready. However, it does not state when not to use it or name alternatives, which matters given overlapping sibling tools.

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