angi_get_pro

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, which covers the safety profile. The description adds meaningful behavioral disclosure beyond the annotations: it enumerates exactly which data sections are returned and clarifies that the tool provides a review count rather than review content — preventing a false expectation of receiving full reviews. This count-vs-content distinction is a genuine behavioral trait an agent needs to know.

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?

Two sentences with zero waste. The first sentence front-loads the core purpose with a verb and a comprehensive content list; the second sentence earns its place by disclosing the review-count behavior and routing to the sibling tool. Every clause adds information an agent needs.

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 simple read-only tool with two well-documented parameters and safety annotations, the description is nearly complete. It covers the return contents — valuable because there is no output schema — the review-count behavior, and sibling routing. Minor gaps are edge-case behavior (error handling, missing profiles, and exact consequences of compact mode on the listed fields), which are acceptable given the strong schema and annotation coverage.

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 the baseline of 3 applies. Both parameters are already well-documented in the schema — profileUrl's description even includes an example URL and a reference to angi_search_pros. The main description adds no parameter-level detail beyond what the schema states; the 'full profile' phrasing implicitly contrasts with compact mode, but the schema already carries that meaning.

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 opens with a specific verb ('Read') and a precise resource ('one Angi pro's full profile'), then enumerates the content areas (business details, service area, hours, amenities, awards, tasks offered, contact address, ratings breakdown). The final clause explicitly contrasts with sibling angi_get_reviews by stating it only reports a review count, which distinguishes it from the review-focused siblings.

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 parenthetical '(fetch them with angi_get_reviews)' gives explicit routing guidance: this tool returns a review count but not the reviews themselves, naming the exact alternative to use. The profileUrl schema description reinforces the intended workflow by referencing angi_search_pros as the source of the URL. It does not address when to prefer compact mode or other siblings, but covers the most relevant decision point.

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