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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered structurally. The description adds real value beyond that by scoping the destruction: only future repetition stops, grids already run are preserved. It does not say what happens when the schedule_id does not exist.

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 permanence constraint front-loaded before the retained-data caveat. Nothing to trim.

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 rich annotations and no output schema, the description covers the key behavioral question (what survives the delete). Minor gap: behavior on a nonexistent or already-deleted schedule_id is unstated.

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

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

Schema description coverage is 0% for the single required schedule_id, so the description is the only place that could clarify it, and it is never mentioned. The uuid format is self-evident from the schema, but the definition adds nothing about which schedule identifier to supply.

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

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

States a specific verb+resource: permanently stop a repeating grid ('for good'), which distinguishes it from the reversible-sounding update_schedule and from list_schedules. It never names an alternative sibling explicitly, so it falls short of the top tier.

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?

'For good' implies this is the terminal option versus update_schedule, but the description never says when to choose this over pausing/modifying a schedule, nor any preconditions. Usage is only implied.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description goes further with genuinely useful behavior: nothing is reserved or charged, and points at sea are removed for shapes (so the estimate can differ from a naive count). It does not describe latency, rate limits, or how the balance figure is derived.

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 compact sentences with the output promise, the run_grid relationship, and the cost profile all front-loaded. No filler, no repetition of the title.

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

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

For a 9-parameter tool with no output schema, the description does well to enumerate the conceptual return values (point count, credit cost, resulting balance), which removes the need for a return-value schema. However, it leaves all nine parameters undocumented, which is a real gap for a tool this parameterized.

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

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

Schema description coverage is 0% across 9 parameters, so the schema supplies names and constraints but no meaning. The description only offers 'Same parameters as run_grid' plus a hint about shape/sea points, leaving the agent to infer semantics for radius_km, density, place_id, and the rest from a sibling tool's 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?

States a specific verb and resource ('estimate ... what a grid would cost') plus the exact output quantities (points and credits). It also explicitly positions itself relative to run_grid ('before running it'), so an agent can distinguish it from the sibling that actually executes a grid.

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?

Clearly frames the usage window ('before running it') and notes it is free, implying it should be called ahead of run_grid. It stops short of an explicit 'call this first, then call run_grid' instruction or any when-not-to-use guidance, but the context 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 cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely new context: the call is free and the payload yields place_id values for chaining. No contradiction. Rate limits and result caps remain undisclosed, so not a 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?

Three short sentences, front-loaded with the action, then the return value, then the cost flag. The one-word 'Free.' earns its place as a routing signal, though the sentence fragments are slightly clipped.

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 name place_id as the key output. However it omits the language parameter, result-count/pagination behavior, and any limits, leaving meaningful gaps for a search 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 0%, so the description must carry full parameter burden. It hints that 'query' covers name and city, but gives no format guidance, and the 'language' parameter is not mentioned at all. It compensates only partially 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?

States a specific verb and resource ('Search Google Maps listings by name and city') and names the downstream sibling it feeds ('place_id values to use with run_grid'). An agent can distinguish this discovery step from run_grid/get_grid without opening any 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?

Implies the workflow position explicitly: call this first to obtain place_id values, then pass them to run_grid. The 'Free' note also signals a cost trade-off against paid siblings like estimate_grid/get_balance. No explicit when-not guidance, but the usage 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds two genuinely new facts: the unit conversion (1 credit = 1 grid point) and that the call is free, which is cost/rate context not present in the annotations. However, it says nothing about auth requirements, return format, or whether balance can be negative or stale.

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 fragments, front-loaded with the core fact (what the balance is) followed by unit clarification and cost. No filler. Slightly terse to the point of reading as a label rather than a sentence, which costs a point.

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 the annotations cover read-only safety, so little is needed. But with no output schema, the description does not say what the balance looks like on return (a number, a formatted string, a per-workspace breakdown), leaving a small but real gap for an agent consuming the result.

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

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

The tool takes zero parameters, so the baseline is 4. There is no parameter surface for the description to compensate for, and the '(1 credit = 1 grid point)' note usefully clarifies the semantics of the returned value's unit.

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

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

