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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the output layout (before, after, and differences in red), the fixed-camera condition, and the flexible style input forms (object, URL, or file path). This is richer than simply restating annotation signals.

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 with no filler: the first states the core behavior and output, the second gives the intended use case and input formats. Every clause earns its place, and the most important 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 10 parameters, nested objects, and no output schema, the description covers the essential return value (one image with before/after/differences), the invocation context, and the accepted style representations. Parameter defaults and constraints are already in the schema, so nothing critical is missing for an agent to call it 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 coverage is high at 80%, and the schema already documents each parameter with descriptions. The description adds value by summarizing how to supply styles ('Pass each style as an object, a URL or a file path') and by implying that center/zoom/bounds/bearing/pitch are shared across both renders via 'at the same camera.' This compensates for the remaining undocumented parameters.

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 precise verb and resource: it renders two MapLibre style versions at the same camera and returns an image showing before, after, and differences in red. This inherently distinguishes it from siblings like render_style (single render) and validate_style (validation), even without naming them. The output artifact is also specified, leaving no ambiguity about what the tool accomplishes.

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 for when to use the tool: 'Use it after changing a style, to check that the change did what you meant and nothing else, at a few places and zoom levels.' It does not explicitly mention when not to use it or name alternative tools, but the guidance is concrete and actionable for an agent deciding to invoke 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 only declare readOnlyHint and openWorldHint; the description adds substantial behavior: it reads vector tiles and GeoJSON at the place, enumerates the failure causes it detects (hidden, out of zoom, missing source-layer, filter match, fill geometry, opacity/width/size/color, sprite icons), and flags GL JS vs MapLibre Native text differences from missing glyphs.

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?

