Returns one person by DealMachine person ID (id, required), with their name, phones, emails, optional extended fields and associated properties. Needs a connected DealMachine account with paid access. The person costs one people credit; chargeable property fields or associated properties can consume property credits.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| fields | No | ||
| property_limit | No | ||
| include_properties | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses the connected paid-account prerequisite and valuable billing behavior: one people credit per person, with possible additional property credits for chargeable fields or associated properties. It does not explain what destructive side effect destructiveHint=true represents, leaving that part of the supplied behavioral profile unclear.
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?
Three compact sentences front-load the operation and scope, then cover access prerequisites and credit consumption. There is no filler, and the billing detail is specific enough to earn its place.
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?
For a four-parameter billable lookup without an output schema, the description covers the core result, required identifier, access requirement, and important cost behavior. Fuller optional-parameter documentation, explicit sibling routing, and clarification of the destructive annotation would make it more complete.
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?
With 0% schema description coverage, the text usefully clarifies that id is required and conveys the purpose of extended fields and associated properties, including their potential cost. However, it never explains property_limit, valid field identifiers, defaults, or how include_properties and property_limit interact.
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 gives a specific operation and resource: return one person by DealMachine person ID, including contact details and optional extended or property data. The single-record, known-ID scope functionally distinguishes it from dealmachine_people_get_many and dealmachine_people_search.
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?
It establishes a clear use case: the caller has a person ID and wants that person's details, with paid access and credit costs affecting the decision to call. It does not explicitly direct unknown-ID lookups to people_search or bulk retrieval to people_get_many, so selection guidance is not exhaustive.
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.