States a specific resource and what it returns: 'Credits left on the account.' An agent can tell this is a read of account balance and distinguishes it from the grid/schedule siblings, which do entirely different things. It is phrased as an output description rather than a verb+resource, 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?

No when-to-use or when-not-to-use guidance is given, and no alternatives are named. 'Free' hints that calling it has no cost, which is mildly useful, but nothing tells the agent when to reach for this versus estimate_grid or run_grid.

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, so safety is covered. The description adds genuinely useful behavior beyond that: the per-grid outcome states (waiting/running/completed/failed with reason) and that the call is free, which is a cost hint an agent cannot get from 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?

A single sentence with the resource and lifecycle anchor front-loaded, followed by the status enumeration. Every clause carries information and there is no filler.

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 annotation detail, the description must convey the return shape, and it does: per-grid status plus average rank and top 3 for completed grids, and failure reasons. Only the batch_id parameter origin is left thin.

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 batch_id is not described in the schema at all, so the description carries the burden. It only indirectly signals that batch_id is the handle returned by run_grids; it never states the parameter name, format, or its source explicitly.

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 precisely what the tool returns — the progress/status of a batch — and anchors it to the run_grids lifecycle, which separates it from get_grid (single grid) and list_grids. It reads as a noun phrase rather than an explicit verb+resource, but the resource and scope are 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 phrase 'a batch started with run_grids' implies the prerequisite and where the batch_id originates, so usage is inferable. However, no alternative is named (e.g. get_grid for a single grid) and there is no explicit 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 only declare readOnlyHint=true; the description adds genuinely useful behavior: the output includes a full ranks matrix oriented north-up, change versus the prior grid of the same listing, and a map image that appears only 'once completed' — implying a not-yet-finished state an agent must expect. It does not discuss cost, rate limits, or error states when the grid is pending.

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 sentence, front-loaded with the primary concept ('Status and result'), then the return contents. Slightly overloaded as a comma-separated list, but every clause adds information and none 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?

There is no output schema, so the description carries the burden of describing returns and does so well by naming the four output components. It is complete for a read-only getter apart from the undocumented grid_id and the absence of any mention of incomplete/pending responses.

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

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

Schema description coverage is 0% and the single grid_id parameter is documented nowhere; the description never says what a grid_id is, that it is a UUID, or how to obtain one. With one required param and zero schema-level documentation, the description needed to compensate and does 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?

States a specific verb and resource ('get_grid') and enumerates the concrete payload: ranks matrix, competitors most often in top 3, change since previous grid, and the rendered map. It also names the producer sibling (run_grid) so the agent can place it. It does not explicitly contrast with list_grids, 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 rather than stated: the phrase 'created with run_grid or the API' tells the agent this reads back an asynchronous job, and 'once completed' hints at polling. There is no explicit when-to-use versus list_grids/list_schedules, and no stated prerequisite that a grid_id must first come from run_grid.

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 only declare readOnlyHint=true, so the description earns credit for adding the ordering guarantee (oldest first), the scope of returned data (only completed grids of a matching map), and the cost profile ("Free"). It omits failure behavior (no completed grids, mismatched identifiers) and how the limit parameter truncates results.

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 return shape and followed by the invocation recipe and cost note. No filler, no restatement of the name or title.

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 work of explaining the return payload (ordered grid history plus first-to-last change), which is the key missing piece elsewhere. Gaps remain around pagination via limit and edge cases such as no prior grids for a keyword.

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 burden and largely does: it explains that grid_id and the place_id/keyword pair are alternative selection modes and that the latest grid determines map format. The limit parameter is never mentioned, leaving one of four parameters undocumented anywhere.

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

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

The description names a specific resource and its contents: the ranking evolution of a listing for a keyword across every completed grid of the same map, plus the delta between first and last. An agent knows exactly what it gets back, though no sibling (get_grid, list_grids) is named to sharpen the boundary between this and those 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?

