dealdesk.get_contact_commercial_summary

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

With no annotations, the description carries the full burden, and it does disclose what the operation returns (pipeline value buckets and linked deals/quotes/orders), which is useful content context. It says nothing about permissions/auth, read-only nature, or the projectId-must-match-key constraint that is only implied by the schema. Adequate but not rich.

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 listing the returned value tiers and linked entities, with zero filler. Nothing is wasted.

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?

Because there is no output schema, the description usefully enumerates return contents, which is the main gap it needed to fill. But for a tool that duplicates a company-level sibling, it lacks routing guidance and fully omits any detail on the undocumented contactId parameter.

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 only 50%: projectId is documented in the schema, but contactId has no description anywhere. The description mentions 'for a contact' but adds no syntax, format, or sourcing detail for either parameter, so it fails to compensate for the coverage gap.

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+resource ('get_contact_commercial_summary' for a contact) and enumerates what it returns: open/won/lost pipeline value plus linked deals, quotes, and orders. That is clear and differentiated from plain 'get_contact'. However, it never distinguishes itself from the near-identical sibling 'get_company_commercial_summary', so the agent must infer the contact/company split from the name alone.

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 when-to-use or when-not-to-use guidance is provided, and no alternative is named. The agent gets no signal on when to prefer this over 'get_contact' or 'get_company_commercial_summary'. Usage is left entirely to inference from the name.

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