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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds behavioral detail by specifying exactly what checks are performed (files present, WGS84, DBF encoding) and the output (list of DBF columns with sample values). 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 a single, well-structured sentence that front-loads the action and includes specific details about checks and output. There is no extraneous information, and every word adds value.

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 simple tool with one parameter and no output schema, the description covers the essential behavior: what it checks and what it returns. It does not describe error conditions or return format in detail, but the provided information is 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 0% for the 'path' parameter, so the description must compensate. It implies that 'path' refers to a local layer zip file, but does not explicitly state the expected format, file extension, or that it must be a zip file. This provides some context, but not enough to fully resolve ambiguity without additional inference.

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 verb ('Check') and resource ('local layer zip'), and specifies what it checks (files present, WGS84, DBF encoding) and what it returns (DBF columns with sample values). This distinguishes it from sibling tools like spatial_upload or spatial_verify_layer, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'before uploading' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it. The context is sufficient for an agent to understand it's a pre-upload validation step, but lacks explicit exclusions or references to related tools.

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 description adds real behavioral context beyond the annotations: it reveals that the tool orchestrates multiple operations, waits for creation events, and changes spatial-service configuration. It does not mention the dryRun/confirm safety gate, but the schema documents that, so this is a useful but not exhaustive disclosure.

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 dense sentence that front-loads the main purpose, enumerates the workflow steps, and appends the key side effect. There is no filler, repetition, or unnecessary detail.

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 28-parameter tool with no output schema, the description conveys the overall workflow, the wait behavior, and the side effect on spatial-service, which covers the main orchestration context. However, it does not clarify preview mode vs. actual execution, what a successful invocation returns, or how to interpret failures, so it is adequate but not 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?

The description provides no parameter-level meaning, and schema coverage is only 61%. Several properties such as path, notes, source_link, metadata, and licence fields remain unexplained in both the schema and the description, and the required path parameter has no description. The description does not compensate for those gaps.

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 identifies a concrete composite operation: inspect, upload, create layer, wait for LayerCreation, create field, wait for FieldCreation, and reload intersect config. This is more specific than a tautology and distinguishes it from the lower-level sibling tools, though it never states an explicit end result like 'adds a layer to the spatial service'.

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 phrase 'whole wiki procedure in one go' implies this tool is for when an agent wants the full end-to-end workflow, but it does not name alternatives or say when to use a lower-level tool instead. Usage guidance is implied rather than explicit.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds the side-effect note '[changes spatial-service]', which reinforces that this mutates service state, but it does not describe reversibility, consequences for the running task, or any additional behavioral risks beyond what the annotation already 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?

The description is a single front-loaded sentence with no wasted words. The bracketed '[changes spatial-service]' is somewhat cryptic and redundant with the destructive annotation, but it does not meaningfully inflate the 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 destructive two-parameter tool, this is minimally adequate: purpose, target state, and side-effect are present, and the confirm guardrail is documented in the schema. But the description does not explain what happens when a task is not cancellable, does not mention the require-confirm flow, and gives no sense of the response, leaving an agent to infer important operational 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 coverage is 50%: only 'confirm' has a description, while 'id' is bare. The description does not document parameters directly, but 'Cancel a queued or running task' makes it inferable that 'id' identifies the task to cancel. The 'confirm' parameter is already explained in the schema, so the description adds no new parameter-level meaning.

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 ('Cancel'), a specific resource ('a queued or running task'), and a clear scope. It is immediately distinguishable from siblings like run_task, rerun_task, and task_status because it is the only one that explicitly cancels an in-flight task.

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 phrase 'queued or running task' gives a clear condition for when the tool applies, implying it is not for completed tasks or task listing/status checks. However, it does not name alternatives or explicitly state when not to use this tool, so guidance is mostly implied rather than stated.

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 mark the tool read-only and non-destructive; the description adds useful non-obvious behavior by disclosing that admins see private tasks and that the content covers analyses/maintenance plus input specs. This goes beyond the structured annotations without contradicting them.

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 communicates the core purpose, scope, and access nuance with no filler. It is front-loaded and appropriately sized for a simple discovery 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 zero-parameter, read-only capability listing, the description is largely sufficient: it states what is listed and who can see private entries. It could be more explicit about the output structure, but the missing details are minor given the tool's simplicity and annotations.

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 has zero parameters and an empty schema, so there is no parameter documentation burden. The mention of 'input specs' refers to the listed tasks' inputs, not to parameters of this tool 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 identifies a specific resource ('tasks', clarified as analyses and maintenance processes) and states that the tool returns their input specs, with an access nuance for admins. It is clear, but it does not explicitly differentiate itself from sibling tools like spatial_list_tasks.

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 implies this tool is for discovering available tasks and their input specs, especially before running them. However, it never explicitly says when to use this over spatial_list_tasks or spatial_run_task, leaving routing to inference.

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 destructiveHint=false, so the safety profile is covered. The description adds that the tool interacts with a remote spatial-service, but it does not disclose what 'compare' entails (e.g., network requests, metadata-only diff, side effects like caching). Given annotations, the description provides some additional context but not deep behavioral detail.

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, front-loaded sentence with no filler or redundancy. It states the primary action and target efficiently, making it easy for an agent to grasp the tool's purpose at a glance.

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?

