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

No annotations are provided, so the description carries the full behavioral burden. It mentions the configured token but does not disclose whether requests can mutate data, how the method affects safety, whether errors are surfaced, or what happens with POST versus GET; the examples include a job submission but no warning about side effects.

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

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

The description is front-loaded with a one-sentence purpose followed by compact, concrete examples. The examples are directly relevant and no sentence is wasted for a tool that must cover arbitrary ArcGIS endpoints.

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-level generic REST caller with no annotations and 0% schema description coverage, the definition is missing critical context: method semantics, mutation/safety guidance, error behavior, and when to prefer this over the many sibling tools. The output schema exists, so return-value documentation is appropriately not repeated in the 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%, so the description must fully compensate. It gives useful path and params examples, but the method parameter is never explained—even though choosing GET versus POST is critical for a generic REST caller—and the null/default behavior of params is not clarified beyond the schema.

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

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

The description states a specific verb and resource: 'Call any ArcGIS Online REST endpoint with the configured token.' It is clear what the tool does, but it does not explicitly differentiate itself from the many higher-level sibling tools such as query_hk_data or build_map.

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 examples imply several usage scenarios—searching items, fetching item JSON, querying feature services, and submitting GP jobs—but there is no explicit guidance on when to use this generic tool versus the domain-specific siblings, nor any stated exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden, and it does disclose useful traits: keyless basemap (no token needed), a localhost server is started, and the caller receives a URL to open. It omits server lifecycle (does it keep running, on what port, how is it stopped), failure behavior for invalid dataset_ids, and whether writes occur on disk.

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, with the core capability front-loaded and the post-call action (open the URL) as the trailing detail. 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?

An output schema exists, so return values need no explanation, and the description covers what the tool produces at a high level. But for a 4-parameter tool with 0% schema coverage and zero annotations, three of four parameters and the server's behavior remain undocumented.

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 4 parameters, so the description must compensate and largely does not: only dataset_ids is hinted at via 'from loaded datasets.' The default basemap ('imagery') is only obliquely gestured at by 'keyless basemap,' and title and labels are never mentioned at all.

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 ('Build an interactive 2D web map'), names the rendering stack (ArcGIS Maps SDK) and the input source (loaded datasets), and says it serves the result on localhost. It never explicitly contrasts with build_scene (3D) or export_static_map, so an agent must infer the 2D-vs-3D and interactive-vs-static split from adjectives alone.

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

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

'from loaded datasets' implies the prerequisite that data must first be loaded via load_hk_data, and 'open the returned URL in your client's browser' tells the agent what to do after. There is no explicit when-not guidance and no routing to build_scene or export_static_map for alternative output shapes.

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

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

With no annotations, the description carries the full burden, and it does disclose the important operational fact: 'Keyless (public imagery + Terrain3D elevation)', which tells the agent no credentials or setup are needed. It says nothing about side effects, whether a scene is persisted/published, or rendering cost, so the write/read profile remains ambiguous.

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, purpose front-loaded, then the use case. No filler, no repetition of the tool name, and the concrete examples land at the end where they help most.

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?

An output schema exists, so return values needn't be described, and the description adequately covers what the tool produces and when to reach for it. The remaining gap is invocation-level: no guidance on tilt values, when to enable labels, or allowed basemaps, which matters given a 0%-described 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 0% across 5 parameters, so the description must compensate and largely doesn't. Only 'tilted camera' loosely hints at the tilt parameter and 'imagery' at the basemap default; labels, title, and the meaning of dataset_ids are left entirely undocumented in both schema and 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+resource: rendering datasets as a 3D scene with terrain relief and a tilted camera. The opening 'Same datasets, rendered in a 3D scene' implicitly contrasts with the 2D sibling build_map, though it never names it. An agent can tell what it produces, if not exactly how it differs from build_map's static output.

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?

'Use it when relief, height or a walk-through view matters — towers, slopes, trails, coastal context' gives a concrete selection criterion tied to the user's intent. It stops short of explicitly routing the agent to build_map when a flat map suffices, so the alternative is implied rather than stated.

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

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

