Skip to main content
Glama

record_evidence

Record experimental results and update belief states in the hypothesis DAG, automatically capturing git context. Batch multiple outcomes in one call to revise beliefs efficiently.

Instructions

Record one result, or many in one call, and update the belief state. Auto-captures git context_hash + git_branch when unset. Record against the hypothesis whose statement you actually tested: evidence against a goal is refused, and evidence against a premise a composition assumed corrupts a confirmation that is still true on its own. Ran several experiments this turn? Report them together with results — one call, applied in order.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNoRigour/scale of the test that produced this result. A confirmation at depth d only supports claims tested no deeper than d.
notesNo
messageNo
metricsNo
node_idNo
resultsNoSeveral results at once, applied in the order given. Use this whenever you ran more than one experiment: reporting k results costs one call instead of k. Each entry takes the same fields as a single result. When present, the single-result fields below are ignored.
successNo
claim_idNoThe claim this result answers. Optional: omit it entirely for a probe you initiated yourself, which is always safe. Pass the one get_next_targets issued for work it handed you, so the lease is released.
duration_sNoHow long the experiment took, in seconds. Optional, and worth sending whenever your probes differ in cost: it is what lets the navigator rank by value per unit cost rather than treating a three-day run and a one-second check as interchangeable.
error_typeNo
source_refNoWhat was actually run to produce this number — a file path, a URL, a CI run id, a commit. Optional, but a trail that says '0.85, from pytest run #4412' is worth more later than one that says '0.85'.
lease_ttl_sNoTTL for the fused dispatch, if any.
evidence_kindNological
attestation_idNoRunner-minted attestation id. Provenance fields cannot be supplied here; unknown ids degrade to self-reported.
count_next_targetsNoHow many targets you want to be holding when this returns — a top-up, not an addition, so recording a batch of results leaves you with this many, not this many per result. Saves a separate get_next_targets round-trip. Leave at 0 when you are reporting a long-running experiment and are not ready to claim more work — anything claimed and not reported is work nobody else can do.
Behavior4/5

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

With no annotations, the description carries the burden and does disclose key behaviors: auto-captures git context when unset, refuses evidence against goals, and corrupts confirmations for premises assumed corrupt. It also explains the order-of-application for batch results. Minor gap: does not disclose that it mutates state, but the verbs 'record' and 'update' imply it.

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

Conciseness5/5

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

The description is dense but every sentence adds value: batch guidance, auto-capture, hypothesis targeting rule, and a concrete example of batch usage. It's front-loaded with the core action and quickly moves to important constraints.

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?

Given 15 parameters, low schema coverage, and no output schema, the description covers the most decision-relevant parameters but not all (e.g., error_type, metrics, attestation_id are not explained). Since the schema covers those partially, this is acceptable; however, for a complex tool, more coverage would improve completeness. The absence of an output schema is noted, but the description doesn't need to explain return values.

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

Parameters5/5

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

Schema coverage is low (53%), so the description must add meaning. It explains the critical `results` parameter (batch usage), the `claim_id` parameter (optional vs. lease release), `duration_s` (for ranking), `source_ref` (provenance value), and `count_next_targets` (top-up semantics). This goes beyond the schema with actionable context.

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 clearly states the primary action ('Record one result, or many in one call') and the resource (evidence) and explicitly includes the belief state update. It distinguishes from siblings by focusing on recording evidence versus creating hypotheses or managing claims.

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

Usage Guidelines4/5

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

Provides explicit guidance on when to use the batch mode ('Ran several experiments this turn? Report them together') and clarifies the rule about which hypothesis to record against. However, it does not mention when NOT to use this tool compared to siblings like get_evidence_history or update_status.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tygryso/hypotree'

If you have feedback or need assistance with the MCP directory API, please join our Discord server