Loading ToolBench
Browser compatibility and Baseline status for any web feature — offline, from MDN's browser-compat-data, web-features, and caniuse. STDIO or Streamable HTTP.
Strong tool definitions with excellent naming, comprehensive descriptions, and well-structured schemas. All 4 tools follow verb_noun pattern (browsercompat_check_*, browsercompat_compare_*, browsercompat_get_*, browsercompat_list_*). Descriptions are detailed (150-250 chars), explaining WHAT, WHEN, and WHAT-RETURNS. Input schemas are complete with type constraints, minItems/maxItems, minLength/maxLength, and per-parameter descriptions. All parameters have descriptions explaining format and constraints. Output schemas are documented in descriptions. Error handling is present (invalid_feature_input, found: false with guidance). Minor gaps: no explicit per-tool error recovery guidance in descriptions, no confirmation pattern for destructive ops (though all tools are READ_ONLY), and output field documentation could be more formal.
Check whether web features are safe to ship: Baseline state and the date it crossed, the browser and version that limits support, whether the feature is deprecated or discouraged, and the share of tracked global traffic that requiring it would exclude. Accepts up to 20 BCD keys or web-features ids in one call.
Compute whether a set of web features clears an explicit browserslist target query. Returns a per-feature verdict, the target browser and version that fails, the share of tracked traffic the targets cover, and unchecked_targets for every resolved target browser with no compatibility data. A feature is never reported as clearing a target the server could not evaluate.
Get the compatibility record for one web feature: Baseline state and the date it crossed, deprecation and standards status, per-browser version added and removed with flags, vendor prefixes and partial-implementation notes, and the MDN and specification links. Accepts a BCD key such as css.selectors.has or a web-features id such as has; the response echoes which one it matched. An unresolved feature returns found: false with guidance rather than an error.
Enumerate the reference vocabulary this server uses: BCD namespaces, BCD browser ids, browserslist agent ids and their BCD counterparts, Baseline states, web-features groups, and ECMAScript snapshots. Use it to build valid inputs for the other tools and to see which target browsers can be evaluated.
Output schemas not formally documented in JSON Schema format. Descriptions mention what is returned (e.g., 'Baseline state and the date it crossed, the browser and version that limits support') but no structured output schema is visible in tool definitions.
No explicit error recovery guidance in tool descriptions. While errors are mentioned (invalid_feature_input, found: false), descriptions do not guide LLMs on next steps (e.g., 'If feature not found, call browsercompat_search_features first').
Parameter 'resolve' boolean lacks guidance on when to enable it. Description states 'Off by default so a typo returns a miss you can correct' but does not explain the performance or accuracy trade-off of enabling it.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
No pagination or result-limiting parameters visible in browsercompat_list_reference. If the reference vocabulary is large (104 groups, 11 snapshots), returning all items could bloat responses.
Tool descriptions do not explicitly state that all tools are READ_ONLY and safe to retry. While Risk: READ_ONLY is declared in metadata, LLMs benefit from explicit 'This tool does not modify state' language in descriptions.