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

Annotations only cover readOnlyHint and openWorldHint; the description adds meaningful behavior beyond them: an access_token is required, results are paginated at 20 per page, each entry is a full offer record with listed fields, and there is no server-side prop_id filter. The 'Read-only.' sentence is the one part that restates the annotation.

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?

Content is front-loaded with the lifecycle stage, then auth, return shape, and constraints; nearly every sentence earns its place. The standalone 'Read-only.' sentence is redundant with readOnlyHint rather than additive, a minor structural waste in an otherwise tight description.

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 two-parameter, read-only list tool with an output schema present, the description covers everything an agent needs: lifecycle timing, auth source, pagination mechanics, per-entry fields, and a filtering limitation plus the client-side workaround. Nothing material is missing.

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 is 3, but the description adds real meaning by disclosing the page size (20 per page) and the need to pass page to advance, which the schema's 'Page number of the paginated offers list' does not convey. It does not add anything beyond the schema for access_token.

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 names a specific verb and resource ('offers received on the owner's listings') and even pins the underlying endpoint (GET /offers). It distinguishes itself from siblings like beycome_get_my_listings by scoping to received offers, and from the messaging/response tools by stating that accept/reject/counter is not here.

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?

It states the lifecycle trigger ('used once a listing is live'), gives the operational workaround for single-listing views (no server-side prop_id filter, filter client-side on each offer's prop_id), and explicitly excludes an adjacent capability (responding to offers). When-to-use, how-to-adapt, and when-not are all present.

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