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

With no annotations, the description bears the transparency burden. It does disclose a meaningful output behavior: a regular CityJSON output is automatically opened and returned as a dataset_id. It does not cover side effects, error handling, or behavior when json_lines is true, leaving some ambiguity.

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 core action and followed by the output behavior, with no redundant phrasing. The mention of citygml-tools is minor but not damaging.

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 no-annotation, no-output-schema conversion tool with two parameters, the description gives the essential purpose and result but omits the meaning of json_lines and any constraints on source. It is minimally usable for the default path but not fully complete.

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

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

The input schema has no descriptions and the description has 0% parameter coverage, so the description needed to explain both parameters. It indirectly refers to the CityGML source dataset but never names the source property or explains that json_lines toggles a CityJSON Lines variant. The optional parameter is entirely 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 uses a specific action (convert), resource (CityGML 1.0/2.0/3.0 GML/XML to CityJSON), and explicitly names the direction, so an agent can distinguish it from sibling tools like cityjson_to_citygml. It also scopes the accepted input formats clearly.

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 clearly implies the tool is for converting CityGML inputs to CityJSON, with supported input versions stated. It does not, however, name alternative tools for cases like already-CityJSON inputs or reverse conversion, so exclusions are absent rather than explicit.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that coordinate values are not changed and that the tool returns a new dataset_id, covering the most important side-effect and output behavior. It does not detail error cases or whether the original dataset is mutated, but for this simple assignment operation the disclosure is reasonably complete.

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

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

The description is two short sentences with the core behavior front-loaded. The phrase 'using cjio' is mild filler that an agent does not need, but the overall size is appropriate and the return behavior is included.

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 tool with no output schema, the description covers the required semantic context: what the tool does, what it does not do, and what it returns. The schema covers dataset_id and requiredness. It could be more complete by explicitly stating whether the input dataset is left unchanged, but the description is adequate 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?

The dataset_id parameter is already documented in the schema, but the epsg parameter has no schema description. The tool description ties epsg to the 'EPSG reference' concept and clarifies it is not a coordinate transformation, which adds some meaning. However, it does not provide examples, valid-range guidance, or further semantics beyond what the parameter name already implies.

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 ('Assign/update the EPSG reference') and adds the key distinguishing constraint 'without changing coordinate values', which separates it from tools like cityjson_reproject. An agent can tell what this tool does and what it deliberately avoids doing.

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 'without changing coordinate values' provides clear usage context: use this when setting/updating CRS metadata rather than transforming geometry. It stops short of explicitly naming an alternative tool or saying 'use reproject when coordinate values must change', so it does not fully earn a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It communicates that this is a removal/mutation operation but does not say whether it is irreversible, whether it operates in memory, what happens if the attribute does not exist, or what the return value is.

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

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

The description is a single focused sentence with no filler. It front-loads the core action and resource, making it easy to scan.

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

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

For a mutation tool with no annotations and no output schema, the description is too thin. It omits important operational context such as the effect on the dataset, whether the operation is reversible, and what the tool returns, leaving an agent to infer key behavior from the sibling tool family.

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

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

Schema coverage is 50%, with dataset_id well documented but name only given a type and minLength. The description adds the useful context that the tool removes an 'attribute', which helps map the name parameter to an attribute name, but it does not fully compensate for the missing schema-level description of name.

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

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

The description clearly states a specific action ('Remove an attribute') applied to a specific resource ('CityObjects with cjio'). It is distinguishable from the sibling cityjson_attribute_rename, though it does not explicitly name it.

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

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

No guidance is given about when to prefer this tool over alternatives such as cityjson_attribute_rename or other transformation tools. The description does not mention prerequisites, effects, or operation 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?

With no annotations, the description must fully convey behavioral traits. It states that renaming happens across CityObjects, but does not disclose whether the operation mutates in place, whether changes need to be saved, what happens if old_name is missing or new_name already exists, or any other side effects. This is a significant gap for a mutation 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 a single, front-loaded sentence with no filler or redundant detail. Every word contributes to identifying the action, scope, and implementation context.

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

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

For a tool with no annotations, no output schema, and low parameter coverage, the description is too minimal. It does not explain the return value, whether the dataset handle is updated or returned, whether persistence is required via cityjson_save, or how collisions are handled. These are important for an agent to invoke the tool correctly in a multi-step workflow.

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

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

Schema description coverage is only 33%, with dataset_id documented but old_name and new_name left to their property names. The description 'Rename an attribute across CityObjects' helps map old_name and new_name to attribute names and clarifies scope, but it does not add constraints like uniqueness, existence requirements, or name validity rules. It partially compensates for the schema gap.

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

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

The description names a specific verb ('Rename'), a concrete resource ('an attribute'), and a clear scope ('across CityObjects'), which distinguishes it from sibling mutation tools like cityjson_attribute_remove. Despite the title being similar, the description adds operational specificity.

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 implies the tool should be used when renaming an attribute across CityObjects, but it does not explicitly state when to use it versus alternatives such as cityjson_attribute_remove, nor does it mention any prerequisites or exclusions. The usage context is present but not explicit.

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

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

With no annotations, the description carries the burden of explaining behavior. It states that the tool checks installation and callability, which is useful, but it does not disclose output format, possible side effects, or whether external processes are invoked. This is acceptable for a simple status check but not fully transparent.

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, purposeful sentences with no wasted words. The key action is front-loaded and the usage recommendation follows naturally.

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

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

For a zero-parameter diagnostic tool, the description covers what the tool does and when to run it. It does not specify the return value format, but the intent is clear enough; a brief note on output would make it fully complete.

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

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

The tool has zero parameters, so there is nothing for the description to add about parameter meaning. The baseline of 4 applies because no parameter documentation burden exists.

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

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

The description uses a specific verb ('Check') and names a specific resource ('external CityJSON/CityGML engines installed and callable'), clearly distinguishing this diagnostic tool from the many file-operation siblings. It also frames the tool's role relative to backend-dependent failures.

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

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

