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

With no annotations, the description carries the full burden. It discloses the type values and the provider fallback, but says nothing about duplicate-layer handling, permissions, whether the layer is registered in the current project, or failure behavior for an unreadable path.

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?

Short and front-loaded, but the trailing Georgian translation ('/ ფენის დამატება') is pure duplication that earns no space and adds no semantics.

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?

A 4-parameter mutation tool with no annotations, no output schema, and 0% schema coverage should do considerably more. Nothing tells the agent what state changes or what the return looks like after adding a 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?

Schema coverage is 0% across 4 params, so the description must compensate. It does add value by enumerating type values ('vector'/'raster') that are absent from the schema and by stating the ogr/gdal provider fallback, but leaves 'name' and 'path' completely bare.

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 ('Add a layer from a file/URI'), which clearly separates it from siblings like remove_layer and list_layers. It does not explicitly name any sibling, but the action is unambiguous.

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 (e.g. load_project or headless_command for loading data). Usage must be inferred purely from the verb.

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, but it does disclose real behavior: supported formats (png/jpg) and that extent is interpreted in project CRS with a canvas default. It omits whether the file is overwritten, whether the project must be loaded/GUI open, and what the tool returns.

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 and short, with the key constraint (extent format) placed after the primary purpose. However, the trailing Georgian translation ' / რუკის ექსპორტი.' merely restates the purpose and earns no place for an agent consuming the definition.

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 file-writing tool with no annotations and no output schema, the description covers purpose and extent semantics but is silent on the write side effects (file creation/overwrite at path) and on the return value, leaving gaps an agent would have to discover empirically.

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. It does explain the one non-obvious parameter well ('extent=[xmin,ymin,xmax,ymax] in project CRS; default = canvas'), which adds real meaning beyond the bare anyOf array, but path, width and height remain entirely unexplained (path format/location especially).

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 the map to an image (png/jpg)'. No sibling tool performs map exporting (run_pyqgis and headless_command are generic execution paths), so the agent can identify it without ambiguity.

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 notes that extent defaults to the canvas, which is a useful behavioral default, but it gives no when-to-use guidance and never contrasts itself with the generic run_pyqgis or headless_command siblings that could also produce output files.

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 says 'headlessly' but discloses nothing about execution duration, whether the algorithm runs on the current project state, error behavior for invalid algorithm IDs, or what is returned when an output schema is absent.

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 English sentence is tight and front-loaded, but the trailing Georgian fragment 'Processing ალგორითმი' adds no information and appears to be a truncated duplicate, diluting an otherwise efficient description.

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 whose core input is an arbitrary parameters dict and which has no output schema or annotations, the description is not complete enough: an agent gets no guidance on constructing the dict or on interpreting results.

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% across both parameters. The description compensates only for 'algorithm' by giving the example 'native:buffer'; the 'parameters' dict is a free-form nested object with additionalProperties=true and receives no explanation of expected keys or value formats.

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: run a QGIS Processing algorithm headlessly, with a concrete example ('native:buffer'). However it does not distinguish itself from the sibling headless_command or headless_list_algorithms, which an agent must choose between.

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 statement of when to use this versus headless_command (which presumably runs arbitrary code/commands) or headless_list_algorithms (to discover algorithm IDs). No prerequisites or context given; usage must be inferred entirely from the name.

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. It does disclose two real behavioral traits: passing `project` loads a .qgz first, and save=True writes changes back to disk (an implicit mutation/persistence signal). It says nothing about error behavior, permissions, or that arbitrary commands may be destructive, so the disclosure is partial for a no-annotation 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?

The core is two tight, front-loaded sentences leading with the capability and the persistence semantics. The trailing Georgian sentence duplicates 'without the GUI' and adds no information for most agents, but the overall size is small and the important content comes first.

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 dispatcher with a free-form `params` object, no typed enum, and no output schema, the agent is left guessing the shape of `params` for each command and what is returned. The description aids discovery with an (open-ended '...') example list and covers persistence, but does not say how to enumerate the full command set or where per-command parameter shapes are documented.

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% for 4 parameters, so the description must compensate. It explains `project` (loads a .qgz first) and `save` (writes changes back), and implicitly defines `command` via the example list, but `params` — the argument dict passed to the chosen sub-command — is entirely undocumented, which is the most consequential gap for correct invocation.

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+resource ('run any command ... WITHOUT the QGIS GUI') and names concrete example commands (list_layers, layer_info, add_layer, export_map, run_pyqgis) that double as pointers to sibling tools, so an agent can see this is a GUI-less dispatcher. It stops short of explicitly framing the relationship to those siblings as alternatives, which keeps it from 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 'WITHOUT the QGIS GUI' phrasing implies the usage context (no GUI session available), and 'Pass `project` to load a .qgz first' gives a concrete prerequisite. However there is no explicit guidance on when to prefer headless_command over the sibling list_layers/add_layer/etc., or over headless_algorithm and headless_list_algorithms, which is the main routing decision an agent faces.

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 whole burden. 'List' implies a read-only operation, but nothing is said about output size, pagination, whether the catalog is cached, or what happens with a limit of 100 by default.

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 English sentence is short and front-loaded, but the appended Georgian translation 'ალგორითმების სია' is pure duplication that adds no information for an agent selecting the 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 catalog-listing tool with no annotations, no output schema, and 0% parameter coverage, the description should at minimum explain pagination/limit behavior and the shape of results; it does neither.

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. It explains 'filter' as a text filter but says nothing about 'limit', its default of 100, or how the two interact, leaving half the parameters undocumented.

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 ('List Processing algorithms via qgis_process'), which is clearly distinguishable from the sibling headless_algorithm that runs a single algorithm. It does not explicitly name that sibling, 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?

