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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no distinct behavioral disclosure beyond what annotations provide—no mention of pagination, output shape, or limits. It is not contradictory, but it also offers no extra behavioral context.

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?

The description is a single, short phrase with no filler or redundancy. It front-loads the essential resource type and the two key filters. While it could be more detailed, it is concise and structured appropriately for its length, so it earns a high score without reaching maximum because it omits useful structure like explicit sentence form.

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?

The tool has three parameters, no output schema, and a very brief description. It does not explain what an 'owner portfolio' contains, whether results are paginated (despite the per_page parameter), or what the response format looks like. With no output schema, the description carries a heavier burden, and it falls short of giving the agent enough context to anticipate the tool's output and use it correctly.

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 0%, so the description must interpret the parameter names. It clarifies that 'state' and 'name' are the state and owner name used to filter the portfolio, which is valuable. However, it says nothing about per_page or its purpose, and offers no value formats or examples, only partially compensating for the 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?

The title 'Look up an owner portfolio' supplies the verb, and the description 'An owner's parcel portfolio by state and owner name' names the specific resource (owner parcel portfolio) and two filter dimensions. This is enough to differentiate it from siblings like estate_search or estate_stats, but it does not explicitly contrast against them or mention whether it is the only owner-portfolio tool, losing the last point.

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 usage guidance is provided. The description gives no context on when to choose this tool over alternatives like estate_search or estate_parcel, no mention of what it is not suitable for, and no prerequisites or fallback conditions. The agent is left to infer applicability 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.