Skip to main content
Glama

Business Frameworks: apply a decision rule

bf_apply_decision
Read-only

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.

Input Schema

NameRequiredDescriptionDefault
inputYesThe figures, shaped as that decision's input_schema.
decisionYesDecision path from bf_decision_schema, e.g. "cash-flow/decide/runway".

Output Schema

NameRequiredDescriptionDefault
nodeNo
handleYes
appliedNo
cite_asNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

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

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.