Skip to main content
Glama

aibvf-mcp

by io.github.Bahamas1717

assess_ai_initiative

Read-onlyIdempotent

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. A stated gap or missing work architecture evidence blocks Accelerate and stays visible in the audit trail. Pillar scores and work architecture evidence remain optional inputs, but unresolved values are never guessed and cannot unlock Accelerate. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scoresNoOPTIONAL, 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 disclosed AI BVF planning assumptions, 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_tierNoOptional correction or answer: automation/RPA, GenAI/copilot, or agentic/autonomous. Overrides anything inferred from proposal.
functionNoOptional correction or answer in canonical or everyday language, for example customer service, procurement, finance or risk. Overrides anything inferred from proposal.
industryNoOptional correction or answer in canonical or everyday language, for example retail, hospital, bank or public sector. Overrides anything inferred from proposal.
proposalYesThe 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.
readinessNoOptional correction or answer: agile, traditional, or siloed, including everyday descriptions such as cross-functional, hierarchical or bureaucratic. Overrides anything inferred from proposal.
revenue_eurNoOptional approximate annual revenue in EUR. Overrides any EUR amount extracted from proposal. No currency conversion is performed.
work_architectureNoOptional 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_completenessNoOptional 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

TableJSON Schema
NameRequiredDescriptionDefault
statusYesneeds_input when one or more required decision inputs remain unresolved; verdict when scoring completed.
verdictNoThe AI BVF score. Present only when status is verdict.
proposalYesThe supplied proposal, returned so the next call can preserve it verbatim.
bvf_versionYes
resolutionsYesEvery deterministic resolution, naming the field, canonical value, source and matched phrase.
suggestionsNoAccepted values for an explicitly supplied field that could not be resolved.
next_questionNoThe single next question to ask. Present only when status is needs_input.
missing_fieldsYes
resolved_inputsYesCanonical fields resolved so far. Explicit corrections override proposal inference.

TDQS

A5/5.0
Behavior5/5

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

The description goes far beyond the annotations with behaviors like "Pure deterministic calculation, no network, auth or side effects." It also reveals key logical rules, including that missing work architecture blocks Accelerate, unresolved values are never guessed, estimated pillars reduce confidence, and a fully-estimated pass can never return Accelerate. This is materially richer than the readOnlyHint/idempotentHint/destructiveHint 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 dense but every sentence earns its place. It front-loads the primary call condition and purpose, then covers behavioral constraints, sibling routing, evidence handling, and final safety guarantees. For a tool with 9 parameters and significant decision logic, this length is justified and well structured.

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?

The description explains invocation timing, candidate context, missing-data handling, the effect of evidence gaps, verdict conditions, and determinism. Since an output schema already exists, the description does not need to itemize return fields. There are no obvious situational gaps left for an agent deciding whether and how to invoke the 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?

Even though the schema already covers 100% of parameters in high detail, the description adds critical usage semantics around those parameters: pass only pillar scores with real evidence, do not invent numbers, call with whatever the user gave, then re-call with evidence. It further explains that work architecture fields should only be true when the design has actually been redesigned, which directly improves correct field-set selection.

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 first sentence explicitly names the tool as "the front door for one AI investment decision" and says "CALL THIS FIRST" when the user describes an AI idea in ordinary language. It clearly separates this tool from its siblings by naming exact alternatives (score_initiative, score_portfolio, diagnose_process). This gives the agent an unambiguous actionable purpose with no need to parse schemas.

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 gives explicit when-to-use conditions: "when user describes an AI idea in ordinary language or asks whether it should proceed." It also provides clear alternatives: "Use score_initiative when canonical fields are already known, score_portfolio for several initiatives, and diagnose_process for measured waste in a running process." This is Specific and direct usage routing.

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

All aibvf-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation4/5

Each tool has a clear trigger and purpose, with descriptions explicitly cross-referencing when to use which. However, assess_ai_initiative, score_initiative, and score_portfolio all produce verdicts and could be confused without carefully reading the canonical-vs-conversational distinction.

Naming Consistency5/5

All 13 tools follow a consistent snake_case verb_noun pattern: assemble, assess, calculate, diagnose, get, infer, list, map, recommend, score, sequence, validate. No mixed conventions or vague verbs.

Tool Count5/5

13 tools is well within the ideal range for a domain of this complexity. Each tool covers a distinct stage of the AI investment workflow—taxonomy, assessment, scoring, portfolio, sequencing, diagnostics—without redundancy or bloat.

Completeness5/5

The tool surface covers the full lifecycle: mapping input language, assembling and validating portfolio documents, assessing and scoring initiatives, diagnosing processes, measuring readiness, calculating pace-layer drag, recommending improvements, and sequencing portfolios. No obvious dead ends or missing operations for the stated domain.

Resources