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

Annotations already establish readOnlyHint and idempotentHint, so the safety profile is covered. The description still adds real value beyond the annotations: the ~2k token cost and the exact digest fields returned, which helps an agent budget context. It stops short of describing truncation or paging behavior for large libraries.

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?

Three sentences, front-loaded with the concrete deliverable (the digest and its fields) before any next-step guidance. The middle sentence is somewhat chatty ('you know the operator's repo, data, and recurring pain'), but it still orients the agent toward its own selection judgment.

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?

There is no output schema, and the description compensates by stating the digest's contents and rough size (~2k tokens), plus the follow-up options. For a one-optional-param read tool, this is enough for an agent to call it correctly and know what comes back.

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% and the single optional 'category' filter is documented there with examples, so the schema does the heavy lifting. The description only mentions 'category' as a returned field, not as a filter, adding no meaning beyond the schema; 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?

States a specific resource and scope: the entire AI Loop Library as a compact digest, enumerating exactly what each entry contains (id, category, use_when, verifier strength). It also names the follow-up siblings (get_loop for depth, render_run_protocol to run one), so an agent can distinguish this from deeper or execution-oriented 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?

Says this is the highest-signal single call and describes the follow-on path (get_loop for depth, render_run_protocol to run), giving a clear usage context. However it never contrasts with close siblings search_loops or pick_loop_for_goal, so the when-not guidance is incomplete.

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=true and idempotentHint=true, so safety and repeatability are covered without description help. The description adds that results describe the catalog's provenance ('where the catalog was loaded from'), which is genuine context, but it does not disclose freshness guarantees or whether last_updated reflects load time or content change.

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 front-loaded fragment that lists only relevant fields, with no filler. It is a noun phrase rather than a sentence, which is terse but marginally less readable than a stated verb would be.

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?

An output schema exists, so the return shape need not be explained further, and with zero parameters there is no invocation nuance to cover. For a no-arg read-only stats tool, the description is sufficient.

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 of 4 applies. There is no parameter semantics to explain and the description correctly avoids inventing any.

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 concrete resource (the catalog) and enumerates the exact payload: loop count, categories, featured loops, last_updated, and load origin. It is distinguishable from browse_catalog, search_loops, and list_categories, though it never uses an explicit verb like 'returns' or 'reports', leaving the action slightly implicit.

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?

No guidance on when to call this versus siblings. An agent cannot tell from the text whether this should precede browse_catalog/scarch_loops or how it relates to list_categories, which overlaps on the 'categories' output. No prerequisites or exclusions are given.

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?

Adds meaningful context beyond the readOnly/idempotent annotations: it discloses that this is a deterministic text lint rather than a model, and that 'missing' means 'not stated' rather than absent — a crucial interpretive caveat. It stops short of describing limits such as length caps or determinism guarantees on scoring.

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?

Front-loaded with the core action and scope, then the rubric list, then the return shape. The nine-item check enumeration is long but earns its place by telling the agent what to include; the trailing clause about determinism could be tightened.

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 an output schema handling return values and annotations covering safety, the description fills the remaining gaps: the rubric criteria, the deterministic-lint caveat, and the return shape. Nothing material to correct invocation 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?

With a single parameter at 100% schema coverage, the baseline is already 3-4; the description goes further by enumerating the rubric dimensions (verifier, stop condition, budget, MVL, human gates…) that loop_description should cover, effectively telling the agent what content to supply.

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 and resource ('lint any loop design') and immediately distinguishes it from the design/browse siblings by its rubric-linting scope. An agent can tell it apart from design_loop or get_loop 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?

Gives clear context for when to call it ('the operator's own, or one you drafted'), which covers both review and self-check scenarios. It does not, however, name an alternative or an explicit when-not condition relative to siblings like design_loop or render_run_protocol.

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 declare readOnlyHint and idempotentHint, which the description is consistent with (it produces a draft rather than persisting anything). It goes beyond the annotations by enumerating the returned draft's contents (trigger, scope, one-round action, verifier, state files, stop conditions, budget, risk colors), the MVL sanity check, and nearest existing loops — though it does not say whether the draft is saved anywhere.

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?

Front-loads the core action and its precondition, then packs the return contents into a single dense clause, closing with the next-step instruction. Efficient overall, though the middle enumeration is long and slightly list-heavy.

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 compensates by describing what the draft contains and what analysis accompanies it, and it states the required follow-up tool. Only the persistence/state question is left open, which is minor for a scaffolding tool.

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 goal, cadence, context, and constraints, and the baseline is 3. The description only loosely echoes these (bottleneck, domain, trigger) without adding format, syntax, or interaction detail beyond the schema.

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 (scaffold) and resource (a new loop spec), plus the trigger condition (from a stated bottleneck when no catalog loop fits). This distinguishes it cleanly from catalog-reading siblings like search_loops, get_loop, and pick_loop_for_goal.

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?

Explicitly scopes usage with 'when no catalog loop fits', implying the catalog tools are the alternative when one does fit, and names the required follow-up step (critique_loop on the completed draft). It stops short of naming a specific sibling to try first, so it is clear context without full routing.

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 cover safety (readOnlyHint, idempotentHint), so the bar is lower; the description still adds value by disclosing the depth of the payload, including verifier strength and approval boundary. It stops short of noting error behavior for unknown ids/slugs or whether the response is cached.

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?

Two compact sentences, front-loaded with the action and the returned surface, ending with the routing hint. No filler or repetition.

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 an output schema present, the description need not explain return values, yet it usefully summarizes them; the single required parameter is fully documented in the schema. Nothing an agent needs to invoke this correctly 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 coverage is 100% on the single parameter, so the baseline is 3. The description says 'by id or slug' while the schema documents 'id ... or its title', a mild inconsistency that adds no disambiguating detail beyond the schema.

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 ('Fetch') and resource ('one loop's full spec') and enumerates exactly what is returned: objective, trigger, verification, stop condition, budget, approval boundary, prompt, canonical URL. This is clearly distinguishable from siblings like browse_catalog and search_loops.

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?

'Use after browse_catalog or search_loops' gives explicit sequencing context, telling the agent when this tool is the right next step. It does not, however, name an exclusion or an alternative for the case where the agent already knows the identifier directly.

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 and idempotentHint, so the safety profile is covered. The description adds that counts are "live" and that filter URLs are included, but with an output schema present it need not elaborate further; this is modest added context.

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 front-loaded sentence with no filler; the key noun (loop categories) leads. It is almost too terse to carry usage or scope nuance, but every word 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?

With zero parameters, read-only annotations, and an output schema to describe the return shape, the description covers the essentials. The one gap is routing guidance relative to the many sibling catalog 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 and the schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-argument tool.

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 ("List loop categories") and adds scope detail (live counts, library filter URLs), so the agent knows exactly what comes back. It does not distinguish itself from siblings like browse_catalog or catalog_stats, which also surface catalog-level information.

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 statement of when to reach for this tool versus browse_catalog, search_loops, or catalog_stats. The implied usage is a bare listing, but no conditions, prerequisites, or exclusions are given.

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 and idempotentHint, so safety is covered. The description adds genuinely non-structured behavior: lexical ranking, an honest confidence signal, and a candidate payload of use_when/verification/why-matched. It stops short of rate limits or failure modes, so 4 rather than 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?

Front-loads the verb and resource, then layers the caveat and the follow-up. Dense but every clause carries routing or behavioral information; the em-dash aside is slightly compressed but not wasteful.

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?

Output schema exists, so return values needn't be enumerated, yet the description still tells the agent what the candidates contain and when to distrust the ranking. Nothing needed to call it correctly 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 coverage is 67%, so the schema already documents goal, limit, and constraints reasonably. The description clarifies that goal is an operator outcome and that constraints capture operator context the server can't see, but it omits the constraints parameter by name and the configurable limit ('Returns 5 candidates' only reflects the default). Baseline 3 fits.

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+resource ('shortlist the best-matching loops') scoped to a stated goal, and distinguishes itself from siblings by naming browse_catalog and render_run_protocol. An agent can tell it apart from search_loops without opening either 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?

Explicitly names the fallback ('When confidence is low, trust your own read of browse_catalog') and the required follow-up ('Follow with render_run_protocol for the executable version'). This is a clear when-to-use plus named alternatives, not mere implication.

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 establish readOnlyHint and idempotentHint, so the safety profile is covered. The description adds substantive behavioral detail beyond that: the protocol is paste-ready, includes a durable state-file skeleton, stop conditions, budget, a risk-colored approval boundary, and undo-losers discipline for tick loops. It stops short of saying what is returned (inline markdown vs. file) or what happens on a bad id_or_slug.

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?

Two sentences, front-loaded with the core purpose before the content enumeration. The first sentence is a dense but scannable list where each item earns its place; the second adds the session/tick split. Slightly list-heavy, but no filler or repetition.

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 carries the burden of describing the return value, and it does so thoroughly by enumerating the protocol's sections. The remaining gap is the delivery form (returned as text, written to a file, or a URL) and error handling for an unresolved id_or_slug, which an agent would want before invoking.

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 coverage is 100%, so the baseline would be 3, but the description goes further by explaining the two protocol flavors that the `kind` enum selects between (session rounds vs. scheduled-tick experiment logs) and by tying budgets, risk-colored approval, and the goal to their respective parameters. That meaning is not present in the schema strings alone.

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 leads with a specific verb+resource: 'Render a loop as an executable markdown run protocol an agent can follow directly,' and then enumerates the artifact's contents, so the agent knows exactly what is produced. It does not, however, name or contrast any sibling (design_loop, critique_loop, get_loop), so an agent must infer the boundary itself.

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 description explains that session loops get bounded rounds and scheduled-tick loops get experiment logs, which hints at when each flavor applies, but it never states when to reach for this tool versus design_loop or critique_loop, nor any prerequisite (e.g., the loop must already exist).

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 cover the safety profile (readOnlyHint, idempotentHint), and the description adds real behavioral context: loops are bounded, ship with trigger/verification/stop-condition/budget/human-approval boundaries, and results are ranked with a one-line why-matched. It omits pagination/rate-limit behavior, keeping it below 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?

Front-loaded with the verb and resource, then one compact sentence explaining what a loop contains. It is a touch long in the middle clause list, but every phrase carries informational weight about the returned objects.

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?

An output schema exists, so return values need not be explained, yet the description still tells the agent results are ranked and include a why-matched line. For a low-risk read-only search with three params, nothing critical 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 coverage is 67% and the schema already documents query and category with examples. The description reinforces the 'job-to-be-done' framing and confirms category filtering but adds no syntax, matching, or limit semantics beyond what the schema provides, so the 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?

States a specific verb (Search) and resource (AI Loop Library's bounded, verifiable work loops) plus the search axes (job-to-be-done, keyword, category), so it is distinguishable from get_loop or browse_catalog. It does not explicitly name rival siblings like pick_loop_for_goal, so it stops 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?

Usage is implied by the query axes, but there is no explicit when-to-use statement, when-not condition, or named alternative. The closest sibling, pick_loop_for_goal, is also goal-driven and the description gives no cue for choosing between them.

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