Skip to main content
Glama
anthroos

OpenExp

by anthroos
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

log_prediction

Log a prediction whenever citing a specific day from an experience pack, capturing the recommended action, expected signal, and deadline. Returns an ID to track the outcome later.

Instructions

Log a pack-grounded prediction. REQUIRED whenever the assistant cites a specific relative_day of an installed experience pack as the basis for a real-world action recommendation. Captures: which step was cited, which case it applies to, what was recommended (and what was explicitly NOT recommended), the observable signal that resolves the prediction, and the window in days. Returns prediction_id for later log_outcome.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNoOptional free-text context
case_idNoExternal reference for this case (CRM lead_id, ticket ID, etc.) — opaque string
pack_idNoThe pack's slug (e.g. 'inbound-acquisition-with-free-pilot')
client_idNo[deprecated alias for case_id, accepted for backward compat]
cited_stepNoThe exact relative_day cited (e.g. 'day +57')
confidenceNo[deprecated, removed from required schema 2026-04-27 — Claude confidence is uncalibrated until ≥30 outcome datapoints. Accepted for backward compat.]
predictionNo[deprecated] Free-text prediction. Use applied_action + expected_signal instead. Accepted for backward compat.
pack_authorNoThe pack's author handle (e.g. 'ivan-pasichnyk')
applied_actionNoWhat the assistant recommended TO do, derived from the cited step
expected_signalNoObservable signal that resolves this prediction (e.g. 'counterparty signs both sides')
memory_ids_usedNoMemory IDs that were retrieved for this prediction (for legacy Q-value updates on log_outcome)
strategic_valueNo[deprecated, accepted for backward compat]
prevented_actionNoWhat the assistant recommended NOT to do (negative-space prediction). Optional but encouraged — often the higher-value half.
expected_window_daysNoDeadline in days for log_outcome to be called

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the behavioral burden. It discloses that the tool logs a prediction and returns prediction_id for later use, which is relevant behavioral context. However, it does not address side effects beyond logging, persistence, idempotency, or access expectations; these are minor for a logging tool but still unstated.

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 front-loaded with the mandatory usage condition, uses a compact list to communicate the captured dimensions, and closes with the return value's downstream purpose. Every sentence earns its place with no redundancy or filler.

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 14-parameter tool with no output schema and no annotations, the description covers the core semantics: when to call it, what to include, and what comes back. It omits explicit mention of optional/deprecated parameters, but those are fully documented in the input schema, so the practical coverage is strong.

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 100%, so the baseline is 3 even without extra prose. The description adds a useful conceptual grouping (cited step, case, recommended/not-recommended action, resolving signal, window), but it does not add per-parameter meaning beyond what the schema already documents.

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 opens with a specific verb and resource, 'Log a pack-grounded prediction', and immediately defines the exact trigger condition. It also distinguishes the tool from its sibling log_outcome by noting this tool returns a prediction_id used for a later outcome call.

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?

The description gives an explicit, hard requirement: use this tool whenever the assistant cites a specific relative_day of an installed experience pack as the basis for a real-world recommendation. It does not explicitly discuss when not to use it or name alternative actions, but the trigger condition is concrete and the relationship to log_outcome is implied.

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