Loading ToolBench
MCP-server for designsystemet-flutter — komponent-API, migrering og dokumentasjonssøk
Server provides 6 well-named, read-only tools with clear descriptions (avg 95 chars). All tools have input schemas with type definitions. However, parameter descriptions are minimal or absent in most tools, and output schemas are not documented. Error handling and recovery guidance are not visible in the provided code. Tool names follow verb_noun convention (lookup_, list_, get_, search_) which is strong. Composition is sound, each tool has a single responsibility. No security issues detected (read-only operations, no secrets in params). Baseline: 549 production tools average 194 chars for descriptions and 72 chars for params; this server averages ~95 chars for tool descriptions but lacks per-parameter documentation.
Get the Designsystemet equivalent of a Material Flutter widget, with property mapping and code examples.
Get theme setup instructions and configuration for Designsystemet Flutter.
List all available Designsystemet Flutter components with brief descriptions.
List all available design tokens (colors, typography, spacing, shadows, etc.) from the Designsystemet theme.
Look up a Designsystemet Flutter component by name, with full documentation, properties, and usage examples.
Search the Designsystemet Flutter documentation for topics, components, and guides.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing what each tool returns. Baseline: 100% of A+ tools have documented return types.
Parameter descriptions missing or minimal. 'component' param in lookup_component has description 'Component name, e.g. DsButton, DsTooltip' but lacks format constraints (length, case sensitivity, valid values). 'query' in search_docs has no description visible. Baseline: 100% of A+ tools have descriptions for every parameter.
No error handling or recovery guidance visible. If a component lookup fails or search returns no results, LLMs have no guidance on what to do next. Baseline: error responses must tell the LLM what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Tools with empty input schemas (list_components, get_theme_setup, list_tokens) lack pagination parameters. If results are large, no limit or offset mechanism is visible. Baseline: tools returning lists should accept page/offset and limit parameters.
Tool descriptions contain example values ('DsButton', 'DsTooltip', 'ElevatedButton', 'TextField'). LLMs tend to reuse examples literally rather than adapting to context. Baseline: do not put example values in descriptions; use parameter constraints instead.