The tool has one parameter, simple purpose, and a read-only annotation profile, so the description is mostly adequate. However, with no output schema, the agent does not know what 'compare' returns (e.g., a diff list, a summary). Given the low complexity, the missing return semantics and prerequisites (e.g., network access) represent a moderate gap.

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 for the single remoteUrl parameter. The example URL gives a concrete format and hints that the parameter expects a spatial-service base URL, but it does not explain how the URL is used or what constitutes a valid endpoint. The description partially compensates with the example but leaves room for ambiguity.

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 uses a specific verb 'Compare' with a clear resource ('layers and fields here') and target ('another spatial-service'), and the example URL clarifies what constitutes a remote service. This distinguishes it from siblings like spatial_import_from_remote (import vs compare) and spatial_list_layers (local listing vs cross-service comparison).

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 no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The example URL suggests a use case, but there is no mention of, for instance, 'use this when you need to verify schema parity before importing' or 'not for comparing data contents'. Agents must infer the intended usage solely 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds the '[changes spatial-service]' note, which signals a side effect on the spatial service. It also mentions the return value (pid), which is useful behavioral context. However, it doesn't disclose details like whether existing areas are overwritten or what happens on validation failure, but the dryRun/confirm parameters in the schema cover the safety mechanism.

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 sentence that front-loads the core action and return value, then adds the '[changes spatial-service]' note. It is concise and to the point, with no wasted words. The placement of the side-effect note in brackets is a bit awkward but acceptable.

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 creation tool with 6 parameters and no output schema, the description is somewhat thin. It tells the agent what the tool does and that it returns a pid, but it doesn't explain the dryRun/confirm safety flow (though the schema does), nor does it clarify the relationship to sibling tools like spatial_create_layer. The annotations cover the safety profile, and the schema covers the parameters, so the description is adequate but not 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?

Schema description coverage is only 33%, so the description should compensate for the undocumented parameters. The description mentions WKT or GeoJSON as input formats, which maps to the 'wkt' and 'geojson' parameters, and notes the return pid. However, it doesn't explain the 'name', 'description', 'dryRun', or 'confirm' parameters beyond what the schema already says. The schema itself documents dryRun and confirm well, but the description adds little for the other 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 specific verb and resource: 'Create a user area from WKT or GeoJSON' and notes it returns a pid usable in analyses. It is clear about what the tool does, though it doesn't explicitly distinguish it from sibling tools like spatial_create_layer or spatial_add_layer. The '[changes spatial-service]' suffix adds a bit of context but is not a full differentiation.

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 implies usage by saying the pid is usable in analyses, which hints at when the result is useful. However, it does not explicitly state when to use this tool versus alternatives like spatial_create_layer or spatial_add_layer, nor does it mention prerequisites or exclusions. The dryRun/confirm mechanism is documented in the schema, not the description, so the description itself provides only implied usage 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?

Beyond the readOnlyHint=false annotation, the description discloses meaningful side effects: it "starts FieldCreation" and "reloads the intersect config", explicitly noting that it "changes spatial-service". This is valuable behavioral context that the annotations and schema do not provide.

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 compact and front-loaded with the primary action, followed by side effects. The parenthetical "wiki step 5" is somewhat cryptic but does not add unnecessary length.

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?

The description communicates the core operation and important side effects, but with 11 parameters and no output schema, an agent still lacks guidance on required fields, return behavior, or how the asynchronous FieldCreation result is surfaced. It is adequate but not fully self-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?

The description adds no parameter-level meaning, but schema coverage is 73% and the input schema already documents key parameters like dryRun, confirm, sname, and indb. The description names no parameters itself, so it neither improves nor harms the schema's semantic 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 uses a specific verb and resource: "Add a field to a layer", which clearly distinguishes it from sibling tools like spatial_create_layer, spatial_get_field, and spatial_update_field. The parenthetical "wiki step 5" adds workflow context without obscuring the core action.

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 explicit guidance about when to choose this tool over alternatives, nor any mention of prerequisites or exclusions. The "wiki step 5" hint implies a workflow sequence but does not tell the agent when this is the right tool versus spatial_update_field or spatial_create_layer.

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 description adds some behavior beyond the readOnlyHint=false annotation by saying it 'starts LayerCreation' and 'changes spatial-service', which signals an asynchronous, side-effecting operation. However, it does not clarify what actually changes, how the process is tracked, or what the caller should expect after invocation, so transparency is only partial.

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 genuinely short, but not every part earns its place: '(wiki step 3)' is cryptic and the bracketed '[changes spatial-service]' is ambiguous. It is concise in length but not in clarity.

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 complex 19-parameter mutating tool with no output schema, the description is far too thin. It does not explain the expected response, whether it returns a task id for spatial_task_status, prerequisites around the upload, or the required confirm/dryRun flow. It leans on external wiki knowledge instead of being self-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?

