Slop Patterns

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 fully covered. The description adds what the call returns substantively (release deltas and the versioning scheme), but says nothing about format, ordering, or size of the changelog — adequate, not rich.

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 short sentences, zero filler, with the content of the tool front-loaded and the usage cue second. Nothing here could be cut 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?

With no parameters, no nested objects, and annotations carrying the read-only/idempotent guarantees, the description covers what an agent needs: what the tool returns and the one situation that justifies calling it. It is slightly thin on the shape of the returned changelog, but no output schema exists to rely on and the gap is minor for a zero-arg read.

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, which is the baseline-4 case; there is no parameter meaning for the description to supplement. It correctly avoids inventing arguments and only frames what the parameterless call yields.

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 the resource (library changelog) and enumerates the content it exposes: version, per-release additions/changes, and versioning scheme. That is specific enough to separate it from siblings like list_patterns or get_pattern, though it never explicitly contrasts itself with them and reads partly as a noun phrase rather than a verb+resource statement.

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 gives an explicit use case: 'Use it to cite a specific version of Slop Patterns.' That is real when-to-use guidance rather than an implied one, but there are no exclusions and no mention of alternatives (e.g. get_pattern) when the agent only wants a single pattern rather than version provenance.

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 and destructiveHint=false, so safety is covered. The description adds value beyond that by disclosing the coverage boundary (only the 101 patterns with a mechanical tell) and the shape of what comes back (matches plus the fix for each), which is important 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?

Two sentences, both front-loaded with the highest-value information: what is checked first, then what is returned, then the coverage limit. No filler or repetition of the name.

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 returns and does so adequately (matches plus fixes). Parameters, defaults and the shareStats privacy guarantee are in the schema. Only minor gaps remain, such as input size limits or latency expectations for pasting whole files.

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 both parameters (code and shareStats) are fully documented in the schema, including default values and the privacy behavior of shareStats. The description adds no parameter-level meaning beyond that, so the baseline of 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 (check), the resource (a snippet of CSS, HTML or JSX), and the exact output (every matching AI design anti-pattern plus its fix). Its scope also distinguishes it from the library-browsing siblings (list_patterns, search_patterns, get_pattern) without needing to name 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?

