create_person

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Add' signals mutation, but nothing is said about duplicate handling, whether linked friend parameters create graph relationships, side effects, or expected response behavior. The description discloses only the bare operation type, nothing beyond it.

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 clean sentence with zero filler. The action verb and resource are front-loaded, and nothing in the description is redundant with the schema.

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 10 parameters, linked-friend logic, no output schema, and no annotations, a one-sentence description is inadequate. The agent gets no sense of success/failure semantics, return value, or duplicate behavior. The schema mitigates parameter understanding but leaves the operational context unexplained.

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 100%, so all 10 parameters are already documented with meaningful detail (priority default of 3, relationshipTypeId examples, and the hint to use list_friends for linkedFriendUserId). The description adds no parameter info, but the baseline of 3 applies because the schema does the heavy lifting.

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?

'Add a new person to your CRM' uses a specific verb (add) and resource (person in CRM), clearly conveying a create operation. It distinguishes from the sibling update_person via 'new', though it doesn't explicitly call out any sibling by name.

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 guidance on when to use this tool versus alternatives. With siblings like update_person and add_interaction present, there is no routing advice, no conditions, and no exclusions — the agent must infer usage from the name alone.

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