With 19 parameters and only 53% schema description coverage, the description needed to compensate by explaining key params, but it only implies uploadId through 'from an upload'. It provides no guidance on the dryRun/confirm gating workflow, name constraints, or optional fields, leaving many parameters effectively undocumented in the tool definition.

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 uses a specific verb and resource ('Create a layer from an upload') and clearly ties the tool to the upload pipeline, which distinguishes it from sibling tools like spatial_upload or spatial_create_field. However, it does not explicitly contrast it with spatial_add_layer or name the alternative, 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 actionable guidance about when to use this tool versus spatial_add_layer, spatial_upload, or other siblings. The phrase '(wiki step 3)' is an opaque internal reference rather than a self-contained selection rule, and no exclusions or alternatives are mentioned.

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 flag destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating, destructive operation. The description's '[changes spatial-service]' is a vague side-effect note that adds minimal new information beyond the annotations. It does not disclose confirmation requirements, irreversibility, or permissions, though confirm is documented in the schema.

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 entire description is one sentence, with the action and resource types front-loaded. The trailing note is compact and does not repeat schema content. No filler or redundancy.

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 three parameters, a destructive flag, and no output schema, the description plus annotations and schema give enough to invoke the tool: kinds and id formats are covered, confirm is documented in the schema, and destructiveness is annotated. It doesn't describe the return value, but none is specified, and the tool is a simple delete operation. Overall, it is sufficiently complete for the complexity.

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 schema only describes the confirm parameter (33% coverage). The description compensates by defining the expected id format for each kind: numeric ids for layers, 'cl…/el…' ids for fields, and upload ids. This is essential meaning that the raw schema does not provide, making the tool callable 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 names the verb 'Delete' and the three resource kinds (layer, field, upload) with id formats, making the tool's scope immediately clear. The explicit list distinguishes it from spatial_delete_area, which handles areas. No ambiguity remains about what the tool targets.

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 implies its use case by enumerating the deletable resource types, but it does not explicitly say when to prefer this tool over alternatives or when not to use it. It never mentions spatial_delete_area or creation/update tools, leaving the agent to infer routing from sibling names. This is adequate but lacks explicit exclusions or alternatives.

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 declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds '[changes spatial-service]', which confirms a state change but is vague. It does not mention the confirmation requirement or irreversibility, but the annotations lower the burden; the description provides a minor additional context.

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 efficient sentence with the core action front-loaded. The bracketed '[changes spatial-service]' is somewhat cryptic and adds minimal value, making it slightly less polished than an ideal two-sentence version, but it is still concise.

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 tool with only two parameters and no output schema, the description states the primary purpose and resource type. The confirmation workflow is left entirely to the schema, and the side-effect note is vague. Given the annotations and schema cover safety and parameter details, the description is minimally viable but not rich.

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 50% (only 'confirm' has a description, 'pid' does not). The description's mention of 'user area' gives meaning to 'pid' as the area identifier, which is useful. It does not explain 'confirm', but the schema already covers that, so the description adds some value for the undocumented parameter without fully compensating.

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 verb 'Delete' and the resource 'user area', and it references the sibling tool 'spatial_create_area' to specify exactly what kind of resource it targets. It does not explicitly differentiate from 'spatial_delete', but the resource type makes the purpose distinct enough.

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 implies that this tool is for user areas created with spatial_create_area, giving a condition for when to use it. However, it does not name any alternative tools or explicitly state when not to use it, leaving the routing to inference based on the sibling list.

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 declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the description is not required to restate the safety profile. It adds meaningful behavioral context beyond those hints: 'live' indicates current state rather than stored configuration, and 'drift against the reference version' reveals a comparison behavior that is not visible in the schema or annotations. It also enumerates the kinds of values the form exposes, which helps set expectations for return contents.

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 compact sentence that front-loads the subject ('The live admin form') and then details the useful content after a colon. It contains no filler, though the phrase 'layer/upload or field' is slightly awkward and could be tightened to match the schema's actual kind values.

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 simple read-only tool with two parameters and safety covered by annotations, the description conveys the essential domain object and output themes. However, with no output schema and no explanation of the 'id' parameter, and no usage guidance, it is not fully complete for an agent that needs to call it correctly in a rich sibling context.

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 carries the full burden for parameter meaning, but it only loosely maps to the parameters. The phrase 'layer/upload or field' hints at the 'kind' enum, though it also introduces 'upload' which is not a valid enum value. The 'id' parameter is entirely unexplained, leaving the agent to guess what identifier is required.

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 identifies a specific artifact — 'the live admin form for a layer/upload or field' — and names the information it exposes: 'what the UI allows (maxlength, options, read-only)' and 'drift against the reference version.' This distinguishes it from sibling getters like spatial_get_layer or spatial_get_field by focusing on UI constraints and reference drift. The phrase 'layer/upload or field' is slightly ambiguous because the enum only allows 'layer' and 'field', but the core purpose is still 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 explicit guidance is provided on when to use this tool instead of related siblings such as spatial_layer_admin, spatial_get_layer, or spatial_get_field. The user must infer from the description that this is about inspecting form-level UI properties and drift, which is weak guidance for an agent choosing among 30+ sibling tools.

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 destructiveHint=false, covering the safety profile. The description adds no additional behavioral details, such as error handling or return format, but it does not contradict the annotations. Since the safety is covered, a baseline score is appropriate.

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, efficient sentence that front-loads the core purpose and includes an example. There is zero wasted language, making it highly concise and well-structured.

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 simple getter with one required parameter and no output schema, the description is largely adequate. It doesn't mention return details or error behavior, but these are less critical given the tool's simplicity and the annotations covering safety. Overall, it is sufficiently complete for an agent to use 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?

The schema has no descriptions for parameters (0% coverage), so the description must compensate. It gives an example id ('cl22') and says 'by id', but it does not explain what the id refers to (field id) or its full format. This provides minimal additional meaning 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 a specific verb (get) and resource (field) and identifies the selection criterion (by id) with an example id format. This distinguishes it from sibling tools like spatial_list_fields and spatial_get_layer, making the purpose 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?