With no annotations, the description carries the burden and does well: it discloses that probe makes a live network round trip, reads only 2 KB, and is capped at 10 per call — the kind of cost/limit detail an agent needs before enabling it. It also flags a semantic trap (dct:modified is record revision date, not the statistical reference period). It stops short of describing failure behavior when a probe does not answer.

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 question, then structured into mode behavior and a distinct caveat paragraph. Every sentence carries information; only the question-form opener costs a little directness.

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?

An output schema exists so return values need not be explained, and the probe cost/cap and date-semantics caveat are covered. But one of four parameters (stale_after_days) is left completely undefined, which is a real gap for a tool whose central claim is judging staleness.

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 limit (the N oldest datasets), probe (live endpoint check with cost and cap), and the absence of dataset_id (list mode), but stale_after_days — which clearly drives the staleness verdict — is never mentioned 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 rhetorical question is immediately grounded by concrete explanation: it reports whether datasets are still served and how stale they are, including a catalogue-listing mode. This is clearly distinguishable from catalogue-search or data-loading siblings such as search_hk_data and load_hk_data, though the opening framing is less direct than a verb+resource statement.

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 usage modes explicitly: omit dataset_id to get a drift overview of the oldest datasets, or pass probe=True to actively verify the CSDI export endpoint answers. It does not name a sibling as an alternative, but the when-to-use context is clear enough to act on.

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

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

No annotations are provided, so the description carries the full burden. It discloses that no key is required and the return units, but omits accuracy, coordinate system expectations, coverage limits, and error behavior. Some value, but incomplete for a geospatial lookup.

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 purpose. The second sentence adds useful context without bloat, though it could be slightly tighter.

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?

Output schema exists, so return values needn't be explained, and the description mentions units and no-key access. However, gaps in coordinate format and accuracy/coverage limit completeness for a geospatial 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%, and the description only says 'at a coordinate' without specifying lat/lon format, order, projection, or valid ranges. Minimal compensation for the missing schema descriptions.

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

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

States a specific verb+resource (ground elevation at a coordinate), units (metres), and source (Esri Terrain3D). It does not explicitly differentiate from siblings, but the operation is unique among them.

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

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

Provides clear usage context: handy for hiking/relief context, trail comfort, slope warnings, alongside CSDI layers. No explicit when-not or alternatives are given, but the use case 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?

With no annotations, the description carries the behavioral burden and does disclose important traits: the result is a basemap-only PNG, CSDI features are excluded, and the ArcGIS alternative requires ARCGIS_TOKEN. It is less clear about file overwrite/naming behavior after writing into the workspace.

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 core operation and followed by invocation guidance and an important exclusion. Every sentence adds useful information without repetition.

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

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

The description covers the main invocation path and alternatives well, and the output schema means return values need not be explained. However, for a 5-parameter tool with no annotations and 0% schema description coverage, size and basemap behavior remain under-specified.

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

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

Schema description coverage is 0%, and the description compensates only partially. It explains bbox format and CRS and the bbox-vs-center+zoom choice, but leaves size, basemap values, and center format 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?

The description states a specific verb and resource: render a basemap-only PNG into the workspace. It clearly scopes the output to reports/decks/docs and explicitly separates this tool from build_map and ArcGIS print services.

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 explicit use cases (reports, decks, docs), tells the agent how to specify the area via bbox or center+zoom, and warns that CSDI features are not drawn. It also names the correct alternatives when data-on-basemap output is needed.

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

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

With no annotations, the description carries the burden and does well: it discloses that basemap tiles are remote URLs requiring internet, that features are real vector shapes, and that no API key, headless browser, or image library is needed. It stops short of saying what file/path is produced or whether multiple datasets merge into one page.

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 tight sentences, front-loaded with the output artifact and then the mechanism. No filler, though the line-wrapped formatting slightly obscures the structure.

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

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

An output schema exists, so return values need not be explained, and the behavioral picture is solid. The significant remaining gap is that a required parameter and the sizing/title options are undocumented anywhere.

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

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

Schema coverage is 0% across four parameters, and the description documents none of them explicitly. 'Basemap tiles are referenced by URL' hints at the basemap option, but the required dataset_ids, the title, and the max_px pixel ceiling are never explained.

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 artifact: 'Write a printable static map WITH the data drawn, as one self-contained SVG page.' The SVG/vector/print framing implicitly differentiates it from a raster export such as export_static_map, though no sibling is named 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?

