Andru

Check whether a buyer is ready

get_disqualification_signals

Read-only

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_disqualification_signals"
  }
}

Input Schema

Name	Required	Description
`revenue`	No	Revenue range
`industry`	No	Industry
`vertical`	No	The industry the user sells into (e.g., "fintech", "healthcare", "defense"). Infer from conversation context — the user's product description, company name, or the companies they're asking about. If unclear, ask.
`geography`	No	Location
`techStack`	No	Technologies they use
`targetRole`	No	The buyer role being evaluated (e.g., "CFO", "CTO", "VP Sales"). Infer from context — often explicit in the user's question. If not mentioned, default to the most senior relevant role for their vertical.
`companyName`	No	Company name to check
`dealContext`	No	Current deal context (if applicable)
`employeeCount`	No	Number of employees
`productDescription`	No	A brief description of what the user's product does and who it's for. Infer this from the conversation if the user has already described their product. If the user hasn't mentioned their product yet, ask them: "What does your product do, and who do you sell to?" before calling this tool.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

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, so the safety profile is covered. The description adds useful behavioral context beyond that: it checks the company against both ICP and non-fit profiles, returns one of four fit levels with reasons, and includes guidance for handling a negative answer. It does not detail data sources or limitations.

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?

Three sentences, front-loaded with the trigger condition, followed by what the tool checks and returns, then how to use the answer. There is no filler or redundancy.

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 ten-parameter tool with no output schema, the description supplies the trigger, the comparison basis, and the return shape at a high level. Because the schema descriptions are already rich, this is close to complete, though more detail on the four fit levels or computation would strengthen it.

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 ten parameters, including nested dealContext fields and contextual inference instructions. The description does not add parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: checking a company against the account's ICP and a disqualification profile, returning one of four fit levels with reasons. It clearly conveys the purpose, but it does not explicitly distinguish itself from close siblings such as get_icp_fit_score or assess_company_readiness.

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 clear triggering conditions: use when a deal has stalled or the person wonders whether the buyer is ready. It does not state when not to use it or name alternative sibling tools, so it stops short of full routing guidance.

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

All Andru tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.