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

With no annotations, the description carries the full burden. It usefully discloses overwrite semantics ('or replace'), the visual grouping/drawing order, and the meaning of each clip mode; however it omits error behavior, whether the source file must be local/readable, and side effects on project/map state.

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 opening sentence states the action and placement, then shifts to a per-argument list where each line earns its place. Slightly list-heavy but no filler or repetition.

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 7-parameter mutation tool with zero annotations and no output schema, the parameter documentation is solid, but the description stops short of describing failure modes, persistence of the added layer, or what the agent should expect afterward.

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 0%, so the description must compensate, and it does: all seven parameters are explained, including the clip enum values ('shape' cuts to project polygon, 'extent' to map frame, 'none' keeps whole) and auto-detection behavior for field/label_field. Only 'path' is thin, lacking format or path-style guidance.

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 gives a specific verb+resource ('Add (or replace) a thematic layer, styled from the catalog') and adds concrete placement detail ('Capas temáticas' group, in drawing order). It is distinguishable from list_layer_types and remove_layer, but never explicitly names those siblings as boundaries.

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 establishes a prerequisite workflow by stating layer_type is a 'Key from list_layer_types', which tells the agent to enumerate types first. It gives clear usage context but no explicit when-not-to-use guidance (e.g., versus set_project_area or generate_map).

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?

With no annotations, the description carries the full burden and does so well: it discloses two side effects (clipped layers written to a GeoPackage, a .qgz project saved headless), the QGIS Layout Manager interaction gated on open_layout, and the internet dependency plus attribution requirement for basemaps. It stops short of stating whether an existing file at output_path is overwritten or whether parent directories are created.

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 one-line purpose, then side effects, then a compact Args block; each sentence carries information. The prose and the Args list slightly overlap on open_layout and basemap, but the size is proportionate to a 14-parameter 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 14-parameter tool with zero annotations, no output schema and no schema descriptions, the description covers outputs, side effects and half the parameters, which is decent. It is nonetheless incomplete: six parameters (dpi, grid, title, subtitle, labels, orientation) have no meaning conveyed anywhere, and no return value is described.

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 0%, so the description must compensate, and it documents roughly half the parameters (output_path format with example, layers, page_size values, extent modes, margin_percent units, sources, basemap options and their providers). dpi, grid, title, subtitle, labels and orientation are left entirely to the bare schema titles, so the gap is only partially filled.

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 opening sentence gives a specific verb and resource ('Render one map sheet'), names the four output formats and how they are selected (by extension), and scopes it to the project shape. The singularity implied by 'one map sheet' distinguishes it from the generate_map_series sibling, though that contrast is never made explicit.

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?

Usage is implied rather than stated: the agent learns that basemap 'Needs internet' and that open_layout=true opens the sheet in the Layout Manager. However, there is no explicit guidance on when to prefer this tool over generate_map_series or when the output would be inappropriate (e.g. no layers added).

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?

With no annotations and no output schema, the description carries full burden. It does disclose useful behavior: output files are numbered by drawing order, each sheet is registered in the QGIS Layout Manager, and basemap tiles require internet. It omits overwrite behavior, file naming, runtime cost, and what is returned on success.

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 lead sentence is front-loaded with the core behavior, followed by a tight, example-driven Args list with no filler. The QGIS Layout Manager sentence is arguably secondary but still earns its place by explaining a side effect.

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 9-parameter generation tool with no annotations and no output schema, the description covers purpose and roughly half the parameters. Missing are defaults for output formatting (dpi, format, page_size, orientation) and the meaning of 'sources', leaving real gaps an agent must guess at.

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 0%, so the description must compensate and it only partially does: it explains output_dir (numbered by drawing order), layers (defaults to all added layers), context_layers (with a concrete example) and basemap (the three allowed values plus an internet caveat). Five of nine parameters — dpi, format, sources, page_size, orientation — get no semantic explanation anywhere.

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 ('Render one map per thematic layer') and clarifies the unit of output (a series, one sheet per layer), which implicitly distinguishes it from the single-map sibling generate_map. It does not explicitly name that sibling or state the boundary, 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?

