Skip to main content
Glama

Build-vs-buy recommendation

b4_recommend
Read-only

Get B4 Index recommendations from a natural language description of a software need or business context. Matches the description to relevant categories and returns top matches with scores, banded verdicts, and actionable recommendations. 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
descriptionYesDescribe the software need, business problem, or tool you're evaluating (e.g., 'We need to automate our expense reports and receipt scanning')

TDQS

A4.3/5.0
Behavior5/5

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

This description goes far beyond the readOnlyHint and openWorldHint annotations, disclosing the banded verdict methodology, ±1 uncertainty band, confidence word thresholds, near-call flag, tie-breaking order, strict 3.5 axis threshold, and the org lens's behavior as a read-time filter with no stored profile or user data. It also clarifies that scores never change, reinforcing the read-only 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?

The description is long but front-loaded with a clear purpose statement, followed by logically organized methodological details, the org lens explanation, and a closing note about free tools. Most sentences add necessary information for correct invocation, though the bracketed note about b4_browse and b4_score is a slight aside.

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 and lack of an output schema, this description is exceptionally complete. It covers the return shape (top matches, scores, banded verdicts, actionable recommendations) and the nuanced decision logic (uncertainty bands, confidence words, tie-breaking, threshold strictness), leaving little ambiguity about the tool's behavior.

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 already documents both parameters completely (description maxLength, org enum/default), so baseline is 3. The description adds meaningful context beyond the schema: it explains the org lens as engineering maturity (small/medium/large), the −1/0/+1 band shift, and notes that omitting it yields the published default-lens numbers. This enriches parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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: 'Get B4 Index recommendations from a natural language description of a software need or business context' and details the output (top matches with scores, banded verdicts, actionable recommendations). It names the specific resource and verb, but it does not explicitly differentiate from siblings like b4_compare or b4_audit, only mentioning that b4_browse and b4_score are free 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 gives clear context for when to use the tool ('from a natural language description of a software need or business context') and detailed guidance on the org lens parameter, including what each value does and what happens if omitted. However, it does not explicitly state when not to use this tool or name alternatives for particular use cases.

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