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

The readOnlyHint and openWorldHint annotations already establish the safety profile, and the description adds useful behavior: alias slugs resolve to canonical records, free sources are live, and unpublished rate limits are returned as null. It does not mention missing-model errors or any auth/rate-limit behavior of the tool itself.

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 dense but front-loaded sentence followed by an endpoint reference. Every element earns its place by describing the record contents, alias behavior, or rate-limit semantics.

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, the description appropriately explains the returned record by naming offer, provider, verification/listing status, card rule, context, and rate-limit fields with null semantics. It does not cover error behavior when the slug is unknown or when no free sources exist, so it stops short of fully complete.

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 carry the semantic load. It explains that the sole slug parameter accepts aliases that resolve to the canonical model, which is meaningful beyond the schema's type/length constraints, though it does not define slug formatting beyond that.

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 resource and scope: one model by slug with every live free source. The phrase 'One model by slug' clearly distinguishes this from list/search siblings such as list_models and find_models, and the alias note further clarifies retrieval behavior.

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: use this when you have a slug and want a single model record. However, the description gives no explicit when-to-use or when-not guidance, and it never names alternatives such as find_models, list_models, or get_offer for comparison or discovery.

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