It explicitly tells the agent when to run this tool: 'Run this first when a backend-dependent operation fails.' It does not mention exclusions or alternatives, but there are no obvious status-check siblings, so the guidance is clear and actionable.

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 discloses that the tool removes vertices and returns a new dataset_id, which is helpful, but it does not explicitly address whether the input dataset is modified, deleted, or left intact. The phrase 'Returns a new dataset_id' suggests a new result, but side effects remain implicit.

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, action first, return value second, with no filler. The reference to cjio vertices_clean is relevant because it identifies the implementation and adds useful context without bloat.

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

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

For a tool with only one required parameter and no output schema, this is nearly complete: the input contract is defined by the schema and the return contract is stated in the description. The main missing piece is explicit input-dataset side-effect disclosure, but the operation's simplicity mitigates the gap.

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

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

The single parameter dataset_id is fully documented in the schema (100% coverage), so the description does not need to compensate. It adds no extra parameter-specific meaning beyond the schema, matching the baseline.

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

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

The description uses a specific verb ('Remove') and a concrete resource ('duplicate and orphan vertices'), and names the backend operation ('cjio vertices_clean'). This makes the tool's function unmistakable and clearly differentiates it from siblings like cityjson_filter_lod or cityjson_attribute_remove.

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

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

The description implies usage for cleaning vertices, but it does not explicitly state when to choose this tool over alternatives or point to any sibling tools. It leaves the selection criteria entirely to the agent's 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 to lean on, the description carries the full transparency burden and does a good job. It discloses that the operation is read-only via 'read-only SELECT-defined subset', and the schema further reinforces this by stating mutating SQL and semicolons are rejected. It also reveals the optional collection behavior and output as a 'CityJSON dataset handle'. This goes beyond merely stating the action, though it could additionally clarify that the export does not modify the database or describe error/edge-case behavior.

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

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

The description is a single, front-loaded sentence that leads with the core action and primary purpose, then appends the optional behavior. Every phrase earns its place: 'all objects or a read-only SELECT-defined subset' defines scope, 'from cjdb to CityJSONSeq' defines boundaries, and 'optionally collect...handle' defines the output mode. There is no padding, repetition, or irrelevant detail.

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

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

Given moderate complexity (a nested connection object, three parameters, and no output schema), the description gives a good overview but leaves the agent without important operational details. It does not explain what the returned 'handle' actually is, how connection credentials are used, or what happens when 'query' is omitted (though 'all objects' implies default). Since there are no annotations or output schema, these gaps are more consequential, placing it at an adequate but incomplete level.

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

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

Schema description coverage is only 33% (only 'query' gets description text), and the overall description partially compensates by explaining that the 'query' parameter selects an object_id subset and 'collect' toggles between CityJSONSeq and a normal CityJSON dataset handle. However, the 'connection' nested object remains undocumented in both the schema and description, and the description does not explain the all-objects default behavior with the same explicitness. It adds meaningful context for query/collect but leaves the most complex parameter underserved.

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

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

The description clearly states a specific verb ('Export'), a precise source ('from cjdb'), and an output format ('to CityJSONSeq'), distinguishing it from sibling export tools like cityjson_export by emphasizing the database origin. It also names the two operational modes: all objects or a SELECT-defined subset, and the optional collection behavior, leaving no ambiguity about the tool's core function.

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

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

The description gives clear context for when to use the tool: exporting either the entire cjdb content or a subset specified by a read-only SELECT query. It also explains the optional 'collect' behavior that changes the output form. However, it does not explicitly contrast this tool with alternatives such as cityjson_export or cityjson_db_import, so it stops short of full when-to-use vs 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?

No annotations are provided, so the description carries the behavioral burden. It usefully discloses that the tool converts to CityJSONSeq with cjio, imports via cjdb, and requires PGPASSWORD rather than a password argument. However, it does not disclose side effects on the database, such as whether existing tables are overwritten, whether the schema is created, or what the tool returns.

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 main action and the operational security requirement. There is no fluff or redundant restatement. Every sentence contributes necessary 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?

This is a database import operation with no annotations, no output schema, and incomplete parameter documentation. The description omits important context such as the meaning of attribute indexes, what happens on conflicts, whether the operation is idempotent, and what the success or failure response looks like. It is not complete enough for an agent to invoke the tool confidently in all realistic cases.

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

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

Schema description coverage is only 25%, with only dataset_id documented. The description does not explain the connection object fields, attribute_indexes, or partial_attribute_indexes beyond the schema's minimal structure. It adds the PGPASSWORD context, but that does not compensate for the lack of meaning for most parameters.

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

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

The description clearly states the action: convert the dataset to CityJSONSeq with cjio and import it into PostgreSQL/PostGIS using cjdb. This gives a specific verb, resource, and target database. It does not explicitly name sibling alternatives like cityjson_db_export, but the import direction is clear enough to distinguish it from export-related tools.

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

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

The description implies the tool is used when a dataset should be loaded into a PostgreSQL/PostGIS database. It also gives a prerequisite: the PostgreSQL password is supplied via PGPASSWORD. However, it does not explicitly state when to use this tool over alternatives, such as cityjson_db_export or other transformation tools.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses useful context: web-host streaming vs. standalone embedded resource, and the inline-size limit. It does not mention side effects, prerequisites, or error behavior, but the core delivery behavior is explained.

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 with no filler. The main purpose is front-loaded, and the delivery-mode relationship is stated compactly in the second sentence. Every clause contributes useful 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?

Because there is no output schema, the description wisely explains the return mechanism for both web-host and standalone clients, including the inline-size cap. It does not cover failure handling when the limit is exceeded, but for a two-parameter tool with a clear core flow, the description is largely complete.

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

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

The input schema already documents both parameters, with 100% coverage and clear descriptions for dataset_id and filename. The description adds no parameter-specific meaning beyond restating that the dataset is opened or transformed.

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

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

The description identifies a specific action ('Prepare ... for download') and the resource ('an opened or transformed dataset'), which is clear. It does not explicitly distinguish this from related siblings like cityjson_export or cityjson_save, but the delivery-mode detail provides enough differentiation.

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

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

