aspro_call

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

The description reveals that only list and get methods are supported, that api_key is automatically added, and the exact return structure { status, ok, url, data }. It also indicates parameter shapes are entity-specific and require aspro_describe first, going beyond the readOnlyHint and openWorldHint annotations with concrete behavioral 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?

The description consists of five short, purpose-driven sentences with no redundancy. It front-loads the core purpose and each subsequent sentence adds a necessary operational detail, making it highly concise and well-structured.

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 provides the return shape, which is vital. It also gives parameter-passing conventions, the prerequisite of running aspro_describe, and contrasts with aspro_write. For a generic read tool with sibling tools, this is complete enough 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 description explains how to use id and query ('Pass the entity id via `id`, query-string args via `query`') and warns not to include api_key. It directs users to aspro_describe for the full parameter shape, which compensates for the schema's 50% coverage. However, it leaves module/entity/method semantics implicit and does not mention body, though the list/get restriction makes body usage less relevant.

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 'Read data from Aspro.Cloud' and immediately specifies 'the `list` and `get` methods only,' clearly defining the tool's scope. It also distinguishes it from aspro_write by stating 'Use aspro_write for create/update/delete,' providing explicit differentiation from the write 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 gives explicit when-to-use (reading via list/get), when-not-to-use (use aspro_write for writes), and a prerequisite (run aspro_describe first to learn parameter shapes). It also names an alternative tool for write operations, which is clear guidance.

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