Andru

Read a deal

classify_opportunity

Read-only

Use this after a first conversation, when the person wants one read on whether this buyer is ready: fit score, how well the people involved match the buyers in their ICP, risk flags and a fit check, ending in one call: pursue, proceed with caution, deprioritize, or not a fit today. It doesn't confirm a champion; that takes asking the person. For a quick fit score only, use get_icp_fit_score.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "companyName": "<companyName>"
    },
    "name": "classify_opportunity"
  }
}

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.
`dealStage`	No	Current deal stage
`dealValue`	No	Estimated deal value
`geography`	No	Location
`techStack`	No	Technologies used
`painPoints`	No	Known pain points
`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`	Yes	Company name
`contactTitle`	No	Primary contact job title
`employeeCount`	No	Number of employees
`triggerEvents`	No	Trigger events
`championIdentified`	No	Has a champion been identified?
`competitorInvolved`	No	Known competitor in the deal
`productDescription`	No	A brief description of what the user's product does and who it's for. Infer this from the conversation if the user has already described their product. If the user hasn't mentioned their product yet, ask them: "What does your product do, and who do you sell to?" before calling this tool.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description adds genuine context beyond them: it discloses the return content and the four possible recommendation outcomes, and flags the champion-confirmation limitation so the agent doesn't over-trust the verdict. It stops short of noting that openWorldHint implies external data lookups or describing latency/data freshness, which keeps it from a 5.

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?

Front-loads the usage trigger before the output enumeration and keeps everything in three sentences with no filler. The output list ('risk flags and a fit check') is slightly compressed and could be sharper, but nothing is wasted.

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?

With no output schema, the description properly carries the return-value burden by naming the score, flags, and final recommendation. For a 16-parameter tool it leaves the input expectations entirely to the schema, and it doesn't state that only companyName is required to get a useful read, but nothing an agent needs to invoke it correctly 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 description coverage is 100% across 16 parameters, including inference guidance for vertical, targetRole, and productDescription, so the schema carries the semantics. The description adds nothing parameter-specific, which is the expected baseline-3 outcome when the 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?

States a specific verb (read/classify an opportunity) and enumerates the exact outputs: fit score, people-to-ICP match, risk flags, and a single recommendation from a fixed set (pursue, caution, deprioritize, not a fit today). It explicitly distinguishes itself from the sibling get_icp_fit_score, so an agent can tell the two apart 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?

Gives an explicit trigger ('after a first conversation, when the person wants one read on whether this buyer is ready'), names the alternative for a narrower need ('For a quick fit score only, use get_icp_fit_score'), and sets a boundary on what it can't do ('doesn't confirm a champion; that takes asking the person'). When, alternative, and limitation are all present.

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.