RewindMap

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

Annotations already declare this a safe, idempotent, non-open-world read, so the bar is lower. The description goes beyond them by disclosing the critical trait that rendering happens in the visitor's browser and that the tool returns only a link, never a video file, plus the watermarked-MP4 download step. It stops short of auth or rate-limit details.

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

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

Three sentences, front-loaded with the core purpose and artifact. Each sentence carries distinct information (what the clip shows, what the visitor gets, what the tool returns), though the dense phrasing is slightly long for the amount of structured data already available.

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 explain the return value, and it does so explicitly ('returns the link only, never a video file'). With 8 parameters at 75% schema coverage, the remaining gap is minor, making this largely complete for an agent to call it correctly.

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

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

Schema coverage is 75%, so the schema already documents most parameters including defaults and bbox ordering. The description adds conceptual meaning (borders/event layers, year transitions, title, labels, vertical vs landscape) but no format or constraint details beyond the structured fields, matching 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?

States a specific verb (build a link) plus the resource (RewindMap short-video maker with a map clip) and describes exactly what the link produces. It is clearly distinguishable from find_polity, search_events, and world_at_year, which retrieve data rather than generate a shareable artifact.

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

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

The description implies usage by explaining what the generated link does, but never states when to choose this over the sibling tools (e.g. 'use this to produce a shareable clip, use world_at_year for raw data'). No explicit alternatives or exclusions are offered, so the agent must infer the routing.

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, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: substring, case-insensitive matching over labels/aliases, and the fact that the result set includes lifespan, every border snapshot with bounding box, and links. It does not say what happens on zero or multiple matches.

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: the first front-loads the lookup keys and matching semantics, the second states what is returned. No filler or restatement of the tool name.

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 takes on the burden of describing returns (lifespan, border snapshots with bounding boxes, links) and the matching rules. The only gaps are ambiguity handling for multiple matches and the empty-result case, which are minor for a read-only lookup.

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 schema baseline is 3. The description adds meaning beyond the schema's terse 'Name, e.g. Ottoman or a QID' by clarifying that matching also covers all Wikidata labels and aliases and is substring/case-insensitive, which materially affects how the agent should phrase the query. The 'lang' parameter is left entirely to the schema.

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

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

The description gives a specific verb and resource ('look up a state or empire') plus the exact matching keys (name, Wikidata labels/aliases, QID), so the agent immediately knows this is an entity-resolution tool rather than a temporal or event tool. It stops short of naming sibling tools like world_at_year to explicitly route the agent, so it lands just below 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?

Usage is implied by the lookup semantics and the accepted identifier forms, which tells the agent it should be used when the user names a polity. There is no explicit when-to-use/when-not statement and no mention of alternatives such as world_at_year for time-based queries or search_events for event lookups.

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/non-destructive, so safety is covered; the description adds genuinely new behavior: result ordering by date, precision-gated date matching, and the temporal floor (UCDP since 1989, heritage sites undated). It stops short of describing result shape or how limit/pagination interacts with large result sets.

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 what is searched, then matching semantics, then sort order — three sentences, no filler. The dataset enumeration is long but each item is load-bearing for understanding coverage, so little 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 9-parameter, nested-object tool with no output schema and no required parameters, the description covers the hard parts (date semantics, dataset coverage, ordering) while annotations cover safety. It omits any indication of the returned record shape and how limit defaults/caps interact with the result set, which is the main 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?

Schema coverage is 78% (near the high baseline), and the description still adds meaning the schema does not: how from/to bounds behave against imprecisely recorded dates and that undated records are excluded by any date bound. The layer parameter carries only an enum in the schema and its values are only inferable from the dataset list in the description.

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 (search) plus resource (map events) and enumerates the six underlying datasets with their provenance (Wikidata battles, UCDP, Smithsonian GVP, NOAA, meteorite falls, UNESCO). This scope is distinctive enough to separate it from siblings like world_at_year (a point-in-time snapshot) and find_polity 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?

Gives concrete conditions governing effective use: month/day bounds only match events recorded at that precision, and undated heritage sites match only dateless searches. That is a real when-to-use/when-not rule, but it never names an alternative tool or states when another sibling should be preferred instead.

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 read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful non-structured context: the dataset is incomplete and an empty result must not be read as historical absence, which materially changes how an agent reports the result.

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, no filler, and the core capability is front-loaded ahead of the caveat. Every clause carries 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 enough: it characterizes the returned entities and warns about empty results. It could say more about result shape or whether the snapshot includes geometry, but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents bbox, lang and the negative-year/BC convention. The description only restates the year and optional region at a high level and says nothing about the lang parameter, 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?

States a specific verb ('List') plus the exact resource (states, empires and cultures with an OpenHistoricalMap border snapshot) and scopes it by year and optional region. Very clear on its own, but it never names an alternative like find_polity, so the agent must infer sibling routing from the singular-vs-list 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 by the scope ('in a given year, optionally overlapping a region'), but there is no explicit when-to-use or when-not-to-use guidance relative to find_polity or search_events. The coverage caveat is about interpreting results rather than about choosing this tool.

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