cityjson_upload_chunkUpload large CityJSON files in parts by sending each sequential chunk with its upload ID and byte offset, allowing complete file transfer to the server.
Send the next chunk from the CityJSON file picker.
| Name | Required | Description | Default |
|---|---|---|---|
| bytes | Yes | ||
| offset | Yes | ||
| upload_id | Yes |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior, but it only weakly implies a stateful upload operation. It does not disclose sequencing requirements, retry or idempotency behavior, offset validation, chunk limits in practical terms, error handling, or what server-side state is changed.
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 single short sentence is direct and front-loads the operation without filler. Its brevity comes at the cost of essential protocol details, and the file-picker wording is less precise than describing a chunk of file data.
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 stateful chunked-upload tool with three undocumented required parameters, no annotations, and no output schema, the description is insufficient for reliable invocation. It needs the surrounding start/chunk/finish workflow, byte encoding and offset rules, and expected sequencing or response 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 0%, and the description does not explain any of the three required parameters. In particular, it omits where upload_id comes from, whether bytes is base64 or another encoding, and whether offset is a byte offset that must match the accumulated upload length.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a clear action and resource: sending the next chunk of a CityJSON upload. It distinguishes the operation from starting or finishing an upload, but 'from the CityJSON file picker' is vague and does not explain the upload-session workflow.
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 word 'next' implies that this is used after an upload has begun and that chunks are sent sequentially. However, it never explicitly directs the agent to call cityjson_upload_start first, repeat this tool until all bytes are sent, or use cityjson_upload_finish or cityjson_upload_cancel afterward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.