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

The description carries substantial behavior beyond the annotations: typical latency ('most answers take a few seconds'), the async escape hatch (an id passed to get_report), the one-new-report-per-minute rate limit, the detail that get_report fetches don't count toward it, and the licence obligation to surface `attribution` lines. These are exactly the operational constraints an agent needs and none are derivable from readOnlyHint/openWorldHint/idempotentHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the rate-limit warning are front-loaded and every sentence carries operational value. It is slightly undercut by the garbled clause 'Checks a chosen one depends on run too', which costs clarity without adding information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does the necessary work of explaining what comes back (a result per check, an id for unfinished checks, required attribution lines). It never sketches the shape of an individual check result, so an agent still has to discover the payload structure at runtime.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so lat/lon bounds and the checks enum-by-reference ('from list_checks, omit for plan defaults') are already documented in the schema. The description only reinforces the batching intent for `checks` ('name every check needed in one call'), which is useful but not additive enough to exceed the 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?

States a specific verb and resource — 'Analyse a plot of rural land in Europe and return the result of each check' — which tells an agent exactly what it gets back. It implicitly separates itself from list_checks/get_report by describing the run-and-collect flow, though it never names a sibling explicitly.

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

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

Gives clear operating context: batch all needed checks into one call because of the one-report-per-minute limit, and use get_report with the returned id for long-running checks. It lacks an explicit 'do not use this for X / use save_plot or file_plot instead' exclusion, so it stops short of a full routing rule.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's job is to add context — and it does, disclosing that a negative result carries a reason and that the outcome gates `analyse_plot`. It stops short of describing response shape, latency, or whether coverage boundaries are inclusive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core question and followed by the operational consequence. No filler. 'How finely the ground is measured' is a slightly roundabout way to say resolution but remains readable.

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 carry return-value meaning. It explains the `served` flag and that a reason accompanies a negative answer, but leaves the resolution value's name, units, and possible range unexplained — a gap an agent will hit immediately when reading 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?

Schema coverage is 100%: both `lat` and `lon` carry descriptions plus explicit min/max bounds in WGS84. The description adds nothing about the coordinate convention or bounding behaviour beyond the schema, so the 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 function: determine whether RuralCheck can analyse a given point and at what ground resolution. It also distinguishes itself from the sibling `analyse_plot` by framing itself as the precondition that `analyse_plot` enforces, so an agent can separate the two without opening schemas. The phrasing 'Whether RuralCheck can analyse this point' is slightly indirect but unambiguous in effect.

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

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

It gives a clear selection signal: `served: false` means `analyse_plot` will refuse the point, which strongly implies this is a pre-flight check to run before analysis. However, it never states the guideline outright ('call this before analyse_plot') and gives no explicit when-not condition, such as skipping it for already-known covered points.

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 this is a non-readonly, non-destructive mutation. The description adds meaningful behavioral context beyond annotations: folder names are unique and uniqueness is case-insensitive ('whatever the case'), which implies duplicate creation will fail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no wasted text. The core action is front-loaded, and the uniqueness rule follows immediately.

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 single-parameter creation tool with annotations and no output schema, the description covers the action and an important uniqueness behavior. It does not mention permissions or the return value, but the surrounding structured data carries most of the remaining burden.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the name parameter is already documented. The description adds a useful semantic constraint not present in the schema: the name must be unique regardless of case.

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: 'Make a folder'. It is clearly distinct from sibling folder operations such as list_folders, rename_folder, and delete_folder.

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 by the tool name and the creation verb, but the description does not explicitly state when to use this tool instead of alternatives or any prerequisites. No when-not guidance or sibling routing is provided.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds the crucial non-obvious consequence: plots are not deleted but become unfiled. It does not cover permissions or whether the folder must be empty, but it earns credit for disclosing the non-cascading behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero waste, with the deletion action front-loaded and the content-preservation consequence immediately following.

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 one well-documented parameter, rich annotations, and no output schema, the description covers what an agent most needs to know before calling. Minor gaps (error behavior for nonexistent folder ids) are tolerable at this 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?

Schema coverage is 100% and the single folder_id parameter is documented in the schema as coming from list_folders. The description adds no further semantics about the parameter, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Delete a folder') plus the side effect on contained plots, which distinguishes it from delete_plot. It doesn't explicitly name the sibling for deleting plots, but the verb+resource pairing is unambiguous.

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

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

