Skip to main content
Glama

infer_readiness

Read-onlyIdempotent

Measure organisational readiness from process data using hand-offs, rework, touch ratio, automation and cycle time. Run before scoring an investment, and compare claimed readiness to reveal the real gap.

Instructions

Measure organisational readiness from process data, so the investment case does not depend on an untested maturity claim. CALL THIS before score_initiative, score_portfolio or calculate_pace_layer_drag when the user can provide at least two of five signals: hand-offs, rework, touch ratio, automation level and cycle time. function selects the comparison medians for hand-offs and cycle time; more signals increase confidence and disagreement between them reduces it. claimed_readiness is optional, but pass it when the organisation has declared itself agile, traditional or siloed, because the returned gap exposes where its self-image runs ahead of the process data. Fewer than two signals produces a refusal, not a guess. Pass the measured readiness into the downstream tool, then use diagnose_process when the next question is what to change in that process. Deterministic calculation with no authentication. Anonymous usage telemetry may be sent; set AIBVF_TELEMETRY_DISABLE=1 to opt out.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
functionYesBusiness function the process belongs to. Selects the disclosed AI BVF cycle-time and hand-off reference points used to interpret the signals. Call list_taxonomy if unsure.
handoffsNoDistinct owners or systems an instance passes through. Read against the function median: 1.5x or more the median reads siloed, at or above the median reads traditional, below it reads agile.
rework_rateNoFraction of instances reopened or reworked (0-1). 15% or more reads siloed, 5-15% traditional, under 5% agile.
touch_ratioNoTouch-time divided by cycle-time (0-1); the remainder is waiting. Under 0.15 reads siloed (the process lives in queues), 0.15-0.4 traditional, above 0.4 agile.
cycle_time_daysNoMedian wall-clock days per instance. Read against the function median, same bands as handoffs.
automation_levelNoShare of the process already automated (0-1). Under 0.2 reads siloed, 0.2-0.5 traditional, above 0.5 agile.
claimed_readinessNoOptional. What the organisation says about itself. The measured result is compared against it and the gap returned as readiness_gap plus a gap_finding, because an organisation whose self-image runs ahead of its process data has just told you where the change work starts.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
auditNoReproducibility record: engine version, the rules that fired, and the resolved inputs. Deterministic, no timestamps. If the verdict is challenged months later, the same inputs on the same engine version reproduce it exactly.
guidanceYesHow to use the result downstream, including what a gap between measured and self-reported readiness means.
readinessYesThe readiness classification the measured signals support.
confidenceYesConfidence 0-100, set by signal coverage (2 signals ~45, 5 signals ~90) and discounted when signals disagree.
bvf_versionYesAI BVF protocol version used.
gap_findingNoThe claimed-versus-measured gap read as a change-readiness finding. Surface verbatim when present.
disagreementNoPresent when signals point in opposing directions: readiness is uneven across the process, read the per-signal detail.
signal_readsYesPer-signal read: the value, which readiness it leans toward, and why in plain language. Show these to the user.
signals_usedYesHow many of the five signals were provided.
readiness_gapNoOrdinal distance claimed-to-measured. Positive: the organisation claims better than it measures.
readiness_basisYesAlways measured: this came from process data, not self-report.
claimed_readinessNoEcho of the claim, when supplied.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.14.14

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial extra behavior: refusal thresholds, confidence scaling with signal count, disagreement lowering confidence, determinism, no authentication, and telemetry with an explicit opt-out env var. This is exactly the kind of context annotations cannot carry.

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?

Front-loaded with purpose and call condition, and most sentences carry operational weight. It is dense and slightly long, with mild overlap between the determinism/no-auth sentence and the telemetry sentence, but no filler.

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

Completeness5/5

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

With an output schema present it correctly avoids describing return values, while covering everything else an agent needs: prerequisites, refusal behavior, confidence mechanics, optional-parameter guidance, downstream chaining, and telemetry disclosure.

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 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining that 'function' selects comparison medians and by giving conditional guidance for the optional claimed_readiness (pass it when the org has self-declared agile/traditional/siloed because the gap is diagnostic).

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?

States a specific verb+resource ('Measure organisational readiness from process data') and immediately frames the business purpose. It also differentiates itself from siblings by naming score_initiative, score_portfolio and calculate_pace_layer_drag as downstream consumers.

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

Usage Guidelines5/5

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

Explicit invocation conditions ('CALL THIS before ... when the user can provide at least two of five signals'), an explicit exclusion ('Fewer than two signals produces a refusal, not a guess'), and a routing hint to diagnose_process for the follow-up question. Nothing is left to inference.

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