Retrieve full documentation for a DianaIE script command or constant, including usage, parameters, and return values; close matches are suggested for invalid names.
Full documentation (usage, parameters, return value) of one DianaIE script command or constant.
Args: name: exact command name, e.g. "createSheet"; close matches are suggested otherwise.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Changes observed during successful MCP inspections.
v0.10.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it enumerates what the response contains (usage, parameters, return value) and discloses the near-miss suggestion behavior, which an agent would otherwise have to discover by trial.
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 payload is front-loaded in the first clause, followed by the parameter note; nothing is redundant. The 'Args:' block is a raw docstring remnant that is slightly awkward but costs only one line.
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 lookup tool this covers the essentials: what goes in, what comes out, and the failure behavior. With no output schema, it would be stronger if it sketched the shape of the returned documentation (sections, length) so the agent knows what to expect and whether a follow-up read is needed.
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 must carry the single parameter, and it does: 'name' is the exact command name, with a concrete example ('createSheet') and a note that close matches are suggested on failure. The only gap is that it doesn't say whether names are case-sensitive or how constants differ from commands.
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 and resource: returns full documentation (usage, parameters, return value) for a single DianaIE script command or constant. It is clearly distinguishable from diana_api_search or diana_manual_search by scope (one exact entity), though it never names those siblings explicitly.
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?
Usage context is implied: you must already know the exact command name, and close matches are suggested otherwise, which nudges the agent toward a fuzzy fallback. It does not state when to prefer diana_api_search (unknown name) or diana_manual_read over this tool, so the routing decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.