Usage is implied rather than stated: an agent can infer this is for removing a folder container while keeping its plots. There is no explicit when-to-use/when-not guidance and no reference to alternatives such as delete_plot or list_folders.

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 idempotentHint=true, but the description adds the crucial qualifier that the destruction is deferred and reversible: a 30-day retention window via `deleted_after`, restoration through restore_plot, and permanent removal only afterward. That reframes a 'destructive' mutation as a recoverable one, which is exactly the context an agent needs before calling it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler, front-loading the action and scope before the retention/recovery detail. Every clause — trash, restoration path, 30 days, no immediate deletion — carries distinct operational 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?

For a single-parameter mutation with no output schema, the description supplies the full safety picture: what gets changed, how to undo it, and the time limit. An agent can decide and call correctly without any additional information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and plot_id is documented in the schema as coming from list_plots or save_plot, so the description carries no additional parameter burden. It adds no format or constraint detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Move a kept plot to the Trash') and immediately disambiguates the misleading tool name delete_plot by clarifying this is a recoverable soft delete, not an immediate removal. The word 'kept' signals it applies only to non-deleted plots, separating it from restore_plot at the opposite end of the lifecycle.

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

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

Gives clear usage context: this is the trash operation, and the recovery path is restore_plot within the 30-day window. It does not state an explicit when-not (e.g. behavior if the plot is already trashed) or name a hard-delete alternative, since none exists — but it does say 'Nothing through this server deletes a plot at once,' which closes the loop on 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?

Annotations already declare non-readOnly, idempotent, non-destructive, so the safety profile is covered. The description's only added behavioral claim is that the plot must be 'kept', which hints at a precondition but is never stated as a hard requirement or explained (what happens to an unsaved plot?). It also does not clarify whether moving overwrites an existing folder assignment, though the idempotentHint implies repeat-safety.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence covering both directions of the operation with no filler or restated title. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, non-destructive, idempotent mutation with full schema coverage and no output schema, the definition is nearly sufficient. The remaining gap is the unstated 'kept plot' precondition and what failure looks like, which is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters are well documented there, including 'leave out to take the plot out of its folder', which duplicates the description. The description adds the 'kept plot' qualifier but no syntax or constraint details beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource ('put a kept plot in a folder') and covers the inverse operation too, so an agent understands this is a move/filing operation rather than creation. It does not name or contrast any sibling (e.g. save_plot or update_plot, which likely also take folder assignment), so the differentiation is left partly implicit.

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 two branches of use are stated ('put in a folder' vs 'take it out'), which implies when to omit the folder. However, there is no explicit guidance on prerequisites (plot must be saved/kept), no statement of when to use this versus save_plot with a folder argument, and no error 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 cover readOnly/idempotent/openWorld/non-destructive, so the bar is lower. The description adds real behavioral context beyond them: region/country/postcode results include bbox and a `served` tri-state, approximate marking, and a `message` on failure. It stops short of describing coordinate precision or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then layers in accepted inputs and edge-case behavior. Mostly tight, though the address-degradation sentence is dense and could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by naming the returned fields (bbox, served, approximate, message). Complete enough for an agent to call it and interpret results, missing only the coordinates' format/precision.

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 100% schema coverage the single `query` param is already fully documented. The description reinforces the accepted formats and adds the regional-resolution caveat, giving slight extra meaning, but largely echoes the schema, keeping it near the 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?

States a specific verb and resource: turns a place/region/country/postcode into coordinates. It also enumerates additional accepted inputs (plus codes, map links, street addresses), making the geocoding role unmistakable and clearly distinct from the plotting/report siblings.

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

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

Explains the input forms accepted and, importantly, where street-address resolution works (Norway, Belgium, Denmark) versus where addresses degrade to approximate settlements. This gives clear context for what the tool can and cannot do, though it doesn't name alternative tools or explicit when-not-to-use 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?

The description adds meaningful behavioral context beyond the annotations: it explains what each listing entry contains (status, share link when done, reason if not run) and defines when status is 'done'. However, it does not cover pagination, error behavior, or authentication, so it is not fully 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 two compact sentences, front-loaded with the tool's purpose and immediately followed by useful return-value detail. Every sentence contributes directly to understanding what the tool reports.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must explain return values, and it does so by listing per-listing status, share link, and reason, plus the meaning of 'done'. It leaves out edge cases such as invalid upload IDs or pagination, but is otherwise sufficient for a simple read-only progress tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the sole parameter is already documented as 'The id upload_listings returned.' The description adds no additional meaning about the upload_id parameter, so it meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that this tool reports an upload's progress, including per-listing status, share link once a report is done, and reason for not running. It does not explicitly differentiate itself from siblings such as list_listing_uploads or upload_listings, so it falls short of a 5.

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

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