The phrase 'opened or transformed dataset' implies the tool is used after an import or transformation step. It does not state when to prefer this tool over export/save alternatives or provide exclusions, so usage guidance is only implied rather than explicit.

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

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

There are no annotations, so the description must carry the behavioral disclosure burden. It only restates the export action and target formats; it doesnot disclose whether files are written to the destination, whether existing outputs are overwritten, whether the source dataset is moutated, or how the 'slopy' flag changes behavior.

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

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

Single sentence, no fluff, core information front-loaded. It is easy to scan and contains no redundant clauses.

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

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

For a tool with no annotations, no output schema, and two ambiguous parameters ('destination' and 'sloppy'), the definition is too minimal. An agent cannot reliably infer how to provide the destination or what behavior 'sloppy' toggles during export.

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

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

With only 25% schema description coverage, the description must compensate for undocumented parameters. It implicitly covers 'format' by listing output formats, but it adds nothing about 'destination' semantics or 'sloppy' behavior, both of which the schema also leaves 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 ('Export'), a specific resource ('an opened CityJSON dataset'), and the exact set of output formats (jsonl, obj, stl, glb, b3dm). This clearly differentiates it from transformation, validation, and broader save tools in the sibling list.

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 'opened CityJSON dataset' implies the tool should be used after an import/open operation, and the format list clues the intended use. However, it never explicitly says when to choose this over export-related siblings such as cityjson_db_export or the save tool, and it does not mention 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?

No annotations are present, so the description carries the burden. The phrase 'Fetch ... from the canonical ... URL' conveys a read-only remote retrieval and identifies the source. It doesnot, however, disclose behavior on invalid versions, missing extensions, or the exact returned representation, which would make the behavior more transparent.

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

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

The description is a single, focused sentence with no filler. The action and target are front-loaded, and the canonical URL is supplied as useful context without excess detail.

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

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

This is a low-complexity retrieval tool, and the required parameters and their formats are fully specified by the input schema. However, with no annotations and no output schema, the description is missing explicit return-value or error behavior guidance, so an agent must infer what the tool returns and how failures are signaled.

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

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

Schema description coverage is 0%, and the description does not explain the semantics of 'name' or 'version'. The parameter names are self-explanatory and the JSON Schema patterns define valid formats, but the tool description itself adds no meaning beyond what the schema already provides.

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

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

The description identifies a specific verb+resource: fetching a registered CityJSON Extension schema from the canonical registry URL. The title and description align, and the resource is concrete enough to distinguish this from most sibling tools. However, it does not explicitly contrast itself with cityjson_extensions_registry, which is the closest sibling for registry operations.

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 canonical registry URL and 'registered Extension schema' imply that this tool should be used when an agent needs a specific schema by name and version. There is no explicit statement about when to prefer cityjson_extensions_registry or other schema-related tools, nor any exclusionary guidance, so the usage context is implied rather than explicit.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It states 'Fetch' (suggesting a read operation) but does not describe output format, truncation behavior, registry size, rate limits, or any side effects. The max_chars parameter hints at length control, but the description does not explain how the tool behaves around 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?

The description is a single sentence with no filler, and it front-loads the core purpose. It is efficient for a simple fetch tool, though the optional clause could be slightly more precise about what 'context' means.

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

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

For a tool with no output schema and no annotations, the description should explain what the response contains and how the parameters affect it. It does not mention the output type, what the returned context looks like, or how max_chars caps the result, leaving important details for the agent to discover.

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 needs to compensate for documenting parameters. It only partially covers 'query' by referring to 'a search term,' but max_chars is completely unexplained. The description adds minimal meaning beyond the schema's raw property names.

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 has a specific verb ('Fetch') and a clear resource ('official CityJSON Extensions registry'), and the optional search-term context clarifies a distinct feature. However, it does not explicitly contrast with sibling tools like cityjson_extension_schema, so differentiation relies on 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?

The description implies the tool is for browsing the registry and optionally searching within it, but it gives no explicit guidance about when to use this tool versus alternatives. There is no mention of when not to use it or how it relates to sibling registry/extension tools.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that the output is a new dataset_id and that the operation keeps only one LoD, which implies the dropped LoDs are not retained in the result. However, it does not state whether the original dataset is mutated, whether it remains available, or whether the operation is reversible.

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

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

Two short sentences with no filler or repetition. The action is front-loaded, the implementation is named, and the return behavior is stated. Every sentence earns its place.

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

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

The tool is simple and the description covers the core purpose and output, but there are meaningful gaps: lod value semantics are not specified, there is no mention of side effects on the input dataset, and no output schema exists to clarify what the new dataset_id represents. Overall this is adequate but incomplete for fully reliable 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 50%: dataset_id is documented, but lod has no description. The tool description adds little beyond restating that lod refers to 'one level of detail', which is already implied by the tool name. It does not provide acceptable formats, examples, or allowed LoD values, so an agent may not know whether to pass '1', '2', '1.2', or another representation.

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 action ('Keep only one level of detail') on a CityJSON dataset and names the underlying cjio lod_filter operation. This clearly distinguishes it from sibling tools like cityjson_subset or cityjson_attribute_remove, which perform different transformations. The return statement also clarifies that this is a filtering step producing a new dataset handle.

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 when to use the tool: when a CityJSON dataset should be reduced to a single level of detail. However, it provides no explicit when-not-to-use guidance and does not mention alternatives, such as cityjson_subset or other transform tools. The usage context is interpretable but not directly 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 full burden. It does disclose a useful behavioral detail: the bounding box is computed from referenced vertices, and 'Return' implies a read-only operation. However, it does not describe error behavior for missing/invalid object IDs, response format, or whether any dataset state is affected.

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

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

A single sentence that is direct and front-loaded, with no unnecessary words. It conveys the core action and a key output detail efficiently.

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 output (complete CityObject and bounding box), and the schema provides dataset_id context. But with no output schema and no annotations, it lacks details on error cases, object_id provenance, and return structure beyond the high-level summary.

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

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