The described use case (clean PDF printing from the browser print dialog) implies when to choose this tool, but there is no explicit 'use this instead of export_static_map when...' routing or any stated exclusion.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that this is an Esri public world geocoder and that no key is required, but it does not mention rate limits, error behavior, or how result limits are handled.

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 three short sentences and is front-loaded with the primary purpose. The reverse-mode note follows logically and every sentence adds useful information without waste.

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 output schema is present, so return values need not be explained. But with no annotations and 0% schema coverage, the description is incomplete: it omits the forward-geocoding parameter and the meaning of `max_results`, leaving an agent with insufficient guidance for a four-parameter 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 explain the four parameters. It documents reverse-mode `lon` and `lat`, but leaves `single_line` and `max_results` unexplained, including the forward geocoding input path.

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: geocode an address/place to coordinates, or reverse-geocode a coordinate to an address. It clearly separates the two modes and names the provider, making the tool distinct from the search/query/map 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 gives a mode-specific instruction for reverse geocoding: pass `lon` and `lat`. However, it does not explain when to use this tool versus alternatives such as `arcgis_request`, nor does it clarify how forward geocoding should select the appropriate input parameter.

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

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

With no annotations, the description carries the full behavioral burden, but it does disclose useful context: it uses Esri's public Geometry service and requires no key. It does not mention remote-call implications, rate limits, error behavior, or whether the input geometry is left unchanged, leaving meaningful gaps for an unannotated tool.

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

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

The description is short, front-loaded, and wastes no words. The operation breakdown is compact and directly tied to invocation choices.

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 output schema exists, so return values need not be described. Still, for a 7-parameter, unannotated tool with 0% schema description coverage, the description is only partially complete: it covers the main operation-to-parameter relationships but omits unit vocabularies, validation expectations, and service limitations.

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 usefully maps operation modes to parameters: project uses in_sr/out_sr, buffer uses distance with unit, and simplify uses max_deviation in input SR units. It still leaves unit allowed values, SR ID expectations, geojson format details, and optional-parameter behavior unexplained.

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 three specific operations (project, buffer, simplify) on a clearly scoped resource: one GeoJSON geometry. It also identifies the backing service, Esri's public Geometry service, so an agent can distinguish this computational geometry tool from the data, map, geocode, and export 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?

The operation-specific notes imply when each mode is appropriate: project for SR conversion, buffer for distance expansion, simplify for deviation reduction. However, there is no explicit when-to-use or when-not-to-use guidance and no comparison against siblings such as build_map or arcgis_request.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the return value is a summary rather than the data, that local copies are reused on later calls, that refresh=True forces a re-download, and that data is GeoJSON in WGS84. It does not cover failure modes, permissions, or dataset_id validation, so it is strong but not exhaustive.

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 core action and followed by the most important usage warning and caching detail. Every sentence adds practical value with no 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?

An output schema exists, so the description need not explain the summary structure. For a data-loading tool with no annotations, it sufficiently covers output type, local caching, refresh semantics, and downstream map usage. The main remaining gap is parameter semantics for dataset_id and name.

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 refresh=True behavior meaningfully, but leaves dataset_id format/valid values and the purpose of the name parameter undocumented. Only one of three parameters receives useful semantic explanation.

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: 'Download one CSDI dataset as GeoJSON (WGS84) into the workspace.' It also clarifies the scope and points to build_map for visualization rather than pasting features, which helps distinguish it from query/search 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 gives clear usage context: download data locally, then put it on a map with build_map(), and never paste features into chat. It also explains refresh behavior for re-downloading. It does not explicitly say when to use this instead of search_hk_data or query_hk_data, so it falls short of full alternative 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?

With no annotations, the description carries the full burden and does disclose the key behaviors: an external auth requirement (ARCGIS_TOKEN) and a real side effect (creating a hosted layer in an external account). It omits whether publishing overwrites an existing service, who can see the result, or how to undo 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, front-loaded with the action and destination, followed by the auth requirement and return shape. 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?