Usage is implied through the description ('An upload's progress') and the schema note that upload_id comes from upload_listings, but there is no explicit guidance on when to use this versus list_listing_uploads or upload_listings. The reader can infer the context but must do some work.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description adds real value by disclosing the snapshot semantics and the `report.current` staleness flag with its remedy. It does not cover error behavior for a missing/invalid plot id, keeping it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with no filler; the identity of the resource comes first and the staleness caveat second. Slight redundancy in the repeated "kept" phrasing, but every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining return content and does so at a high level (plot plus its report snapshot, plus the `current` flag). The internal shape of the embedded report is left implicit, which is the only notable gap for a one-parameter read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single `plot_id` parameter is already documented with its provenance ("from list_plots or save_plot"). The description adds no further parameter meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("One kept plot with its report") and qualifies it as a historical snapshot ("as it was when it was kept"), which differentiates it from siblings like get_report, analyse_plot, and update_plot. An agent can tell this is a single-resource read of an immutable snapshot without opening the schema.

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

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

Provides clear usage context: use this to see the kept report, and if `report.current` is false, re-run analyse_plot and keep the result. It names the remediation path with the alternative sibling. It stops short of explicit exclusions (e.g. when to prefer get_report or list_plots), so 4 rather than 5.

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

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

Annotations already declare it read-only, idempotent, non-destructive and open-world, but the description adds a genuinely non-obvious behavior: the call blocks/waits while the report is still running. It stops short of stating any timeout, polling cap, or error behavior for failed reports.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no filler, with the blocking behavior front-loaded in the second sentence where an agent will see it before invoking.

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 tool with full schema coverage and rich annotations, this covers the essentials plus the blocking trait. Slightly incomplete on what happens if the report fails or how long the wait can last.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter already has a description tying it to analyse_plot's return value. The description adds no format constraints (e.g., the 64-char max) beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (fetch) plus resource (report) and explicit provenance (one started by analyse_plot). It also implies the retrieval half of the analyse_plot workflow, though it doesn't address how it differs from the sibling sample_report.

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

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

Usage is implied rather than stated: 'by its id' plus 'The id analyse_plot returned' tells the agent this follows an analyse_plot call. There is no explicit when-not guidance or mention of sample_report as an 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?

Annotations already establish readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the shape of each returned entry, including that runtime is approximate ('roughly how long it takes') and that plan availability is exposed via `free` — details the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the resource and field list, then the hand-off instruction. Every clause earns its place and nothing is repeated from 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?

No output schema exists, so the description carries the burden of describing returns — it does so adequately by naming the four fields and their meaning. Minor gaps remain (ordering of results, whether the list is static or plan-dependent at call time), but nothing critical to correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters the baseline is 4; there is nothing to document and the description correctly does not invent parameter guidance. Instead it spends its words on the return contents, which is the right trade-off.

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 opens with a specific resource and scope: 'Every check a report can run', and enumerates exactly what each entry contains (name, what it answers, runtime, free-plan flag). An agent can immediately tell this is a static catalog of available checks, distinct from the analysis siblings.

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

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

It explicitly routes the agent forward: 'Pass names from here to analyse_plot', making the discover-then-analyse workflow clear. There is no explicit when-not guidance, but for a zero-param catalog tool the intended use is unambiguous.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the one piece of behavior annotations cannot: each entry includes a plot count. It does not disclose ordering, whether all folders are returned or the result is paginated/truncated, or whether empty folders appear.

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?

It is only one short clause, so nothing is padded, but it is a sentence fragment with no verb and the key fact (plot counts) arrives after the resource. Zero waste, yet borderline under-specified rather than genuinely 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 zero-parameter read tool with annotations covering safety, the description tells the agent what comes back at a high level (folders plus plot counts). With no output schema, it should say more about the shape of each folder entry (fields, ordering, completeness), which is the remaining 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 tool takes zero parameters, so there is nothing for the description to disambiguate; schema coverage is 100% anyway. Baseline 4 applies for a parameterless tool.

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 (the account's folders) and its distinguishing payload (per-folder plot counts), which separates it from list_plots and find_place among the siblings. It stops short of an explicit verb like 'list', so the operation is inferred from the name rather than stated, but the intent is unambiguous.

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

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

There is no guidance on when to call this versus alternatives, no mention of the create_folder/rename_folder/delete_folder siblings, and no note of prerequisites or ordering. A single sentence of when-to-use would be needed to rise above 2.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description contributes two extras beyond that: result ordering (newest first) and that each entry carries progress state ('how far each has got') — useful, but the phrasing is vague about what that progress field actually expresses, and pagination is unmentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with the scope and ordering front-loaded and no filler. Every clause carries information, and nothing is buried.

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 parameters and no output schema, the description carries the burden of explaining what comes back, and it does so only sketchily ('how far each has got'). It is adequate for a trivial read, but omits result-set size/pagination and any hint of how this differs from the near-identical sibling list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies no filtering or paging arguments are needed.

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 sentence names the resource ('the account's listing uploads') and the ordering ('newest first'), so an agent knows this is a scoped list operation. It does not, however, differentiate itself from the very similar siblings 'upload_listings' and 'get_listing_upload', which is the one thing a reader would most need.

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

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

There is no when-to-use guidance at all: no mention of when to prefer this over 'upload_listings', when to drill into a single upload via 'get_listing_upload', or any prerequisite such as an authenticated account context. The agent must infer the routing decision from the name alone.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still spends its words well by disclosing return ordering, the included folder payload, the default Trash exclusion, and the `deleted_after` restore window — real behavior an agent could not infer from the 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?

Three short sentences, front-loaded with what comes back before the Trash caveat. Nothing is padded or repeated, and the line-broken formatting reads intentionally rather than carelessly.

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 carries the return-value burden, and it does describe ordering, the per-check key figure, and the embedded folders. It is complete enough to call correctly; only the exact shape of the folder list is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented in the schema, and the description largely restates the `in_trash` rule rather than adding syntax or edge cases. It does add the meaningful consequence that trashed plots carry a `deleted_after` date, but says nothing extra about `folder_id` filtering or nesting.

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 first sentence names the resource (plots owned by the account) and the ordering (newest first), and it discloses the payload contents (key figure per check, plus folders), which distinguishes it from get_plot or analyse_plot. It stops short of naming a sibling it is explicitly not, and bundling 'and the account's folders' into a plot-listing tool slightly blurs the 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?

'Plots in the Trash are left out unless in_trash is true' gives an explicit conditioning rule for one mode of use, but nothing says when to reach for list_plots rather than list_folders, find_place, or get_plot. Usage is implied by the described payload rather than stated as a recommendation.

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, idempotentHint=true, and destructiveHint=false, so the mutation/idempotency profile is known. The description adds nothing beyond that — no mention of permission requirements, whether renaming affects children or paths, or collision behavior when the name is taken.

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?

It is a single short sentence with zero waste and information front-loaded, but it is concise to the point of under-specification — the sentence only repeats the name rather than earning its place with any new information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple and both params are fully documented with annotations covering safety, so little is strictly required. However, for a rename operation an agent would benefit from knowing name-collision handling and whether the change propagates, and none of that is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are self-documented, including that folder_id comes from list_folders and that name is 1-60 characters. The description contributes no additional meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Rename a folder." restates the tool name and title verbatim without adding scope, constraints, or differentiation. It does convey the verb+resource, but it is the definition of a tautological restatement per the rubric.

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 indication of when to use this versus siblings like create_folder, delete_folder, or list_folders, nor any preconditions (e.g., folder must exist, name uniqueness within parent). Usage is only inferable from the name itself.

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

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

Annotations already indicate the operation is idempotent and non-destructive, so safety is covered. The description adds useful context that the plot returns to its original folder if it still exists, but it does not say what happens if the folder no longer exists.

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 that front-loads the core action and includes the key conditional folder behavior. It contains no wasted 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 simple restore operation with one fully documented parameter and clear annotations, the description is mostly complete. The only notable gap is the fallback behavior when the original folder no longer exists.

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 is only one parameter, and the schema fully documents it with a clear source ('list_plots or save_plot'). The description adds no additional meaning beyond the schema, which is acceptable at 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: taking a plot out of the Trash. It distinguishes the operation from delete_plot by emphasizing restoration, though it does not explicitly name alternatives.

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 the tool is used when a plot is in the Trash and needs to be restored. It does not specify when to use this versus other plot tools or any prerequisites such as required permissions.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context by saying this is a public sample, tied to a fixed real location, and intended for previewing check outputs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the key identity of the tool and then its intended use. The location detail is relevant and no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity, read-only sample tool with rich annotations and a fully described optional parameter, the description gives enough context to call it correctly. It also communicates the preview purpose clearly, which is the main missing piece beyond the schema.

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 100% description coverage and fully explains the optional checks parameter. The description adds no parameter-level meaning beyond the schema, so 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 resource and scope: a public sample full report for 4 ha of land at Trémolat in Dordogne, France. It also implicitly distinguishes this from producing a user's own report, so an agent can tell it apart from get_report and analyse_plot.

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

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

It gives clear usage context: use this to see what each check returns before asking for a report of your own. It does not explicitly name the alternative tools such as analyse_plot or get_report, but the when-to-use signal is strong.

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 (idempotentHint=true already declared), the description explains the actual upsert semantics: saving the same plot again replaces its report, preserves the name and note, and pulls it out of the Trash. That is meaningful behavior an annotation alone cannot convey. It stops short of noting permission requirements or what is returned on success.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with the core action front-loaded and no filler. The middle sentence packs prerequisite plus replacement behavior efficiently, though the pronoun-heavy "it takes it out of the Trash" phrasing costs a little 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 non-destructive, idempotent write tool with no output schema, the description covers the precondition, the duplicate-handling behavior, and the Trash interaction — enough to call it correctly. The remaining gap is that the agent is not told what the call returns or how it differs from update_plot for an existing plot.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each of the three parameters is already documented in-schema, and the description adds essentially nothing per-parameter. The only implicit link is that report_id is "the id analyse_plot returned", which the schema itself states. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Keep a finished report in My plots" states a create/persist action against a specific resource, and the requirement that the report must have run every plan check narrows it further. It does not, however, distinguish itself from siblings like update_plot, file_plot, or restore_plot, and the interchangeable use of "plot", "report", and "point" muddies what exactly is being saved.

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

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

It gives an explicit prerequisite workflow — call analyse_plot without naming checks first — which is exactly the kind of when-to-use guidance an agent needs. It lacks any exclusion or comparison against update_plot/file_plot/restore_plot, so the agent still has to infer those boundaries.

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 idempotentHint=true, so safety profile is covered. The description adds the precondition that trashed plots must be restored first and signals that the note is replaced (overwritten), which is useful beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and immediately followed by the key constraint. Nothing redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 3-param update tool with full schema coverage and annotations, the description covers purpose and precondition adequately. It could clarify partial-update behavior (null defaults meaning 'leave unchanged'), but that is largely implied by the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters (name, note, plot_id, defaults, length limits) are fully documented in the schema. The description only echoes the two mutable fields without adding format or validation detail; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific verbs and resource: rename a plot or replace its note, scoped to 'kept' plots. It doesn't name siblings like save_plot or delete_plot explicitly, but the Trash phrase points toward restore_plot implicitly.

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

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

Gives a concrete when-not: a plot in the Trash must be restored first, which implies restore_plot is the right tool in that case. No further routing guidance or exclusions, but the context is clear.

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?

Goes well beyond the annotations: asynchronous fire-and-return with an upload id, ~30s per report, serialized server-side processing that yields to live site traffic, a 100-listing run cap per upload, per-listing skip reasons, and re-run suppression for already-current plots. These are exactly the operational traits an agent needs and none are in the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and effect, then consequences. Slightly dense across six sentences and the 'Up to 100 listings' point could sit nearer the top, but every sentence carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly compensates by describing the return value (immediate upload id, not the reports) and the required follow-up call. Combined with plan requirements and failure modes, an agent has everything needed to invoke and continue correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both params (name, listings with lat/lon/reference) are documented in-schema, so baseline is 3. The description adds the practical 100-listing run limit but no per-field semantics beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Send an estate agent's listings to RuralCheck') and immediately clarifies the effect: each listing becomes a saved plot with a report and share link. This distinguishes it from save_plot/analyse_plot siblings, which act on a single plot.

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

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

Gives clear activation context (Professional plan), names the required follow-up call (get_listing_upload), and states the concurrency constraint (one upload at a time per account). It does not explicitly say when to use this versus save_plot for a single property, which is the one remaining routing gap.

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