Get Cube

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

Annotations already disclose readOnlyHint=true and openWorldHint=true, so the safety profile and open-world response behavior are covered. The description adds no further behavioral context such as error behavior, auth requirements, or what exactly counts as 'details', but it does not contradict the annotations.

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 front-loaded sentence contains the verb, resource, scope, and key parameter concept with zero filler or redundancy. This is appropriately sized for a simple read-only lookup tool.

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 2-parameter read-only fetch with full schema coverage and safety annotations, the description is mostly adequate. However, since there is no output schema, 'details' is vague about the return shape, and the existence of get_cube_ssh suggests a potential boundary that the description does not clarify.

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%: cubeId is documented as the id to operate on and spaceId notes its optional default behavior. The description's 'by id' merely reinforces the schema, adding no new semantic detail beyond what the input 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 states a specific verb ('Get'), a precise resource ('details for a single Cube'), and the access mechanism ('by id'). This clearly differentiates it from list_cubes (plural listing) and from mutation tools like create_cube or delete_cube.

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 'single Cube by id' implies the tool is appropriate when an agent already has a cubeId and wants that one cube's details, rather than listing all cubes. However, there is no explicit guidance about when to prefer get_cube_ssh, or any exclusion or alternative conditions.

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