The 'one map per thematic layer' phrasing implies this is the batch/multi-layer variant versus generate_map, and the context_layers/basemap args hint at cartographic reuse, but the description never states when to pick this tool over generate_map, nor any prerequisites other than internet for basemaps.

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?

No annotations are provided, so the description carries the full burden. "Show" implies a non-mutating read, and it discloses the categories of state returned, which is useful. However, it says nothing about failure behavior (empty/unset map), permissions, or whether the returned state is cached or live.

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?

A single short sentence with no filler, front-loaded on the verb and the returned content. Every clause earns its 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?

With no output schema and no annotations, the description is the only source of information, and it does list the three things returned, which is adequate for a zero-arg getter. It stops short of describing the return structure, error conditions, or when the call is worthwhile, leaving clear gaps for a tool that is the only way to inspect current map state.

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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter meaning is lost.

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?

Specific verb ("Show") plus a named resource ("map state") and an enumeration of what is returned: project shape, output CRS, and layers added so far. That clearly separates it from mutating siblings like add_layer or reset_map, though it never names an alternative explicitly.

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?

There is no when-to-use guidance, no statement of preconditions (e.g., that a project area must be set first), and no reference to siblings such as list_layer_types or inspect_dataset. Usage is only implied by the verb "Show".

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the returned content (CRS, extent, geometry, fields, sample values), which implies a read-only inspection, but it never confirms the operation is side-effect free, says nothing about supported formats, or how a missing/invalid path is handled.

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?

A single sentence with zero wasted words, front-loading the verb and resource and then listing the concrete outputs. Nothing is redundant or padded.

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 and no annotations, the description does well to enumerate the returned fields, which is the key return-value information. However, it omits error behavior, supported data formats, and any workflow context, leaving gaps for a tool that reads external files.

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 0% and the single `path` parameter has no description in the schema. The phrase "a vector or raster file" hints that `path` is a file path rather than a layer name and constrains the accepted inputs, but no format, relative-vs-absolute, or extension guidance is given.

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 gives a specific verb ("Describe") and resource ("a vector or raster file"), and it enumerates the exact outputs (CRS, extent, geometry, fields, sample values). It doesn't name or differentiate from siblings, but the sibling set (map/layer mutation and generation tools) is functionally distant, so disambiguation is barely needed.

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?

There is no when-to-use guidance, no mention of prerequisites (e.g. the file must exist on disk), and no explicit alternative tool. The implied workflow of inspecting a dataset before adding it as a layer is inferable from the sibling `add_layer`, but the description never states 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?

No annotations are provided, so the description carries the burden, but for a zero-parameter read-only list the risk surface is minimal. It discloses the per-entry fields (key, title, default fields), which is useful, yet says nothing about ordering, completeness, or whether the set is static — an output schema exists, which lowers the bar.

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?

A single front-loaded sentence with zero filler. The verb and resource lead, and the parenthetical detail is compact.

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 trivial, parameterless read tool with an output schema, the description is close to sufficient — it identifies the resource and the shape of each entry. It stops short of stating when the list should be consulted relative to add_layer.

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 tool takes no parameters, so there is no parameter semantics to explain; baseline 4 applies. The parenthetical field list is the closest thing to parameter context and is consistent with 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?

States a specific verb ('List') and resource ('thematic layers this server can style'), so the agent knows exactly what is returned. It is distinguishable from mutation siblings like add_layer/remove_layer, though it does not explicitly contrast with discovery siblings such as get_map_state.

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 no when-to-use guidance, no prerequisites, and names no alternatives. It is only weakly implied that this is a lookup to consult before add_layer; the text itself offers nothing.

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?

No annotations exist, so the description carries the burden, but for a zero-parameter probe the risk surface is minimal. It discloses that it reports a version, implying a safe read, but does not state what happens on failure or the exact response shape.

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?