The description implies usage when a specific field id is known, but it does not explicitly state when to use this tool versus alternatives like spatial_list_fields or spatial_get_layer. No exclusions or alternative recommendations are provided, leaving the context to inference.

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, openWorldHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the 'by id or name' lookup flexibility, which is useful. However, it doesn't disclose behavior like whether it returns null/error if not found, or whether 'name' is an alternative parameter (the schema only has 'id'). With annotations covering safety, a 3 is appropriate.

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 short sentence, front-loaded with the key information. It's concise and to the point. However, it's so brief that it misses important details (like the name parameter mismatch), so it's not 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?

For a simple getter with readOnly annotations, the description is mostly adequate. But the 'by id or name' claim vs. schema-only-id is a real gap. There's no output schema, so the description should at least hint at what is returned (layer details). The tool is simple, but the mismatch between description and schema makes it incomplete.

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 schema only defines 'id' as a string. The description says 'by id or name' but the schema only has 'id' – this is a mismatch. The description does not explain how to specify a name (no 'name' parameter in schema), nor does it clarify the format of id. This is a significant gap because the description promises functionality the schema doesn't support.

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 'One layer by id or name' clearly identifies the tool's function: retrieving a single layer using either an id or a name. It uses a specific verb ('get') and resource ('layer'), and the phrase 'by id or name' distinguishes it from list_layers and other layer-related tools. However, it doesn't explicitly name a sibling alternative, so it doesn't fully differentiate from tools like spatial_get_field or spatial_list_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?

The description implies usage: when you need one layer identified by id or name. It doesn't explicitly state when to use this vs. spatial_list_layers (for all layers) or spatial_get_field (for fields). The context is clear enough for a simple getter, but no explicit alternatives 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it checks admin endpoint credentials and version drift, which are useful behavioral details beyond the annotations. No contradiction.

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 sentence that packs several pieces of information without waste. It is front-loaded with the primary subject (which spatial-service).

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 zero parameters, read-only annotations, and no output schema, the description adequately explains what the tool reports. An agent knows what to expect from the call.

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 the description does not need to elaborate on parameters. Schema coverage is 100% (empty), so baseline 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 clearly identifies the tool as reporting on the spatial service connection: which service, version, credential validity, and version drift. It is distinct from sibling tools that perform operations on layers or fields. However, it doesn't explicitly name a sibling alternative, but that's not necessary given its unique role.

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 implies this is a diagnostic/health check tool but does not explicitly state when to use it versus other tools. An agent might infer it's useful before other spatial operations to verify connectivity, but the description provides no such 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 already declare readOnlyHint=false and destructiveHint=false, so the description doesn't need to restate mutation. The description adds the key behavioral context: it changes the spatial-service, and the schema's dryRun/confirm parameters reveal a preview-then-commit flow. The description's '[changes spatial-service]' tag adds transparency beyond annotations, though it doesn't detail what exactly changes (e.g., whether it overwrites existing layers).

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 sentence that front-loads the action and resource, and includes the endpoint reference and side-effect tag. It is concise and informative, though the endpoint path in parentheses adds a bit of noise for an agent that already has the 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 mutation tool with no output schema, the description could explain more about what happens after import (e.g., does it return a task ID? does it overwrite?). The dryRun/confirm flow is documented in the schema, so the description doesn't need to repeat it. However, the lack of any note about remote URL format or authentication is a gap, though the schema's url example helps.

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 75%, so the schema already documents url, dryRun, and confirm. The description adds no extra parameter semantics beyond the schema, but the schema itself is fairly clear. The 'kind' parameter is only an enum without a description, and the description's mention of 'layer or field definition' partially clarifies it. Baseline 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 ('Copy') and resource ('a layer or field definition from another spatial-service'), and references the underlying endpoints (/manageLayers/importLayer|importField). It clearly distinguishes this from sibling tools like spatial_create_layer or spatial_add_layer, though it doesn't explicitly name a sibling alternative.

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 implies usage: importing from a remote spatial-service. It does not explicitly state when to use this vs alternatives like spatial_compare_remote or spatial_create_layer, nor does it mention prerequisites like needing the remote URL. The '[changes spatial-service]' tag hints at side effects but doesn't provide explicit when/when-not 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 already declare readOnlyHint=true and destructiveHint=false, so the description needn't restate safety. However, it adds almost no behavioral context beyond that — it doesn't clarify coordinate system, behavior when no field value exists at the point, or whether multiple fieldIds are returned as a composite. With openWorldHint=true also set, the description does not explain what that implies for the agent. 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?

A single seven-word fragment is terse, but this is under-specification rather than concise efficiency. For a tool with three required parameters and no output schema, the description front-loads nothing of substance and leaves the agent without critical call details.

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?

