A
license-
qualityB
maintenanceAnalyzes enterprise transformation programs to surface maturity gaps and risk signals, enabling AI agents to identify stalled initiatives and prioritize actions.
MIT
aibvf-mcp
Server Details
AI BVF: score AI portfolios Stop/Fix/Accelerate with decision confidence and pace-layer drag.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Craig-Horton/ai-bvf
- GitHub Stars
- 0
- Server Listing
- aibvf-mcp
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.9/5.0
Tool DescriptionsA
Average 4.9/5 across 13 of 13 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool targets a distinct responsibility within the AI BVF workflow: portfolio lifecycle (assemble/validate/score/sequence), initiative evaluation (assess/score/recommend), and supporting lookups (taxonomy, benchmark, readiness). The descriptions explicitly distinguish close pairs like assess_ai_initiative (resolves unknown fields) vs score_initiative (canonical fields known), and map_to_taxonomy vs list_taxonomy. There is no apparent overlap that would cause an agent to misselect.
Naming Consistency5/5
All tool names follow the verb_noun snake_case pattern, with verbs that clearly indicate the action (assemble, assess, diagnose, get, infer, list, map, recommend, score, sequence, validate). The naming is uniform and predictable, with no mixing of styles or vague verbs like 'process' or 'do_thing'.
Tool Count5/5
13 tools is well within the ideal 3-15 range and each tool earns its place by covering a distinct stage of the framework. The count feels proportionate to the server's comprehensive scope—single initiative scoring, portfolio management, process diagnosis, readiness inference, and taxonomy mapping—without redundancy or bloat.
Completeness5/5
The tool set covers the full lifecycle from raw input to sequenced portfolio: taxonomy mapping, benchmark lookups, readiness inference, initiative scoring, portfolio assembly/validation/scoring/sequencing, and follow-up recommendations. There are no obvious dead ends; every tool leads to the next logical step, and the stateless design means updates are handled by re-assembling inputs.
Available Tools
13 toolsassemble_portfolioARead-onlyIdempotentInspect
Assemble a valid AI BVF v1.0 portfolio document from loose inputs, deterministically. Agents arrive with initiative names, plain-language functions and half the pillar scores, then hand-build the portfolio JSON and get the shape wrong; this tool builds it right. Give it the organisation (name plus industry in canonical or everyday language) and one entry per initiative (name, function, ai_tier, plus whatever pillar scores you actually have as bare numbers) and it returns the finished document: aliases resolved through the same mapping as map_to_taxonomy, ids generated from names and deduplicated, missing pillars estimated from readiness, tier, function and the published benchmarks with the estimation reported per initiative in estimated_pillars, and the whole document validated before it is returned. CALL THIS when the user lists several AI initiatives in conversation and you need a portfolio document for validate_portfolio, score_portfolio or sequence_portfolio, instead of composing the JSON by hand. Do NOT invent pillar scores to fill it: pass only the numbers the user gave you and let the estimation carry the rest honestly, the estimated pillars carry low confidence and scoring haircuts accordingly. Unresolvable inputs come back as issues with suggestions; ask the user to choose rather than guessing. Every default the assembler applies is named in plain language in assumptions: surface them to the user, the assembler structures inputs and never makes hidden business judgements. This tool creates a document in the response only: nothing is stored, nothing is edited, no state exists between calls. Pure deterministic calculation, no network, auth, or side effects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| readiness | No | Organisational readiness, canonical or plain language (bureaucratic resolves to siloed). Drives estimation of missing pillars. Defaults to traditional. | |
| initiatives | Yes | One entry per initiative, from whatever the user gave you. Only name, function and ai_tier are required. | |
| organization | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| audit | Yes | 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. |
| issues | Yes | Unresolved inputs, each with path, message and suggestions where the taxonomy has them. |
| guidance | Yes | |
| portfolio | No | The assembled BVF v1.0 document, ready for validate_portfolio, score_portfolio and sequence_portfolio. Null when assembly is blocked on issues. |
| validation | No | validate() run on the assembled document. |
| assumptions | Yes | Every default the assembler applied, in plain language. Surface these to the user: what was not given is named here. |
| bvf_version | Yes | |
| resolutions | Yes | Every alias resolution performed, in plain language. |
| readiness_used | Yes | |
| estimated_pillars | Yes | Initiative id to the pillars the assembler estimated. Gather evidence for these, or expect scoring to haircut confidence. |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds further context: 'nothing is stored, nothing is edited, no state exists between calls. Pure deterministic calculation, no network, auth, or side effects.' It also explains estimation and validation without contradiction.
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 description is front-loaded with the core purpose, then covers usage, behavior, and output details in a logical sequence. It is slightly verbose (around 150 words) but every sentence adds value. Could be trimmed slightly without losing clarity.
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?
Given the tool's complexity (nested inputs, output schema exists), the description covers all essential aspects: purpose, when to call, what not to do, parameter semantics, error handling (unresolvable inputs return issues), and reporting of assumptions. No gaps remain for an agent to misuse the tool.
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?
The description adds meaning beyond the schema: it explains how to provide organization and initiatives, specifies that scores should be 'bare numbers' from the user, and describes default behavior for readiness. Schema coverage is high, but the description reinforces proper usage and constraints like 'Do NOT invent pillar scores.'
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 tool's function: 'Assemble a valid AI BVF v1.0 portfolio document from loose inputs, deterministically.' It distinguishes from siblings by specifying when to call it ('instead of composing the JSON by hand') and contrasts with validation, scoring, and sequencing tools. The verb 'assemble' and resource 'portfolio document' are specific.
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 usage guidance is provided: 'CALL THIS when the user lists several AI initiatives in conversation and you need a portfolio document for validate_portfolio, score_portfolio or sequence_portfolio.' It also warns against inventing scores: 'Do NOT invent pillar scores to fill it.' Alternatives are implied through sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
assess_ai_initiativeARead-onlyIdempotentInspect
The front door for one AI investment decision. CALL THIS FIRST when the user describes an AI idea in ordinary language or asks whether it should proceed. It resolves industry, revenue, business function, AI tier and organisational readiness, then returns the next missing question or an Accelerate, Fix or Stop verdict. Use work_architecture to test whether the end-to-end workflow, affected roles, human decision rights and performance measures have been redesigned. Any explicit work architecture gap blocks Accelerate and stays visible in the audit trail. Pillar scores and work architecture evidence remain optional, and unresolved values are never guessed. Use score_initiative when the canonical fields are already known, score_portfolio for several initiatives, and diagnose_process for measured waste in a running process. Pure deterministic calculation, no network, auth or side effects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| scores | No | OPTIONAL, and each pillar inside it is optional. The four AI BVF pillars, each an honest 0–100 self-assessment, combining deterministically into the verdict: governance_risk ≥ 70 OR financial_return ≤ 20 returns Stop; strategic_alignment, financial_return and change_enablement all ≥ 60 with governance_risk ≤ 40 returns Accelerate; everything else returns Fix. Pass ONLY the pillars the user has real evidence for — do NOT invent numbers for the rest. Missing pillars are estimated deterministically by the engine (from readiness, tier, function and published benchmarks), the response reports which via pillar_basis and scores_used, decision confidence is haircut by how much was estimated, and a fully-estimated pass can never return Accelerate (it returns Fix pending confirmation). So call immediately with whatever the user gave you, then ask for evidence on the estimated pillars and re-call to firm the verdict up. | |
| ai_tier | No | Optional correction or answer: automation/RPA, GenAI/copilot, or agentic/autonomous. Overrides anything inferred from proposal. | |
| function | No | Optional correction or answer in canonical or everyday language, for example customer service, procurement, finance or risk. Overrides anything inferred from proposal. | |
| industry | No | Optional correction or answer in canonical or everyday language, for example retail, hospital, bank or public sector. Overrides anything inferred from proposal. | |
| proposal | Yes | The AI initiative in ordinary business language. Include the organisation, industry, approximate annual revenue, business function, AI ambition and how the organisation works today when known. The resolver extracts what it can and asks one question for the first missing input; it never guesses an unresolved taxonomy value. | |
| readiness | No | Optional correction or answer: agile, traditional, or siloed, including everyday descriptions such as cross-functional, hierarchical or bureaucratic. Overrides anything inferred from proposal. | |
| revenue_eur | No | Optional approximate annual revenue in EUR. Overrides any EUR amount extracted from proposal. No currency conversion is performed. | |
| work_architecture | No | Optional evidence that the work around the AI has been redesigned. Pass only what is known. Any explicit false value blocks Accelerate until the gap is closed; omitted checks remain visible as unknown. | |
| signal_completeness | No | Optional 0–1. How grounded the four pillar scores are in real evidence versus estimated from context. Defaults to 1 (treated as measured). If the organisation lacks formal change-readiness or risk metadata, estimate the pillars from what you know AND set this lower to say so — decision confidence is reduced proportionally and a caveat is attached, instead of returning a falsely confident verdict on soft inputs. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | needs_input when one or more required decision inputs remain unresolved; verdict when scoring completed. |
| verdict | No | The AI BVF score. Present only when status is verdict. |
| proposal | Yes | The supplied proposal, returned so the next call can preserve it verbatim. |
| bvf_version | Yes | |
| resolutions | Yes | Every deterministic resolution, naming the field, canonical value, source and matched phrase. |
| suggestions | No | Accepted values for an explicitly supplied field that could not be resolved. |
| next_question | No | The single next question to ask. Present only when status is needs_input. |
| missing_fields | Yes | |
| resolved_inputs | Yes | Canonical fields resolved so far. Explicit corrections override proposal inference. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, but the description adds valuable behavior: 'Pure deterministic calculation, no network, auth or side effects' and 'unresolved values are never guessed.' It also describes the gating behavior of work architecture gaps blocking Accelerate and staying in the audit trail, enriching the agent's understanding beyond the structured hints.
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 a tight paragraph of about 120 words. It front-loads the critical 'CALL THIS FIRST' instruction, then covers purpose, resolution behavior, work architecture, alternatives, and side effects. Every sentence adds distinct value with no redundancy or 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?
Given the tool's complexity (9 parameters, nested objects, output schema), the description covers all key aspects: what it does, when to use it, how to supply optional work architecture evidence, what it never does (guess), and its deterministic/side-effect-free nature. The existence of an output schema means return values need not be detailed, and the description even mentions the audit trail for workflow context.
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?
The schema has 100% description coverage, so the baseline is 3. The description adds strategic guidance by naming the fields resolved (industry, revenue, business function, AI tier, organisational readiness) and explicitly stating that pillar scores and work architecture evidence are optional. It also directs use of the work_architecture parameter for redesign checks. However, it does not detail each parameter's meaning beyond what the schema already provides, so a 4 is appropriate.
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 tool's role as 'The front door for one AI investment decision' and specifies it resolves fields and returns 'the next missing question or an Accelerate, Fix or Stop verdict.' It explicitly distinguishes from siblings by naming score_initiative, score_portfolio, and diagnose_process as alternatives, making the purpose unambiguous.
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?
It gives explicit when-to-use guidance: 'CALL THIS FIRST when the user describes an AI idea in ordinary language or asks whether it should proceed.' It also provides when-not-to-use by directing users to score_initiative for known canonical fields, score_portfolio for multiple initiatives, and diagnose_process for waste in running processes. This goes beyond general context to concrete alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_pace_layer_dragARead-onlyIdempotentInspect
Quantify the annual EUR cost of an AI ambition outrunning the operating model: queues, hand-offs and slow decisions that prevent the organisation capturing the value already assumed in the case. CALL THIS when the user needs the cost of waiting for the organisation to change, or when a Fix plan needs a cost-of-waiting figure. Do not use it to score an AI initiative, estimate the implementation cost, or calculate a process saving: use score_initiative for the investment verdict, diagnose_process for a running process, and recommend_improvements for the change plan. revenue_eur sets the absolute EUR range; ai_tier and readiness together set the drag rate and pace_gap, so gen3 in a siloed organisation costs more than gen1 in an agile one. industry is accepted for a consistent interface and defaults to universal, but does not change this calculation yet. Returns a low/high EUR range, drag rate, pace-gap severity, drivers and source. Pure deterministic calculation — no network, auth, or side effects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ai_tier | Yes | Ambition of the AI operating model: gen1 = automation/RPA, gen2 = GenAI, gen3 = agentic. Paired with readiness to set pace_gap severity — gen3 on any readiness below agile, or gen2 on siloed, is severe; a higher tier against a slower operating model widens the gap and raises the drag. | |
| industry | No | Optional; defaults to universal if omitted. Reserved for future vertical drag-rate adjustments — does not change the result today. Call list_taxonomy for accepted values. | |
| readiness | Yes | Organisational readiness, honest self-assessment: agile = cross-functional, fast decisions; traditional = functional hierarchy; siloed = rigid, hand-off heavy. Agile readiness yields minimal drag at any tier; the mismatch between a fast AI tier and a slower operating model is what generates the Organisational Drag Cost. | |
| revenue_eur | Yes | Approximate annual revenue in EUR (must be ≥ 0). The result scales with this: annual_drag_eur is returned as an absolute range and as drag_rate, a fraction of this revenue (e.g. 0.02 = 2%). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | Yes | Citation for the drag-rate model applied. |
| drivers | Yes | Named factors contributing to the drag. |
| pace_gap | Yes | Severity of the tier↔readiness mismatch. |
| drag_rate | Yes | Drag as a fraction of revenue (e.g. 0.02 = 2%), low/high. |
| bvf_version | Yes | AI BVF protocol version used. |
| annual_drag_eur | Yes | Estimated annual Organisational Drag Cost in EUR, low/high. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses deterministic calculation with no side effects, no network or auth, consistent with annotations. Adds context about return format and pure calculation nature.
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?
Comprehensive single paragraph, front-loaded with purpose, but could benefit from structural breaks for readability. No wasted words.
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?
Covers purpose, usage, parameter behavior, return values, and safety. Output schema exists but description adds essential context about deterministic nature and no side effects.
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?
Adds meaning beyond schema by explaining how parameters interact (e.g., gen3+silod costs more), scaling with revenue, and future placeholder for industry.
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?
Description clearly states the tool quantifies annual EUR cost of AI ambition outrunning operating model, explicitly distinguishing from siblings like score_initiative, diagnose_process, and recommend_improvements.
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?
Explicitly states when to call ('cost of waiting for the organisation to change'), when not to use, and provides alternative tools for other needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
diagnose_processARead-onlyIdempotentInspect
Diagnose a single existing business process from operational evidence and return the intervention, modelled net EUR saving, efficiency gain, verdict and confidence. CALL THIS when the user can describe a process already running, including volume, touch time, waiting, hand-offs, rework, automation and cost. instances_per_year × fte_hours_per_instance × loaded_hourly_rate_eur builds the labour baseline, direct_spend_eur adds the non-labour baseline, and readiness caps the saving that the organisation can realise. The friction signals select the intervention: low automation points to Automate, many hand-offs or wait to Consolidate & re-sequence, rework to Quality controls, low-volume heavy work to Eliminate / insource. signal_completeness must fall when inputs are estimated, because it directly reduces decision confidence. Use score_initiative for a proposed AI investment and infer_readiness when the question is the organisation’s change capacity. Effectiveness bands are benchmark-cited and figures are directional, not audited. Pure deterministic calculation — no network, auth, or side effects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| function | Yes | Business function the process belongs to. See list_taxonomy. | |
| handoffs | Yes | Distinct owners/systems an instance passes through. Weighed against the per-function median; many handoffs make handoff drag dominant and point to Consolidate & re-sequence. | |
| readiness | No | Optional. Org change-absorption capacity — agile / traditional / siloed — which caps the realised (net) saving below the gross potential. Defaults to traditional. | |
| process_id | Yes | Stable identifier for the process. | |
| rework_rate | Yes | Fraction of instances reopened/reworked (0–1). When rework is the dominant drag factor the intervention becomes Quality controls, and it also sets the addressable share for that path. | |
| touch_ratio | Yes | Touch-time ÷ cycle-time (0–1). The remainder is wait; a low value means the process is mostly waiting, which pushes the intervention toward Consolidate & re-sequence. | |
| cycle_time_days | Yes | Median wall-clock days per instance, end to end. Long cycles relative to touch-time signal wait/latency drag. | |
| automation_level | Yes | Share already automated (0–1). Low automation makes manual effort the dominant drag and selects Automate; the un-automated remainder is the addressable share. | |
| direct_spend_eur | Yes | Annual licence/vendor/tooling spend on the process in EUR. Added to the labour baseline and shifts how much of the saving is labour- vs spend-addressable. | |
| instances_per_year | Yes | Process volume: how many times it runs per year. Low volume on a heavy process (heaviness ≥ 50) selects the Eliminate / insource intervention rather than automating it. | |
| signal_completeness | No | Optional 0–1. How much of the above was measured versus defaulted. Governs decision_confidence proportionally — lower it when you estimated inputs so the verdict stays honest. Defaults to 0.7. | |
| fte_hours_per_instance | Yes | Human touch-time in hours per instance. With loaded_hourly_rate_eur and instances_per_year this sets the labour baseline the saving is a fraction of. | |
| loaded_hourly_rate_eur | Yes | Fully-loaded labour cost per hour in EUR (salary + on-costs). Multiplies fte_hours_per_instance × instances_per_year into the annual labour baseline. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| verdict | Yes | The call on the intervention. |
| function | Yes | Business function diagnosed. |
| heaviness | Yes | Process heaviness index, 0–100. |
| disclaimer | Yes | Directional decision aid, not an audited figure. |
| process_id | Yes | Echo of the input process id. |
| assumptions | Yes | The assumptions behind the figure — never a naked number. |
| bvf_version | Yes | AI BVF protocol version used. |
| intervention | Yes | Recommended move. |
| brain_version | Yes | Advisor Brain model version used. |
| net_saving_eur | Yes | Modelled net annual saving in EUR after readiness capture, low/high. |
| offer_to_execute | Yes | True when the verdict warrants offering to action it (Accelerate). |
| baseline_cost_eur | Yes | Current annual cost: labour + direct spend. |
| evidence_maturity | Yes | Strength of the benchmark evidence behind the effectiveness band. |
| advisory_next_step | No | Optional CTA, present only for Fix/Stop verdicts. |
| drag_decomposition | Yes | Share of heaviness from each friction factor (sums to ~1). |
| decision_confidence | Yes | Confidence in the verdict, 0–100. |
| efficiency_gain_pct | Yes | Efficiency improvement on the targeted slice, percent. |
Tool Definition Quality
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds 'Pure deterministic calculation — no network, auth, or side effects,' which reinforces safety and explains output behavior (e.g., 'signal_completeness must fall when inputs are estimated'). No contradictions; adds useful 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?
The description is front-loaded with a clear summary, then elaborates on parameter usage and trade-offs. While dense and slightly long, every sentence adds value; no wasted words. Could be slightly more concise but well-organized.
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?
Given 13 parameters, 11 required, 100% schema coverage, and an existing output schema, the description thoroughly explains the tool's logic, constraints, and output components (intervention, savings, confidence). It is fully complete for a complex process diagnosis tool.
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 100%, but the description greatly enhances meaning by explaining how parameters interact (e.g., 'instances_per_year × fte_hours_per_instance × loaded_hourly_rate_eur builds the labour baseline') and how friction signals select interventions, thereby providing significant value beyond the schema.
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 what the tool does: 'Diagnose a single existing business process from operational evidence and return the intervention, modelled net EUR saving, efficiency gain, verdict and confidence.' It specifies the verb (diagnose), resource (process), and output, distinguishing it from siblings that focus on portfolios or initiatives.
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 guidance: 'CALL THIS when the user can describe a process already running...' and explains when not to use it, directing to alternatives like 'score_initiative' for AI investment and 'infer_readiness' for change capacity, thus providing clear contextual differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_benchmarkARead-onlyIdempotentInspect
Look up the published raw benchmark rates behind the value model for one business function and industry. CALL THIS when the user wants to inspect the revenue-uplift and cost-takeout assumptions before scoring, or to compare the value drivers across functions. function selects the base rate range and named drivers; industry applies the multiplier, while universal returns the unadjusted base rate. The output is a rate, expressed as a fraction of revenue, not an initiative verdict or EUR business case. Use score_initiative for an Accelerate/Fix/Stop decision, score_portfolio for several initiatives and diagnose_process for measured operational waste. Pure deterministic lookup — no network, auth, or side effects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| function | Yes | Business function to benchmark — must be one of the list_taxonomy function values. Selects the base revenue-uplift and cost-reduction rate ranges (returned as fractions of revenue) and the value drivers. | |
| industry | Yes | Industry whose multiplier to apply — must be one of the list_taxonomy industry values. The returned industry_multiplier is applied to the function base rates; pass "universal" for the un-adjusted rates. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | Yes | Citation for the benchmark figures. |
| drivers | Yes | Named value drivers behind the benchmark. |
| function | Yes | Business function the rates apply to. |
| industry | Yes | Industry whose multiplier was applied. |
| cost_takeout_range | Yes | Cost take-out as a fraction of revenue, lo/hi. |
| industry_multiplier | Yes | Multiplier applied to the base rates for this industry. |
| revenue_uplift_range | Yes | Revenue uplift as a fraction of revenue, lo/hi. |
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint=false, idempotentHint=true. The description adds value by stating 'Pure deterministic lookup — no network, auth, or side effects' and clarifying that the output is a rate fraction, not a verdict or EUR business case, which is consistent and informative.
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 three sentences, front-loading purpose, then usage guidelines, then parameter semantics, then behavioral context. Every sentence is necessary and informative, with no fluff.
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?
Given the tool's simplicity (2 enum parameters, output schema exists), the description covers purpose, usage, parameters, and behavior completely. It also references related tools for context.
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 100%, but the description adds significant meaning: 'function selects the base rate range and named drivers; industry applies the multiplier, while universal returns the unadjusted base rate.' This explains the interaction and purpose beyond the enum lists.
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 'Look up the published raw benchmark rates behind the value model for one business function and industry.' It specifies a specific verb ('look up'), resource ('raw benchmark rates'), and scope ('for one business function and industry'), distinguishing it from siblings like score_initiative and score_portfolio.
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?
Explicitly says 'CALL THIS when the user wants to inspect the revenue-uplift and cost-takeout assumptions before scoring, or to compare the value drivers across functions.' It also provides clear alternatives: 'Use score_initiative for an Accelerate/Fix/Stop decision, score_portfolio for several initiatives and diagnose_process for measured operational waste.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
infer_readinessARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| function | Yes | 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. | |
| 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
ParametersJSON 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. |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: explains that it is a pure deterministic calculation with no network, auth, or side effects, which aligns with readOnlyHint and idempotentHint. It also describes how multiple signals affect confidence and disagreement, providing valuable transparency.
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 description is thorough and well-structured, starting with purpose, then usage, behavior, and parameter details. While it is somewhat lengthy, every sentence serves a purpose, and there is no redundancy. A slight reduction would be possible, but it remains effective.
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?
The description covers the refusal case, downstream usage, and parameter behaviors. With an output schema present, it does not need to detail return values extensively. It could explicitly mention the readiness score type, but overall it equips the agent to use the tool correctly.
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?
Despite 100% schema coverage, the description adds significant semantic value beyond the input schema by providing thresholds and interpretations for each parameter (e.g., handoffs: '1.5x or more the median reads siloed'). It also explains how the 'function' parameter selects medians, enriching agent understanding.
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 tool measures organisational readiness from process data, with a specific verb ('measure') and resource. It distinguishes from siblings by explicitly directing when to call this tool before score_initiative, score_portfolio, or calculate_pace_layer_drag.
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?
The description provides explicit usage guidelines: call this when at least two of five signals are available, and provides downstream actions (pass readiness to downstream tools, use diagnose_process next). It also states that fewer than two signals produce a refusal, establishing clear when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_taxonomyARead-onlyIdempotentInspect
Return the exact industry, function, AI-tier and readiness values every AI BVF calculation accepts. CALL THIS when the caller needs the complete allowed list or when a free-text value is not obvious. It returns taxonomy only, no score, verdict or language mapping. Use map_to_taxonomy when the user has said customer service, banking, RPA or bureaucratic and you need the one canonical value; use this tool when they need the whole menu of values to choose from. Takes no parameters. Pure deterministic lookup — no network, auth, or side effects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ai_tiers | Yes | All accepted ai_tier values (gen1/gen2/gen3). |
| functions | Yes | All accepted business-function values. |
| readiness | Yes | All accepted organisational-readiness values. |
| industries | Yes | All accepted industry values. |
| bvf_version | Yes | AI BVF protocol version these enums belong to. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral details beyond annotations: 'Pure deterministic lookup — no network, auth, or side effects' and 'Takes no parameters', consistent with readOnly and idempotent hints.
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?
Three concise, front-loaded sentences that cover purpose, usage guidance, and behavioral notes with no wasted words.
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?
Given no parameters and an existing output schema, the description fully covers what the tool returns (taxonomy only, no score/verdict/language mapping) and its deterministic nature.
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?
No parameters exist, and schema coverage is 100%. Description confirms 'Takes no parameters', meeting the baseline expectation of clarity for zero-parameter tools.
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?
Description explicitly states it returns 'exact industry, function, AI-tier and readiness values' and distinguishes itself from map_to_taxonomy, which is a sibling tool.
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?
Describes when to call this tool ('when the caller needs the complete allowed list or when a free-text value is not obvious') and explicitly names the alternative map_to_taxonomy for specific term lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
map_to_taxonomyARead-onlyIdempotentInspect
Map everyday business language to the canonical AI BVF values required by the scoring tools. CALL THIS when the user says customer service, procurement, banking, GenAI copilot or bureaucratic and the matching enum is not certain. Pass only the fields written in free text; each returns the canonical value, what it matched on, or null with suggestions. A null result requires the user to choose from the suggestions, because a plausible guess would change the score. Use list_taxonomy when the user needs every permitted value, then pass the mapped values into score_initiative, diagnose_process, get_benchmark or the portfolio tools. Pure deterministic lookup, no network, auth, or side effects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ai_tier | No | Everyday AI language, e.g. RPA, GenAI copilot, autonomous agents. Resolved to gen1/gen2/gen3. | |
| function | No | Everyday function language, e.g. customer service, procurement, legal, people. Resolved to cx, supply, risk, hr and so on. | |
| industry | No | Everyday industry language, e.g. banking, ecommerce, pharma. Resolved to the canonical enum. | |
| readiness | No | Everyday culture language, e.g. bureaucratic, cross-functional, hierarchical. Resolved to agile/traditional/siloed. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ai_tier | No | |
| function | No | |
| guidance | Yes | |
| industry | No | input, resolved and matched_on; or resolved null with suggestions when no confident match. |
| readiness | No | |
| bvf_version | Yes |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, destructiveHint. Description adds 'Pure deterministic lookup, no network, auth, or side effects' and explains null result behavior. This enriches transparency beyond structured fields.
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 description is two paragraphs with a clear first sentence summarizing purpose. It is well-structured and front-loaded, though slightly verbose. Every sentence adds value, so it earns a 4.
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?
Given an output schema exists, the description appropriately focuses on usage behavior. It covers return value structure, null handling, and side-effect-free nature. Context is complete for this complexity level.
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 coverage is 100%, so baseline is 3. The description adds value by explaining that parameters are free text and describing the return structure (canonical value, match, or null with suggestions). This goes beyond the schema descriptions.
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 verb 'Map' and the resource 'everyday business language to the canonical AI BVF values'. It distinguishes from sibling tools like list_taxonomy and the scoring tools, making the purpose unambiguous.
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?
Explicitly tells when to call this tool ('when the user says... and the matching enum is not certain') and when to use list_taxonomy instead. Also directs to pass mapped values into specific tools, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_improvementsARead-onlyIdempotentInspect
Turn a Fix or Stop verdict into the change plan that could earn a re-score, with pillar targets, named plays, owners, stop conditions, cost of waiting and a deadline. CALL THIS after score_initiative returns Fix or Stop. Pass work_architecture when the workflow, roles, decision rights or measures have been tested; any explicit gap adds a work-architecture-redesign play and enters the re-score gate. resistance_type selects the will or skill route, and risk_type selects the regulatory, reputational or operational route. Omitted diagnostics remain provisional and return the question needed to test them. Lead with binding_constraint, surface honest_stop when present, and use rescore_gate to decide whether this remains Fix or becomes Stop. Pure deterministic calculation, no network, auth or side effects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| scores | No | OPTIONAL, and each pillar inside it is optional. The four AI BVF pillars, each an honest 0–100 self-assessment, combining deterministically into the verdict: governance_risk ≥ 70 OR financial_return ≤ 20 returns Stop; strategic_alignment, financial_return and change_enablement all ≥ 60 with governance_risk ≤ 40 returns Accelerate; everything else returns Fix. Pass ONLY the pillars the user has real evidence for — do NOT invent numbers for the rest. Missing pillars are estimated deterministically by the engine (from readiness, tier, function and published benchmarks), the response reports which via pillar_basis and scores_used, decision confidence is haircut by how much was estimated, and a fully-estimated pass can never return Accelerate (it returns Fix pending confirmation). So call immediately with whatever the user gave you, then ask for evidence on the estimated pillars and re-call to firm the verdict up. | |
| ai_tier | Yes | Ambition of the AI being deployed: gen1 = automation/RPA, gen2 = GenAI, gen3 = agentic. Interacts with readiness — a more ambitious tier running on lower readiness widens the pace-layer gap, which discounts the modelled EUR value even when the four pillar scores are strong. | |
| function | Yes | Business function where the AI will operate, as one of the accepted enum values — selects which benchmark value drivers and rate ranges apply. Call list_taxonomy for the exact strings if unsure. | |
| industry | Yes | Your industry, as one of the accepted enum values — used to select the benchmark rate multiplier applied to the modelled EUR value. Call list_taxonomy for the exact strings if unsure. | |
| readiness | Yes | Organisational readiness, honest self-assessment: agile = cross-functional, fast decisions; traditional = functional hierarchy; siloed = rigid, hand-off heavy. Sets the value-capture rate and, paired with ai_tier, the pace-layer drag — lower readiness against a higher tier reduces the captured value. Self-report is gameable: when the user has real process numbers, call infer_readiness first and pass its measured classification here instead. | |
| risk_type | No | Optional. The nature of a high governance-risk score: "regulatory" = statute applies (EU AI Act, GDPR Article 22, DORA), "reputational" = the risk is how failure looks and lands publicly, "operational" = the system failing quietly inside a process. Selects between a regulatory remediation sequence, visible trust guardrails, and a proportionate governance review. If you do not know, omit it: the engine infers (gen3 tier, or a regulated function/industry, infers regulatory) and marks the play provisional. | |
| revenue_eur | Yes | Approximate annual revenue in EUR (must be ≥ 0). Scales the whole output: the benchmark rates are applied as fractions of this figure, so the modelled EUR value range grows with it. A rough order-of-magnitude estimate is fine. | |
| resistance_type | No | Optional. What sits behind a low change-enablement score: "will" = people do not want the change (power shifts, fear, no case for change), "skill" = people cannot yet do it (capability and capacity gap). Selects between a coalition-building play (Kotter 1-2 + ADKAR Awareness/Desire) and an owner-and-capability play (ADKAR Knowledge/Ability). If you do not know, omit it: the engine infers from readiness (agile infers skill, traditional/siloed infers will) and marks the play provisional. Ask the user "is the resistance about not wanting this, or not being able to do it yet?" and re-call to sharpen. | |
| work_architecture | No | Optional evidence that the work around the AI has been redesigned. Pass only what is known. Any explicit false value blocks Accelerate until the gap is closed; omitted checks remain visible as unknown. |
Output Schema
ParametersJSON 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. |
| notes | Yes | Caveats or context on the recommendation set. |
| feasible | Yes | Whether the target is reachable via the listed pillar moves. |
| feedback | No | Optional one-question feedback route, present only for Fix/Stop verdicts. The link opens a prefilled email; no response is recorded unless the user chooses to send it. |
| bvf_version | Yes | AI BVF protocol version used. |
| change_plan | No | The change-leader layer: a specific, sequenced route from Fix or Stop toward Go, aimed at the organisation. Present for Fix/Stop, absent when the initiative is already Accelerate. Present this to the user as the plan, not as raw data. |
| recommendations | Yes | Per-pillar improvement actions. |
| advisory_next_step | No | Optional CTA, present only for Fix/Stop verdicts. |
| target_classification | Yes | Verdict the recommendations aim to reach. |
| current_classification | Yes | Verdict as the initiative stands today. |
| projected_decision_confidence | Yes | Confidence in the verdict if the recommendations land, 0-100. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral disclosure beyond the annotations: 'Pure deterministic calculation, no network, auth or side effects' reinforces the readonly/idempotent hints. It also explains behavior for omitted diagnostics: 'Omitted diagnostics remain provisional and return the question needed to test them,' which is critical for agent expectations. This does not contradict any annotation.
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 earns its place. It front-loads the core purpose, then delivers invocation rules, conditional parameter guidance, omission behavior, output emphasis, and determinism in a compact paragraph. No filler or redundancy is present.
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?
Given the tool's complexity (9 params, nested objects, output schema, annotations), the description is complete. It covers purpose, usage prerequisites, parameter semantics, omission behavior, and computational side-effects. The existence of an output schema means the description need not enumerate return fields, so the absence of that detail is not a gap.
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 coverage is 100%, so the baseline is 3. The description adds value by clarifying when to pass optional parameters: 'Pass work_architecture when...' and 'resistance_type selects the will or skill route,' plus 'risk_type selects the regulatory, reputational or operational route.' This goes beyond the schema's field-level descriptions, though not all parameters receive added context (e.g., industry, revenue_eur remain schema-covered).
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+resource: 'Turn a Fix or Stop verdict into the change plan that could earn a re-score.' It clearly names the output (change plan) and the precondition (a Fix or Stop verdict), which distinguishes it from siblings like score_initiative and diagnose_process. The explicit call-out 'CALL THIS after score_initiative' further disambiguates its role.
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?
Provides explicit when-to-use guidance: 'CALL THIS after score_initiative returns Fix or Stop.' It also gives conditional usage for optional params: 'Pass work_architecture when the workflow, roles, decision rights or measures have been tested' and explains how resistance_type and risk_type influence routes. This makes the invocation context unambiguous, even if it does not list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_initiativeARead-onlyIdempotentInspect
Canonical-field scorer for one AI initiative. CALL THIS when industry, revenue_eur, function, ai_tier and readiness are already known, or when re-scoring with measured pillar evidence. For a proposal written in ordinary business language, call assess_ai_initiative first; it resolves these fields and asks for anything missing. Pillar scores remain optional: missing pillars are estimated deterministically, reported through pillar_basis, and reduce decision confidence, while a fully estimated pass can never return Accelerate. Returns Accelerate, Fix or Stop, modelled gross and net EUR ranges, decision confidence, sensitivity, assumptions and an audit trail. Use score_portfolio for several initiatives and diagnose_process for measured waste in an existing process. Pure deterministic calculation, no network, auth or side effects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| scores | No | OPTIONAL, and each pillar inside it is optional. The four AI BVF pillars, each an honest 0–100 self-assessment, combining deterministically into the verdict: governance_risk ≥ 70 OR financial_return ≤ 20 returns Stop; strategic_alignment, financial_return and change_enablement all ≥ 60 with governance_risk ≤ 40 returns Accelerate; everything else returns Fix. Pass ONLY the pillars the user has real evidence for — do NOT invent numbers for the rest. Missing pillars are estimated deterministically by the engine (from readiness, tier, function and published benchmarks), the response reports which via pillar_basis and scores_used, decision confidence is haircut by how much was estimated, and a fully-estimated pass can never return Accelerate (it returns Fix pending confirmation). So call immediately with whatever the user gave you, then ask for evidence on the estimated pillars and re-call to firm the verdict up. | |
| ai_tier | Yes | Ambition of the AI being deployed: gen1 = automation/RPA, gen2 = GenAI, gen3 = agentic. Interacts with readiness — a more ambitious tier running on lower readiness widens the pace-layer gap, which discounts the modelled EUR value even when the four pillar scores are strong. | |
| function | Yes | Business function where the AI will operate, as one of the accepted enum values — selects which benchmark value drivers and rate ranges apply. Call list_taxonomy for the exact strings if unsure. | |
| industry | Yes | Your industry, as one of the accepted enum values — used to select the benchmark rate multiplier applied to the modelled EUR value. Call list_taxonomy for the exact strings if unsure. | |
| readiness | Yes | Organisational readiness, honest self-assessment: agile = cross-functional, fast decisions; traditional = functional hierarchy; siloed = rigid, hand-off heavy. Sets the value-capture rate and, paired with ai_tier, the pace-layer drag — lower readiness against a higher tier reduces the captured value. Self-report is gameable: when the user has real process numbers, call infer_readiness first and pass its measured classification here instead. | |
| revenue_eur | Yes | Approximate annual revenue in EUR (must be ≥ 0). Scales the whole output: the benchmark rates are applied as fractions of this figure, so the modelled EUR value range grows with it. A rough order-of-magnitude estimate is fine. | |
| work_architecture | No | Optional evidence that the work around the AI has been redesigned. Pass only what is known. Any explicit false value blocks Accelerate until the gap is closed; omitted checks remain visible as unknown. | |
| signal_completeness | No | Optional 0–1. How grounded the four pillar scores are in real evidence versus estimated from context. Defaults to 1 (treated as measured). If the organisation lacks formal change-readiness or risk metadata, estimate the pillars from what you know AND set this lower to say so — decision confidence is reduced proportionally and a caveat is attached, instead of returning a falsely confident verdict on soft inputs. |
Output Schema
ParametersJSON 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. |
| caveat | No | Present only when signal_completeness was low: warns the verdict rests on soft inputs and confidence was reduced. |
| reason | Yes | One-line justification for the classification. |
| drivers | Yes | Named value drivers behind the estimate. |
| feedback | No | Optional one-question feedback route, present only for Fix/Stop verdicts. The link opens a prefilled email; no response is recorded unless the user chooses to send it. |
| bvf_version | Yes | AI BVF protocol version used. |
| multipliers | Yes | Factors applied to the base rates. |
| scores_used | No | The four pillar values the verdict was actually computed on, whether given by the caller or estimated by the engine. Show these to the user when any pillar was estimated. |
| sensitivity | No | What moves this verdict, computed deterministically: the value if readiness were one notch worse, the value at revenue minus 20 percent, and the nearest single-pillar movements that flip the classification. Boards trust ranges with visible assumptions over point estimates; show this. |
| pillar_basis | No | Per pillar: "given" (caller supplied it) or "estimated" (deterministic prior). When any pillar is estimated, tell the user which, and ask for evidence on those to firm up the verdict. |
| net_value_eur | Yes | Modelled net value in EUR after capture rate, low/high. |
| classification | Yes | The verdict for this initiative. |
| applied_modules | Yes | BVF scoring modules that fired for this input. |
| gross_value_eur | Yes | Modelled gross value in EUR before capture, low/high. |
| benchmark_source | Yes | Citation for the benchmark rates applied. |
| work_architecture | Yes | The work architecture gate across workflow, roles, human decision rights and performance measures. Any stated gap blocks Accelerate. |
| advisory_next_step | No | Optional CTA, present only for Fix/Stop verdicts. |
| decision_confidence | Yes | Confidence in the verdict, 0-100. |
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description goes further: 'Pure deterministic calculation, no network, auth or side effects.' It also discloses that missing pillars are estimated deterministically, reported via pillar_basis, reduce decision confidence, and that a fully estimated pass can never return Accelerate — substantial behavioral context beyond the annotations.
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 compact despite covering a complex tool. Each sentence serves a distinct purpose: when to call, when to avoid, estimation behavior, return values, alternative tools, and side-effect safety. It is front-loaded with the tool's identity and remains free of 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?
For a tool with rich input schema, annotations, output schema, and nested objects, the description covers the essential context: when to invoke, what the verdicts are, how estimation works, what is returned, and the pure/deterministic/no-side-effect nature. There is no critical gap that would prevent correct selection and invocation.
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 coverage is 100% with detailed descriptions for every parameter, including enum values, optionality, and estimation rules for pillar scores. The description adds that the five required parameters should already be known, and mentions that pillar scores are optional, but this is largely redundant with the schema's own guidance. No new parameter-level semantics beyond the schema.
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 'Canonical-field scorer for one AI initiative', naming a specific verb and resource. It clearly states the tool returns Accelerate, Fix or Stop with modelled ranges and an audit trail, and distinguishes itself from assess_ai_initiative, score_portfolio, and diagnose_process.
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 when-to-use guidance is provided: 'CALL THIS when industry, revenue_eur, function, ai_tier and readiness are already known, or when re-scoring with measured pillar evidence.' It also names alternatives, telling the agent to call assess_ai_initiative first for ordinary business language and score_portfolio for multiple initiatives, plus diagnose_process for measured waste.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_portfolioARead-onlyIdempotentInspect
Score several AI initiatives as one AI BVF v1.0 portfolio and return the board-level position: counts of Accelerate / Fix / Stop, aggregate modelled EUR value range, mean decision confidence, the highest-value initiative, the highest-risk initiative, and every individual result. CALL THIS when the user has a portfolio document and needs to know what it contains before deciding funding or order, instead of looping score_initiative one initiative at a time. The single readiness value applies across every initiative: it changes capture rates and the pace-layer drag, so measure it with infer_readiness first when process data exists. The portfolio must carry organization.revenue_eur for EUR values; initiatives with missing revenue or invalid taxonomy are reported as skipped, never silently counted. Run validate_portfolio first only when the document shape is uncertain, then call sequence_portfolio when the verdicts need turning into a 90-day order. Pure deterministic calculation — no network, auth, or side effects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| portfolio | Yes | A portfolio document conforming to the AI BVF v1.0 schema: bvf_version, organization (name, industry, optional revenue_eur), and a non-empty initiatives array. Each initiative carries id, name, function, ai_tier, and a scores object whose four pillars are each either a bare number (0–100) or an object { value: 0–100 }; both shapes are accepted everywhere. Every initiative is run through the same rule as score_initiative — governance_risk ≥ 70 OR financial_return ≤ 20 → Stop; all of strategic_alignment/financial_return/change_enablement ≥ 60 with governance_risk ≤ 40 → Accelerate; else Fix — and the verdicts are aggregated into portfolio counts. organization.revenue_eur is required to model EUR value; initiatives that cannot be scored (missing revenue, unknown function/ai_tier) appear in skipped_initiatives rather than scored_initiatives. Validate first with validate_portfolio if the document may be malformed. Schema: https://www.aibvf.com/protocol. | |
| readiness | Yes | Organisational readiness applied to every initiative in the portfolio. Honest self-assessment: agile = cross-functional, fast decisions; traditional = functional hierarchy; siloed = rigid, hand-off heavy. The portfolio schema does not carry per-initiative readiness; this single value sets the capture rate for the whole portfolio and, paired with the ai_tier of each initiative, its pace-layer drag — lower readiness against a higher tier discounts the modelled EUR value. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total initiatives in the portfolio (scored + skipped). |
| valid | Yes | True when the portfolio passed schema validation. False means no initiatives were scored. |
| summary | Yes | |
| feedback | No | Optional one-question feedback route, present only when any initiative was Fix or Stop. The link opens a prefilled email; no response is recorded unless the user chooses to send it. |
| readiness | Yes | Readiness value applied across all initiatives. |
| bvf_version | Yes | AI BVF protocol version used. |
| organization | Yes | Echo of the portfolio organisation fields applied to scoring. |
| validation_errors | No | Empty when valid; otherwise one entry per schema violation. |
| advisory_next_step | No | Optional CTA, present only when any initiative was Fix or Stop. |
| scored_initiatives | Yes | Per-initiative scoring result. |
| skipped_initiatives | Yes | Initiatives that could not be scored, with the reason. Empty when all initiatives scored. |
| aggregate_net_value_eur | Yes | Sum of net EUR value across scored initiatives, low/high. |
| highest_risk_initiative | No | Scored initiative most at risk: worst classification (Stop > Fix > Accelerate), tie-broken by lowest decision_confidence. Omitted when none were scored. |
| top_initiative_by_value | No | Scored initiative with the highest mid-point net EUR value. Omitted when none were scored. |
| mean_decision_confidence | Yes | Mean decision confidence across scored initiatives (0–100); 0 when none were scored. |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses deterministic nature, no side effects, and the scoring rule (Accelerate/Fix/Stop) including handling of skipped initiatives. Aligns with annotations (readOnlyHint, idempotentHint) and adds context about readiness affecting calculations. No contradiction.
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 main purpose and use case. While slightly long, every sentence contributes important context. Could be tightened but is well-organized and efficient.
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?
Comprehensive for a complex tool with nested parameters and output schema. Covers behavior, prerequisites, alternatives, and side effects. Output schema exists, so return values need not be detailed.
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 coverage is 100%, and the description adds meaningful context beyond the schema: explains portfolio document structure, readiness enum meanings, and how parameters affect the calculation. Adds value without redundancy.
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 tool scores a portfolio of AI initiatives and returns board-level position. It distinguishes from score_initiative by specifying it handles multiple initiatives at once, and references siblings like validate_portfolio and sequence_portfolio, making its purpose distinct.
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?
Explicitly tells when to use: 'CALL THIS when the user has a portfolio document... instead of looping score_initiative one initiative at a time.' Also provides guidance on when to use validate_portfolio first and sequence_portfolio next, including when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sequence_portfolioARead-onlyIdempotentInspect
Turn a scored AI portfolio into three waves with gates over a configurable horizon, so the roadmap respects the change capacity of each business function. CALL THIS after score_portfolio when the user asks what to stop, fund first, defer or fit into the next 90 days. It does not change any verdict or re-score the business case. Stops enter wave 1 to reclaim budget and attention, quicker Accelerates enter wave 2, complex Accelerates and Fixes enter wave 3 behind their re-score gates. Pass the portfolio returned by score_portfolio directly through portfolio, or pass organization plus initiatives; both score shapes are accepted and nested values are flattened. readiness sets capture rates and pacing, max_parallel_per_function caps simultaneous change in one function per wave, and horizon_days divides the plan into three equal windows. Capacity overflow is reported as a conflict or a deferral beyond the horizon, never hidden. Run recommend_improvements for a Fix before treating its wave placement as permission to proceed. Pure deterministic calculation, no network, auth, or side effects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| portfolio | No | Alternative input: the same AI BVF v1.0 portfolio document score_portfolio accepts (organization + initiatives with nested {value} pillar scores). Pass either this OR the top-level organization + initiatives; nested score values are flattened automatically, and missing pillars are estimated honestly. | |
| readiness | Yes | Organisational readiness applied across the portfolio; sets capture rates and pacing. Measure it with infer_readiness when process numbers exist. | |
| constraints | No | Change-capacity constraints. The defaults encode the core principle: no function absorbs unlimited concurrent change. | |
| initiatives | No | The portfolio to sequence. Each initiative carries flat 0-100 pillar numbers (not the nested value objects of the portfolio wire format). | |
| organization | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| audit | Yes | 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. |
| waves | Yes | Three waves with named gates: Stops first (free the budget), quick Accelerates second (buy trust), complex Accelerates plus Fixes third (spend the trust). Present this to the user as the rollout plan. |
| totals | Yes | Counts: stopped, quick_wins, complex_or_fix, deferred. |
| skipped | No | |
| bvf_version | Yes | |
| capacity_conflicts | Yes | Where more initiatives land on one function than it can absorb per wave, with the deferral applied. Surface these: an overloaded function is how good portfolios fail. |
| sequencing_principles | Yes | |
| deferred_beyond_horizon | No | Initiatives that did not fit the horizon under the capacity constraint; they need their own decision. |
| aggregate_accelerate_value_eur | No | Sum of modelled net EUR for the sequenced Accelerates, low and high. |
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces this with 'Pure deterministic calculation, no network, auth, or side effects.' It adds behavioral details like capacity overflow reporting ('never hidden') and how readiness affects pacing, which go 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads purpose and usage. Every sentence adds value—no filler. It is appropriately sized for the tool's complexity and fits within a typical token budget.
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, the description doesn't need to explain return values. It covers all necessary aspects: what it does, when to call, accepted inputs, key parameters, capacity overflow behavior, and ordering with siblings. It fully equips an agent to invoke the tool correctly.
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?
The description adds significant meaning beyond the schema's 80% coverage. It explains the alternative input formats (portfolio vs organization+initiatives), how readiness determines capture rates and pacing, the impact of max_parallel_per_function, and that nested values are flattened and missing pillars estimated. These details make the parameters more actionable.
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 starts with a clear verb-resource pair ('Turn a scored AI portfolio into three waves with gates') and immediately distinguishes from siblings by specifying it is called after score_portfolio. It also states what it does not do ('does not change any verdict or re-score'), making the purpose unambiguous.
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?
Explicitly states when to call ('after score_portfolio when the user asks what to stop, fund first, defer or fit into the next 90 days'), what inputs to pass, and even references a sibling ('Run recommend_improvements for a Fix before treating its wave placement as permission to proceed'). This provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_portfolioARead-onlyIdempotentInspect
Check whether a supplied AI BVF v1.0 portfolio document has the shape the portfolio tools require, before scoring, sequencing, storing or sharing it. CALL THIS when the document came from a file, another system or hand-built JSON and its structure is uncertain. It checks required fields, taxonomy values and 0–100 pillar ranges only; it does not judge the evidence or calculate a verdict. Pillars may be bare numbers or { value, confidence } objects, both are valid. Use assemble_portfolio when the user has a list of initiatives in conversation and needs the document built for them, score_portfolio when the document is already ready for verdicts, and sequence_portfolio only after its initiatives are scoreable. Returns valid=true or one error per failing JSON path. Pure deterministic validation — no network, auth, or side effects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| portfolio | Yes | The portfolio document as a JSON object following the AI BVF v1.0 schema: a top-level object with bvf_version, organization, and a non-empty "initiatives" array, each initiative carrying the same fields score_initiative expects (industry, revenue_eur, function, ai_tier, readiness, and a scores object with the four 0–100 pillars, each either a bare number or an object { value, confidence? }; both shapes pass). Checked structurally only — required fields present, correct types, enum values valid, pillar numbers in range; the pillar values are NOT scored or judged here (use score_initiative or score_portfolio for that). On failure, errors[] names each failing JSON path and the rule it broke. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | True when the portfolio conforms to the schema. |
| errors | Yes | Empty when valid; otherwise one entry per schema violation. |
| bvf_version | Yes | AI BVF protocol version validated against. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosure goes beyond annotations: states it is 'pure deterministic validation — no network, auth, or side effects', explains what it does not do ('does not judge the evidence or calculate a verdict'), and clarifies valid pillar shapes. No contradiction with annotations.
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?
Description is concise, well-structured, and front-loaded. Every sentence adds unique value without repetition or fluff. The first sentence immediately states purpose and context.
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?
Given input schema details, output schema existence, and lack of output schema shown in input, the description covers validation behavior, return format (valid=true or errors), and scope. No gaps remain for the agent to select and invoke correctly.
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 coverage is 100%, but the description adds significant value: explains the portfolio document structure (bvf_version, organization, initiatives array), the validation scope (required fields, taxonomy, ranges), and the acceptable score shapes (bare number or object). This exceeds schema descriptions.
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 tool validates an AI BVF v1.0 portfolio document with the verb 'check' and resource 'shape'. It explicitly distinguishes from siblings by naming assemble_portfolio, score_portfolio, and sequence_portfolio with their specific use cases.
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?
Provides explicit guidance: 'CALL THIS when the document came from a file, another system or hand-built JSON and its structure is uncertain.' Also specifies when to use alternatives (assemble_portfolio, score_portfolio, sequence_portfolio), giving clear when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Alicense-qualityBmaintenanceBasel III + SR 11-7 + ECB TRIM AI/ML model risk MCP for banks, with EU AI Act compliance built-in.MIT
- Alicense-qualityBmaintenanceProvides grounded investment decisions with evidence links and invalidation conditions, enabling users to review their portfolio through a structured decision process.MIT
- Alicense-qualityDmaintenanceQuantitative governance gate for AI agents. Six gates (risk, profit, novelty, complexity, quality, utility) return PROCEED/PAUSE/HALT/ESCALATE with confidence scores and hash-chained, tamper-evident audit trails. Generates NIST AI RMF and EU AI Act Annex IV artifacts. 10 MCP tools; local stdio and hosted Streamable HTTP with a free tier.MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.