Schema description coverage is only 50%: dataset_id is explained, but object_id is only given a type and minLength. The description does not compensate by explaining what object_id represents, how it is formatted, or how to discover valid IDs.

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

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

The description states a specific action ('Return') and resource ('one complete CityObject'), and adds a distinctive output detail ('computed real-world bounding box derived from referenced vertices'). This clearly distinguishes it from sibling list/query operations that operate on many objects.

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

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

No guidance is provided about when to use this tool versus alternatives such as cityjson_list_objects or cityjson_query. It does not mention prerequisites, such as obtaining a valid object_id from another tool, nor when a different tool should be preferred.

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 behavioral burden. It discloses that the result is an immutable dataset handle and that import succeeds only if the inbox contains exactly one JSON file when filename is omitted. This adds meaningful behavior beyond the schema, though it does not cover error cases or persistence 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, zero filler, and the most important constraint (filename only, no path) is front-loaded. Every sentence earns its place.

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

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

For a tool with one optional parameter, no annotations, and no output schema, the description covers the input source, parameter constraint, omission behavior, and return type. It is not exhaustive about failure modes or the handle format, but it is sufficient for correct invocation in most cases.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds important parameter semantics beyond the schema: never pass an absolute path, and the behavior when filename is omitted. This meaningfully disambiguates the single optional parameter.

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

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

The description states a specific verb ('Import'), a precise resource ('a CityJSON file already placed in the configured input inbox'), and an explicit outcome ('return an immutable dataset handle'). It also contrasts with the sibling cityjson_list_imports and cityjson_import_text by anchoring on the inbox source, so the agent can distinguish it from related tools.

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

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

The description gives clear context: the file must already be in the inbox, and the filename must be passed rather than an absolute path. It also explains the ambiguity condition when filename is omitted. It does not explicitly name alternatives or state when not to use this tool, but the intended usage is unmistakable.

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 of behavioral disclosure. It adds a useful behavioral constraint: the complete JSON travels through the MCP request, explaining the size limit. However, it does not describe side effects, return value, or error behavior, so the disclosure is only partial.

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

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

Two concise, front-loaded sentences. The first sentence states the scope and limitation; the second gives the alternative. No waste, and the key warning is placed first.

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

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

For a low-complexity tool with two well-described parameters and no output schema, the description is sufficient to guide correct invocation: it covers the use case, size constraint, and preferred sibling. It omits return/result details, but not enough to degrade confident calling.

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 baseline is 3. The description adds the transport-related constraint relevant to the content parameter, but does not add meaning beyond what the schema already provides for either parameter.

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

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

The description clearly states the tool's purpose: importing small, programmatically supplied CityJSON documents as a fallback. It specifically distinguishes itself from the main cityjson_import sibling by naming the alternative and the condition that selects it.

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?