It states the two invocation paths clearly (grid_id alone, or place_id + keyword where the latest grid sets the format) and flags the operation as free, which matters given credit-consuming siblings like estimate_grid and get_balance. It stops short of naming alternatives or stating when-not to use this tool.

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, so the safety profile is covered; the description adds non-annotation context: newest-first ordering and a 'Free' cost signal. Pagination mechanics (limit/before) remain undescribed.

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 dense sentences with the resource and ordering front-loaded, then filters, then the return/follow-up routing and cost. No wasted words.

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

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

With no output schema and only readOnlyHint, the description usefully covers scope, ordering, return type (grid_id), follow-up tools, and cost. The main gap is lack of guidance on limit/before pagination for a list endpoint.

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

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

Schema coverage is 0%, so the description must compensate. It clarifies place_id ('one listing') and keyword ('one exact keyword'), but says nothing about limit or before, leaving two of four parameters undocumented.

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

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

States a specific verb+resource ('The account's grids') plus scoping ('newest first', 'optionally for one listing') and distinguishes itself from siblings by naming the follow-up tools (get_grid, get_history, schedule_grid). Clear, though it doesn't explicitly contrast with get_grid/run_grids.

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 when to use it (retrieve grids, optionally filtered by place_id or keyword) and routes to the correct follow-up tools once grid_id is obtained. No explicit when-not, but the filtering conditions give solid 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 declare readOnlyHint=true. Description adds value beyond that: it discloses status semantics (active, paused, or stopped and why), which fields are returned (rhythm, next run, credits per month), and a cost trait ('Free'). Good behavioral context for a read tool.

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

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

Single compact sentence, front-loaded with the resource, plus a one-word cost note. Every element (fields, status reasons, free) earns its place; no filler.

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-param, read-only listing with annotations covering safety and description covering returned fields and cost, the definition is nearly complete. Without an output schema the description carries the return-shape burden and does list key fields, though it doesn't specify ordering, timestamps, or error behavior.

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

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

No parameters (zero-param tool), so parameter semantics baseline is 4. Description correctly implies no filtering arguments and focuses on output fields, appropriate for a list-all endpoint.

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: lists the account's repeated grids (schedules) and enumerates returned fields (rhythm, status with reasons, next run, credits per month). Clearly distinguishes from sibling list_grids (static grids) and schedule/update/delete_schedule by implying read-only listing. Slight ambiguity that 'repeated grids' is the schedule concept, but siblings make it 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?

Usage is implied (list schedules) but no explicit when/when-not guidance or named alternatives. The 'Free' note adds cost context but not selection guidance relative to siblings like schedule_grid or update_schedule.

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

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

With annotations only declaring the generic write/open-world/non-idempotent profile, the description carries real behavioral weight: one credit per point with worked cost examples, sea points skipped and uncharged, refund on failure, free mock grids for gga_test_ keys, and the wait_seconds-then-return-id timing contract. This is exactly the context an agent needs before spending credits.

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 leads, then cost, then timing/refund, then test-key behavior. Dense but every clause is actionable; the enumerated cost examples (9/49/81, medium circle 29) are verbose yet genuinely useful for predicting spend.

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 10-parameter tool with no output schema and no field descriptions, the description covers the hardest parts: billing, partial-failure refunds, mock mode, and what is returned when the run outlives wait_seconds. The remaining gap is location resolution (place_id vs keyword vs radius_km), which an agent cannot resolve from either schema or description.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate. It clarifies size (3/5/7/9), shape and density vocabularies, and wait_seconds semantics, but leaves keyword, query, place_id, radius_km, country and language entirely unexplained, including how the grid center is anchored.

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

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

The description gives a specific verb and resource: measuring Google Business Profile rank on Google Maps across every point of a grid around a location. It is far more concrete than a restated title, but it never names the closest siblings (estimate_grid for cost-only, run_grids for batch), so an agent must infer the distinction.

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

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

Usage is implied (this is the tool that actually consumes credits and produces a grid id), and the credit/test-key/refund notes give some decision context. However, there is no explicit 'use this instead of estimate_grid when...' routing, and no stated prerequisites for the required keyword.

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?

Adds substantial behavior beyond the annotations: credit cost per grid point, refund on failure, upfront refusal when balance is insufficient, concurrency of 10 slots, and the wait_seconds truncation semantics. These are exactly the kind of cost, throttling and timing traits annotations cannot express.

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?

Four dense sentences, each front-loaded with the fact that matters most (batch size, shape constraint, cost, then wait behavior and follow-up call). 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?

Covers return semantics (partial batch plus get_batch), cost, failure and timing for a tool with no output schema. It is close to complete, with the remaining gap being the six unexplained geographic and size parameters.

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 coverage across 8 parameters, the description must carry the load. It does explain the items structure (place_id or query, plus required keyword) and wait_seconds behavior, but leaves size, shape, country, density, language and radius_km entirely undocumented, so it only partially compensates.

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 with scope: 'Run up to 50 grids in one call.' The batch constraint ('all with the same format: one listing with several keywords, or several listings with one keyword') makes it immediately distinguishable from the single-grid sibling run_grid without opening either 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?

Gives the operating condition (batch shape must be homogeneous) and routes to the alternative for the remainder of results ('call get_batch for the rest'). It does not explicitly say when to prefer run_grid over run_grids for a single grid, so it falls short of full 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description discloses the real behavioral traits: each run consumes the grid's credits, runs occur around 7 am Paris time, and the schedule auto-stops with an account email when the balance is exhausted. That cost and failure-mode context is exactly what 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 tight sentences with the core action front-loaded, then the cadence and parameter conventions, then cost and stop behavior. Every clause carries information an agent needs; nothing is padding.

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

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

With no output schema, the description still covers timing, cost, and termination, which is the important operational surface. It stops short of stating whether weekday and month_day are mutually exclusive per frequency, or how an agent later identifies the created schedule for update_schedule/delete_schedule.

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 carry the parameter meaning, and it largely does: weekday is 1=Monday through 7=Sunday, month_day spans 1 to 28, and frequency is weekly or monthly. It also clarifies that grid_id refers to an existing grid whose listing, keyword, format and radius are reused, though it does not explain grid_id's UUID form.

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

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

The description states a specific verb and resource: rerun an existing grid on a recurring weekly or monthly cadence, which separates it from the immediate-run siblings run_grid and run_grids. It never names update_schedule, delete_schedule or list_schedules, so the boundary with the other schedule-management tools is left to inference.

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?

Recurring execution is implied by 'every week ... or every month', so an agent can infer this is the tool for creating a standing schedule rather than a one-off run. There is no explicit when-to-use statement, no exclusions, and no pointer to update_schedule/delete_schedule for managing an existing schedule.

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-destructive, idempotent, non-read-only mutation, so the description needn't repeat the safety profile. It adds a genuinely useful behavior beyond the annotations: resuming also restarts a schedule that was stopped for lack of credits. It does not mention permissions or what happens to in-flight grid runs.

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, front-loaded with the primary action, with the restart caveat tucked into a parenthetical. No filler, nothing repeated from structured fields verbatim.

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 toggle with full annotations and no output schema, the description covers the core ambiguity (what pause/resume means and the credits-restart nuance). It stops short of explaining how to obtain schedule_id or what the call returns, which is acceptable given the annotations carry the safety profile.

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

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

Schema description coverage is 0%, so the description must compensate. It explains what each status value does, but the enum already enumerates 'active'/'paused', and the schedule_id parameter is never addressed (its UUID format is only in the schema). Partial compensation, hence baseline-level.

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

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

The description gives concrete verbs (pause, resume) tied to a concrete resource (a repeated grid/schedule), and it resolves the ambiguity of the tool name 'update_schedule' by stating exactly what kind of update it performs. This distinguishes it from sibling tools such as schedule_grid (creation) and delete_schedule (removal) without needing their schemas.

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 parenthetical mapping of status values implies when to use each mode (paused vs active), but there is no explicit when-to-use guidance, no exclusions, and no named alternatives for related tasks. Usage is inferable rather than stated.

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