Origami Tutor

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

Annotations already establish readOnly, idempotent and non-destructive behavior, and the description adds useful context: results are ranked, include paper requirements and lesson links, and are paginated. It does not discuss rate limits or result caps, but for a safe read tool this is solid added value.

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?

A single well-formed sentence with the search scope and return contents front-loaded. Every clause carries information; nothing is wasted.

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 usefully enumerates what is returned (ranked projects, paper requirements, lesson links, pagination), which is what an agent needs to decide relevance. It omits any mention of result quality or ranking criteria, a minor 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?

Schema description coverage is 100%, so the schema already documents query, cursor, category, pageSize and difficulty fully. The description only restates the filter dimensions, adding no syntax or format detail beyond the schema, so baseline 3 applies.

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 gives a specific verb and resource ('Searches public paper crafts') plus the filter axes (query, difficulty, category) and the return payload, so an agent can tell it is the discovery/search tool. It does not explicitly name how it differs from get_origami or suggest_origami, keeping it short of a 5.

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?

Search semantics imply the use case (finding projects by keyword), and the schema clarifies that empty query means browse. However, there is no explicit when-to-use guidance versus get_origami or suggest_origami, so the routing decision is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context by naming the returned fields, which matters because no output schema exists. It stops short of describing not-found/ambiguity behavior, which keeps it off a 5.

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?

One sentence, front-loaded with the payload and ending with the accepted identifier forms. Nothing is redundant or padded.

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 one required parameter, rich annotations and no output schema, the description does the necessary work by specifying what is returned. The only gap is resolving ambiguity or miss behavior, which an agent would otherwise have to discover at call time.

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% for the single parameter, and the description's 'slug, identifier or unambiguous name' essentially restates the schema's own wording. The baseline of 3 applies since the schema carries the semantic load and the description adds no new constraint or example format.

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 uses a specific verb ('Returns') and enumerates the resource contents: difficulty, paper requirements, materials and lesson links. That payload list implicitly separates it from get_origami_steps (which would return construction steps), though no sibling is named explicitly. An agent can tell what it fetches without opening the schema.

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 only implied: this is the lookup for a single known model. There is no statement of when to prefer it over find_origami (search) or suggest_origami (recommendation), nor what to do when the slug is ambiguous or unknown. The phrase 'unambiguous name' hints at a precondition but doesn't spell out the fallback.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that it returns the complete set of illustrations plus a 'Finish' note, which is useful payload context, but says nothing about ordering guarantees, payload size, or failure behavior for unknown slugs.

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?

A single sentence with no filler, front-loaded on the return payload and closed with the accepted identifier forms. Nothing could be removed without losing information.

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 one-parameter, read-only, idempotent tool with no output schema, the description conveys enough about the returned content (illustrated steps plus the Finish note) to set expectations. The only real gap is the absent differentiation from get_origami, which the description could have closed in one clause.

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?

With a single parameter at 100% schema description coverage, the schema already explains that the slug accepts 'a public model slug, identifier or unambiguous model name'. The description restates that same acceptance set without adding resolution rules, format hints, or what 'unambiguous' means when a name collides.

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?

States a specific verb ('Returns') and resource ('all illustrated folding instructions and the Finish note') with a clear input surface (slug, identifier or name). An agent can tell this is the step/folding-instruction fetch, but the description never names the sibling get_origami, so the boundary between model metadata and folding steps is inferred from the tool name rather than stated.

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 only implied: an agent infers it should call this when it needs the folding sequence rather than the model overview. There is no explicit when-to-use, no mention of get_origami vs get_origami_steps, and no stated prerequisite such as resolving the model via find_origami first.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds meaningful context the annotations do not carry: results are public categories and include project counts and page links for navigation, which matters given there is no output schema.

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?

A single short sentence with no filler, front-loading the verb and resource and then the returned information. Every clause 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?

For a zero-argument, read-only browser tool with no output schema, the description supplies the key thing an agent cannot get from structured fields: what the listing contains. The only real omission is guidance on when to reach for this versus the origami lookup tools.

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 tool takes zero parameters, so the baseline is 4. There is nothing further the description could reasonably say about inputs, and it correctly implies the listing is unfiltered.

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?

States a specific verb ('Lists') and resource ('public craft categories') plus the payload (project counts, page links). It is clearly distinguishable from the origami-specific siblings like find_origami and get_origami_steps, though it does not explicitly contrast itself with them.

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?

There is no explicit when-to-use guidance and no mention of alternatives. The browsing intent is only implied by the title and the word 'Lists', leaving the agent to infer that this is a discovery entry point before the find_origami/get_origami tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The definition usefully adds that results are ranked and paginated, but says nothing about how ranking is determined or what an empty result set means, so it does not go far beyond the structured fields.

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?

One sentence, front-loaded with the filtering capability and closed with the return shape and pagination. Every clause carries information and nothing is repeated.

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 full schema coverage and read-only annotations, the definition only needed to add the return shape, which it does (ranked matches plus pagination) despite there being no output schema. What remains missing is the ranking basis and any hint about how results feed into get_origami_steps.

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 every parameter is already documented at the field level. The description enumerates the same filter dimensions (occasion, age, duration, difficulty, category) without adding syntax, defaults, or combination semantics, which is baseline territory.

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 definition names a concrete verb (filters) and resource (projects) plus the five filter dimensions and the ranked-result behavior, so the agent knows exactly what it does. It never contrasts itself with find_origami, the obvious overlapping sibling, so the reader must infer the difference from the names alone.

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 only implied: the occasion/age/duration/difficulty framing signals a discovery scenario, but there is no statement of when to prefer this over find_origami or when to follow up with get_origami for details. No exclusions, prerequisites, or fallback behavior are given.

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