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 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 only give readOnlyHint and openWorldHint=false, so the description carries useful extra context: the map is served on the user's machine, needs no browser/web server setup, follows a file and redraws on change, and supports reusing a prior link to update an open page. This is genuinely behavioral detail beyond the structured fields.

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 purpose is front-loaded, but the phrasing is rambling ('no viewer page to write, no web server to start and no browser to open for them') and the final sentence restates the input modes already covered. Some sentences do not fully earn their 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?

For a 4-parameter, zero-required tool with a nested style object and no output schema, the description adequately covers all input modes and the live-reload/redraw semantics an agent needs. It is reasonably complete, though it omits any mention of the returned link's format or lifetime.

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 url, link, path, and style. The description's explanation of the link/style interaction largely restates the schema's own description for 'link', adding little syntax or format detail beyond it, 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 clearly states a specific verb+resource: it provides a link to an interactive map of a style, served locally by the server. This is distinguishable from rendering siblings, but no sibling tool (e.g., render_style, show_map) is named, so it falls short of a 5.

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 three input modes (file path, URL, style object) and the live-reload behavior, which implies usage, but it never states when to prefer this over render_style, show_map, or render_page. No explicit when-not-to-use guidance is given.

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, and the description adds real behavioral detail beyond them: it runs a headless browser, waits for window.map to finish loading before drawing, reports page errors/warnings/failed requests/camera, and returns what the script evaluates to. It does not cover timeout behavior or sandboxing of arbitrary page JS, which openWorldHint implies is relevant.

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 core action is front-loaded in the first clause, and the remaining sentences each add a distinct fact (outputs, input modes, window.map timing, script evaluation). Sentences are long and clause-heavy, but few words are wasted.

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: screenshot plus errors, warnings, failed requests, camera, and the script result. For a 5-parameter tool with a mutation-free but open-world execution model, it is close to complete, missing only timing/limit behavior.

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 60%, and the description compensates: it explains that path is served together with the files in its folder, that url points at a page (developer server), and that script runs before the screenshot and its evaluated value is returned. Only width/height are left implicit, which are self-evident from their names and bounds.

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 chain (loads a page in a headless browser, returns a screenshot) plus the secondary outputs (errors, warnings, failed requests, camera). It explicitly contrasts itself with a named sibling: 'which render_style leaves out since a style cannot hold them.' An agent can distinguish this from render_style without opening either schema.

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 names the alternative (render_style) and the condition selecting this tool: when you need plugins, controls and code that a style cannot hold. It also clarifies the two input modes (HTML file served with its folder, or a URL). It stops short of explicit when-not-to-use guidance or pointing at show_map / preview_style.

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 safety (readOnlyHint, openWorldHint), so the bar is lower; the description still adds real behavioral detail: it reports renderer notices such as style errors, failed requests, and missing fonts/icons, and it discloses the camera-fallback rule when center/zoom/bounds are absent. It stops short of describing output format or size limits, but the added context is substantive.

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-loads what the tool does, then layers usage context, camera fallback, and the 3D path. Dense but every sentence carries information; the only slight drag is the three-input-forms sentence, which is arguably covered by 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 13-parameter, no-output-schema tool, the description covers the key return information (diagnostics plus computed view parameters) and the main parameter interactions. Minor gaps remain around width/height/bearing/pitch guidance, but nothing critical to invoking 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 77% (high-ish), so the baseline is 3, and the description exceeds it by explaining the mutually exclusive camera paths: center/zoom/bounds vs. the style's stored camera, and the 3D case where cameraPosition plus lookAt are required and the result returns center/zoom/bearing/pitch to store back. It also notes the style input may be an object, URL, or file path.

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: 'Renders a MapLibre style to a PNG image'. It also clarifies the motivating use case ('so you can see what the style looks like'). It does not, however, distinguish itself from close siblings such as preview_style or show_map, which an agent would likely weigh against it.

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 implied context ('after changing it') and states the fallback rule when no camera params are supplied, which is useful selection guidance. But it never names an alternative or an exclusion, so the agent gets no explicit routing between this and preview_style/validate_style, whose domains overlap with the 'reports style errors' behavior.

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.