A single front-loaded sentence with zero waste, stating both the action and the expected output.

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 trivial connectivity probe with no params and no output schema, the description says enough: it checks liveness and returns version info. Minor gaps around failure behavior, but nothing essential 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?

The tool takes zero parameters, so the baseline is 4. There is nothing to document and the description correctly implies a no-argument call.

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 gives a specific verb+resource ('Check that QGIS answers') plus a return hint ('report its version'), which is more than a tautology. It doesn't differentiate itself from siblings, though the uniqueness of the name makes confusion unlikely.

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?

Usage is implied: this is a connectivity/health-check tool to confirm QGIS is responsive before other operations. No explicit when-to-use, when-not-to-use, or named alternatives are provided.

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?

No annotations are provided, so the description carries the full disclosure burden for a mutation tool. It implies removal but says nothing about reversibility, error behavior for an unknown layer_type, or what happens if the layer is absent. That is a substantial 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?

A single tight sentence with no filler and the action front-loaded. It is efficient, though its brevity reflects under-specification rather than disciplined economy.

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 mutation tool with no annotations, no output schema, and an undocumented parameter, the description leaves too much unsaid: side effects, failure modes, and how to obtain a valid layer_type are all 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 0% and the description never mentions the single required parameter layer_type, nor that valid values come from list_layer_types. The description adds no meaning beyond the bare property name 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?

States a specific verb and resource: 'Remove a thematic layer from the map.' An agent can distinguish this from add_layer by the verb alone. It does not, however, name or contrast with any sibling explicitly, so it stops 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?

No guidance on when to use this versus reset_map (which presumably removes all layers) or get_map_state to verify current layers. No mention of prerequisites such as needing a valid layer_type from list_layer_types.

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?

With no annotations, the description carries the full burden. It does disclose the destructive scope ('every layer added so far'), which is the most important behavioral fact. However, it omits irreversibility (no undo), whether the project area/state is also cleared, or whether any confirmation is expected – gaps left open by the absence of 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?

A single short sentence that front-loads the destructive scope. No filler, nothing redundant, immediately actionable.

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 zero-parameter destructive tool with no annotations and no output schema, the description covers what it clears but not the operational context an agent needs: reversibility, what state remains afterward (e.g., does it affect the project area?), or expected follow-up calls. Adequate but with clear 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?

The tool takes zero parameters and the schema is fully covered, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter tool; the description adds no misleading parameter implications.

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 action (forget/reset) and its scope – the project shape and all layers added so far. This clearly separates it from siblings like remove_layer, add_layer, or get_map_state, which operate on individual layers or read state. The only weakness is the informal verb 'forget' and the slightly fuzzy term 'project shape' instead of 'reset'/'map state'.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives – notably remove_layer, which also removes layers but one at a time. An agent must infer that this is the wholesale reset path rather than reading 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?

With no annotations, the description carries the full burden and does disclose visible side effects: the layer is added on top as a red outline and the canvas zooms to it. It does not say whether an existing project area is replaced/destroyed or what permissions are required, leaving a real gap for a mutation tool.

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 front-loaded sentences capture purpose plus visual behavior, followed by a tight Args block with no filler. Every line earns its 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 four-parameter, no-annotation, no-output-schema tool, the description covers parameters and UI side effects well. It stops short of describing replace/overwrite semantics on repeat calls, which is the one behavior an agent might need to reason about.

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 0%, so the description must compensate and does: it documents all four parameters with concrete formats and defaults — file extensions for path, default-to-filename for name, an EPSG example for crs, and a literal filter expression for subset.

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 ('Set the project shape (polygon layer)') and clarifies scope: this is the base geometry 'every map is built on', which separates it from a generic add_layer sibling. An agent can tell what this does without opening the 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?

Usage context is implied rather than stated — the description makes clear this defines the base area of the project, but it never says when to call it versus add_layer, nor whether it should be set before generate_map. No alternatives or exclusions are named.

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