There is no output schema, so the description must convey return shape, yet it only says 'values... at a point' with no mention of structure, ordering, or error behavior. For a 3-required-parameter spatial tool this is materially incomplete — an agent cannot predict the response or handle edge cases.

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 only 33% (fieldIds has a description; lat and lng are bare numbers). The description fails to compensate: it says nothing about lat/lng format, units, or coordinate reference system, which are essential for a spatial point query. It only loosely reinforces that fieldIds means 'one or more fields', already implied by the schema. At 33% coverage the description was obligated to document the undocumented params and did not.

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 the resource ('fields at a point') but omits a verb — it is a fragment, not a statement of action. 'Values of one or more fields at a point' implies a read/sample operation, but the agent must infer the verb. It does hint at distinction from siblings like spatial_get_field (which returns field definitions) via the 'at a point' spatial qualifier, but this is indirect.

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 the many siblings. Given related tools such as spatial_search_gazetteer, spatial_get_field, and spatial_list_fields, the description gives no context on selection criteria, exclusions, or prerequisites. An agent cannot tell when to pick this over spatial_get_field without opening other definitions.

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 destructiveHint=false, so safety is covered. The description adds minimal behavioral context—it says 'metadata, its fields and the tasks started for it' but does not detail what 'tasks started' means (e.g., includes only active tasks, or all?) or how the response is structured. With annotations carrying the safety profile, the description provides some additional context but not rich behavioral detail.

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 sentence with no filler. It is front-loaded with the core purpose ('Admin view') and immediately lists the contained elements. No unnecessary detail.

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 that returns an 'admin view' encompassing metadata, fields, and tasks, the description is underspecified. There is no output schema, and the description does not indicate the structure or scope of the returned data (e.g., which metadata fields, whether tasks are filtered by status, pagination behavior). An agent would be uncertain about the exact output shape and could not reliably parse the response.

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 fully describes the only parameter ('id' as 'Layer id or upload id'), so coverage is 100%. The description does not add any further meaning about the parameter, such as format or constraints. Baseline 3 is appropriate since the schema already handles it.

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 ('Admin view') and resource ('layer or upload'), and enumerates the contents (metadata, fields, tasks). It is clear that this combines several aspects, but it does not explicitly distinguish itself from sibling tools like spatial_get_layer or spatial_list_tasks, so an agent may not know when this is preferred.

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 explicit guidance is given on when to use this tool versus alternatives. The phrase 'Admin view' implies a broader perspective, but it does not state conditions like 'use this for a full overview' or 'instead of calling get_layer separately.' An agent would have to infer the use case.

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 destructiveHint=false, so the safety profile is covered. The description adds useful context about what 'fields' means in this system, but it does not disclose filter behavior, limit semantics, or return format.

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 text is brief and has little filler, but the compressed 'cl… contextual, el… environmental' notation is cryptic and the overall fragment lacks clear sentence structure. It is short, not genuinely well-communicated.

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 a description this sparse, an agent lacks information about return values, q filter semantics, and limit behavior. Safe no-argument calls may be possible, but filtered or detailed usage requires guessing beyond what is provided.

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?

There are two parameters with 0% schema description coverage. The phrase 'optionally filtered' vaguely maps to q, but the description does not explain how to use q or what limit does, so it fails to compensate for the schema's lack of parameter documentation.

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 identifies the resource ('Fields') and hints at a filtering option, while adding the domain distinction of sampling/intersect layer views with contextual/environmental prefixes. However, it lacks an explicit verb or full command sentence, so the actual 'list' operation must be inferred from the tool name.

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 is given about when to use this tool over siblings like spatial_get_field or spatial_list_layers. The only implicit usage cue is that fields are a special view of layers and can be filtered, with no exclusions or decision conditions.

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 destructiveHint=false, so the safety profile is covered. The description adds the filtering criteria (name, display name, classification), which clarifies query semantics, but it does not disclose pagination behavior (limit default 50) or return structure. With annotations carrying the main behavioral burden, this is modest added context but not a rich disclosure.

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 extremely concise, using a single short phrase with no filler words. It front-loads the resource name and the filter condition, which helps scanning. It is a fragment rather than a complete sentence, which slightly hurts structural clarity but does not add unnecessary length.

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 list tool with no output schema, no parameter descriptions in the schema, and no explicit return statement, this description is incomplete. It does not explicitly state that the tool returns a list of layers, does not mention the limit parameter or its default, and offers no information about output format or behavior. The annotations cover safety, but the operational context an agent needs to call it correctly is largely 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 description gives meaningful semantics to the 'q' parameter by specifying that it filters on text across name, display name, and classification. However, the 'limit' parameter is entirely unexplained in both the description and the schema (schema coverage is 0%), and the description does not mention the default value or its purpose. This partial compensation for the schema gap warrants a middle score.

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 identifies the resource (layers) and the optional filter by text on name, display name, and classification. It does not use an explicit verb like 'list' or 'returns', but the tool name and the noun phrase make the action clear. It differentiates from sibling list tools (spatial_list_fields, spatial_list_objects) by naming the resource type.

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 guidance on when to use this tool versus alternatives such as spatial_get_layer (for a single layer) or other list tools. It only states the optional filter condition and does not mention exclusions, prerequisites, or scenarios where another tool would be more appropriate.

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, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds that objects are polygons, which is useful context but does not disclose additional behaviors like pagination, ordering, or completeness limits. With annotations present, the added value is moderate.

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 short phrase, but it is under-specified rather than concisely complete. It omits essential context about parameters and usage, making it too terse to be effective.

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 simple listing tool, the description still lacks critical information: no parameter semantics, no usage guidance, no mention of return format or pagination. Even with annotations covering safety, the absence of param documentation makes it incomplete for an agent to call 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?

