Skip to main content
Glama
Sign In
daf-jev

daf-jev

by docxology
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

jev_reask_plan

Builds a max-entropy re-ask plan from a posteriors sidecar by selecting the next unasked variable to query and returning the question queue and evidence.

Instructions

Build the max-entropy re-ask plan from a posteriors sidecar. path selects the sidecar JSON file; graphspec_path optionally supplies a dafjev.bayesnet/1 GraphSpec document to cross-check the sidecar's variables and states against; asked lists variables already asked (excluded from the plan).

Same policy as the daf-jev posteriors-reask CLI command (:mod:daf_jev.reask): next variable = max entropy among not-yet-asked posterior rows, ties broken by the sidecar's insertion order. Only dafjev.bayesnet-posteriors/1 sidecars are accepted. On success returns {next_question, entropy, queue, evidence}; when the document fails validation, returns {error, message, ok: false} instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "jev_reask_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes
askedNo
graphspec_pathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.2

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden, and it does well: it discloses the deterministic selection algorithm, the tie-breaking rule, the validation gate, and both outcome shapes including the failure object `{error, message, ok: false}`. Gaps remain around filesystem behavior (missing or unreadable sidecar path), and it never explicitly states that the tool is read-only and mutates nothing on disk.

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 verb and object lead, followed by parameter roles, then policy, then return shapes, which is a sensible front-loaded order with little filler. The reference to the CLI command and module path is developer-facing and only marginally useful to an agent, keeping it from a 5.

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?

With no output schema and no annotations, the description supplies the return contract and error contract itself, plus the core selection policy, which covers what an agent needs to invoke and interpret results. Missing pieces are minor but real: file-not-found handling, whether the returned `queue` and `evidence` are ordered or truncated, and behavior when all variables have been asked.

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

Parameters4/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, and it defines all three parameters in prose: `path` as the sidecar JSON file, `graphspec_path` as an optional `dafjev.bayesnet/1` GraphSpec used to cross-check variables and states, and `asked` as the list of already-asked variables excluded from the plan. It also constrains the accepted document version for `path`, which the schema does not. It does not specify path format (absolute/relative) or whether `asked` must match sidecar state names exactly.

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 opening sentence names a specific verb and resource: build a max-entropy re-ask plan from a posteriors sidecar. That is far more than a restatement of the name and makes the operation unmistakable. It stops short of a 5 because it never contrasts itself with the sibling that likely produces or consumes this data (jev_posteriors_load, jev_ask), so an agent must infer the boundary from the stated inputs.

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 gives strong operational context: the exact selection policy (max entropy among not-yet-asked rows, ties by insertion order) and the accepted input format `dafjev.bayesnet-posteriors/1`. It also explains what `asked` does in effect: already-asked variables are excluded. What is missing is explicit when-to-use routing, e.g. that this should be called after loading posteriors and before jev_ask, and what to do when no eligible variables remain.

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