leadpipe-mcp

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

No annotations provided, so description carries full burden. It discloses what data is accessed (pipeline data) and what computations are performed (breakdowns, averages, conversion rates), but omits operational details like real-time vs cached data, time range limitations, or read-only safety guarantees.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Single sentence structure with colon-separated list of metrics. Front-loaded with action verb 'Get'. Zero redundancy; every phrase specifies either the operation or a specific returned metric.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero input parameters and absence of output schema, description compensates by listing specific analytics returned. However, lacks structural details about output format (JSON object structure, nesting of breakdowns) that would fully complete the specification.

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

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

Zero parameters present per input schema, establishing baseline score of 4. No parameters require semantic explanation.

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

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

Description uses specific verb 'Get' with clear resource 'lead pipeline analytics' and enumerates exact metrics returned (total leads, status/source breakdown, average score, score distribution, conversion rates). Distinct from sibling operational tools like lead_ingest or lead_search by focusing on aggregate analytics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance provided. However, the specific list of aggregate metrics (breakdowns, conversion rates) implies this is for analytics/reporting versus individual lead operations (lead_search) or data export (lead_export). Lacks explicit comparison to alternatives.

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