Explicitly says when to use this tool ('small programmatically supplied CityJSON documents only'), when not to use it ('normal chat attachments or large models'), and names the alternative (cityjson_import 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?

With no annotations, the description carries the full burden. It clearly describes the read-only nature by saying 'Return', and it enumerates the output categories, which goes beyond the title. However, it does not disclose error behavior for invalid dataset_ids, whether the dataset is modified, or any restrictions on when the information is available.

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 sentence, no fluff, enumerates the exact kinds of information returned. The key verb and resource are at the beginning, making the purpose immediately clear.

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 schema plus description fully covers how to invoke the tool (dataset_id) and what to expect (metadata, counts, types, LoDs, attributes, transform, extensions). No output schema exists, but the description gives a comprehensive preview of return contents. Minor gaps include error conditions and exact return structure, but these do not prevent correct selection or 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?

The schema description for dataset_id is thorough, specifying that it is a handle returned by specific tools, so schema coverage is 100%. The tool description doesn't add much parameter-level meaning, but it does not need to because the schema already documents the single parameter clearly.

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

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

The description uses a specific verb with a clear resource: 'Return metadata, object counts, types, LoDs, attribute names, transform and extensions for an opened dataset.' This distinguishes it from sibling tools like cityjson_list_objects or cityjson_get_object, which operate on individual objects rather than providing a dataset-level summary.

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 'for an opened dataset' implies the tool should be used after cityjson_open or cityjson_import, but it does not explicitly state when to prefer this over alternatives like cityjson_list_objects or cityjson_query. There are no specific exclusion criteria or comparisons to sibling tools.

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

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

No annotations are provided, so the description carries the burden, and it does disclose what the tool returns: 'Returns filenames only.' It alsotells the agent to never ask for an absolute path, which is useful interaction behavior. It could go slightly further by noting side-effect-free behavior, but the word 'list' plus the return statement make the safety profile reasonably clear.

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

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

Two short sentences, with the core purpose first, then usage conditions, then a user-interaction constraint. Every sentence adds value; there is no boilerplate or redundant text.

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

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

For an zero-parameter list tool with no output schema, this description is complete: it specifies the source (configured input inbox), the scope (JSON files), the return content (filenames only), the trigger conditions, and an explicit interaction constraint. Nothing critical is missing for an agent to select and invoke it correctly.

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

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

The tool has zero parameters, and the input schema is an empty object, so the schema fully covers the parameter surface. The description appropriately adds no unnecessary paramter detail; the baseline of 4 for a zero-parameter tool applies.

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

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

The description states a specific verb and resource: 'List JSON files in the configured input inbox.' This clearly distinguishes the tool from siblings like cityjson_open or cityjson_import by indicating it is a listing operation over the input inbox, not an open/import action.

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

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

It explicitly says when to use the tool: 'when the user did not name an attached/imported file or when cityjson_import reports multiple candidates.' It also instructs against asking for absolute paths, giving the agent clear behavioral guardrails. This is strong usage guidance for a simple listing 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?

With no annotations, the description carries the behavioral disclosure burden. It disclosees output contents and mentions filtering and pagination, which is useful. However, it does not clarify what 'selected attributes' means, how pagination results are returned, or any other behavioral constraints such as limits or read-only implications.

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

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

The description is a single concise sentence with no filler. The main action and output contents are front-loaded, and the filtering/pagination capabilities follow efficiently. Every phrase earns its place.

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

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

For a listing tool with no output schema, the description provides a reasonable summary of what will be returned and which capabilities are available. It is slightly incomplete because 'selected attributes' is vague and there is no statement about response shape or dataset prerequisites beyond the schema, but the core calling context is present.

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

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

Schema description coverage is only 25% (dataset_id only). The description compensates somewhat by referenceing filtering by CityObject type and pagination, which map to the 'types', 'limit', and 'offset' parameters. However, it does not explicitly define each parameter's behavior or add meaningful detail beyond the schema, leaving coverage incomplete.

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

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

The description clearly states a specific action ('List') and resource ('CityObjects'), and enumerates the returned fields (IDs, types, selected attributes, LoDs). Naming 'CityObjects' and supporting filtering/pagination is clear, but it does not explicitly distinguish itself from siblings like cityjson_get_object or cityjson_query, so it stops short of full sibling differentiation.

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

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

The description tells the agent the tool lists CityObjects, but gives no guidance on when to prefer it over alternatives such as cityjson_get_object, cityjson_query, or cityjson_info. No when-to-use / when-not-to-use or alternative routing is provided.

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

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

No annotations are provided, so the description must fully disclose behavior. It only says a new dataset_id is returned; it does not state whether the input datasets are mutated or remain open, whether merging requires compatible CRs/schemata, or whether the operation has side effects. For a transformation tool, these are material gaps.

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

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

Two short sentences with no redundancy. The operation is front-loaded and the return value is stated clearly. Every phrase contributes to the tool's selection and invocation.

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 tool with no annotations and no output schema, the description covers the core operation, the input princile, and the return value as a new dataset_id. It does not exhaustively describe merge semantics or error conditions, but an agent has enough information 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 description coverage is 0%, so the description carries more responsibility. It partially compensates by indicating the inputs are 'opened CityJSON datasets' and 'two or more', which maps to the dataset_ids array and minItems=2, but it does not explain that entries must be dataset handle strings. That detail only lives in the schema's item 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?

Description uses a specific verb 'Merge' on a specific resource 'CityJSON datasets', with a clear input condition ('opened') and method ('with cjio'). The sibling list contains no other merge-like tool, so the agent can distinguish this operation from alternatives.

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

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

The phrase 'opened CityJSON datasets' clearly indicates datasets must already be loaded/open, and 'two or more' sets the cardinality condition. It does not explicitly mention alternatives or exclusions, but the context is unambiguous enough for selection.

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. It mentions constraints like allowed root and chat attachment exclusion, but does not disclose side effects, whether the file becomes active state, what happens on success, or error behavior. 'Open' is ambiguous regarding its lasting impact.

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 fluff, with the core purpose and the key constraint front-loaded. The alternative is stated efficiently 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?

For a one-parameter tool with no output schema and no annotations, the description is mostly adequate but leaves open what happens after opening and how the resulting file is used by later tools. It also does not explain the allowed-root concept further. It is usable but not fully self-sufficient.

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

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

There is only one parameter and the schema already documents it fully (full server-visible path, not a chat attachment). The description mirrors that and adds the advanced/conventional framing, but no new parameter-level details.

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?

Clearly states the operation: opening a CityJSON file by a full server-visible path within an allowed root. It also distinguishes itself from cityjson_import, which uses a filename for inbox files.

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?

Explicitly says when to use this tool (advanced path-based access inside allowed root) and when to use the alternative (cityjson_import for files in the input inbox). This provides strong routing 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?

With no annotations provided, the description carries the behavioral burden. It helpfully discloses the supported attribute predicate operators (eq, neq, gt, gte, lt, lte, contains, in) and that thebbox is 2D. However, it does not disclose return shape, pagination behavior, how multiple predicates combine, or whether this is a read-only operation beyond what 'Query' implies.

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 concise and well-structured: one sentence states the purpose and filter capabilities, and the second sentence lists the supported predicate operators. There is no filler or redundant 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?

Given the tool has 7 parameters, no annotations, and no output schema, the description is minimally adequate but not complete. It explains the main query dimensions but omits attribute predicate object syntax, pagination semantics, how criteria are combined, and what the result contains, which an agent would need for reliable use.

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

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

Schema description coverage is only 29%, so the description must compensate. It maps the main params (ids, types, bbox, attributes) to filter categories and documents supported operators, which adds real value. However, it does not explain how attribute predicates are structured as an object or clarify the limit/offset parameters, leaving important gaps for correct invocation.

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

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

The description clearly states the operation ('Query CityObjects') and enumerates the query dimensions: IDs, types, 2D bbox, and attribute predicates. It is specific enough to understand the core function, though it does not explicitly distinguish it from closely related siblings such as cityjson_list_objects or cityjson_get_object.

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

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

No explicit guidance is given about when to use this tool versus alternatives. The description implies that it should be used for filtering CityObjects by the listed criteria, but it does not state exclusionary conditions or name sibling tools that might be more appropriate for listing all objects, fetching a single object, or subsetting.

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 of behavioral disclosure. It does reveal that a new dataset_id is returned, which is useful, but it does not state whether the original dataset is modified, whether the operation is destructive, or what side effects removing all materials may have.

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

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

The description is two short sentences with the core action first and the return value second. Every sentence earns its place, 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?

For a one-parameter transformation tool with no annotations and no output schema, this description is minimally sufficient: it tells the agent what is removed and that a new dataset_id is returned. However, it lacks side-effect information and usage context, so it is not fully complete for confident selection among the many transformation siblings.

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?

Schedule coverage is 100%, and the dataset_id parameter is already described in the schema as a dataset handle from previous import/open/transformation tools. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Remove') and a specific resource ('all materials'), and it names the implementation ('cjio'). It is clear enough to be distinguished from the similar sibling cityjson_remove_textures, though it does not explicitly contrast the two.

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

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

The description provides no guidance about when to use this tool versus alternatives such as cityjson_remove_textures or other transformation tools. It states only the operation itself, leaving usage conditions 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?

No annotations are provided, so the description carries the full burden. It states the core effect and that a new dataset_id is returned, but does not disclose whether the original dataset is modified, whether removal is irreversible, or any 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 short and front-loaded with the key operation. The phrase 'with cjio' adds marginal value, but otherwise there is no wasted text.

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

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

For a simple one-parameter tool, the description covers the operation and the return value. However, with no annotations, no output schema, and no mention of side effects or alternatives, it remains minimally adequate rather than complete.

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

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

Schema description coverage is 100% and the only parameter, dataset_id, is clearly documented in the schema. The description adds no parameter detail, but the baseline of 3 applies because the schema already handles the semantics.

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: 'Remove all textures'. This clearly identifies what the tool does and is enough to distinguish it from siblings like cityjson_remove_materials.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention cityjson_remove_materials, clean transformations, or any when-to-use/when-not-to-use 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?

With no annotations provided, the description carries the full burden. It discloses that the operation uses cjio, requires an existing CRS, and returns a new dataset_id, which communicates the non-in-place nature of the result. However, it does not mention whether the original dataset is modified, how the optional 'digit' affects transformation, or failure behavior if the source lacks a CRS.

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 concise sentences with no filler: the operation, the key prerequisite, and the result type. Information is front-loaded and each sentence serves a distinct purpose.

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 transformation tool with no annotations and no output schema, the description is missing meaningful context about the 'digit' parameter, side effects on the source dataset, and possible error conditions. The included return value and prerequisite are useful but insufficient for an agent to fully understand the tool's 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?

Schema description coverage is only 33%; only dataset_id has a schema description. The description helps with 'epsg' by stating 'target EPSG CRS', but provides no information about the 'digit' parameter, leaving its purpose ambiguous. It does not compensate enough for the low schema coverage.

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

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

The description uses a specific verb ('Reproject') and names the target resource ('coordinates to a target EPSG CRS'), making the operation clear. It implies a distinction from assign_crs by requiring the source to already define a CRS, but does not explicitly name sibling alternatives.

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

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

The statement 'The source dataset must already define a CRS' provides an explicit prerequisite, helping an agent decide when this tool is appropriate. It lacks explicit 'when not to use' alternatives, but the prerequisite offers clear contextual 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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It only says 'Copy' to a destination path and gives no information about overwrite behavior, side effects on the original dataset, error conditions, or what happens to associated resources like textures and materials.

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

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

The description is a single, front-loaded sentence with no filler or redundancy. It earns its place by giving the core operation and object, though it is concise at the expense of needed behavioral detail.

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

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

For a mutation-like save operation with no annotations, no output schema, and low parameter coverage, this description is too thin. It omits overwrite semantics, expected destination path format, and what the tool returns or confirms after saving, leaving an agent without enough context to invoke it confidently.

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

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

Schema description coverage is only 33%, and the description does not compensate. It hints at the destination parameter via 'destination path' and at the dataset_id via 'opened/derived dataset', but the overwrite parameter is completely unexplained, and destination lacks any semantic detail beyond its name.

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

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

The description clearly states the operation ('Copy') and target resource ('opened/derived CityJSON dataset') with an explicit outcome ('destination path'). It is specific enough to distinguish this from import/download/export siblings, though it does not explicitly name a differentiating alternative.

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

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

The phrase 'opened/derived' implies the tool applies to datasets already loaded or produced by other tools, offering some usage context. However, there is no explicit guidance about when not to use it or how it compares to alternatives like cityjson_export or cityjson_download.

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 must carry the behavioral burden. The verb 'Fetch' clearly indicates a read-only retrieval operation, and 'canonical ... JSON Schema' identifies the domain. It does not describe the response shape, error behavior, or whether the raw JSON is returned directly, but these are low-risk details for a simple fetch.

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

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

The description is a single, tightly worded sentence with no wasted content. It front-loads the action, resource, version, and selection method immediately.

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

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

For a one-parameter read tool with an enum and default in the schema, the description is mostly sufficient: it tells the agent what is fetched and how selection works. It lacks explicit return-value or usage-context details, and there is no output schema, but the low complexity makes this an acceptable gap.

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

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

Schema description coverage is 0%, and the description adds only 'by name', which is minimal. However, the single 'name' parameter is fully constrained by an enum and a default in the input schema, so the parameter is still unambiguous. The description adds modest context by framing these as canonical CityJSON 2.0.2 schemas, but does not explain how to choose among the enum values.

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 ('Fetch'), exact resource ('one canonical CityJSON 2.0.2 JSON Schema'), and selection mechanism ('by name'). The 'canonical' qualifier helps distinguish this from related schema or specification 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?

No explicit usage guidance is provided, and no alternative tools are named. The phrase 'canonical CityJSON 2.0.2' implies official schemas, but the agent is left to infer when to choose this over sibling tools like cityjson_extension_schema or cityjson_spec_read.

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 disclosure burden. 'Return' clearly signals a read-only information retrieval operation, and 'bundled' implies the data is local rather than fetched remotely. It identifies what is returned without detailing exact formatting, but for a zero-parameter informational tool that is sufficient.

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 with no redundant phrasing; the verb and object are front-loaded so an agent immediately knows what the tool does. Every word earns its place.

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

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

Given the low complexity, zero parameters, no output schema, and no annotations, the description is nearly complete for safe invocation. It names both output components, outline and canonical URLs. A brief pointer to cityjson_spec_read for full content would improve context, but is not required for correct usage.

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

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

There are zero parameters, so the baseline is 4. The description does not need to explain parameter behavior, and the empty schema leaves nothing unknown for caller preparation.

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 ('Return') and a concrete resource: the bundled outline and canonical URLs for the current CityJSON specification and schemas. This is clearly distinct from siblings like cityjson_spec_read and cityjson_schema_read, which imply reading actual content rather than an outline and URLs.

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 a quick-reference retrieval use, but there is no explicit when/when-not guidance or mention of alternatives. An agent is not told to choose this over cityjson_spec_read or cityjson_schema_read, though the purpose makes the intended context reasonably inferable.

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

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

The description conveys a read-only operation and the conditional behavior based on whether a query is supplied. With no annotations and no output schema, though, it does not explain how max_chars affects the returned text, what format the text takes, or how the context window is determined.

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

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

The description is a single front-loaded sentence with no filler. It efficiently covers the source, version, and two output modes without wasting 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?

For a simple read tool this is mostly adequate, but it leaves gaps around max_chars semantics, output format, and how this relates to sibling spec tools. The absence of annotations and an output schema increases the burden on the description, and those gaps remain.

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 query parameter gains some meaning from 'context window around a search query' and 'beginning' when absent. However, max_chars is not mentioned at all, and with 0% schema description coverage, the agent must infer its behavior solely from the parameter name and constraints.

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 action ('Fetch'), a specific resource ('canonical CityJSON 2.0.2 living specification'), and a clear output behavior (beginning or context window around a search query). This distinguishes it from sibling tools like cityjson_spec_outline and cityjson_schema_read, which target other spec artifacts.

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 use case is implied: retrieve spec text, optionally near a search query. However, the description never states when to choose this over cityjson_spec_outline or cityjson_schema_read, and it provides no exclusions or alternative conditions.

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

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

With no annotations, the description bears the full responsibility for behavioral disclosure. It says a new dataset_id is returned, which is useful, but it does not explain whether the original dataset is modified, whether subsetting is deterministic, whether method combos are allowed, or what side effects or prerequisites exist. For a transformation tool, this leaves important behavior unknown.

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 concise: two sentences with no filler. The main action and output are front-loaded, and the list of subsetting methods is easy to parse. It earns its place, though it sacrifices enough detail to cap the score below 5.

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

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

Given seven parameters, no output schema, no annotations, and low schema coverage, the description is too thin to fully enable correct invocation. It does not explain required dataset_id provenance, valid combinations of subsetting criteria, coordinate/reference constraints beyond bbox, or the exact meaning of 'exclude'. An agent would likely need trial and error or additional external knowledge.

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

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

Schema description coverage is only 29%, so the description must compensate for undocumented parameters. It does clarify that 'random' means random count and 'types' refers to CityObject types, and it names bbox, radius, and IDs. However, it never addresses the 'exclude' parameter, does not explain how criteria combine, and leaves parameter formatting/units to inference.

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

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

The description clearly states the tool creates a derived CityJSON subset and enumerates the selection methods: IDs, bbox, radius, random count, and CityObject types. It goes beyond the title by specifying the tool (cjio) and the output (new dataset_id), but does not explicitly differentiate it from sibling tools like cityjson_filter_lod or cityjson_query, which may also produce subsets.

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

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

The description implies usage for subsetting CityJSON data by several common criteria, giving an agent a reasonable sense of when to invoke it. However, it provides no explicit guidance about when not to use it or which sibling tool might be more appropriate for related tasks such as LOD filtering, querying, or exporting.

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 provided, the description carries the full burden. It does add useful behavioral context: the conversion is delegated to 'citygml-tools' and the installed version influences the target encoding. However, it does not disclose whether the source dataset is modified, whether an output file is created, what happens in the output_directory, or what the tool returns.

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

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

The description is two sentences long, front-loaded with the core conversion intent, and every sentence adds useful information. The second sentence about citygml-tools version and target encoding is relevant and non-redundant.

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 is not fully complete for an agent: there is no output schema, no annotations, and the description omits how optional parameters affect behavior, what the result of the conversion is, and how output is stored or returned. For a conversion tool with three parameters and no structured output metadata, this leaves significant 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 low: only dataset_id is described, while crs_name and output_directory have no schema descriptions. The tool description does not compensate by explaining these parameters, leaving their exact semantics ambiguous, especially crs_name.

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 action ('Convert'), the input ('an opened CityJSON dataset'), the output format ('CityGML'), and the implementation tool ('citygml-tools'). This clearly distinguishes it from the reverse sibling tool 'citygml_to_cityjson' and from import/export variants that do not perform this exact conversion.

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 clearly establishes the prerequisite that the dataset must already be opened/imported, which tells the agent when the tool is applicable. It does not explicitly mention alternative tools such as 'cityjson_export' or when not to use this tool, so it stops short of full routing 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?

No annotations are provided, so the description must disclose behavior. It does state that without minxyz jio falls back to the model minimum and with minxyz it shifts relative to the supplied minimum. However, it does not say whether the transformation modifies data in place, returns a new object, or affects the coordinate reference system, which are material for a transform 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 two sentences with no filler, front-loading the main operation and then explaining the optional parameter's effect. The first sentence is somewhat redundant with the title, but the whole description remains efficiently sized.

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

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

For a transformation tool with no annotations and no output schema, the description leaves significant gaps: it does not state whether the dataset is modified in place or a new handle is returned, how this differs from reprojection/CRS assignment, or what success/errors look like. The algorithm is explained, but the operational context an agent needs is incomplete.

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

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

Schema coverage is only 50%; dataset_id is described in the schema, while minxyz is not. The description adds meaning to minxyz by explaining its role and the default when omitted. It does not detail the ordering or units of the three numbers, but the core semantic is conveyed.

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

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

The description identifies a concrete operation: translating CityJSON coordinates via cjio, with an explicit explanation of how minxyz affects the shift. Although it does not explicitly contrast with sibling tools like cityjson_reproject or cityjson_assign_crs, the phrase 'shifted relative to the supplied minimum' makes the coordinate-translation intent 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?

There is no explicit guidance on when to use this tool instead of the many sibling transformation tools, nor any mention of alternatives or excluded cases. The description only explains the behavior with and without minxyz, which is parameter guidance rather than tool-selection 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the default is a 'robust triangulator' and sloppy is a fallback, but it does not disclose whether the dataset is modified in place, what is returned, what failure modes exist, or any 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?

Two short sentences with no filler. The first states the tool's purpose, and the second gives conditional parameter guidance. Every sentence earns its place.

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

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

With no annotations and no output schema, the description is too thin. It does not explain the return value, whether the operation mutates the input dataset, or how the result fits into the broader cityjson workflow, leaving an agent without enough information to predict the outcome of 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 only 50%, but the description compensates for the undocumented sloppy parameter by explaining that it should only be used when the robust triangulator fails. dataset_id is already well-described in the schema with its valid sources.

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: 'Triangulate surfaces with cjio.' This clearly differentiates the action from related tools such as cityjson_clean_vertices or cityjson_reproject, but it does not explicitly contrast it with any sibling.

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 use when a CityJSON dataset's surfaces need triangulation and gives explicit guidance about when to set sloppy=true. However, it does not state when not to use the tool, mention alternatives, or describe prerequisites beyond what the schema provides.

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 bears full responsibility for disclosing behavior. It states the outcome but not whether the input dataset is modified in place, whether a new dataset handle is returned, whether the operation is reversible, or any side effects. This is a significant transparency gap for a transformation 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?

One concise sentence that states the action, input, and target result with no filler. It is appropriately front-loaded and efficiently sized.

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

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

With no output schema and no annotations, the description should clarify the return value or mutation behavior of the upgrade operation. It does not explain what happens after upgrade, how the result is used, or whether the original dataset handle remains usable, leaving an agent uncertain in a processing pipeline.

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% for the single parameter, so the schema already documents dataset_id. The tool description does not add additional parameter-level detail, but none is needed beyond the baseline.

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

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

The description uses a specific verb ('Upgrade') and resource ('older supported CityJSON file') and defines the target state ('version supported by the installed cjio'). This clearly distinguishes it from sibling transformation tools like translate or reproject, which do not perform version upgrades.

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 intended use case is implied: use it when a CityJSON file is older than the version cjio supports. However, the description does not explicitly state when not to use it, how to detect whether an upgrade is needed, or mention any alternative approach.

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 it does so well: it names the two validators run, explains that the result is combined, and directs the agent to geometry.reportSummary for the complete invalidObjectIds list. It stops short of explicitly stating whether the operation is read-only or what other result fields exist, but the core behavior is clearly disclosed.

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, each earning its place: the first states the action and scope, the second supplies the most useful operational detail (where to find invalidObjectIds). No fluff 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?

With no output schema, the description appropriately highlights the key return field, geometry.reportSummary, and explains its reliability for follow-up subsets. It is sufficient for confident invocation, though a bit more detail about the overall result shape would make it fully complete.

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

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

There is only one parameter, dataset_id, and the schema already describes it for 100% coverage. The description does not add parameter-specific guidance beyond implying the dataset is the target of validation, so the baseline of 3 applies.

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

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

The description states a concrete action: run cjval and val3dity and produce a combined structural plus geometric validation result. This clearly distinguishes it from siblings like cityjson_validate_schema and cityjson_validate_geometry, which cover only one of those aspects.

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 tool is positioned as the holistic validation entry point by advertising both structural and geometric checks in one call. That gives the agent a clear reason to pick it over the split validate_schema/validate_geometry siblings, though it does not explicitly spell out when to prefer 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 present, the description carries the full burden of behavioral disclosure. It clearly explains the validation scope and the return behavior: a detailed report plus a compact reportSummary with invalid object IDs and error-code counts. It does not mention side effects, but 'validate' strongly implies read-only analysis and no dataset mutation.

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

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

The description is two sentences with no filler. It front-loads the core purpose and validation method, then summarizes the output contract. Every sentence earns its place.

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

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

For a two-parameter tool with no output schema, the description covers most essential context: what gets validated, how, and what the return contents are. The only meaningful gap is the undocumented verbose parameter and the lack of explicit guidance about when not to use this tool in favor of sibling validators.

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

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

Schema description coverage is only 50%: dataset_id is documented, but the verbose parameter has no schema description and is not mentioned in the tool description. The agent is left to infer what verbose changes about the report. Since the description does not compensate for this gap, parameter semantics are incomplete.

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 ('Validate'), a concrete resource ('CityJSON 3D primitives'), and the validation approach (val3dity, ISO 19107, CityJSON-specific geometric checks). This clearly differentiates it from sibling validation tools like cityjson_validate_schema, which target schema validation rather than geometry primitives.

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 when the tool is appropriate: when validating 3D geometry primitives rather than the overall schema or general CityJSON file validity. However, it does not explicitly name alternatives such as cityjson_validate_schema or cityjson_validate, nor does it state conditions for choosing one over another.

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 disclosure burden. It disloses the use of the official cjval validator and enumerates the checks performed, which is useful. It does not state whether any state is modified, whether external resources are needed, or what the result/returned information looks like, leaving the behavioral picture partially incomplete.

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, dense sentence front-loads the operative verb and resource and structures the validation scope in a colon list. Every clause adds information and nothing is redundant.

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 is adequate for a simple validation tool with two parameters, and the dataset_id schema covers the core input. But without an output schema it does not describe what the caller receives (e.g., pass/fail, list of errors), nor does it clarify how it relates to the cityjson_validate sibling, which an agent would likely need when selecting among the validation-related tools.

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

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

The schema already documents dataset_id well as a handle returned by specific tools. The description adds context about extensions but does not clarify the format, source, or use of the extension_schemas array, whose schema description is still missing. At 50% schema coverage the description compensates only partly.

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 ('Validate'), a concrete resource ('a dataset'), and names the exact validation scope: JSON syntax, CityJSON schemas, extensions, and structural checks. It does not, however, distinguish itself from the sibling tool 'cityjson_validate', so it falls short of full sibling differentiation.

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

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

The description clearly implies this is the tool for full cjval-based validation of a CityJSON dataset, but it gives no explicit when-to-use versus alternatives such as cityjson_validate_geometry or cityjson_validate. The intended usage is inferable, not stated.

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