Skip to main content
Glama

Audit a stack

b4_audit
Read-only

Analyze a software stack against the B4 Index. Provide a list of tool/category names, and get per-tool banded verdicts plus a portfolio summary with verdict distribution, BEWARE spend, near calls, and priority actions. 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. [B4 Agent — the free tools are b4_browse and b4_score.]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
orgNoOrg-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
toolsYesList of software tool or category names to audit (e.g., ['Salesforce', 'Slack', 'Expense Management']). Max 100 per call.

TDQS

A4.7/5.0
Behavior5/5

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

The description goes far beyond the readOnlyHint annotation, explicitly stating that the org lens is never stored, no user attribute is saved/inferred, and the scores never change. It also transparently details the banding methodology, confidence thresholds, near-call flag, and tie-breaking rules. This is exemplary behavioral disclosure 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 long but every sentence carries essential methodology or usage detail. It is front-loaded with the core function, then progressively explains uncertainty, parameter effects, and sibling tools. No redundancy or filler phrases are 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 there is no output schema, the description thoroughly describes the return value: per-tool banded verdicts, portfolio summary, verdict distribution, BEWARE spend, near calls, priority actions, confidence words, and tie-breaking. It also covers edge cases like the 3.5 threshold and tie-breaking order, making the description effectively complete for an agent to invoke and interpret results.

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 input schema already has descriptions for both parameters (100% coverage). The description adds valuable semantics for the 'org' parameter, explaining it shifts the AI-feasibility band center by −1/0/+1 and is a read-time filter, and it gives an example of the 'tools' parameter. This exceeds the baseline of 3 but is not a full 5 because the schema already handles the basic meaning.

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: analyzing a software stack against the B4 Index and producing per-tool verdicts plus a portfolio summary. It distinguishes from siblings by noting the free tools (b4_browse and b4_score) and implies this is the stack-audit tool compared to single-score or browsing tools.

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: use when you have a list of tools/categories to audit as a portfolio. It mentions that b4_browse and b4_score are free, implying these are alternatives for individual operations, but it does not explicitly state when to use b4_compare or b4_recommend over this tool, so it falls short of explicit when-not-to-use guidance.

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

Try in Browser

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