browser-compat-mcp-server

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true. The description adds useful behavioral detail beyond those annotations by specifying exactly what the check returns: Baseline state, date crossed, limiting browser/version, deprecation/discouragement, and traffic exclusion share. It does not contradict the annotations.

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 deliver the core purpose, the output fields, and the key input constraint with no filler. The most important information is front-loaded, and 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?

With a detailed input schema and an output schema present, the description does not need to explain return formats. It provides the purpose, the nature of the results, the batch limit, and the key-types accepted, making it complete enough for correct invocation and selection.

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 fully documents both parameters, including the resolve fallback behavior and the features array constraints. The description restates the batch size and key types but does not add 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 uses a specific verb ('Check whether web features are safe to ship') and enumerates the concrete outputs: Baseline state, crossing date, limiting browser/version, deprecation status, and excluded traffic share. This clearly distinguishes it from sibling tools like browsercompat_get_feature or browsercompat_search_features by its batch Baseline-assessment focus.

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: use this when you need Baseline safety data for web features, and it states the batch limit of 20 keys. It does not explicitly name sibling alternatives or say when *not* to use this tool, but the purpose is unambiguous enough for an agent to select it appropriately.

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 read-only/idempotent annotations, the description discloses non-obvious behavior: per-feature verdicts, the failing target browser and version, traffic-share coverage, unchecked_targets for resolved browsers without data, and the guarantee that unevaluable targets are never reported as cleared. This is exactly the behavioral context an agent needs.

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 dense sentences: action first, then return value highlights, then a one-sentence safety caveat. There is no filler, and the most important scoping information is front-loaded.

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 tool with a rich input schema, annotations, and an output schema, the description adds the critical caveat about unevaluable targets and summarizes the return shape. An agent has everything needed to invoke the tool correctly.

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 reinforces the meaning of targets ('explicit browserslist target query') and features ('set of web features'), but it does not add parameter format or syntax details beyond what the input schema already documents.

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 and resource: it 'compute[s] whether a set of web features clears an explicit browserslist target query'. This clearly identifies the tool as an evaluation/verdict tool, though it never names sibling tools such as browsercompat_check_baseline to make the boundary explicit.

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 context is implied by the focus on an explicit browserslist query and the required targets parameter, but the description gives no direct when-to-use/when-not-to-use guidance or alternative tool names. An agent comparing against sibling tools must infer when this tool is the right choice.

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 readOnly and idempotent annotations, the description clearly discloses important runtime behavior: an unresolved feature returns found: false with guidance rather than throwing an error, and the response echoes which identifier form matched. This tells the agent what to expect on both success and miss paths.

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 cover the output contents, accepted input forms, and error-like miss behavior in a front-loaded order. There is no filler or repetition of schema details; 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?

The description is complete for a read-only single-feature lookup tool: it states the return contents, input conventions, example identifiers, and unresolved-key behavior. Parameter semantics are fully covered by the input schema, and return structure is covered by the output schema, so nothing needed to call the tool 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?

Input schema coverage is 100%, so the schema already documents the parameters. The description adds real value on top by explaining accepted identifier formats (BCD key vs web-features id) with concrete examples and noting that the response echoes which one matched. This helps an agent construct the feature argument correctly.

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 a specific verb and resource ('Get the compatibility record for one web feature') and enumerates exactly what the record contains. It does not explicitly differentiate itself from the sibling tools such as browsercompat_check_baseline or browsercompat_compare_support, but the singular 'one web feature' scope makes the core purpose unmistakable.

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 implies when to use it: when you need a full compatibility record for a single web feature. It also gives behavioral context about unresolved keys and accepted identifier forms, but it never explicitly says when not to use it or names alternatives like browsercompat_compare_support or browsercompat_list_reference.

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 already cover read-only, idempotent, and non-open-world behavior. The description adds only that this is an enumeration tool and hints at its use for building inputs, which is more usage guidance than behavioral disclosure. It does not contradict annotations, but it also doesn't add significant behavioral detail beyond 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?

The description is two sentences: the first lists the vocabulary categories, the second explains the use case. Every word earns its place, and it is front-loaded with the action and resource.

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 output schema, rich annotations, and fully documented parameter, the description covers the tool's purpose, usage, and relation to other tools. Nothing an agent needs to invoke this tool 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 description coverage is 100% and the topic parameter has a full enum with descriptions for each value. The description adds no parameter-specific meaning beyond the general point that the result is used to build valid inputs, 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 states a specific verb ('Enumerate') and resource ('reference vocabulary'), and then names the exact categories: BCD namespaces, browser ids, browserslist agents, Baseline states, groups, and snapshots. This clearly distinguishes it from siblings like check_baseline or get_feature, which operate on individual data rather than listing the vocabulary.

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 says to use this tool to build valid inputs for the other tools and to see which target browsers can be evaluated. This gives clear when-to-use context, but it does not name specific sibling alternatives or state when not to use it.

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 this as read-only and idempotent, so the safety profile is covered. The description adds behavioral detail by stating results are 'ranked matches' and enumerating exactly what each match includes, which goes beyond the structured annotations.

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 earning its place: purpose and scope, output contents, and handoff to the sibling tool. The most important decision signal, 'canonical key is unknown,' is front-loaded.

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?

The description is complete for a search tool with a rich output schema and fully documented parameters. It covers what the tool does, what it returns, and how to continue the workflow with browsercompat_get_feature, leaving no critical gap for an agent.

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 input schema already documents query, limit, baseline, and namespace. The description reinforces that query is a plain-language name or keyword, but it does not add meaningful parameter semantics 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 states a specific verb and resource: 'Find web features by plain name or keyword when the canonical key is unknown.' It clearly distinguishes itself from browsercompat_get_feature, which is the exact-key lookup, and lists the covered technology areas and return fields.

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 defines when to use this tool: when the canonical key is unknown. It also routes the caller to browsercompat_get_feature for the full record, giving a clear alternative action after search results are returned.

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