Only 'optionally filtered by text' hints at usage; there is no guidance on when to choose this over headless_algorithm, headless_command, or qgis_status, and no prerequisites or exclusions are 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?

No annotations are provided, so the description carries the full burden. It discloses the substance of the result (fields, feature count, geometry, raster size), which is meaningful since there is no output schema, but it never states that the operation is a read-only lookup or what happens if the id/name is not found.

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?

One front-loaded sentence that names the resource, the identifier options, and the returned fields with no filler. The appended Georgian translation is redundant for the primary audience but costs little.

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 low-complexity, single-parameter read tool with no output schema, the description covers the essentials, including the shape of the returned data. Only the read-only nature and error behavior are left unstated.

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% for the single 'layer' parameter, so the description must compensate. It does add useful meaning by stating the parameter accepts either an id or a name, but gives no format expectations, case sensitivity, or failure behavior for unmatched values.

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 resource and what is retrieved: details of one layer identified by id or name, including fields, feature count, geometry and raster size. The singular 'one layer' implicitly distinguishes it from the sibling list_layers, though that distinction is not 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?

No guidance on when to use this versus list_layers, project_info, or qgis_status. It does not state prerequisites (e.g. that a project/layer must be loaded) or when this tool is the wrong choice; the agent must infer usage entirely.

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 behavioral burden. 'List' implies a non-mutating read and the parenthetical discloses exactly which attributes come back, which is genuinely useful given there is no output schema. It says nothing about scoping limits (all layers vs. visible only) or result size, leaving gaps.

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 English sentence is short, front-loaded, and wastes nothing. The appended Georgian translation is redundant for an agent and slightly dilutes the density, which keeps it off a 5.

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 compensates by naming the returned fields and the implicit scope (the open project). It is complete enough to call correctly, though the absence of any relationship to layer_info or add_layer/remove_layer leaves the layer-tool cluster under-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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly signals there is nothing to configure by scoping the call to 'the open project'.

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 ('List layers of the open project') and enumerates the returned fields, so an agent immediately knows what it gets. It does not distinguish itself from the close sibling layer_info, which also concerns layers, 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?

There is no when-to-use guidance, no statement of when not to use it, and no pointer to alternatives such as layer_info for per-layer detail. The agent must infer from the name alone that this is the bulk-enumeration option.

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 disclosure burden. It reveals the accepted file formats (.qgz/.qgs) but says nothing about what loading does to the currently open project, error behavior for a missing/invalid path, or any permission requirements.

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?

Very short and front-loaded with the action and accepted formats. The bilingual duplication of the same sentence adds a redundant line, though it is a localization choice 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?

For a state-mutating tool with no annotations, no output schema, and an undescribed required parameter, the definition is thin. It omits the side effects of loading a project and error handling, which an agent would need to call this safely.

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% for the single 'path' parameter, but the description partially compensates by implying the path points to a .qgz/.qgs project file. It adds format meaning but no syntax, absolute-vs-relative, or path-resolution details.

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 (Open) and resource (.qgz/.qgs project), which is unambiguous and distinguishable from save_project and project_info by the verb alone. It does not explicitly name or contrast with any sibling, but the action is clear.

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 alternatives such as project_info or save_project, and no prerequisites stated. The agent must infer usage entirely from the name.

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. It does disclose the return content (file, title, CRS, layer count), which is the primary behavioral trait for a parameterless read. It does not explicitly state that it is read-only, side-effect free, or requires a loaded project, leaving minor gaps.

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 covering the resource and its return fields. The appended Georgian translation is redundant for most agents and slightly dilutes the signal, but the entry remains very short.

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?

