Get Test Results By Table

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

The only annotation is openWorldHint=true, which is weak — it does not declare read-only or destructive behavior, so the description carries most of the transparency burden. The description adds useful behavioral context (filtering to a single table's test cases, pagination support, and the prerequisite that test execution must already be started), but it leaves the safety profile implicit — read-only must be inferred from the verb 'get' — and says nothing about result volatility between calls or failure behavior. No contradiction with the annotation.

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, all informative and front-loaded: purpose first, return scope second, pagination third, and the prerequisite last. The only minor waste is the overlap between sentence 1 ('filtered by specific table ID') and sentence 2 ('only test cases for the specified table'), and the pagination sentence partly duplicates schema content, but there is no fluff or 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?

With 10 parameters, no output schema, and only a weak openWorldHint annotation, the description covers the core workflow (filter by table, paginate, run tests first) and the rich schema covers parameter semantics. However, the agent is left without a picture of the return structure — 'test execution summary' is never concretely defined — and there is no guidance on polling/waiting for test completion or how this tool relates to the sibling summary tool. Adequate but with clear gaps.

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%: every parameter, including pagination mutual-exclusivity rules, defaults, limits, and the response_format enum, is documented in the schema itself. The description only echoes table filtering and pagination at a high level and adds no syntax or constraint information beyond the schema, so the baseline of 3 is appropriate.

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: 'Get test execution results filtered by specific table ID,' and elaborates that it returns 'only test cases for the specified table,' which meaningfully scopes the operation. It is clear about what the tool does, but it never names sibling tools like openl_get_test_results or openl_get_test_results_summary, and its use of the word 'summary' creates a slight overlap with openl_get_test_results_summary, so differentiation relies mostly on the name and the table-ID qualifier.

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 one explicit sequencing rule — 'Use openl_start_project_tests() first to start test execution' — which is genuinely useful for an agent planning a multi-step workflow. However, it provides no guidance on when to choose this tool over the near-siblings openl_get_test_results and openl_get_test_results_summary, and no conditions for when not to use it, so the selection among the three results tools 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.