tes_resource_shop

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

No annotations are provided, so the description carries the burden. It discloses that the tool returns a 'page' of listings, that subject is not a curated enum and varies per author, and that the listing is a summary requiring follow-up calls. However, it doesn't disclose pagination behavior (page size, whether page is required), rate limits, or what happens for invalid usernames. The description is honest about the non-enum subject values, which is useful, but it doesn't fully cover behavioral traits like default page size or error behavior.

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 paragraph that front-loads the core purpose and return fields, then adds the username source and subject caveat. It's information-dense but not bloated. The only minor issue is that the long parenthetical about username sourcing could be slightly restructured for readability, but every sentence earns its place.

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?

Given the tool's moderate complexity (3 params, no output schema, no annotations), the description covers the essential context: what the tool returns, how to identify the username, how to use the subject filter, and what follow-up calls are needed. It doesn't mention pagination defaults or error cases, but for a read-only lookup tool with a clear schema, this is reasonably complete. The lack of an output schema makes the return-value enumeration in the description especially valuable.

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. The description adds meaning beyond the schema: it explains that 'username' comes from the author field of tes-resource-search/tes-resource-detail or the trailing path segment of author_url, and it clarifies that 'subject' corresponds to the subject tabs on the shop's own page and is not a curated enum. This is genuinely useful context that helps the agent pick correct values. The 'page' parameter is only described as 'One-based page' in the schema and the description doesn't add much, but the overall parameter guidance is strong.

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 ('Get') and resource ('a Tes teaching-resources author shop'), then enumerates exactly what normalized detail is returned: display name, average rating, upload/view/download counts, bio, and a page of resource listings. It also names the sibling tools (tes-resource-search/tes-resource-detail) and explains how the username is derived, which clearly distinguishes it from related tools.

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 gives clear context on when to use this tool: to fetch a shop by username, and it explicitly references the source of that username (from tes-resource-search/tes-resource-detail's author field or the trailing path segment of author_url). It also instructs the agent to call tes-resource-detail for each listing id to get full details. It doesn't explicitly state when NOT to use it or name alternatives beyond the implicit sibling references, but the usage context is strong.

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