Returns one prospect by prospect ID, or by the record it tracks, with its lifecycle, status (Hot, Warm, Cold, Follow up, Do Not Contact; read only), tags, and note and file counts. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | No | Record ID such as `prop_12345`, used when prospect_id is not known | |
| prospect_id | No | Prospect ID such as `prospect_8812` | |
| record_type | No | What kind of record. Defaults to property. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and non-destructive, and the description adds genuinely new behavioral facts: the call is free (no credit consumption) and the status field is read-only. It does not say what happens when neither identifier is supplied, which is the main remaining gap.
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 front-loaded sentence with the lookup keys first and the returned payload second, followed by the cost note. No filler.
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?
With no output schema, the description carries the return-value burden and does so by enumerating lifecycle, status, tags and note/file counts. Only the fallback behavior when no identifier is given is missing, which is minor for a free lookup tool.
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 coverage is 100%, so baseline is 3, but the description adds the important lookup-mode semantics: the tool accepts either a prospect ID or a record ID plus its type, information the zero-required-parameter schema does not make explicit.
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?
States a specific verb (returns) and resource (one prospect) plus the two lookup keys and the returned fields, which clearly separates it from the sibling prospect_search / prospect_add tools. It stops short of naming the sibling, but the singular-vs-list distinction is unambiguous.
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?
The 'or by the record it tracks' phrasing implies when to use record_id instead of prospect_id, and 'Free' hints it costs nothing to call. There is no explicit when-to-use/when-not guidance, e.g. whether to prefer this over prospect_search when only a property ID is known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
