Convert a run_eval_contract() LLM Test Runner JSON result into a fully self-contained dark-themed HTML report with Pass/Fail badges, side-by-side Input/Output/Ground-Truth panels, evaluator score bars, and a radar chart. Returns the HTML as a string.
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes | The JSON object returned by run_eval_contract() |
| Name | Required | Description | Default |
|---|---|---|---|
| html | No |
Changes observed during successful MCP inspections.
Input schema / examplesAdded value: +[
+ {
+ "results": {}
+ }
+]Output schema / propertiesAdded value: +{
+ "html": {}
+}Input schema / properties / results / additionalPropertiesAdded value: +trueOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds meaningful behavior beyond that: it is a pure transformation whose output is a self-contained HTML string, which tells the agent not to expect a file write. It does not mention output size or that assets are inlined rather than linked.
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?
Two sentences, front-loaded with the transformation and then the return value; the feature list is dense but each item adds selection value. Slightly list-heavy but no filler sentences.
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 one required object parameter, full schema coverage, rich annotations, and an output schema in place, the description covers what an agent needs to call it correctly. Only marginal gaps remain (output size, whether the result object shape is validated).
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% and the single parameter's schema text ('The JSON object returned by run_eval_contract()') matches the description's wording, so the description adds no new syntax or structural detail. Baseline 3 applies since the schema does the heavy lifting.
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 (convert) and a precise input resource (run_eval_contract() LLM Test Runner JSON result) plus the exact output artifact (self-contained dark-themed HTML report). The enumerated report contents (Pass/Fail badges, Input/Output/Ground-Truth panels, score bars, radar chart) make it unmistakable versus siblings like ab_test_report or format_table.
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 explicit: it consumes the JSON returned by run_eval_contract(), which tells the agent this is the step that follows that tool. No exclusions or alternative reporting tools (e.g. ab_test_report) are named, so the agent must infer when a different report generator is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.