Because an output schema exists, the description needn't explain return values, though it helpfully does (itemId + service URL). The real gap is argument documentation: for a 3-param mutation with zero schema coverage, the description should at least say what dataset_id refers to and what title/tags control.

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 3 parameters, and the description names none of them. Neither dataset_id (required) nor title nor tags (with its 'CSDI,Hong Kong' default) is explained, so an agent learns nothing about arguments from either source.

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 (publish), a specific resource (a loaded CSDI dataset), and a specific destination (ArcGIS Online as a hosted feature layer). It is clearly separable from siblings like load_hk_data (local ingest) and build_map (visualization).

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 'loaded CSDI dataset' implies the prerequisite that load_hk_data must run first, which is useful context. However, no alternative is named and no explicit when-not-to-use condition is given, so guidance is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden. It discloses the hard 20-row cap and the matching semantics of `where` (case-insensitive field match vs. free text across all fields), which are real behavioral facts. It is silent on error/empty-result behavior and permissions, but the read-only nature is clear from 'Read'.

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 paragraphs with the core purpose front-loaded and no filler sentences; every clause either scopes the tool or routes to a sibling. The second paragraph blends query semantics with alternative-tool guidance, a minor organizational quibble.

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?

An output schema exists, so return values need not be described. However, with zero annotation coverage and zero schema property descriptions, leaving `fields` undocumented and no note on empty results means the definition is not fully sufficient for a 4-parameter 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 compensate. It explains `where` thoroughly and implies the row cap that governs `limit`, but `fields` is never explained despite being a non-obvious parameter (field projection). Roughly half the parameters gain meaning from 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?

The description opens with a specific verb and resource ('Read a FEW individual features') and states the scope limit (single value verification, capped at 20 rows). It also explicitly distinguishes itself from `summarise_hk_data` (aggregates) and `build_map` (visualize layer), so an agent can tell what this tool is for 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?

It gives clear when-to-use ('so a single value can be verified') and when-not-to-use ('this tool exists to check a value, not to dump a dataset'), and names two alternatives with their purposes. It does not address the closest sibling, `search_hk_data`, leaving the query-vs-search distinction to inference.

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

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

With no annotations, the description carries the burden and does well: it discloses local search scope, ranked results, Chinese synonym expansion, and the returned fields. It does not describe auth needs, rate limits, or pagination behavior, but for a local read-style search the key behavioral traits are mostly covered.

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 front-loaded with scope and browse behavior, then adds language expansion and the load_hk_data handoff. It has minor redundancy in saying both 'English or Chinese' and 'Chinese and English both work', but otherwise every sentence is useful.

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?

An output schema exists, and the description still helpfully notes the returned dataset_id and bilingual title. The main gap is lack of limit/offset guidance for paging, but the schema supplies defaults, so the definition is largely complete 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 0%, so the description must compensate for all parameters. It explains keyword semantics well, including empty keyword browse mode and bilingual expansion, but it never mentions the limit or offset parameters, leaving two of three parameters to be inferred from bare schema defaults.

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: search ALL ~1150 CSDI datasets. It specifies scope (local), language handling, ranking, and browse behavior, and it distinguishes the next step from the sibling load_hk_data by saying to feed the dataset_id there.

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: no keyword means browse, and results should be passed to load_hk_data. However, it does not explicitly contrast with siblings like query_hk_data or summarise_hk_data, so the agent must infer those 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?

With no annotations, the description carries the behavioral burden and does disclose important output behavior: a text table, data rows, a localhost chart URL, and no features in the chat. However, it does not discuss limits such as the top parameter, permissions, or whether the operation is purely read-only.

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 front-loaded with purpose and structured with focused bullets for each grouping/aggregation case. It is efficient overall, though the final return-value sentence could be tighter and partly duplicates what an output schema may cover.

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

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

The description gives enough to perform common aggregations and notes return behavior, and an output schema exists. Still, with five parameters at 0% schema coverage and no annotations, the unexplained top parameter and lack of explicit sibling routing leave meaningful gaps.

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 group_by, agg, and value_field with examples, but it leaves top and dataset_id semantics unaddressed, so coverage is only partial.

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 the tool answers a question about a dataset in text and with a bar chart, and it explains the summarization behavior without returning raw features. It is distinguishable from map/query siblings by its aggregate text-and-chart output, though it does not explicitly name those 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?

It gives clear usage scenarios: empty group_by for an overview, group_by with agg=count for feature counts per group, and sum/avg with value_field for totals or averages. It does not state when not to use this tool or explicitly route to siblings such as query_hk_data.

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