BusCalc — Business & Trade Calculations

Algebra and matrix calculations

buscalc_linear_algebra

Read-onlyIdempotent

Solve numerical quadratic/linear equations, solve a small linear system, multiply or transpose matrices, or compute a determinant/inverse. Structured JSON matrices up to 8×8; singular or unreliable solves are rejected. No arbitrary code, symbolic algebra or unbounded optimization. Put tool fields inside inputs. Supply units or modelVersion only when listed in inputSchema. Follow its required fields and exact choices. Do not pass the REST calculator field inside MCP arguments.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "inputs": {
        "mode": "matrix",
        "matrix": [
          [
            1,
            2
          ],
          [
            3,
            4
          ]
        ],
        "operation": "determinant"
      }
    },
    "name": "buscalc_linear_algebra"
  }
}

Input Schema

Name	Required	Description	Default
`units`	No
`inputs`	Yes
`modelVersion`	No

Output Schema

Name	Required	Description	Default
`units`	No
`inputs`	Yes
`receipt`	Yes
`results`	Yes
`sourceURL`	Yes
`calculator`	Yes
`modelVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 4, 2026

addedInput schema / examples

Added value: +[
+  {
+    "inputs": {
+      "matrix": [
+        [
+          1,
+          2
+        ],
+        [
+          3,
+          4
+        ]
+      ],
+      "mode": "matrix",
+      "operation": "determinant"
+    }
+  }
+]

AddedNov 4, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already carry the safety profile (readOnly, idempotent, non-destructive, closed world), so the description earns credit for adding behavior beyond them: a hard 8×8 matrix ceiling and the fact that singular or unreliable solves are rejected rather than returned. That failure behavior is exactly what an agent needs to anticipate errors. Remaining gap is the response format, which the output schema covers.

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?

Capability statement is front-loaded and the whole description is four tight sentences with no filler. The trailing invocation notes ("Put tool fields inside inputs", REST-field warning) are terse to the point of being slightly cryptic, but nothing is wasted.

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 a rich nested oneOf schema and an output schema, the description supplies what structured fields cannot: the supported operation set, size limits, and rejection semantics for degenerate input. Nothing essential to calling it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Top-level schema coverage is 0%, so the description must compensate and it partly does: it names the supported operations, states the 8×8 cap, and tells the agent to nest tool fields inside `inputs` and to supply `units`/`modelVersion` only when the schema lists them. It does not explain the `mode` discriminator values or the oneOf structure, which are the hardest part of this nested schema, so compensation is incomplete.

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 first sentence names concrete verbs and resources: quadratic/linear equation solving, small linear systems, matrix multiplication/transposition, determinant and inverse. This is specific enough to separate it from the numeric-finance siblings such as buscalc_financial_mathematics or buscalc_statistics 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description sets negative boundaries ("No arbitrary code, symbolic algebra or unbounded optimization"), which is genuinely useful exclusions guidance. However, it never names a sibling alternative or states the condition under which an agent should prefer one of them, so routing is only implied by the operation list.

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

All BusCalc — Business & Trade Calculations tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?