aibvf-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.7.0
Disambiguation5/5
Each tool targets a distinct operation: taxonomy enumeration, benchmark lookup, single initiative scoring, portfolio scoring, validation, process diagnosis, recommendation generation, and drag cost calculation. There is no functional overlap or ambiguity among them.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., list_taxonomy, score_initiative, validate_portfolio). The verb clearly describes the action, and the noun indicates the entity, making the pattern predictable and easy to interpret.
Tool Count5/5
With 8 tools covering the core workflows of an AI business value framework (taxonomy lookup, benchmarking, scoring single and portfolio, validation, diagnosis, recommendations, and drag cost), the number is well-scoped. Each tool serves a clear purpose without redundancy.
Completeness5/5
The tool surface covers the full lifecycle of AI BVF assessment: prepare (taxonomy, benchmark), evaluate (score_initiative, score_portfolio), validate (validate_portfolio), improve (recommend_improvements, diagnose_process), and quantify impact (calculate_pace_layer_drag). No obvious gaps exist for the stated domain.
Average 4.7/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 93 commits in the last 12 weeks
- Last stable release on June 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds important context: 'Pure deterministic calculation — no network, auth, or side effects,' reinforcing safety and idempotency. No contradiction with annotations; it adds value beyond them.
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, each serving a distinct purpose: definition, usage, and output/nature. It is front-loaded with the core concept and contains no unnecessary words. Every sentence earns its place.
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 has 4 parameters, output schema exists, and the description lists all return values (EUR low/high, drag rate, pace_gap severity, drivers, source), plus the deterministic nature, it provides complete context for an agent to invoke correctly without needing additional information.
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%, so baseline is 3. The description does not add extra meaning beyond the schema definitions. It mentions ranges and enums but doesn't elaborate on parameter relationships or formatting. Thus, it meets but does not exceed the baseline.
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 calculates 'annual Organisational Drag Cost' and distinguishes it from the cost of AI build. It specifies the exact return values (EUR range, drag rate, pace_gap severity, drivers, source), making the purpose unambiguous and distinct from siblings like score_initiative or validate_portfolio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to quantify the cost of NOT changing the operating model,' providing a clear when-to-use. It also says 'NOT the cost of the AI build,' which helps avoid misuse. However, it does not explicitly discuss when not to use or compare to sibling tools, slightly lowering the score from 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds 'pure deterministic calculation — no network, auth, or side effects' and 'Pillar-level targets with named actions and rationale.' No contradictions.
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 sentences, each providing essential information. Front-loaded with purpose, no unnecessary words or repetition.
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 6 parameters, nested objects, output schema, and rich annotations, description covers purpose, usage, and behavioral traits adequately. References sibling tool and provides complete guidance for an agent.
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 description coverage is 83% (high). Description adds minimal parameter detail beyond schema, but provides context about expected scores from score_initiative. Baseline 3 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?
Description clearly states the tool returns concrete recommendations for Stop or Fix initiatives to flip toward Accelerate, specifying verb, resource, and condition. Differentiates from sibling tools like score_initiative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use after score_initiative and for Stop/Fix classifications. Notes pure deterministic calculation with no side effects, but does not enumerate when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares 'Pure deterministic lookup — no network, auth, or side effects,' which adds behavioral context beyond the annotations (readOnlyHint, idempotentHint, destructiveHint). There is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, concise and front-loaded with the core purpose, then usage guidance, then behavioral traits. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters with enums, full annotations, and an output schema), the description is complete. It conveys purpose, usage, return values, and safety, leaving no gaps for an AI agent.
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 enum descriptions for both parameters. The description does not add additional semantics beyond what the schema already provides, so a baseline score of 3 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 explicitly states it looks up published benchmark rates for a business function and industry, and lists the specific return fields: revenue/cost ranges, industry multiplier, value drivers, and cited source. It also distinguishes this tool from score_initiative.
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 clear guidance: use when the caller wants raw rates and multiplier without running a four-pillar verdict; for an initiative-level Accelerate/Fix/Stop call, use score_initiative instead. This explicitly states when to use and when not to use, along with the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructiveHint, and the description reinforces these by stating 'Pure deterministic validation — no network, auth, or side effects.' This adds explicit behavioral context beyond annotations 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences plus a brief list of alternatives and a link. Main purpose is front-loaded, and every sentence adds value: purpose, return format, usage guidelines, and behavioral context. No extraneous 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 the presence of an output schema (as indicated by context signals), the description explains the return format, including the error structure. The input schema is fully documented, annotations cover behavioral traits, and sibling tools are listed. The description also provides a reference to the external schema. This is a complete enough description for the tool's moderate complexity.
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?
The input schema already provides a detailed description of the 'portfolio' parameter (covering structure and required fields), achieving 100% schema description coverage. The tool description does not add additional parameter-level meaning beyond what the schema provides, so it meets the baseline expectation but does not exceed it.
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 'Check' and the resource 'BVF portfolio document', and specifies conformance to a specific schema. It distinguishes itself from siblings by mentioning alternatives like 'score_initiative' and 'score_portfolio', and the context 'before you score, store, or share it' clarifies when to use.
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 explicitly states when to use ('before you score, store, or share it') and directs to alternative tools for different tasks ('use score_initiative to evaluate a single initiative, or score_portfolio to score them all'). It also notes that the tool is deterministic and has no side effects, guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds 'Takes no parameters and has no side effects' reinforcing safety. No contradictions.
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?
Single coherent paragraph, front-loaded with purpose, then usage and side effects. Efficient but could be slightly more structured (e.g., bullet points for enum categories)
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 rich annotations, description fully explains what the tool returns, when to use it, and that it's safe. Complete for agent guidance.
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. Description adds value by explaining the output (full enum lists) and usage context, meeting baseline for zero-param 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?
Clearly states 'Return every accepted enum value for the AI BVF taxonomy' with specific items (industries, functions, ai_tier levels, readiness levels). Differentiates from siblings by naming the tools that accept these values.
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 first when unsure which exact strings ... will accept' and lists six sibling tools, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosure beyond annotations: 'Pure deterministic calculation — no network, auth, or side effects, so calling it is always safe and free.' Also explains behavior when scores are estimated (set signal_completeness lower). No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint).
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 a paragraph of about 10 sentences. It is well-structured: starts with purpose, then usage instructions, then caveats. Every sentence adds value. Could be slightly more concise, but not overly verbose.
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 complexity (7 parameters, nested objects, output schema exists), the description is very complete. It covers when to call, how to handle partial info, how to convey estimation, and differentiates from siblings. Output schema handles return value documentation.
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 86%, so the schema already documents most parameters. The description adds meaningful context: e.g., how to estimate pillar scores and set signal_completeness, and suggesting list_taxonomy for enum uncertainties. It adds 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 the tool's purpose: 'Pre-flight verdict on a single AI initiative using AI BVF v1.0' and lists outputs (classification, value range, confidence, etc.). It distinguishes from sibling tools like score_portfolio and diagnose_process by specifying when to use which.
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 use proactively: 'Whenever the user describes, proposes, compares, or asks whether to pursue any AI... run this first.' It provides guidance on partial information, estimation, and calling list_taxonomy first. It clearly says when to use alternatives (score_portfolio for portfolio, diagnose_process for existing processes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses deterministic calculation, no network/auth/side effects (reinforcing annotations), schema validation first, and skipped initiatives behavior. Adds context beyond readOnlyHint and idempotentHint 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?
Well-structured with purpose upfront, then usage, validation, and side-effect note. Every sentence adds value, though slightly verbose; front-loaded purpose is good.
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: covers return structure (counts, value range, confidence, top/highest-risk, per-initiative), error handling (validation errors), and skipped initiatives. With rich schema/annotations and output schema, description is complete.
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% with detailed property descriptions. The tool description adds extra context: portfolio's required fields, revenue requirement for EUR value, and readiness application. Moderately enhances schema info.
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 in a single call and returns portfolio-level metrics, distinguishing it from score_initiative (single initiative) and validate_portfolio (pre-requisite). The verb 'score' and resource 'portfolio' 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?
Explicitly tells when to use: after validate_portfolio or instead of looping score_initiative when board-level verdict is needed. Implicitly advises against using for single initiative scoring.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: 'Pure deterministic calculation — no network, auth, or side effects' aligns with readOnlyHint and idempotentHint. It also discloses that figures are directional and benchmark-cited, not audited.
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 well-structured and concise. Every sentence adds value: it front-loads purpose and outputs, then gives usage, partial input handling, and final notes on calculation nature. 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 the tool's complexity (13 parameters, 2 enums, output schema), the description fully covers purpose, usage, behavior, partial inputs, and output contents. The presence of an output schema relieves the need to detail return values.
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 meaningful extra info, especially about signal_completeness: 'pass what the user gave you and set signal_completeness to reflect how much was measured versus estimated, and the decision confidence scales down accordingly.' This enhances understanding beyond 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 diagnoses a single existing business process and returns specific outputs like intervention, net EUR saving, efficiency gain, verdict, and confidence. It distinguishes from sibling score_initiative by stating 'operational counterpart' and contrasting 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?
Explicitly states when to call ('CALL THIS WHEN the user describes a real, running process...') and when to use alternatives ('use score_initiative to judge a proposed AI initiative...'). Also advises calling list_taxonomy first if unsure about the function enum.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ai-bvf MCP server](https://glama.ai/mcp/servers/Craig-Horton/ai-bvf/badges/card.svg)](https://glama.ai/mcp/servers/Craig-Horton/ai-bvf)

Score Badge

Copy to your README.md:

[![ai-bvf MCP server](https://glama.ai/mcp/servers/Craig-Horton/ai-bvf/badges/score.svg)](https://glama.ai/mcp/servers/Craig-Horton/ai-bvf)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Craig-Horton/ai-bvf'

If you have feedback or need assistance with the MCP directory API, please join our Discord server