get_council_member

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

No annotations are supplied, so the description carries the full behavioral burden. It does add real value by disclosing that PersonWWW2 may carry a warning plus an upstream value, which is data-quality context an agent could not get from the schema. However, it says nothing about behavior on zero or multiple matches, whether the lookup is case-sensitive, or what fields beyond contact info and status come back.

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 short sentences with the core purpose front-loaded and no filler. The final sentence on PersonWWW2_warning and PersonWWW2_upstream is dense field-level jargon that interrupts the flow, but it is substantive rather than padding.

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 and no annotations, the description must do all the work, and it covers purpose, rough return content, and one data-quality caveat. It is still thin on failure modes for a partial-name lookup, such as no match or multiple matches, which are the most likely ambiguities an agent will hit here.

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% for the single parameter, so the schema already documents that name accepts a full or partial value. The description restates the same idea without adding matching semantics such as case sensitivity, minimum substring length, or tie-breaking, so it sits at the baseline when 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?

The description opens with a specific verb and resource ("Look up an NYC Council member by name") plus the scope of the return ("current contact info and active status"). This clearly separates it from siblings like get_bill, get_committee, and get_votes, which address legislation and committees rather than individual members.

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?

Usage is implied by the verb "look up" and the fact that a name can be partial, but there is no explicit when-to-use guidance, no statement of when to prefer a sibling tool, and no note on how to resolve an ambiguous partial name. The agent can infer the intent, but nothing in the text directs tool selection beyond the obvious subject matter.

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