The schema has 0% description coverage for its two parameters (fieldId, limit). The description provides no explanation of what fieldId refers to, how limit works, or any default behavior. The description completely fails to compensate for the missing schema descriptions.

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 clarifies that the tool lists objects (polygons, e.g., states) belonging to a contextual field. While it is a noun phrase rather than an explicit verb statement, it distinguishes from siblings like spatial_list_fields and spatial_list_layers by specifying the resource type (objects of a field).

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 is provided on when to use this tool versus alternatives. With many sibling tools covering layers, fields, tasks, and uploads, there is no explicit routing or exclusions, leaving the agent to infer the appropriate context.

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 destructiveHint=false, and the description aligns with that by describing a read-only listing operation. It adds value beyond annotations by defining the status code semantics (0-4) and the admin scope, which helps the agent understand the data being returned and the tool's intended audience. There is no contradiction.

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 sentence that front-loads the core purpose ('Recent tasks (admin)') and then provides the key filtering capabilities. Every word contributes value, with no filler or redundancy. It is highly efficient and easy to parse.

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 simple list tool with 3 optional parameters and no output schema, the description covers the essential aspects: what it does, its scope, and the meaning of the main filters. It does not describe return format or error behavior, but these are not critical for a straightforward list operation, and the status code mapping adds important context. Overall, it is sufficiently complete for an agent to invoke 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 0%, so the description must compensate. It explains the 'q' parameter as text filtering and 'status' with the full mapping of numeric codes to human-readable states. However, it does not explain the 'max' parameter beyond its existence in the schema, leaving its semantics (maximum number of results) implicit. This is a partial compensation for the schema gap.

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 purpose: listing recent tasks, with an admin scope. It specifies the resource (tasks) and the action (list), and distinguishes itself from task-management siblings like spatial_run_task or spatial_cancel_task by focusing on listing. The filter options (text/status) further clarify its role.

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 does not explicitly state when to use this tool versus alternatives like spatial_task_status. It implies a general listing use case with 'Recent tasks' and an admin note, but there is no explicit guidance on selecting this over other task-related tools. However, it is not misleading and the purpose is clear enough that an agent can infer the primary use case.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the admin scoping and the 'waiting to become layers' state, which is useful behavioral context. It doesn't describe pagination, ordering, or whether the list is complete, but with zero parameters and read-only annotations, the description carries a lighter burden.

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, compact phrase that conveys the resource, state, and audience. Every word earns its place, and there is no redundancy with the schema or annotations.

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, read-only list tool with no output schema, the description is nearly complete. It tells the agent what the tool returns (uploaded files pending layer creation) and who it's for (admin). The only minor gap is not naming sibling tools like spatial_list_layers to clarify the distinction, but the state phrase 'waiting to become layers' largely covers that.

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 has zero parameters, so the schema provides no parameter semantics. The description doesn't need to explain parameters, and the baseline for zero-param tools is 4. The description's mention of 'uploads' and 'admin' gives context about what the returned list contains, which is sufficient.

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: 'Uploaded files waiting to become layers (admin)'. It clearly identifies what the tool lists (uploads pending layer creation) and scopes it to admin. It doesn't explicitly differentiate from spatial_list_layers or spatial_list_tasks, but the phrase 'waiting to become layers' distinguishes it from already-created 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?

The description implies usage context: it's for admin users to see uploaded files that haven't yet become layers. It doesn't explicitly state when to use this over spatial_list_layers or spatial_upload, but the 'waiting to become layers' phrasing gives enough context for an agent to infer this is the pre-layer staging view. No exclusions or alternatives are named.

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 false and destructiveHint false. The description adds that it 'changes spatial-service', which is a useful side-effect disclosure. However, it doesn't detail consequences like whether it's safe to rerun or if it causes downtime. The openWorldHint suggests potential side effects not fully described. It adds some value but not comprehensive.

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 sentence that front-loads the action and purpose. It is concise, though the parenthetical '(wiki step 7)' is cryptic and may not help the agent. It is appropriately sized.

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 simple one-parameter tool with annotations and no output schema, the description explains the purpose and effect. However, the reference to a wiki step and the unclear 'dryRun' mention leave gaps. The agent knows it must set confirm=true to actually execute, but the description doesn't clarify the dryRun reference. Overall, it's mostly complete but has minor ambiguities.

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 schema already documents the single parameter 'confirm' with a description. The main description does not add anything about parameters, and actually mentions 'dryRun false' which is not a parameter in the schema, potentially confusing. Since schema coverage is 100%, the baseline is 3; the description doesn't add value and introduces a minor inconsistency.

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 verb 'Reload' and the resource 'intersect configuration', and specifies the purpose: to make new fields answer /intersect. It is distinct from siblings like spatial_intersect (which queries) and spatial_list_fields (which lists), so it's clear what this tool does.

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 implies usage after adding new fields (so they answer /intersect) but does not explicitly mention alternatives or when not to use. It references a wiki step, which gives process context but is not explicit about selection criteria. It could be clearer but provides enough context.

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 show readOnlyHint=false, but the description adds useful context: the operation 'changes spatial-service' and is admin-scoped. It does not discuss idempotency or reversibility, though destructiveHint=false provides a partial safety signal.

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 entire description is one compact sentence with the core action, scope, example, and side-effect all present. There is 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?

