Skip to main content
Glama
Sign In

Andru

by io.github.geter-andru
OverviewDiscussionsAdmin

Read your ideal customer profile

get_icp_profile
Read-only

Use this when the person asks who their ideal customer is, who isn't a fit, or needs to explain who buys from them and why. Returns the account's ICP, built from what they sell: the enterprise buyers who decide, what each one is measured on and the concerns each needs answered, the signals that a company is ready to change, and who isn't a fit. If the first ICP is still being built, it says so; ask again in a minute.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / properties / includeAntiPatterns
      Removed value: -{
-  "description": "Include anti-patterns and churn predictors (default: true)",
-  "type": "boolean"
-}
    • removedInput schema / properties / includeSevenAnswers
      Removed value: -{
-  "description": "Include seven critical buyer answers (default: true)",
-  "type": "boolean"
-}
    • removedInput schema / properties / layers
      Removed value: -{
-  "description": "Specific layers to include (1-5). Omit for all layers.",
-  "items": {
-    "enum": [
-      1,
-      2,
-      3,
-      4,
-      5
-    ],
-    "type": "number"
-  },
-  "type": "array"
-}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

The annotations only tell us this is a read-only, open-world read, so the description's main value is the disclosure that the ICP is derived from what the account sells and that it may still be under construction: "If the first ICP is still being built, it says so; ask again in a minute." That is a genuinely useful async-state caveat an agent would otherwise not know. It does not cover staleness or refresh behavior beyond the initial build.

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 usage trigger, then the payload, then the edge case. No filler. The middle sentence's list is long but every item tells the agent what it will get back, so it earns its length.

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 and no parameters, the description must describe the return shape, and it does: buyers, metrics, concerns, signals, disqualifiers. It also covers the build-pending edge case. Only staleness or caching behavior is unaddressed, which is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate, and the default expectation does not apply. The description correctly does not invent parameter 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?

States a specific verb and resource ("Returns the account's ICP") and then enumerates the contents: decision-makers, what each is measured on, buying signals, and disqualifiers. That makes it clearly distinct from siblings like get_icp_fit_score, get_persona_profile, or get_disqualification_signals, which each return a slice of this picture.

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?

Opens with concrete invocation triggers: "when the person asks who their ideal customer is, who isn't a fit, or needs to explain who buys from them and why." That is clear guidance on when to call this tool. It doesn't name alternatives for the overlapping case ("who isn't a fit" overlaps with get_disqualification_signals), so it is not a 5.

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

All Andru toolsInspect
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.

Resources