Operating judgement for businesses under $50M revenue. Free top layer; nodes and bundles over x402.
Scored across 6 tools
Each tool occupies a distinct stage: catalogue for discovery, resolve for multi-node quotes, read_bundle to buy a quoted bundle, read_node for single nodes, decision_schema for inputs, apply_decision for computed results. The boundaries between resolve, read_bundle, and read_node lean heavily on the descriptions (quote vs. purchase vs. single read), so careful reading is required but the tools are ultimately separable.
All tools share a consistent bf_ prefix and are readable and predictable. Minor deviation: catalogue and decision_schema are noun forms while the others are verb_noun (apply_decision, read_node, read_bundle, resolve), but the pattern remains clear.
Six tools is well-scoped for a discover-quote-read-apply pipeline; each one maps to a distinct step and earns its place. No redundant or filler tools.
The surface covers the full lifecycle: discovery, schema inspection, price quoting, single- and multi-node reading, and rule application. Minor gap: no keyword/topic search beyond catalogue listing and resolve pattern matching, but agents can work around it.
Runs one decision node's rule on the numbers you send and returns the computed figures, a verdict, the actions in order, the check to keep and the node text with its citations. Deterministic: the result comes from the published rule, not from a model. Costs the decision's catalogue price ($0.05, USDC on Base over x402); the input is checked first, and an input the rule cannot use is refused without charge. Call it when the user has the figures for a specific decision in a business under about $50M in revenue and wants the rule's answer for them; get the schema from bf_decision_schema first. When the question gives figures for a decision, the applied route computes them; the answer reports its result and does not recompute it. Do not call it with invented or placeholder figures, and do not treat the verdict as tax, legal or investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The figures, shaped as that decision's input_schema. | |
| decision | Yes | Decision path from bf_decision_schema, e.g. "cash-flow/decide/runway". |
| Name | Required | Description |
|---|---|---|
| node | No | |
| handle | Yes | |
| applied | No | |
| cite_as | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare read-only/non-destructive/closed-world; the description adds material it does not cover: deterministic rule evaluation rather than model output, a stated cost ($0.05 USDC on Base via x402), and the validation-first charging policy where unusable input is refused without charge. It also notes the verdict is not tax/legal/investment advice, which is real behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the operation and return shape, with cost and prerequisites following sensibly. It runs long (five sentences) and the clause about the 'applied route' computing figures and the answer not recomputing them is somewhat convoluted and overlaps earlier content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still names the return fields, and it covers the things structured data cannot: cost/rails, determinism, validation-before-charge, schema prerequisite, and a liability caveat. Nothing an agent needs before calling is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 goes beyond it by tying the 'input' object to a per-decision input_schema and instructing the agent to fetch that contract from bf_decision_schema, which is the key operational fact for a free-form nested object. It does not add per-field guidance itself, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('runs one decision node's rule ... returns the computed figures, a verdict, the actions in order, the check to keep'), and the enumerated outputs make the operation unambiguous. It is clearly distinct from siblings: bf_decision_schema fetches the schema, bf_read_node reads text, this one executes the rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit call condition ('when the user has the figures for a specific decision in a business under about $50M in revenue'), a prerequisite ('get the schema from bf_decision_schema first'), a negative case ('do not call it with invented or placeholder figures'), and a routing note that a different route already computed the figures. When/not-when and the alternative are both named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every Business Frameworks node: handle, title, layer, token count, price, whether it is free, and whether its decision rule can be run on numbers. Business Frameworks is operating judgement for running a business from launch to about $50M in revenue: value, cash flow, risk (the cost of capital) and growth, down to ten decision rules. Call this first, once, to choose which node answers the question; pass branch to see one branch only. Free. Do not use it for businesses above about $50M in revenue, for tax, legal or accounting treatment, or for market data: it holds judgement and rules, not figures about any company.
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | One of: equation, value, cash-flow, risk, growth, decision, market, ethics, worker, quality. Omit for the whole catalogue. |
| Name | Required | Description |
|---|---|---|
| nodes | No | |
| scope | No | |
| access | No | |
| bundles | No | |
| cite_as | No | |
| payment | No | |
| product | No | |
| version | No | |
| license_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, non-destructive and closed-world, so the description correctly doesn't repeat safety semantics; instead it adds cost ('Free'), a call-once discipline, and domain boundaries that the annotations can't express. It stops short of describing result shape or catalogue size, though an output schema exists so that gap is small.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the resource and returned fields, then moves to routing advice and exclusions in a logical order. Slightly padded — the domain-value framing ('value, cash flow, risk (the cost of capital) and growth') and the one-word 'Free.' sentence could be trimmed without losing routing signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-param, read-only catalogue call with rich annotations and an output schema, nothing an agent needs is missing: it knows to call it first, what it returns, and which questions it must route elsewhere. The negative scope statements are the key addition and they are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the `branch` enum plus 'Omit for the whole catalogue' is already documented in the schema. The description only restates the branch behavior ('pass `branch` to see one branch only') without adding syntax, defaults, or examples beyond it, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource — 'Lists every Business Frameworks node' — and enumerates the returned fields (handle, title, layer, token count, price, free flag, runnable-on-numbers flag). The scope statement ('operating judgement for running a business from launch to about $50M in revenue') separates it cleanly from bf_read_node and bf_resolve, which fetch one node rather than the catalogue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit positive guidance — 'Call this first, once, to choose which node answers the question' — plus an alternative path (pass `branch` for one branch only) and hard exclusions (businesses above ~$50M revenue, tax/legal/accounting, market data). When to use, when not to, and what to do instead are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the input schema, an example input, the price and the fit record (what the framework does for this decision by model, before paying) for one of the applied decisions (reinvest or distribute, build or run for cash, cash cycle, runway, owner pay, hurdle rate, concentration, pace of growth, price, adjacency; and, in the market branch, verdict, pricing power, binding node, rent, shock). Free. Call it before bf_apply_decision to learn which numbers the rule needs and what each one means; without decision it lists them all. Do not guess missing inputs to fill the schema: ask the user for the figures the business actually has.
| Name | Required | Description | Default |
|---|---|---|---|
| decision | No | Decision path, e.g. "risk/decide/hurdle". Omit to list the fifteen. |
| Name | Required | Description |
|---|---|---|
| fit | No | |
| how | No | |
| title | No | |
| handle | No | |
| summary | No | |
| decision | No | |
| decisions | No | |
| price_usd | No | |
| input_schema | No | |
| example_input | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed world), so the description's added value is cost ('Free'), the pre-payment fit record concept, and the behavioural rule about not fabricating inputs. It does not discuss response size, truncation, or error behaviour for an unknown decision path, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The return contents are front-loaded and the workflow instruction follows, with zero filler sentences. The long parenthetical inventory of decision names is dense but does real work; it slightly impedes scanability of the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the description still characterises them (schema, example, price, fit record). It covers cost and the prerequisite for bf_apply_decision; only minor gaps remain around the branch structure ('market branch') and behaviour for an invalid path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already defines `decision` with a path example, so the baseline is 3. The description goes further by explaining the omit-behaviour (lists all fifteen) and by naming the decision vocabulary (reinvest/distribute, hurdle rate, concentration, etc.), which helps an agent choose a value rather than just pass a string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and a well-defined resource: it returns the input schema, example input, price and fit record for one applied decision. It enumerates the decision set and names the sibling it complements (bf_apply_decision), so an agent can distinguish it from bf_catalogue or bf_resolve without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit ordering rule ('call it before bf_apply_decision'), names the alternative behaviour ('without `decision` it lists them all'), and adds a usage constraint ('do not guess missing inputs... ask the user'). When-to-use, when-not-to, and the alternative path are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the nodes of one bundle in order — the central node full, the supporting nodes terse — with citations and a cite-as line per node, on one settlement at the quoted price (a flat $0.05 for every bundle, band included; USDC on Base over x402). Pass the bundle id from bf_resolve or bf_catalogue, and a band to add the scale band for the business's revenue. Call it after bf_resolve has quoted the bundle and the user accepts the price; the quote's url is the same resource over HTTP. Do not call it to browse: the quote already lists the nodes and the price, and a narrow question is cheaper node by node through bf_read_node.
| Name | Required | Description | Default |
|---|---|---|---|
| band | No | A scale band to add, by slug ("1-5m") or label ("$1–5M"); omit for the bundle without a band. | |
| bundle | Yes | Bundle id from bf_resolve or bf_catalogue, e.g. "runway"; the quote url is accepted too. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| task | No | |
| nodes | No | |
| handle | No | |
| cite_as | No | |
| price_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the read-only annotations: one settlement at a flat $0.05 per bundle, USDC on Base over x402, the quote URL is the same resource over HTTP, and the return is ordered with central versus supporting node detail. These are concrete operational traits an agent needs before invoking a paid read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the return shape in the first sentence, then pricing and prerequisites, then exclusions. Every sentence carries distinct operational information; nothing is filler given the paid, gated nature of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema, the description covers what is returned at a high level, the payment and quote prerequisite, the bundle/band inputs, and the sibling alternative for browsing or narrow reads. An agent has enough context to decide whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already defines both parameters. The description still adds useful context: where to get the bundle id, that the quote URL is accepted, and that band adds the scale band for the business's revenue. It does not add format examples beyond the schema, so it is strong but not fully additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns the ordered nodes of one bundle, with central node full and supporting nodes terse. It also distinguishes the output shape (citations and cite-as lines per node) and scope (one quoted bundle), so an agent can tell exactly what this does versus bf_read_node or bf_resolve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to pass the bundle id from bf_resolve or bf_catalogue and to call only after bf_resolve has quoted the bundle and the user accepts the price. It names the exclusion too: do not call it to browse, and use bf_read_node for narrow questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one node with its citations and a cite-as line; variant chooses full (the default), terse (the lede alone) or agent (the same text as fields: scope, inputs, rule, action, check, units, example, the applied route, the recheck, and two strings to paste: recheck_note and closing_citation) at the same price. Free nodes (marked in bf_catalogue) cost nothing; the rest cost their catalogue price ($0.02 to $0.05, USDC on Base over x402), charged once per call, only when the node is returned. Call it with a path from bf_catalogue when the question needs that node's rule; prefer variant agent when you will answer from it (the decision in one sentence, the first step, the reason, the next check, the offer to write the recheck into the user's notes, then closing_citation last). Read the free parent first; use bf_resolve when the question takes several nodes. Do not call a paid path to see what it contains: the catalogue line says what it covers; a rule on numbers is bf_apply_decision.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Node path from bf_catalogue, e.g. "risk" (free) or "risk/decide/hurdle" (paid). A full handle is accepted. | |
| variant | No | full (default): lede, conditions and reasoning; terse: the lede alone; agent: the same text as fields (scope, inputs, rule, action, check, reasoning, units, example, apply, recheck, recheck_note, closing_citation). The same price for all three. |
| Name | Required | Description |
|---|---|---|
| url | No | |
| kind | No | |
| rule | No | |
| text | No | |
| apply | No | |
| check | No | |
| cites | No | |
| scope | No | |
| title | No | |
| units | No | |
| action | No | |
| handle | Yes | |
| inputs | No | |
| levels | No | |
| tokens | No | |
| cite_as | No | |
| example | No | |
| recheck | No | |
| related | No | |
| variant | No | |
| leads_to | No | |
| versions | No | |
| citations | No | |
| reasoning | No | |
| free_first | No | |
| recheck_note | No | |
| closing_citation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the read-only safety profile, and the description adds genuinely new behavioral context: free vs paid nodes, the $0.02–$0.05 USDC/x402 pricing charged once per call and only when the node is returned, and a strong nudge (prefer agent variant when answering from it, closing_citation last). None of this is in the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the variant behavior are front-loaded and every clause carries information (pricing, routing, variant choice). It is, however, a dense run-on paragraph of semicolon-clause chains that takes effort to parse; a little structural separation would help.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, yet the description still covers variant shapes, pricing conditions, and the cite-as behavior. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents both parameters, so baseline is 3. The description adds meaning: what each variant actually contains relative to the others and the fact that all three cost the same, which is decision-relevant beyond the enum description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (returns one node with citations and cite-as line) and immediately names the sibling it is not: bf_resolve for multi-node questions and bf_apply_decision for number rules. An agent can pick this tool over its siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use (call with a path from bf_catalogue when the question needs that node's rule), when-not (do not call a paid path to see what it contains; a rule on numbers is bf_apply_decision), and alternatives (bf_resolve, read the free parent first). This is textbook routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quotes the minimal set of nodes that answers a broad task — a decision bundle, a market (chain) bundle or a cross bundle — with its price — one flat price, USD 0.05, with or without its scale band — stated before anything is paid. Deterministic and free: a named bundle or decision wins, then the input fields sent, then the authored patterns of the question; on ambiguity it returns candidates with their task lines, and with no match the task lines to choose from. Call it when the user's question takes more than one node (a whole decision with its context, a supply chain read, a shock traced to a seat), passing the question, revenue_usd and chain_position when known; then buy the quote with bf_read_bundle or read nodes one at a time with bf_read_node. Do not use it for a single term or a single rule, which bf_catalogue and bf_read_node answer more cheaply, and do not treat a quote as an answer: it names the nodes and the price, nothing more.
| Name | Required | Description | Default |
|---|---|---|---|
| bundle | No | A bundle id from a task line, when the caller already knows which. | |
| inputs | No | The figures already in hand, by field name; the resolver reads the names, not the values. | |
| decision | No | A decision path when the task is one decision, e.g. "cash-flow/decide/runway". | |
| question | No | The task in the user's words (up to 2,000 characters). | |
| revenue_usd | No | Annual revenue in US dollars, to pick the scale band. | |
| chain_position | No | Where the business sits on the chain being read: binding_upstream, binding_downstream, at_binding or unknown. |
| Name | Required | Description |
|---|---|---|
| by | No | |
| how | No | |
| match | No | |
| tasks | No | |
| access | No | |
| bundle | No | |
| candidates | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses the pricing behavior, that the quote is free and deterministic, the resolution precedence, ambiguity handling, and no-match behavior. It also clarifies that a quote names nodes and price but is not itself an answer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded and every sentence carries operational value: purpose, behavior, invocation conditions, alternatives, and what a quote is not. There is no filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations, a full input schema, and an output schema already present, the description completes the picture by explaining routing, pricing, determinism, ambiguity handling, and follow-up tools. An agent has enough information to decide when and how to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already documents all six parameters, the description adds meaningful resolution semantics: a named bundle or decision wins, then the input fields sent, then the authored patterns of the question. It also tells the caller to pass question, revenue_usd, and chain_position when known.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: it quotes the minimal set of nodes for a broad task, covering decision, market/chain, and cross bundles. It also distinguishes this tool from bf_catalogue and bf_read_node by naming what those are better for, so an agent can route between them without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to call it: when the user's question takes more than one node. It also states the alternatives and exclusions: use bf_catalogue or bf_read_node for a single term or rule, and use bf_read_bundle or bf_read_node after receiving the quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
bf_catalogue1 field changedInput schema / properties / branch / descriptionPrevious value: -"One of: equation, value, cash-flow, risk, growth, decision, market, ethics. Omit for the whole catalogue."New value: +"One of: equation, value, cash-flow, risk, growth, decision, market, ethics, worker, quality. Omit for the whole catalogue."bf_catalogue1 field changedInput schema / properties / branch / descriptionPrevious value: -"One of: equation, value, cash-flow, risk, growth, decision, market. Omit for the whole catalogue."New value: +"One of: equation, value, cash-flow, risk, growth, decision, market, ethics. Omit for the whole catalogue."bf_apply_decision1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "description": "The rule run on the figures sent: applied.figures (the computed numbers, named), applied.verdict (one sentence), applied.action (in order), applied.check (when to re-examine), applied.basis (how it was computed); then the node text with its citations and the cite_as line. Report applied.verdict and applied.figures; do not recompute them.",
+ "properties": {
+ "applied": {
+ "additionalProperties": {},
+ "properties": {
+ "action": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "basis": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "check": {
+ "type": "string"
+ },
+ "figures": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "verdict": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "cite_as": {
+ "type": "string"
+ },
+ "handle": {
+ "type": "string"
+ },
+ "node": {
+ "additionalProperties": {},
+ "properties": {
+ "cites": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "handle"
+ ],
+ "type": "object"
+}bf_catalogue1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "description": "The catalogue: every node as a row (path, handle, title, layer, tokens, free, price_usd; decision and apply_price_usd on the fifteen decisions), the payment line, the access sentence and the cite_as pattern; the bundles section when no branch is named.",
+ "properties": {
+ "access": {
+ "type": "string"
+ },
+ "bundles": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "cite_as": {
+ "type": "string"
+ },
+ "license_url": {
+ "type": "string"
+ },
+ "nodes": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "apply_price_usd": {
+ "type": [
+ "string",
+ "number",
+ "null"
+ ]
+ },
+ "decision": {
+ "type": "boolean"
+ },
+ "description": {
+ "type": "string"
+ },
+ "free": {
+ "type": "boolean"
+ },
+ "handle": {
+ "type": "string"
+ },
+ "layer": {
+ "type": "number"
+ },
+ "path": {
+ "type": "string"
+ },
+ "price_usd": {
+ "type": [
+ "string",
+ "number",
+ "null"
+ ]
+ },
+ "title": {
+ "type": "string"
+ },
+ "tokens": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "handle"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "payment": {
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}bf_decision_schema2 fields changedInput schema / properties / decision / descriptionPrevious value: -"Decision path, e.g. \"risk/decide/hurdle\". Omit to list the ten."New value: +"Decision path, e.g. \"risk/decide/hurdle\". Omit to list the fifteen."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "description": "Without `decision`: the list of applied decisions with prices. With one: its input_schema (JSON schema), example_input, price_usd, how, and fit (what the framework does for this decision by model, before paying).",
+ "properties": {
+ "decision": {
+ "type": "string"
+ },
+ "decisions": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "decision": {
+ "type": "string"
+ },
+ "handle": {
+ "type": "string"
+ },
+ "price_usd": {
+ "type": [
+ "string",
+ "number",
+ "null"
+ ]
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "example_input": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "fit": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "handle": {
+ "type": "string"
+ },
+ "how": {
+ "type": "string"
+ },
+ "input_schema": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "price_usd": {
+ "type": [
+ "string",
+ "number",
+ "null"
+ ]
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}bf_read_bundle1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "description": "The bundle's nodes in order — the central node full, the rest terse — each with its text, variant, role and cite_as; one settlement at the quoted flat price.",
+ "properties": {
+ "cite_as": {
+ "type": "string"
+ },
+ "handle": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "nodes": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "cite_as": {
+ "type": "string"
+ },
+ "handle": {
+ "type": "string"
+ },
+ "role": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "variant": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "price_usd": {
+ "type": [
+ "string",
+ "number",
+ "null"
+ ]
+ },
+ "task": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}bf_read_node3 fields changedInput schema / properties / variant / descriptionPrevious value: -"full (default): lede, conditions and reasoning; terse: the lede alone. The same price either way."New value: +"full (default): lede, conditions and reasoning; terse: the lede alone; agent: the same text as fields (scope, inputs, rule, action, check, reasoning, units, example, apply, recheck, recheck_note, closing_citation). The same price for all three."Input schema / properties / variant / enumPrevious value: -[
- "full",
- "terse"
-]New value: +[
+ "full",
+ "terse",
+ "agent"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "description": "One node. full/terse: text (and levels), cites, related, cite_as. agent: the accepted text as fields — scope.applies_if / scope.not_for, inputs, rule, action, check, reasoning, units (every input's unit, bounds and default), example (the published example input run through the rule), citations, leads_to, apply (the applied route), free_first, recheck (cadence, trigger, handle, the exact re-run call), and two strings to paste unchanged: recheck_note and closing_citation.",
+ "properties": {
+ "action": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "apply": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "method": {
+ "type": "string"
+ },
+ "schema_url": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "check": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "citations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "cite_as": {
+ "type": "string"
+ },
+ "cites": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "closing_citation": {
+ "type": "string"
+ },
+ "example": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "action": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "basis": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "check": {
+ "type": "string"
+ },
+ "error": {
+ "type": "string"
+ },
+ "figures": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "input": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "source": {
+ "type": "string"
+ },
+ "verdict": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "free_first": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "handle": {
+ "type": "string"
+ },
+ "inputs": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "kind": {
+ "type": "string"
+ },
+ "leads_to": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "levels": {
+ "additionalProperties": {},
+ "properties": {
+ "conditions": {
+ "type": "string"
+ },
+ "lede": {
+ "type": "string"
+ },
+ "reasoning": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "lede"
+ ],
+ "type": "object"
+ },
+ "reasoning": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "recheck": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "cadence": {
+ "anyOf": [
+ {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ ]
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "handle": {
+ "type": "string"
+ },
+ "rerun": {
+ "additionalProperties": {},
+ "properties": {
+ "body": {},
+ "method": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "trigger": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "recheck_note": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "related": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "rule": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "scope": {
+ "additionalProperties": false,
+ "properties": {
+ "applies_if": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "not_for": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "applies_if",
+ "not_for"
+ ],
+ "type": "object"
+ },
+ "text": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "tokens": {
+ "type": "number"
+ },
+ "units": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "fields": {
+ "additionalProperties": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "note": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "required": {
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "variant": {
+ "enum": [
+ "full",
+ "terse",
+ "agent"
+ ],
+ "type": "string"
+ },
+ "versions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "handle"
+ ],
+ "type": "object"
+}bf_resolve1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "description": "A quote: match (single, candidates, none, out_of_scope), by (what decided it), bundle {id, task, nodes, price_usd — a flat USD 0.05 — tokens, url, band} or candidates/tasks to choose from; the access sentence.",
+ "properties": {
+ "access": {
+ "type": "string"
+ },
+ "bundle": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "by": {
+ "type": "string"
+ },
+ "candidates": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "how": {
+ "type": "string"
+ },
+ "match": {
+ "type": "string"
+ },
+ "tasks": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}bf_apply_decisionbf_cataloguebf_decision_schemabf_read_bundlebf_read_nodebf_resolveAI-operated. Free previews: licences, page reads, endpoint checks. Paid full versions over x402.
Evidence-weighted decision engines: AI business cases, venture readiness, free soundchecks.
Advisory context, intent, budget and API-ledger checks with free examples and x402 payments.
AI-operated. Free tier only in this listing; no paid plans are being sold right now.
Add one secure layer between your agents and this server.