The description covers purpose and side-effect, and annotations cover basic read/write safety. However, it leaves the task-id parameter unexplained and contains an unresolved dryRun reference in the schema, so an agent still has some ambiguity before invoking it.

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 description does not clarify that 'id' is the task identifier, and schema coverage is only 50% with the required parameter left undocumented. The confirm parameter's schema text references a 'dryRun' parameter that does not exist in the schema, adding confusion rather than compensating for the coverage gap.

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 ('Re-run a task'), adds an admin scope, and gives concrete examples (failed LayerCreation or FieldCreation). It is distinguishable from spatial_run_task and spatial_cancel_task, though it does not explicitly name sibling tools.

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 admin qualifier and the 'e.g. a failed LayerCreation or FieldCreation' example imply the intended recovery scenario. However, it does not explicitly contrast this with spatial_run_task or state when not to use it, leaving the routing decision partially to inference.

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 description includes the note '[changes spatial-service]', which discloses that the tool has side effects on the spatial service, consistent with readOnlyHint: false. It does not contradict the annotations. However, beyond that note, it does not elaborate on what changes occur or whether they are reversible. Given that annotations already indicate it is not read-only, the description adds only minimal behavioral context, so a 3 is appropriate.

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 sentence that front-loads the core purpose and then provides examples and a reference to spatial_capabilities. It is concise and avoids redundant wording. However, the list of examples is somewhat lengthy and could be trimmed without losing meaning, so it is not a perfect 5 but remains efficient.

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?

The tool runs tasks and has no output schema, so the description should ideally mention what happens after execution (e.g., how to check status via spatial_task_status) and clarify the dryRun/confirm flow. While the schema covers the dryRun/confirm mechanics, the description does not mention the task lifecycle or the need to follow up with status checks. It also does not explain that the tool might return a task ID. Given the complexity of the tool and the absence of an output schema, the description is incomplete in this regard, earning a 3.

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 schema has descriptions for dryRun and confirm (50% coverage), but name and input lack descriptions. The description partially compensates by telling agents to see spatial_capabilities for names and inputs, which is a useful pointer. However, it does not explain the structure or purpose of the 'input' parameter beyond that, nor does it elaborate on the semantics of name beyond the examples. Since schema covers half the parameters and the description adds a pointer, a 3 is fair.

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 purpose: it runs a task via /tasks/create, and gives specific examples of user analyses (AreaReport, AooEoo, PointsToGrid) and admin maintenance processes (Thumbnails, TabulationCreate, etc.). This makes it distinct from sibling tools like spatial_task_status or spatial_cancel_task, which handle other aspects of task lifecycle. The verb 'Run' and resource 'task' are explicit, so an agent can easily identify what this tool does.

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 context by distinguishing between user analysis tasks and admin maintenance processes, and explicitly points to spatial_capabilities for valid names and inputs. However, it does not explicitly state when to use this tool versus alternatives like spatial_rerun_task or spatial_cancel_task, or when not to use it. The pointer to spatial_capabilities is helpful but the guidance on alternatives is implicit rather than explicit.

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 destructiveHint=false, so the safety profile is covered. The description adds the 'across the gazetteer fields' scope, which is useful context, but does not disclose return format, pagination, or any rate limits. With annotations present, the description adds some value but lacks deeper behavioral details.

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, concise sentence, which is efficient. However, it contains only the bare minimum information and does not structure any additional details. While it is not verbose, it also does not add sufficient value beyond the tool name to justify its length.

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 two parameters and no output schema, the description is very thin. It does not explain the expected response format, any limitations, or how results are ordered or filtered. With no output schema, the agent is left without critical information needed to correctly interpret results, making the description incomplete.

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 does not explain either parameter. It implies q is the name query, but does not clarify its type or format, and completely omits the 'limit' parameter and its default behavior. With no parameter documentation in the description, an agent has no semantic guidance beyond the schema's bare type definitions.

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 clear verb ('Search') and resource ('objects') with a specific scope ('by name across the gazetteer fields'). It distinguishes from a generic list operation, though it does not explicitly name sibling alternatives like spatial_list_objects. The purpose is understandable and specific enough for an 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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or conditions that would make this tool preferred over spatial_list_objects or other search-like tools. The usage context is only implied by the tool name and the phrase 'by 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so no side-effect warnings are needed. The description adds useful detail by specifying the state machine and that the response includes the last log lines, helping an agent understand what a status check returns. 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?

One concise sentence that front-loads the key output content and enumerates the status vocabulary with zero filler. It is appropriately sized for such a simple 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, read-only status tool, this is largely complete: it names the input domain and the return content (status, message, last log lines). It could be improved by noting where the task id originates or that the status is for an asynchronous task, but these are minor given the sibling naming.

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 0% schema description coverage, the description's phrase 'of a task' is the only clue that the 'id' parameter refers to a task identifier. This adds minimal meaning beyond the schema, but it does not state that the id comes from spatial_run_task or spatial_list_tasks, nor explain behavior for unknown ids.

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 identifies the tool as returning status, message, and log lines for a single task, and enumerates the exact status values (queued/running/success/failed/cancelled). It is distinguishable from siblings like spatial_list_tasks and spatial_run_task, though it lacks an explicit verb such as 'get' or 'retrieve'.

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: after running a task, this tool reports its status and logs. However, it does not explicitly state when to use this versus spatial_list_tasks, nor how the task id is obtained from spatial_run_task, and it names no alternative.

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 description adds 'Read-only fields of the form cannot be changed' and '[changes spatial-service]', which provides behavioral context beyond the annotations (readOnlyHint=false, destructiveHint=false). It signals that the tool mutates state and has restrictions. It doesn't contradict annotations, and the note about read-only fields is a valuable guardrail.

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 that immediately states the action ('Edit a field'), followed by a key restriction and a side-effect tag. It is front-loaded with the primary purpose and wastes no words. The structure is efficient and appropriate for a tool with a clear scope.

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?

