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?

The annotations already mark it readOnly and openWorld; the description confirms a non-destructive read-and-check behavior. It adds value beyond the annotations by explaining that the tool lists per-source layers/fields and cross-checks layer references, and by clarifying accepted style inputs.

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 deliver the operation, the validation behavior, concrete use cases, and input forms without any filler. The main action and when-to-use guidance are 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 no required parameters and no output schema, the description gives enough to invoke it correctly: what it inspects, what it validates, when to call it, and the three supported inputs. It leaves open the exact return structure, but the stated behavior ('lists' and 'checks') covers the essential expectations.

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?

The input schema already describes all three parameters at 100% coverage. The description's 'object, a URL or a file path' maps cleanly to style/url/path, but it doesn't state that exactly one should be provided or define precedence, so it adds little beyond the schema baseline.

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 concrete operation—'Reads the metadata of every source'—and enumerates what it produces ('lists the source layers and fields') plus the validation it performs. This makes it easy to distinguish from siblings like describe_style_spec (spec-level) and validate_style (style-level), since the focus is squarely on sources and their data layers.

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 explicit triggers: use it 'before writing layers against data you do not know' and 'when a layer draws nothing.' It doesn't mention when not to use it or name alternatives, so it misses the top rung but provides solid contextual guidance.

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 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.