Front-loaded with the core purpose and dense with useful detail, but the second sentence is a long run-on list of causes that could be trimmed or split for faster scanning.

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 return-value burden and does so by describing the per-layer verdict and reasons reported, and the GL JS/MapLibre text caveat. An agent has enough to call it 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 coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema by clarifying that the style may be supplied as an object, a URL, or a file path (i.e., the style/url/path params are alternatives), and that the data is read 'at the place'.

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: reports, per style layer, whether it draws anything at a place/zoom and the reason when it does not. It enumerates the diagnostic categories, making it clearly distinct from siblings like validate_style or inspect_tile.

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 explicit triggering context ('Use it when a layer draws nothing') and the input forms to pass. It does not name an alternative sibling such as inspect_tile for the case where a layer draws something unexpected, so it stops short of full when/when-not routing.

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 and openWorldHint, so safety is already covered. The description adds meaningful behavior beyond that: results are scoped to a GL JS version, non-default versions are fetched from jsDelivr, and the return content (signature, documentation, parameters, default, examples, class/options members) is disclosed. It does not discuss latency or failure modes of the remote fetch, which is a minor gap.

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 with no filler: purpose and accepted key formats first, then what is returned, then version scoping and the Mapbox caveat. The example keys are load-bearing disambiguation rather than padding.

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 return-value burden and does so explicitly. It covers lookup targets, return payload, versioning behavior, and the primary risk (assuming Mapbox-only APIs exist in MapLibre), leaving nothing an agent needs to invoke it 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 coverage is 100%, so the schema already documents both parameters and the baseline is 3. The description goes further by showing accepted name shapes ("Map", "Map#flyTo", "MapOptions.maxPitch", "click", "addProtocol") and clarifying that version may be a range like "5" or a point release, plus what the default resolves to.

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 (looks up) and a precise resource (class, method, option, event, or function of MapLibre GL JS), reinforced by concrete example keys like "Map#flyTo" and "MapOptions.maxPitch". It is clearly distinguishable from sibling tools such as describe_style_spec or describe_sources, which cover style/source spec material rather than the GL JS API surface.

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 the agent to check here before using a method or option whose existence is uncertain, and explains the Mapbox-vs-MapLibre divergence as the reason. It also explains version selection (server version by default, or a project's version). It stops short of naming a sibling tool as an alternative, so it is clear context rather than a full when/when-not/alternatives statement.

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 readOnlyHint=true, and the description consistently describes read-only actions ('Reads', 'checks'). It adds context beyond annotations by detailing the verification step and the input flexibility (object, URL, path). No contradiction with 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?

The description is about four sentences and contains no filler. It front-loads the core function, then usage guidance, alternatives, and input methods. It could be slightly tighter but each sentence contributes essential 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?

For a read-only inspection tool with no output schema, the description covers purpose, when to use, alternatives, and input methods. It implies the output (lists and checks) well enough for an agent to understand what to expect. 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?

Schema coverage is 100% with each parameter described, so baseline is 3. The description adds value by clarifying that the three parameters are alternative ways to pass the style ('as an object, a URL or a file path'), which is not explicitly stated in 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 clearly states the tool reads metadata of every source, lists source layers and fields, and checks layer-source consistency. It distinguishes itself from siblings by explicitly naming inspect_tile and debug_layers and explaining their different purposes.

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 'Use it before writing layers against data you do not know,' providing a clear when-to-use condition. It also mentions alternatives (inspect_tile, debug_layers) and what each does, enabling correct tool selection.

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 aligns with that by describing a lookup operation with no side effects. Beyond the annotation, it discloses what the tool returns (documentation, type, default, allowed values, expression support, version support) and the Mapbox/MapLibre nuance, which gives the agent a fuller picture of behavior without contradicting the provided metadata.

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 no filler. It front-loads the core purpose, then quickly enumerates the accepted name categories with examples, and closes with a practical usage tip. Every sentence contributes value: purpose, scope of inputs, and the Mapbox caveat. This is well-structured and appropriately sized for a simple lookup tool.

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 one-parameter lookup tool with no output schema, the description is complete. It covers what kinds of names are accepted, what information is returned, and includes the key caution about MapLibre vs Mapbox. Given the tool's simplicity and the annotations providing the read-only safety profile, nothing essential for an agent to call it 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 coverage is 100% and the parameter 'name' already has a description ('The name to look up.'). The description adds meaningful context by listing concrete examples of valid values (e.g., 'fill', 'fill-extrusion-height', 'geojson', 'interpolate') and clarifying that these encompass layer types, properties, source types, and expression operators. This goes beyond the schema's generic description and helps the agent format the 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 clearly states the action ('looks up a name') and the specific resource ('MapLibre Style Specification'), enumerating the exact types of names it handles (layer types, properties, source types, expression operators). It also distinguishes itself from sibling tools by noting it returns documentation and version support, and explicitly contrasts MapLibre with Mapbox, which signals its unique scope among the listed siblings.

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 a clear usage directive: 'Check here before using a property you are not sure exists in MapLibre' and explains the reasoning (Mapbox has properties MapLibre does not). This tells the agent when to invoke it. It doesn't explicitly name alternatives to avoid, but given the tool's niche nature and the specific trigger, the guidance is sufficient for correct selection.

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 idempotentHint=true and destructiveHint=false, and the description adds important behavioral context: formatting in place modifies the file, while passing a style object or URL returns formatted JSON. It also clarifies the exact formatting style (specification order, two-space indentation). The description does not contradict annotations; it complements them with mode-specific behavior.

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 a single, well-structured sentence that front-loads the core function and then clarifies the two modes. Every clause earns its place, and there is no redundant or vague wording.

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 formatting tool with no output schema, the description adequately explains what happens in each mode. It could be more complete by noting whether the URL input is fetched and formatted in memory or written back, and whether the style object is mutated. However, given the tool's simplicity and the annotations covering idempotency and non-destructiveness, the description is largely sufficient.

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 documents all three parameters (url, path, style). The description adds the key behavioral distinction between path (in-place) and the other inputs (returned JSON), which is valuable. However, it does not explain how the three parameters interact (e.g., mutual exclusivity or precedence), so the description adds only moderate value 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 clearly states the tool's function: it formats a MapLibre style with keys in specification order and two-space indentation, matching gl-style-format. It also distinguishes the two modes of operation (in-place file formatting vs. returning formatted JSON), which makes the purpose unambiguous and differentiates it from sibling tools like validate_style or render_style.

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 explains the two usage modes: if a file path is given, the file is formatted in place; otherwise, the formatted JSON is returned. This gives clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives among siblings, so it falls just short of a 5.

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 and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: it explains the dual source-resolution model (style source id vs. a TileJSON/PMTiles/tile URL), discloses supported formats (MVT and MLT), and notes it reports metadata layers that the tile lacks — a non-obvious diagnostic behavior.

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?

Roughly four sentences, front-loaded with the what-then-what-you-get, then usage, then source resolution, then formats. Dense but every clause carries information. Minor redundancy between the return-value sentence and the param semantics of 'source', which slightly dilutes sharpness.

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 correctly carries the full burden of explaining the return shape, and does so thoroughly (layer list, feature counts, geometry types, field values, examples, zoom range, missing layers). All eight parameters are documented in the schema, and the non-obvious 'source' semantics are covered in prose. Nothing an agent needs to invoke it correctly is absent.

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 adds genuine meaning on top by clarifying that 'source' accepts either a style source id or a vector-source URL and naming the concrete URL forms (TileJSON, PMTiles, {z}/{x}/{y}), which the schema's brief 'id of a source in the style, or the URL' does not fully spell out.

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 ('Reads the vector tile of a source at a place and zoom') and then enumerates exactly what it returns — source layers, feature counts, geometry types, field values, examples, and the source's zoom range. This is detailed enough to distinguish it from siblings like describe_sources and debug_layers, which operate at a different level.

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 states the motivating context: 'Use it to learn the values data really has, like the classes of roads, before writing filters and expressions.' That is a concrete when-to-use. It stops short of naming which sibling to use instead when the agent only wants metadata or validation, so it lacks the explicit alternative-routing of a 5.

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 cover the safety profile (readOnly=false, idempotent=true, destructive=false). The description adds meaningful behavioral context beyond those annotations: file-path styles are migrated in place while others return migrated JSON, and it specifies what the migration actually changes. No contradiction with 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 with no filler. The core operation, transformation details, and side-effect behavior are all present and front-loaded, with no redundant restatement of the title or schema.

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 three optional parameters and no output schema, the description covers the input modes, the transformation scope, and the return behavior. It lacks only minor details such as error handling and explicit mutual exclusivity of parameters, but is otherwise sufficient for an agent to invoke it 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 schema already documents all three parameters. The description adds the important behavioral distinction between path-based in-place migration and other inputs returning JSON, but this is behavioral rather than parametric; the baseline 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 states a specific verb and resource: 'Migrates an old style to the current MapLibre Style Specification.' It adds concrete transformation details (v7 to v8, legacy functions/filters to expressions) and names gl-style-migrate, making its scope clear and distinguishing it from siblings such as format_style and validate_style.

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 for when the tool is used—migrating old styles—and explains the path vs. non-path behavior. However, it does not explicitly say when not to use it or name alternatives, leaving the agent to infer from sibling names rather than being directed.

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 and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavioral context by stating the tool also 'reports what the renderer noticed, such as style errors, failed requests and missing icons', plus the fallback-to-style-camera behavior.

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, front-loaded with the primary purpose, then the extra output, then input variations and default behavior. Every sentence earns its place with no wasted words.

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 an 11-parameter tool with no output schema, the description covers what the tool produces (PNG, plus renderer observations) and how to provide input. It does not spell out where the PNG is returned or saved, but that is partially implied and not critical for initial 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?

With 73% schema coverage, the schema already documents most parameters. The description adds meaningful grouping ('Pass the style as an object, a URL or a file path') and clarifies the interaction between camera parameters and the style's stored camera, which is information not present in 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 names a specific verb and resource: 'Renders a MapLibre style to a PNG image', with a concrete use case ('see what the style looks like, for example after changing it'). This clearly separates it from validation/spec/comparison siblings, even if show_map overlaps slightly.

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 clear context for when to use the tool ('after changing it') and explains the camera fallback behavior. It does not explicitly name alternatives or exclusion conditions, but the intended use is clear enough to guide selection.

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 readOnlyHint=true, and the description adds important context beyond that: the user sees the map while the agent does not, and the map auto-fits layers and markers without center/zoom. It also notes the client requirement, which is useful operational context. No contradiction with 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?

The description is four concise sentences with no wasted words. The core purpose is front-loaded, followed by the critical user-versus-agent caveat, the alternative tool, auto-fit behavior, and the client requirement.

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 display-only tool with zero required parameters, the description covers the essential operational details: what the user sees, what the agent cannot see, the alternative for self-inspection, auto-fit behavior, and client compatibility. The schema handles the parameter specifics, so nothing critical 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 low at 29%, so the description partially compensates by clarifying the interaction between center/zoom and layer auto-fitting. It also confirms layers and markers are GeoJSON-based. However, it does not add meaning for pitch, bearing, or basemap behavior beyond what the schema already provides, so the compensation is incomplete.

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: showing an interactive MapLibre map with GeoJSON layers and markers on an OpenFreeMap basemap. It also distinguishes itself from the sibling render_style by clarifying that the map is for the user, not for the agent.

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 tells the agent when to use this tool versus an alternative: 'to look at a map yourself, use render_style.' It also adds a practical prerequisite, 'Needs a client that supports MCP Apps,' and explains the auto-fit behavior when center and zoom are omitted.

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 and openWorldHint=true, so the description doesn't need to repeat those. It adds useful behavioral context about the output format ('lists every problem, each with the path to the property'), which goes beyond the annotations. It doesn't mention any limitations or side effects, but given the read-only nature and the output schema, this is sufficient.

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 with no filler. The first sentence states the core purpose and output, and the second gives usage guidance and input options. Every sentence earns its place, and the most important information is front-loaded. It is appropriately sized for the tool's complexity.

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, full schema coverage, an output schema (which explains return values), and annotations covering read-only behavior, the description is complete. It covers purpose, usage trigger, and input options. It doesn't mention version-specific validation or potential limitations, but these are not critical for an agent to call the tool correctly. The output schema handles return details.

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 each parameter (url, path, style) is already documented in the schema. The description adds a high-level summary ('Pass the style as an object, a URL or a file path') that maps to the three parameters, but doesn't provide any additional semantics beyond what the schema already offers. This meets the baseline for high coverage.

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 ('Checks'), a specific resource ('MapLibre style'), and the standard it validates against ('MapLibre Style Specification'). It also clarifies the output ('lists every problem, each with the path to the property'), which distinguishes it from sibling tools like render_style or compare_styles. An agent can immediately understand what this tool does and how it differs from others.

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 provides clear usage context: 'Run it after editing a style.' This tells the agent when to invoke it. It does not explicitly mention alternatives or exclusions, but the trigger is specific enough. Sibling tools have distinct purposes, so the lack of explicit 'when not to use' is acceptable given the clear context.

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