Mark a lead as paid by logging the amount received, updating its pipeline status from new to paid for accurate ROI tracking.
Record that you've actually been paid for a lead.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| lead_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a mutation ('record') but says nothing about permissions, idempotency or duplicate-payment handling, or how this affects downstream aggregates like earnings_summary.
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?
A single short sentence with no filler and the action front-loaded, but its terseness is under-specification rather than efficiency given the total absence of behavioral and parameter detail.
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?
An output schema exists so return values need not be described, but for a mutation tool with no annotations and zero parameter documentation the single sentence leaves too much unstated about inputs and side effects.
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?
Schema description coverage is 0% for two required parameters, and the description never mentions lead_id or amount. The agent must infer that amount is a currency value and lead_id identifies the paying lead purely from the property names.
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?
The description states a specific verb and resource ('Record ... payment') scoped to a lead, so the agent knows the core action. It does not, however, distinguish itself from nearby siblings like record_won_amount or log_win_reason, which an agent could easily confuse with this.
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?
'Actually been paid' hints at a real-payment trigger, but there is no explicit when-to-use guidance, no prerequisite conditions, and no routing to or away from alternatives such as record_won_amount or earnings_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.