Sirveil Exposure

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

The description substantially extends the annotations by specifying the exact three return states, warning that 'indeterminate' must not be reported as 'not found,' and disclosing that stale index entries will still read as indexed. This is exactly the kind of behavioral context beyond readOnly/openWorld/idempotent hints that agents need.

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 compact and front-loaded, with the core question stated first, followed by essential return-state details and a critical limitation. Every sentence earns its place; there is no filler or repetition of schema content.

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 description covers the return states, interpretive guidance for 'indeterminate,' and the stale-index caveat, which are the critical operational facts. However, with no output schema, the phrase 'returns the evidence' is vague about what the evidence looks like (e.g., URLs, snippets, confidence fields), leaving a minor completeness gap.

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?

The description adds no parameter-level meaning beyond a general 'named person' and 'one domain' framing, even though schema description coverage is only 60% and four parameters (email, phone, middleName, street) are undocumented in the schema. It does not explain optional disambiguators or 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?

The description states a specific verb and resource: it checks whether a named person is indexed on one data-broker domain. It also clearly distinguishes itself from a hypothetical page-fetching alternative with 'This reports INDEX PRESENCE only.' There are no siblings, so no further differentiation is needed.

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 description makes the tool's scope unambiguous: it checks one domain and returns index presence only. It does not name alternative tools because there are no siblings, but the 'INDEX PRESENCE only' limitation effectively tells an agent when not to rely on the result for content-level claims.

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