Andru

Score a company's fit

get_icp_fit_score

Read-only

Use this when the person asks whether one company is a good fit, before they reach out or spend more time. Scores it in seconds against the account's ICP on 5 dimensions (company profile, tech stack, pain, budget fit, buying signals) and returns an A–D tier with the reason behind each score. For many companies at once, use batch_fit_score.

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_icp_fit_score"
  }
}

Input Schema

Name	Required	Description
`domain`	No	Company website domain
`revenue`	No	Revenue range (e.g., "$1M-$5M")
`industry`	No	Industry vertical
`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	HQ location
`techStack`	No	Technologies the company uses
`painPoints`	No	Known pain points or challenges they face
`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 evaluate
`employeeCount`	No	Number of employees
`triggerEvents`	No	Recent trigger events (e.g., "just raised Series B", "new CTO hired")
`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.4/5.0

Behavior4/5

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

Annotations declare readOnlyHint and openWorldHint, so safety is already covered; the description adds value by naming the five scoring dimensions and disclosing the return shape ('A–D tier with the reason behind each score'), which matters because there is no output schema. It does not mention latency, cost, or what happens with missing data, keeping it short of 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first front-loads the trigger and the value, the second covers mechanism plus the sibling hand-off. No filler, and the routing hint lands last where it is easy to act on.

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 12 optional parameters and no output schema, the description supplies the missing return-value picture (tier plus per-dimension reasons) and a rough speed expectation. It leans on the schema for the 'infer or ask the user' behaviors, which is acceptable given full schema coverage, though a note on what happens with sparse inputs would round it out.

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 carries parameter meaning and the baseline is 3. The description only indirectly maps to parameters by naming the scoring dimensions (company profile, tech stack, pain, budget fit, buying signals), adding modest signal about which inputs matter but no syntax or precedence guidance.

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?

Specific verb ('Scores') plus specific resource ('a company's ICP fit') with the evaluation scope spelled out as 5 named dimensions and an A–D tier output. It explicitly distinguishes itself from batch_fit_score, so an agent can pick between the two without opening schemas.

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 opening clause gives a concrete trigger ('when the person asks whether one company is a good fit, before they reach out or spend more time'), and the closing sentence names the alternative and the condition that selects it ('For many companies at once, use batch_fit_score'). Both when-to-use and when-not-to-use are 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.