Skip to main content
Glama
shaun0927

OpenChrome

by shaun0927
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

oc_assert

Evaluate an outcome contract assertion against a provided snapshot, persist the redacted result, and return a pass/fail/inconclusive verdict with failed leaf assertions.

Instructions

Evaluate a single Outcome Contract assertion against caller-supplied evidence (snapshot), persist the redacted result for bounded retrieval, and return verdict pass/fail/inconclusive plus failed leaf assertions. Core-tier single-call surface; retry and escalation live in the pilot runtime.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsNoReserved for future contract templating. Ignored in v1.11.
contractNoAssertion DSL object (see src/contracts/types.ts: kind ∈ url|dom_text|dom_count|network|screenshot_class|no_dialog|image_qa|performance|console|and|or|not). Validated via validateAssertion() before evaluation.
evidenceNoPre-captured page evidence. Required for evaluation; without it the verdict is `inconclusive`.
contract_idNoOptional identifier for a registered contract in the canonical outcome-template registry. Mutually exclusive with `contract`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.13.0
    • changedInput schema / properties / contract / description
      Previous value: -"Assertion DSL object (see src/contracts/types.ts: kind ∈ url|dom_text|dom_count|network|screenshot_class|no_dialog|image_qa|and|or|not). Validated via validateAssertion() before evaluation."New value: +"Assertion DSL object (see src/contracts/types.ts: kind ∈ url|dom_text|dom_count|network|screenshot_class|no_dialog|image_qa|performance|console|and|or|not). Validated via validateAssertion() before evaluation."
    • changedInput schema / properties / contract_id / description
      Previous value: -"Optional identifier for a registered contract. Reserved for forward compatibility — currently no registry exists, so callers must supply `contract` inline."New value: +"Optional identifier for a registered contract in the canonical outcome-template registry. Mutually exclusive with `contract`."
    • addedInput schema / properties / evidence / properties / provenance
      Added value: +{
+  "description": "Optional caller-supplied capture provenance persisted with the result. `target_id` and `worker_id` identify the source target; `captured_at` is an ISO timestamp.",
+  "properties": {
+    "captured_at": {
+      "description": "Optional source capture time as an ISO timestamp.",
+      "type": "string"
+    },
+    "target_id": {
+      "description": "Optional source target/tab ID.",
+      "type": "string"
+    },
+    "worker_id": {
+      "description": "Optional source worker ID.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
    • changedInput schema / properties / evidence / properties / snapshot / description
      Previous value: -"Snapshot fields. Provide the subset the assertion needs: `url` (string), `dom_text` (string | { selector: string|null }), `dom_count` ({ selector: number }), `network` (NetworkLogEntry[]), `screenshot_png_base64` (base64 PNG), `has_open_dialog` (boolean)."New value: +"Snapshot fields. Provide the subset the assertion needs: `url` (string), `dom_text` (string | { selector: string|null }), `dom_count` ({ selector: number }), `network` (NetworkLogEntry[]), `contract_facts` (bounded facts from performance_metrics/console_capture), `screenshot_png_base64` (base64 PNG), `has_open_dialog` (boolean)."
  2. First observedv1.12.8

TDQS

A3.9/5.0
Behavior4/5

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

The description discloses that the tool persists a redacted result and returns a verdict, which are behavioral facts not captured by the annotations (all false). It also mentions bounded retrieval and single-call scope. This goes beyond the annotations, which are empty, so the description carries the burden and meets it reasonably, though it could be more explicit about side effects of persistence.

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 two sentences and front-loads the core purpose. The second sentence about 'Core-tier single-call surface' is concise but somewhat jargon-heavy; still, it doesn't waste words. Overall, it is well-structured and compact.

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

Completeness4/5

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

For a tool with nested parameters and no output schema, the description gives a good overview of the operation and return values. It mentions evidence, verdict, and persistence, which are key. However, it does not cover error cases or the mutual exclusivity of contract vs contract_id, though the schema covers those. Given the rich schema, the description is sufficient for an agent to understand the tool's role.

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?

The schema has 100% description coverage, so all parameters are documented in the schema. The description adds minimal parameter-level detail, only reiterating that evidence is a snapshot and that the verdict is returned. It does not add meaning beyond the schema, so the baseline score of 3 is appropriate.

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

Purpose5/5

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

The description states a specific action ('Evaluate'), a specific resource ('a single Outcome Contract assertion'), and the expected output (verdict pass/fail/inconclusive plus failed leaf assertions). It also mentions persistence for bounded retrieval, which clarifies the tool's role. This clearly distinguishes it from sibling tools like oc_evidence_get or oc_query, which are about retrieval.

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

Usage Guidelines3/5

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

The description offers minimal guidance on when to use this tool versus alternatives. It notes 'Core-tier single-call surface; retry and escalation live in the pilot runtime', implying this is the primary evaluation call and retries are elsewhere, but it does not explicitly name alternatives or conditions for choosing them. No explicit when-to-use or when-not-to-use guidance is provided.

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

Deploy Server

Other Tools