Despite having 11 parameters and a complex dryRun/confirm pattern, the description is very brief and omits the essential confirmation requirement. An agent must know that dryRun defaults to true and confirm must be set false to actually apply changes. The description doesn't mention this critical operational detail, nor does it explain return behavior or prerequisites. For a mutation tool, this is a significant gap.

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 73%, with many parameters having their own descriptions. The description lists 'name, description, flags' but doesn't map these to specific parameters or add syntax details. It doesn't compensate for the uncovered parameters, but the schema already carries most of the burden. The description adds marginal value beyond what the schema provides.

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: 'Edit a field' with the resources (name, description, flags). It distinguishes from siblings like spatial_create_field and spatial_get_field by indicating editing rather than creation or retrieval. The constraint about read-only fields further clarifies scope.

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 implies usage for editing existing fields, and the sibling set includes create_field and get_field, making the context clear. However, it doesn't explicitly state when to use this instead of alternatives, nor does it mention any prerequisites or conditions beyond read-only restrictions. The implication is strong enough to guide an agent.

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 description discloses two behavioral facts: read-only fields cannot be changed, and the operation changes the spatial service. This adds context beyond the annotations (readOnlyHint=false, destructiveHint=false) and aligns with them. However, it omits the critical preview/confirm mechanism (dryRun/confirm) and does not clarify whether changes are reversible, which is a notable gap given the tool's side-effect nature.

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 short and front-loaded with the core action. The second sentence, however, is cryptic ('Read-only fields of the form cannot be changed [changes spatial-service]') and could be clearer, but overall it is efficient and avoids redundancy. It earns a 4 for brevity and structure.

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 20 parameters, a required id, and a dryRun/confirm safety pattern, the description is far from sufficient. It does not explain the required id parameter, the preview-then-confirm workflow, or how the many optional parameters interact. An agent would need to open the schema and infer heavily, making this incomplete for correct invocation.

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 only 50% schema description coverage, the description needed to compensate by explaining undocumented parameters like keywords, source_link, metadatapath, etc. It does not – it only mentions a few examples that already have schema descriptions (displayname, classification, licence). No additional meaning is added for the many parameters lacking descriptions, leaving agents to guess.

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 the verb 'Edit' and the resource 'layer metadata', and gives concrete examples (display name, classification, licence, enabled). This clearly indicates an update operation and distinguishes it from creation tools like spatial_create_layer. However, it does not explicitly contrast with spatial_update_field, which also edits metadata but at the field level, so it stops short of perfect differentiation.

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 guidance on when to use this tool versus alternatives, no prerequisites, and no conditions or exclusions. The description does not mention that this is for layer-level metadata while field-level changes go to spatial_update_field, nor does it hint at the dryRun/confirm workflow for safe previewing. An agent must infer usage from the schema and sibling names.

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?

Beyond the annotations, the description adds that the tool returns an upload id and that the follow-up create_layer call changes spatial-service. However, it does not clarify whether the upload itself persists anything, whether it is idempotent, or what the default dryRun behavior means for the returned id; the schema already covers dryRun/confirm.

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 compact and front-loaded, with the action stated first and the return value and next step following. The parenthetical '[changes spatial-service]' and 'wiki step 2' are slightly cryptic but still contribute workflow context without bloating the text.

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 one required parameter and no output schema, the description covers the essential outcome (upload id) and next step, but it leaves out the meaning of path and any prerequisites or zip constraints. An agent could invoke it correctly, but richer context about the upload lifecycle and how to use the returned id would improve completeness.

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 67%: dryRun and confirm are already explained in the schema, while path has no description. The description only implies that path contains a layer zip and does not add detail about path formats, required zip structure, or how the upload id relates to the parameters. This is adequate but does not compensate for the undocumented path parameter.

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 uses a specific verb ('Upload') and a concrete resource ('a layer zip'), clearly naming what the tool does and what it returns ('the upload id'). It also distinguishes itself from the closely related spatial_create_layer by presenting the upload as the prior step, so an agent can separate the two.

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 places the tool in a workflow ('wiki step 2') and explicitly names the next tool (spatial_create_layer), giving clear contextual guidance. It does not mention when to avoid this tool or compare it with similar siblings such as inspect_layer_zip, but the sequential cue is enough for most selection decisions.

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 destructiveHint=false, so there is no safety contradiction. The description contributes the fact that verification spans multiple systems and UI surfaces, but it does not say what happens on inconsistency, how results are returned, or whether external services like GeoServer WMS are queried 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?

The description is short, but 'Wiki step 8' is cryptic noise that does not help an agent, and the long list of endpoints is packed into one clause without explaining their roles. It is concise but not structured in a way that highlights the essential meaning.

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 explanation of what a successful verification looks like, the agent cannot predict the return value or interpret failures. The many sibling tools and the optional lat/lng/fieldId parameters make the lack of self-contained context a significant gap.

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 schema has 0% description coverage, so the description needed to explain layerId, fieldId, lat, and lng. It only loosely maps 'layer' and 'field' to two of the parameters and leaves lat/lng completely unexplained, giving an agent little basis for constructing a correct 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 names a verb ('check') and a resource ('layer and field'), and lists concrete target systems (/layers, /fields, /objects, /object, KML, intersect, GeoServer WMS, admin UI), so it is not a bare tautology. However, it never defines what 'check' verifies—existence, consistency, correctness, or availability—and the leading 'Wiki step 8' reference makes the purpose depend on external context rather than standing alone.

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 guidance about when to use this tool over siblings such as spatial_get_layer, spatial_health, or spatial_compare_remote. The only hint is 'Wiki step 8', which is opaque to an agent that has not read the wiki.

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