aibvf-mcp

infer_readiness

Read-onlyIdempotent

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. Pure deterministic calculation, no network, auth, or side effects.

Input Schema

TableJSON Schema

Name	Required	Description
`function`	Yes	Business 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.
`handoffs`	No	Distinct 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_rate`	No	Fraction of instances reopened or reworked (0-1). 15% or more reads siloed, 5-15% traditional, under 5% agile.
`touch_ratio`	No	Touch-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_days`	No	Median wall-clock days per instance. Read against the function median, same bands as handoffs.
`automation_level`	No	Share of the process already automated (0-1). Under 0.2 reads siloed, 0.2-0.5 traditional, above 0.5 agile.
`claimed_readiness`	No	Optional. 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

Name	Required	Description
`audit`	No	Reproducibility 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.
`guidance`	Yes	How to use the result downstream, including what a gap between measured and self-reported readiness means.
`readiness`	Yes	The readiness classification the measured signals support.
`confidence`	Yes	Confidence 0-100, set by signal coverage (2 signals ~45, 5 signals ~90) and discounted when signals disagree.
`bvf_version`	Yes	AI BVF protocol version used.
`gap_finding`	No	The claimed-versus-measured gap read as a change-readiness finding. Surface verbatim when present.
`disagreement`	No	Present when signals point in opposing directions: readiness is uneven across the process, read the per-signal detail.
`signal_reads`	Yes	Per-signal read: the value, which readiness it leans toward, and why in plain language. Show these to the user.
`signals_used`	Yes	How many of the five signals were provided.
`readiness_gap`	No	Ordinal distance claimed-to-measured. Positive: the organisation claims better than it measures.
`readiness_basis`	Yes	Always measured: this came from process data, not self-report.
`claimed_readiness`	No	Echo of the claim, when supplied.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 23, 2026

changedInput schema / properties / function / description

Previous value: -"Business function the process belongs to. Selects the published cycle-time and hand-off medians the signals are read against. Call list_taxonomy if unsure."New value: +"Business 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."

Changed5 schema fields changedJul 5, 2026

addedInput schema / properties / claimed_readiness

Added value: +{
+  "description": "Optional. 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.",
+  "enum": [
+    "agile",
+    "traditional",
+    "siloed"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / audit

Added value: +{
+  "description": "Reproducibility 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.",
+  "properties": {
+    "bvf_version": {
+      "type": "string"
+    },
+    "engine": {
+      "type": "string"
+    },
+    "engine_version": {
+      "type": "string"
+    },
+    "inputs_used": {
+      "description": "The resolved inputs the result was computed on, including estimated pillar values.",
+      "type": "object"
+    },
+    "note": {
+      "type": "string"
+    },
+    "rules_fired": {
+      "description": "The rules that actually fired, in order: estimation, gates, classification, value arithmetic.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / claimed_readiness

Added value: +{
+  "description": "Echo of the claim, when supplied.",
+  "enum": [
+    "agile",
+    "traditional",
+    "siloed"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / gap_finding

Added value: +{
+  "description": "The claimed-versus-measured gap read as a change-readiness finding. Surface verbatim when present.",
+  "type": "string"
+}

addedOutput schema / properties / readiness_gap

Added value: +{
+  "description": "Ordinal distance claimed-to-measured. Positive: the organisation claims better than it measures.",
+  "type": "number"
+}

First observedJul 5, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, non-destructive, idempotent. The description adds genuinly useful 'pure determininitic calculation, no network, auth, or side effects', the no-guess refusal, and the confidence effect of signal disagreement. Strong extra behavioral context beyond annotations.

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?

Dense and front-loaded: starts with purpose, then scheduling, then parameter context/closing behavior and safety. It is a good-size paragraph and every sentence contributes; the only minor downside is slight overlap with the claimed_readiness schema text.

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?

For a deterministic readiness calc, with rich param descriptions, an output schema, and annotations already carrying safety profile, the definition adds enough decision rules, input condition, refusal behavior, and workflow. There is no obvious gap an agent would need filled.

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?

Since input schema already fully describes all 7 parameters with concrete thresholds and enums, the bar is lower. The description still adds meaning about function as median-selector, claimed_readiness purpose, signal-count interaction confidence, and disagreement relation, going beyond the schema is a worthwhile way.

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?

Opens with a concrete verb and resource: 'Measure organisational readiness from process data'. It distinguishes itself from siblings by naming where it slots in the workflow, before score_initiative/score_portfolio/calcucalate_pace_layer_drag and before diagnose_process for follow-up.

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?

Gives explicit when: 'CALL THIS before ... when the user can provide at las two of five signals'. It also tells the agent the refusal behavior with fewer than two and states when to pass claimed_readiness, so the choice condition is fully operational.

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

All aibvf-mcp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.