B4 Index

Score a software category

b4_score

Read-only

Score a software category using the B4 Index. Provide a known category name to get pre-computed scores, or provide raw dimension scores (1-5 each) for a custom evaluation. Returns the banded verdict (primary, confidence, near-call flag, full distribution, tipping point), axes, urgency level, and a concise breakdown. The default result is intentionally lean — set includeEvidence: true to also get the full research trail and source URLs behind each score. Verdicts are banded (B4 methodology v4.0), not point calls: each of the three quadrant dimensions carries a ±1 uncertainty band, the resulting cells are enumerated exactly, and the verdict is the quadrant holding the most probability mass. Every verdict ships with its full distribution, a confidence word — clear (≥70% of the mass), lean (50–70%), split (<50%) — and a near-call flag when the runner-up is within 15 points. An axis counts as high only when it clears the 3.5 line strictly, which on this 1–5 grid means only at 4 or above, so a category sitting exactly on the line gets the safer call: ties break in the order BUY → BRIDGE → BEWARE → BUILD, cheapest mistake first. Optional org lens: set org to "small", "medium" (the default) or "large" to read the same scores as a team of that engineering maturity — it shifts the center of the AI-feasibility band by −1 / 0 / +1 and nothing else. The lens is a filter the caller looks through, never a stored profile: no user attribute is saved, inferred, or asked for, and the scores themselves never change. Omit it and you get the default-lens numbers, which are the ones published on logged-out surfaces.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`org`	No	Org-maturity lens: "small" (no dedicated engineering), "medium" (default — some AI capability), "large" (AI-mature). Shifts the AI-feasibility band center by −1/0/+1 at read time. A filter the caller looks through, never a stored profile.	medium
`scores`	No	Custom dimension scores for a tool not in the database
`category`	No	Name of a known B4 category (e.g., 'Expense Management', 'CRM')
`includeEvidence`	No	Include the full evidence trail and source URLs behind each dimension score. Off by default so the initial result stays concise; set true for deep verification.

TDQS

A4.6/5.0

Behavior5/5

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

With readOnlyHint=true, the description adds substantial behavioral detail beyond the annotation: banded verdicts, ±1 uncertainty bands, confidence thresholds, near-call flags, tie-breaking order, and the org lens as a stateless filter that 'never stores a profile.' It also transparently explains the default lean result and the effect of includeEvidence. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense. Every sentence adds unique detail about methodology, output contents, or option behavior, and the opening sentence front-loads the core purpose. The single-paragraph structure is somewhat heavy, but appropriate given the tool's complexity and lack of an output schema.

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?

Despite having no output schema, the description enumerates the return components (banded verdict, confidence, near-call flag, full distribution, tipping point, axes, urgency level, breakdown) and explains the scoring methodology and option effects. This is sufficient for an agent to understand what it will get and how to invoke the tool 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%, so the baseline is 3. The description adds meaningful operational semantics: explaining that org shifts the AI-feasibility band by −1/0/+1, that scores are pre-computed or custom, and that includeEvidence returns the full research trail. This goes beyond the schema's structural 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 identifies the action ('Score') and the resource ('a software category using the B4 Index'), and distinguishes two input modes: known category name or custom dimension scores. This differentiates it from sibling tools like b4_compare or b4_recommend by focusing on scoring rather than comparison or recommendation.

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 provides clear context on how to invoke the tool: use a known category or provide raw scores, optionally set includeEvidence and org. It also explains the org lens semantics. However, it does not explicitly state when to use this tool instead of the sibling tools, so it lacks explicit exclusion or alternative guidance.

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

All B4 Index tools Inspect

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

Disambiguation5/5

Each tool has a clearly distinct purpose: browse discovers categories, recommend maps natural language to categories, score evaluates a single category, compare provides build-vs-buy analysis, and audit aggregates verdicts across a portfolio. The detailed descriptions eliminate ambiguity between overlap-adjacent tools like score and compare.

Naming Consistency5/5

All tools follow a consistent 'b4_<verb>' pattern with lowercase and underscores, making the action of each tool predictable. The verbs (audit, browse, compare, recommend, score) are distinct and match the tool's function.

Tool Count5/5

The 5-tool set is well-scoped for the B4 Index domain, covering discovery, evaluation, comparison, recommendation, and portfolio analysis without redundancy or bloat. Each tool provides a distinct value-add, and the count is within the ideal 3-15 range.

Completeness5/5

The set provides full lifecycle coverage for the B4 Index domain: users can browse categories, get natural-language recommendations, score a category, compare build vs. buy, and audit an entire stack. There are no obvious dead ends, and the optional org lens and evidence flag add depth without creating gaps.

Resources

Need Help?