Download CityJSON content

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.