Skip to main content
Glama

owp_run_tests

Execute tests after verifying the signed request, then write an execution receipt to the ledger and save evidence files for audit.

Instructions

Run tests, write an execution receipt to the ledger, and save test evidence files.

The ledger coordinator checks the signed request before execution. The configured executor writes execution artifacts under the runtime and evidence roots supplied in the payload.

Args: ledger: SQLite ledger file that receives the execution receipt. payload: JSON string of the run-tests execution payload (must include the signed AgentRequest and typed arguments).

Input Schema

NameRequiredDescriptionDefault
ledgerYes
payloadYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

B3.4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden and does a good job stating that the ledger coordinator checks the signed request and that execution artifacts are written under runtime and evidence roots. It still omits failure modes, permission requirements, and reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and side effects, then follows with useful process context and an Args section. It is appropriately sized, though the Args section is somewhat formal and could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main action, side effects, and parameter roles. However, for a tool that runs tests and writes execution artifacts, it remains vague about what tests are run, where test configuration comes from, and what happens on failure, leaving meaningful gaps even with an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the ledger as a SQLite file receiving the execution receipt and the payload as a JSON string containing a signed AgentRequest and typed arguments, but it does not specify the payload structure in detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a clear verb and resource: it runs tests, writes a receipt, and saves evidence files. It distinguishes itself by explaining the receipt and evidence side effects, but it does not explicitly contrast itself with siblings such as owp_run_verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It mentions that the payload must include a signed AgentRequest, which is a prerequisite, but it gives no guidance on when to use this tool versus alternatives such as owp_run_verification. There are no exclusions or contextual selection cues.

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