No output schema, so the description's enumeration of returned fields is exactly the compensation needed, and no annotations or params exist to leave undocumented. Only the silence on prerequisites (a loaded project) and sibling boundaries keeps it from being fully complete.

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?

Zero parameters, so there is nothing to document; baseline 4 applies. The description correctly adds no parameter noise.

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 resource (the current project) and enumerates the returned fields: file, title, CRS, layer count. An agent immediately knows this is a read of project-level metadata. It does not, however, distinguish itself from siblings like qgis_status or layer_info, which could confuse selection.

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 at all: the description never says to call this before export/save, nor distinguishes it from qgis_status (overall app status) or layer_info (single-layer metadata). The agent must infer the boundary from the name alone.

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 supplied, so the description carries the full burden. It does disclose the response content (version and project) and implies a non-mutating connectivity probe, but it says nothing about failure behavior when the plugin is unreachable, authentication needs, or any side effects.

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 English sentence is front-loaded and wastes no words. The duplicated Georgian line adds no information for most agents, but it is short and does not bury the core statement.

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 status tool with no output schema, the description adequately states what is returned. It is incomplete about the not-connected case and about how its result relates to sibling tools, leaving the agent to infer error-handling 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter confusion is possible.

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 ('Check the connection to the QGIS plugin') plus what it returns (QGIS version and project), so the purpose is unambiguous. It does not, however, distinguish itself from the sibling project_info, which plausibly overlaps with the 'return project' portion.

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 statement of when to call this versus alternatives such as project_info, nor a prerequisite like 'call before run_pyqgis to confirm connectivity'. A health-check tool's usage is somewhat self-evident, but the description provides no explicit routing 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 are absent, so the description carries the full behavioral burden. It implies destruction but says nothing about irreversibility, whether unsaved edits are discarded, what happens if the id/name matches nothing, or whether save_project is needed afterward.

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?

Short and front-loaded with the action first, which is good. However, the Georgian sentence restates the same content verbatim with slight added meaning ("from the project"), making it duplicative rather than additive for most readers.

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 destructive, un-annotated tool with no output schema, the description omits failure behavior, side effects on dependent layers, and required follow-up steps. Only the identifier forms are covered.

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 single parameter has 0% schema description coverage, so the description must compensate. It does add the useful fact that the identifier may be an id or a name, but gives no format, exact-match, or case-sensitivity guidance for either form.

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 layer") and identifies the accepted identifier forms. It is implicitly distinguishable from siblings like add_layer and list_layers, though it never names a sibling or the scope (project-level removal is only in the Georgian line).

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 list_layers/layer_info to resolve a layer first, nor any note about when removal is inappropriate. Usage must be inferred entirely from the name.

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 full burden. It usefully discloses the execution output contract (print output returned, assign to `result`) and the injected variables (iface, project, QgsProject, qgis), but says nothing about the fact that arbitrary code runs unsandboxed with write access to the live session and project data.

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 tight sentences with the essential scope statement front-loaded. The appended Georgian translation duplicates the same content without adding meaning, which is the only wasted space.

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-param arbitrary-code-execution tool with no annotations and no output schema, the description covers the variable environment and return mechanism but leaves out side-effect and safety context. Adequate but with a clear gap given the tool's risk profile.

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 single `code` parameter is undocumented in the schema. The description partially compensates by explaining which variables are in scope and how to return a value, which genuinely clarifies what to put in `code`, but omits format or length constraints.

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 — execute PyQGIS code — and scopes it to 'the running QGIS session', which implicitly separates it from the headless_command and headless_algorithm siblings. It stops short of naming those alternatives, so the differentiation is inferred rather than stated.

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 is given. With siblings like headless_command and headless_algorithm in the toolset, the agent gets no signal for choosing live-session execution over a headless path, nor any prerequisites (e.g. project must be open).

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 must carry the full behavioral burden. It discloses the default target (current project file if path is omitted), but omits whether saving overwrites, required permissions, error handling, and other mutation side effects.

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 short sentences, front-loaded with purpose and fallback behavior. The bilingual translation is compact and does not dilute the core instruction.

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 a simple one-parameter mutation tool with no annotations or output schema, the description covers purpose and default target. However, it omits when to use it over siblings and what side effects or return behavior to expect, leaving it only minimally self-contained.

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?

One optional parameter with 0% schema description coverage. The description explains that path is optional and falls back to the current file, adding meaning beyond the empty-string default, but it does not specify path format, relative vs. absolute, or validation.

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 'Save' and resource 'the project', with scope clarified as saving to a given path or the current file. This distinguishes it from siblings like load_project and project_info without needing to name them.

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 tool versus alternatives such as load_project, project_info, or export_map. It implies saving after changes but does not state prerequisites, exclusions, or contexts for selection.

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