ebms_get

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

With no annotations provided, the description carries the full burden and delivers meaningful behavioral disclosure: unselected reads return every field including computed ones, large reads risk a 2-minute limit, count defaults on for collections, and results indicate truncation. This is genuine operational behavior not present in the schema.

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?

Four sentences, front-loaded with purpose, followed by the most operationally critical guidance (select necessity and timeout risk), then count/truncation behavior, ending with a pointer to the skill for depth. Every sentence earns its place with zero filler.

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 9-parameter tool with no annotations and no output schema, the description covers the critical failure modes (unselected reads, 2-minute limit, truncation) and defers query syntax and install quirks to the ebms-api skill, which compensates for depth. Remaining gaps like expand/orderby semantics are reasonably left to schema and skill.

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 coverage is only 56%, so the description must compensate, and it does: path receives explicit syntax examples for both modes, select gets a mandatory-use directive with reasoning, and count gets its default-behavior note. These add real meaning beyond the schema's bare descriptions.

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 a specific verb-resource pair ('Read from EBMS OData') and concretely defines the tool's two invocation forms with real path examples ('ARINV' for collections, "ARINV('<AUTOID>')" for single records). It is clearly differentiated from writes/commands by its 'Read' positioning, though no sibling is named 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?

The description gives strong how-to-call guidance ('Always pass select', count defaults on, truncation is reported, query syntax is in the ebms-api skill), but it never states when to prefer this tool over ebms_write, ebms_command, or other siblings, nor does it give exclusions. Usage is implied rather than explicitly routed.

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