CSS SOTA

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

The annotations already mark this as read-only, and the description adds substantial behavioral detail: it reports the offending line, error type, and minimum working version. It also warns about the Baseline 'Limited' nuance and instructs the agent to read the browsers-missing line before removing anything, which is critical for correct use.

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 long but front-loaded with the core action, then progresses through target syntax, output details, and a crucial interpretation warning. Each sentence contributes necessary context, though it 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 a rich description, good schema coverage, and an output schema present, the tool is fully specified for an agent to invoke it correctly. It even includes a subtle caveat about interpreting Baseline 'Limited' status that could otherwise lead to false confidence.

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?

All parameters already have schema descriptions (100% coverage), so the baseline is 3. The description adds value by explaining the exact target syntax and clarifying that malformed CSS is tolerated for the source parameter, which goes 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?

The description opens with 'Scan CSS source and report every feature...' which clearly identifies a verb, resource, and output. It distinguishes from sibling tools by focusing on auditing an entire CSS source against browser targets rather than querying individual features.

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 explicitly states accepted target formats and calls out that Browserslist queries are not supported. However, it does not name alternative tools for when a user might prefer checking a single feature, so it falls short of full when/when-not 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 declare readOnlyHint=true, and the description reinforces a safe local read by stating 'no network call' and 'bundled with this server'. It also discloses output characteristics (vendor prefixes, partial implementations, Baseline status). No contradictions.

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, each carrying essential information: purpose, input modes, and output extras. No redundant phrases.

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 doesn't need to detail return structure. It covers data source, input modes, precedence, and key output categories, making it complete for a lookup 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 descriptions already cover all four parameters (100% coverage), so baseline is 3. The description adds meaningful relational semantics: bcd_key takes precedence over property/value, and value falls back to property support. This elevates it above the baseline.

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 phrase 'Look up which browser versions support' with a clear resource (MDN browser-compat-data), and enumerates the queryable entities (CSS property, value, selector, at-rule, function). This clearly distinguishes it from sibling tools like search_css_features or audit_css.

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 explains the two input modes (BCD key or property/value) and the precedence relationship. It does not explicitly contrast with sibling tools, but the scope is clear enough that an agent would know when to invoke it for support lookups.

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?

Beyond the readOnlyHint annotation, the description transparently discloses that review is static, does not render the page, cannot measure computed contrast, real target sizes, or focus placement, and that linked stylesheets are not followed. These limitations are exactly the kind of behavioral context that matters for correct invocation.

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 longer than typical but every clause adds value. It front-loads the core purpose and then details mode differences and limitations. A slight trimming of parenthetical examples could improve conciseness, but the structure remains logical and readable.

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 (two modes, five parameters, output schema), the description covers what each mode returns, how to filter, and what the static review can and cannot detect. With no output schema details provided, the description adequately explains behavior without needing to list return fields.

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?

Although the schema already covers all parameters, the description adds crucial semantics: mode='guidelines' vs 'review', topic is ignored in review mode, and url only reads HTML and inline styles, requiring css to be passed separately. This goes beyond the schema's prose and meaningfully improves parameter understanding.

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 clearly states dual functions: returning UI/UX principles (guidelines mode) and reviewing HTML/CSS/URL against them (review mode). It names specific resources and behavior, and naturally distinguishes itself from CSS-feature siblings like audit_css or check_support by focusing on UX principles and page review.

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 tells when to use each mode: 'Read them BEFORE designing or building UI' for guidelines and 'statically reviews supplied HTML and CSS, or a URL' for review. It also advises passing css along with url for full coverage. It lacks an explicit 'when not to use' or alternative tool mention, but the context is strong.

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, ensuring the agent knows this is a safe read operation. The description adds the dual input forms (id or display name) and lists return categories, but these are already covered by the schema and output schema. It discloses no side effects or unexpected behaviors beyond what structured fields provide.

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 and no filler. The second sentence efficiently explains input format and provides referral guidance, making every word earned.

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 100% schema coverage, presence of readOnly annotation, and an output schema, the description is fully adequate. It covers purpose, input format, and usage guidance without unnecessary repetition, leaving no critical gaps.

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 input schema already fully documents both parameters (feature_id and include_mdn) with descriptions, examples, and defaults. The description does not add any parameter meaning beyond the schema, so the baseline score of 3 is appropriate.

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 specifies the verb 'Get' and resource 'one CSS feature' while enumerating exact data returned (Baseline status, browser versions, spec links, etc.). It clearly distinguishes this tool from the sibling search_css_features, as it targets a single known feature rather than searching.

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 explicitly instructs 'Use search_css_features first if you do not know the id,' providing a clear alternative for a common scenario. It also implies this tool is for comprehensive detail retrieval on a single feature, contrasting with the search tool.

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 indicate read-only and open-world behavior. The description adds 'Returns live Baseline data,' which clarifies the data source is real-time and not cached, and clarifies the meaning of Baseline through examples. This goes beyond the annotations without contradicting them.

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: purpose, usage examples, and alternative. No wasted words; information is front-loaded and directly relevant to tool selection and invocation.

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 5 parameters, read-only/open-world annotations, and presence of an output schema, the description covers the essential aspects: what it does, when to use it, the live-data nature, and an explicit alternative. It does not need to explain return values since an output schema exists.

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 input schema provides 100% coverage of parameter descriptions, so the schema does the heavy lifting. The description only summarizes the filter dimensions (keyword, baseline status, date range) without adding new syntax or format details beyond what the schema already specifies.

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 clearly states the tool searches CSS features on the Web Platform Dashboard with specific filters (keyword, Baseline status, date range). It distinguishes itself from check_support by explicitly naming that sibling for version-specific queries, and it provides concrete example questions.

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 explicitly describes when to use this tool ('Use this to answer questions like...') and points to an alternative (check_support) for a different use case. This gives clear guidance on tool selection among 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?

The annotations indicate a read-only operation, and the description adds valuable behavioral context beyond that: it mentions the default window, ordering (newest first), and the semantic that the date is the interop date rather than first-ship date. This helps set expectations.

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 three sentences, with the first stating the action, the second giving usage, and the third providing default behavior and a key semantic caveat. Every sentence earns its place and there is no redundancy.

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 simple nature of the tool, the comprehensive schema, annotations, and the presence of an output schema, the description fully covers purpose, usage, and an important nuance. It does not need to explain return values.

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%, with all parameters described in detail. The description reinforces the date-range and threshold concepts but does not need to restate parameter specifics. It meets the baseline for adequate semantics.

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 clearly states the action: 'List CSS features that crossed a Baseline threshold within a date range, newest first.' It specifies a distinct verb and resource plus a date-range scope, which differentiates it from siblings like check_support and search_css_features.

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 explicitly names use cases: 'to answer "what CSS can I start using now?", to write release notes, or to catch up after time away.' This provides clear context, though it does not explicitly name alternative tools for other scenarios.

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