The closing line 'Useful for reviewing generated UI code' implies a usage context but never states when to use this tool versus the sibling pattern-lookup tools, nor any exclusions. An agent can infer the context but gets no explicit routing guidance.

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, and destructiveHint=false, so safety is covered by structured data. The description goes further by enumerating what the returned entry contains (appearance, cause, who it hurts, fix, sources), which is real behavioral disclosure given the absence of an 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 front-loaded sentence that establishes the verb, the key, and the return contents with no filler. Every clause earns its place by previewing the response shape.

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 must preview the return, and it does so adequately by listing the pattern entry's components. Minor gap: it doesn't say what happens when an unknown id is supplied, which would matter for error handling.

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 0% and the schema only says the id is a string, so the description carries the burden — it correctly explains that the parameter accepts either a short code ('a1') or a slug ('the-unchosen-gradient'). This is meaningful clarification beyond the bare string type.

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 ('Get one full pattern entry by id or code') and the word 'one' implicitly separates it from list_patterns/search_patterns. It does not explicitly name the sibling tools, so an agent must still infer the boundary from the singular scope.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as search_patterns or list_patterns. The example identifiers hint that a known id is required, but nothing tells the agent when this tool is the right choice over its siblings.

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 readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds context they don't carry: the exact shape of the response (code, id, name, one-liner), which is valuable since no output schema exists.

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 front-loaded sentence that names the resource and the return fields with no filler or repetition of the title.

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 communicates what comes back, and annotations cover the safety profile. The only omission is any mention of the optional track filter or how results are ordered or paginated.

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 single 'track' enum parameter is already documented by the schema and the baseline is 3. The description does not mention the filter at all and its 'whole taxonomy' phrasing arguably understates the filtered mode, but it does not contradict 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 ('List') and resource ('the whole Slop Patterns taxonomy') and even enumerates the returned fields (code, id, name, one-liner). It distinguishes itself implicitly from search_patterns/get_pattern by emphasizing the complete enumerations, but never names those siblings explicitly.

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 word 'whole' implies this is the tool to use when you want the entire taxonomy rather than a targeted lookup, giving mild implied guidance. However, no alternatives are named and no when/when-not conditions are stated, so an agent must infer the distinction from sibling names.

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=false and openWorldHint=true, so the agent already knows this is a non-idempotent creating submission. The description adds genuinely new context beyond that: reports are human-reviewed before publication and published entries credit the reporter, which sets expectations about latency and outcome.

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, zero filler. The most decision-relevant constraint (not yet in the library) is front-loaded, followed by what happens to the submission.

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 5-parameter creation tool with no output schema, the description covers the key workflow facts (not-listed prerequisite, human review, credit). It does not describe what the tool returns on submission, but the annotation profile makes that 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%, with per-field guidance (name example, credit, example snippet, whereSeen usefulness). The description adds no parameter-level detail beyond the schema, 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 (report) and resource (AI design anti-pattern) with an explicit scope constraint — patterns NOT yet in the library. This cleanly separates it from get_pattern, list_patterns, and search_patterns.

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 a clear trigger: report when a design failure is seen repeatedly and a search of the library does not find it, which implicitly routes the agent to search_patterns first. No explicit 'do not use for X' clause, but the context is unambiguous.

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 readOnly=true, idempotent=true, destructive=false, so the safety profile is covered. The description adds useful behavioral context that the query is interpreted in plain language with fuzzy-ish matching, but says nothing about result ordering, result count, or pagination.

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 short sentences with the core purpose front-loaded and an illustrative example appended; 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?

There is no output schema and no annotations about returns, so the description should at least indicate what comes back (a ranked list of matching patterns, presumably) and whether results are paginated. For a one-parameter search tool it is adequate, but the result-side context 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 0% for the single 'query' parameter, so the description must carry the load. The worked example ('gradient headline' → A10 Gradient Text Headline) usefully conveys that input is free-form natural language, but it leaves matching rules, multi-term behavior, and case handling unexplained.

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 ('Plain-language search across the library') and clarifies the matching style as natural language rather than exact match. It does not explicitly distinguish itself from close siblings like list_patterns or get_pattern, 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?

The example shows how a query looks but never says when to choose this over list_patterns (browse all) or get_pattern (fetch one known item). No prerequisites, exclusions, or alternatives are named, leaving selection 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, non-destructive and closed-world, so the safety and caching profile is covered. The description adds that results are causally scoped ('only the causal explanation'), which is useful, but says nothing about permission needs, result format, or what happens if no cause is found.

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 tight sentence, front-loaded with the action and scoped by the parenthetical. No filler, though the sentence is short enough that structure is a minor factor.

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 simple one-parameter read tool with annotations covering safety, the description is serviceable. It is incomplete on parameter meaning (what 'id' refers to) and on behavior when no causal explanation exists, which matters given no output schema.

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?

One required parameter with 0% schema description coverage: the schema only gives 'id' as a string with no meaning. The description refers to 'one pattern' but never explains that the id identifies a pattern or whether it's a pattern id vs. other ids. With low coverage, the description should have compensated and does not.

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 action ('Return only the causal explanation') and resource ('one pattern'), and the parenthetical scopes what 'why' means (model/tool/template default). It distinguishes itself from get_pattern by emphasizing causation, but it doesn't explicitly name the sibling to use for non-causal pattern data.

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 word 'only' implies this is a focused query rather than general pattern retrieval, hinting get_pattern is the alternative. But there's no explicit when-to-use/when-not-to-use statement or named alternative, so guidance is only implied.

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