Business Frameworks

Business Frameworks: decision input schema

bf_decision_schema

Read-onlyIdempotent

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.

Input Schema

Name	Required	Description	Default
`decision`	No	Decision path, e.g. "risk/decide/hurdle". Omit to list the fifteen.

Output Schema

Name	Required	Description	Default
`fit`	No
`how`	No
`title`	No
`handle`	No
`summary`	No
`decision`	No
`decisions`	No
`price_usd`	No
`input_schema`	No
`example_input`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 22, 2026

changedInput schema / properties / decision / description

Previous 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."

changedOutput 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"
+}

First observedOct 12, 2026

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Business Frameworks tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.