How do I use DecisionMatrix MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DecisionMatrix MCP Rank these job candidates by salary, experience, and interview score, with weights 1, 2, 1." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

DecisionMatrix MCP

by inity13

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

DecisionMatrix MCP

A transparent, 100% deterministic Model Context Protocol (MCP) server that gives LLM agents a reliable multi-criteria decision analysis (MCDA) engine.

Agents are great at gathering options but unreliable at weighing them: they lose precision, apply inconsistent weights, and can't show their work. DecisionMatrix offloads the scoring to an exact, explainable engine. You provide options and weighted criteria (plus a score matrix); it returns a fully scored, ranked, and explained result — with per-criterion breakdowns, the methodology used, the weights applied, and a plain-language explanation.

Every number flows through decimal.js at 40-digit precision (never floats), so identical inputs always produce byte-identical output. The server is stateless — no database, no sessions.

🌐 Live hosted server (free, no install)

A public remote MCP server runs on Cloudflare's edge — point any Streamable-HTTP MCP client at it:

https://decisionmatrix-mcp.pages.dev/mcp

{ "mcpServers": { "decisionmatrix": {
    "type": "http", "url": "https://decisionmatrix-mcp.pages.dev/mcp" } } }

It runs in open mode on the free tier (no key, 15 calls/day per IP). Paid plans (Starter $12/mo · 5,000/day, Pro $39/mo · 50,000/day) are live via Stripe Checkout — buy a plan, get an API key instantly, and send it as X-API-Key. Self-host for unlimited calls with no keys. Landing page + pricing: https://decisionmatrix-mcp.pages.dev.

Related MCP server: Cruxible Core

What it does

Six tools, all returning a uniform, agent-parseable envelope:

Tool	Purpose
`create_decision`	Main tool. Rank options against weighted criteria → winner, full ranking, per-criterion breakdowns, methodology, weights, and a plain-language explanation.
`score_options`	Return the full normalized scored matrix when scores are supplied separately.
`sensitivity_analysis`	Sweep each criterion's weight ±X% and report how robust the winner is (and where it flips).
`compare_two`	Head-to-head comparison of exactly two options with per-criterion win counts.
`list_methods`	Discovery: available scoring methods and when to use each.
`health_check`	Version, status, and capabilities.

Scoring methods

method	model	normalization	notes
`weighted_sum` (default)	Simple Additive Weighting (SAW)	min-max per criterion	Most transparent; additive contributions. Handles negatives.
`weighted_product`	Weighted Product Model (WPM)	ratio (x/max, min/x)	Punishes any single weak criterion; requires scores > 0.
`topsis`	Closeness to ideal solution	vector (Euclidean)	0–1 closeness coefficient; robust with many criteria.

Each criterion has a direction: benefit (higher is better — quality, speed) or cost (lower is better — price, latency, risk). Weights are relative; they are normalized to sum to 1 internally.

Consistent response envelope

Every successful response contains: status, method, winner, ranking (with per-criterion breakdown), methodology, weights_used, inputs_used, notes, and a natural-language explanation.

{
  "status": "success",
  "method": "weighted_sum",
  "winner": { "option": "Gamma", "score": 0.666667, "score_exact": "0.666667", "rank": 1, "tie": false, "tied_with": [] },
  "ranking": [
    { "rank": 1, "option": "Gamma", "score": 0.666667, "score_exact": "0.666667",
      "breakdown": [
        { "criterion": "Price", "direction": "cost", "weight": 0.5, "weight_raw": "3",
          "raw_score": "900", "normalized_score": 1, "weighted_contribution": 0.5 }
      ] }
  ],
  "methodology": {
    "method": "weighted_sum",
    "name": "Weighted Sum Model (Simple Additive Weighting)",
    "normalization": "min-max per criterion (best value -> 1, worst -> 0)",
    "score_range": "0 to 1 (higher is better)",
    "weighting": "Criteria weights are normalized to sum to 1; only their relative sizes matter.",
    "deterministic": true
  },
  "weights_used": [ { "criterion": "Price", "direction": "cost", "weight_input": "3", "weight_normalized": 0.5 } ],
  "inputs_used": { "options": ["Alpha","Beta","Gamma"], "method": "weighted_sum", "option_count": 3, "criterion_count": 3 },
  "notes": [ "Scores are normalized within this option set; they express relative standing, not an absolute grade." ],
  "explanation": "Using the Weighted Sum Model, 'Gamma' ranks #1 with a score of 0.666667, ahead of 'Alpha' (0.527778) by 26.32% ..."
}

Errors never cross the tool boundary as exceptions — they come back as a structured, actionable envelope:

{
  "status": "error",
  "error": {
    "type": "incomplete_scores",
    "message": "Missing 1 score(s) in the options x criteria matrix.",
    "hint": "Provide a score for every option and criterion. Missing: Beta / Weight."
  }
}

Design note — exact numbers: score is a deterministically-rounded number (6 dp) for easy consumption; score_exact / raw_score are full-precision strings so no precision is lost in JSON. Rankings are computed on the exact values, with input order as a stable tie-break.

Project structure

decisionmatrix-mcp/
├── worker-src/
│   ├── index.mjs        # Cloudflare Pages Function (_worker.js): MCP over Streamable HTTP + billing routes
│   ├── engine.mjs       # The deterministic MCDA engine: 3 methods + 6 tools + validation
│   └── billing.mjs      # Stripe Checkout + KV-backed API keys, quota metering, webhook
├── site/
│   ├── index.html       # Static landing / pricing / docs page
│   └── _worker.js        # Built bundle (esbuild output; git-ignored)
├── tests/
│   └── engine.test.mjs  # 21 core scoring-logic tests (node --test)
├── examples/
│   └── agent_example.mjs # End-to-end MCP client demo over HTTP
├── package.json         # build / deploy / dev / test scripts
├── wrangler.toml        # Cloudflare Pages config
├── .env.example         # Optional auth/rate-limit env reference
├── LICENSE              # MIT
└── README.md

Separation of concerns: engine.mjs is pure and transport-agnostic (import it directly in tests or any Node/Deno/edge runtime); index.mjs only handles the MCP JSON-RPC wiring, HTTP, CORS, and the auth/metering seam.

Requirements

Node 18+ (for the build, tests, and local dev). Only two dev/runtime deps: decimal.js (math) and esbuild (bundler).
A Cloudflare account (free tier is fine) to deploy the hosted version.

Run it locally

git clone <your-fork> decisionmatrix-mcp && cd decisionmatrix-mcp
npm install

# Run the test suite (no server needed)
npm test

# Serve the MCP endpoint locally via Wrangler (builds + runs Pages dev)
npm run dev          # -> http://127.0.0.1:8788/mcp

# Try the end-to-end client demo (hosted by default, or pass a local URL)
node examples/agent_example.mjs
node examples/agent_example.mjs http://127.0.0.1:8788

Quick manual call:

curl -s http://127.0.0.1:8788/mcp \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
        "name":"list_methods","arguments":{}}}'

Install via npm (stdio, no hosting)

Run the server locally over stdio with a single command — nothing to deploy:

npx -y decisionmatrix-mcp

Claude Desktop / any stdio MCP client (claude_desktop_config.json):

{ "mcpServers": { "decisionmatrix": { "command": "npx", "args": ["-y", "decisionmatrix-mcp"] } } }

This is the same deterministic engine as the hosted server, running on your machine.

Client configuration

Cursor — `~/.cursor/mcp.json`

{ "mcpServers": { "decisionmatrix": {
    "url": "https://decisionmatrix-mcp.pages.dev/mcp" } } }

Claude Desktop — `claude_desktop_config.json`

Claude Desktop launches stdio servers, so bridge to the HTTP endpoint with mcp-remote:

{ "mcpServers": { "decisionmatrix": {
    "command": "npx", "args": ["-y", "mcp-remote", "https://decisionmatrix-mcp.pages.dev/mcp"] } } }

VS Code — `.vscode/mcp.json`

{ "servers": { "decisionmatrix": {
    "type": "http", "url": "https://decisionmatrix-mcp.pages.dev/mcp" } } }

Any Streamable-HTTP MCP client

Point it at https://decisionmatrix-mcp.pages.dev/mcp (or your self-hosted URL). If you enable auth, add X-API-Key (or Authorization: Bearer <key>) in the client's headers.

Tools & parameters

`create_decision(options, criteria, scores, method="weighted_sum")`

options — array of names (["Vendor A","Vendor B"]) or objects ([{"name":"Vendor A","scores":{...}}]). Minimum 2, names unique.
criteria — array of { "name", "weight" (>=0), "direction": "benefit"|"cost" }. At least one weight must be > 0.
scores — the option×criterion matrix. Accepted shapes:
- object map: { "Vendor A": { "Price": 100, "Quality": 8 }, ... }
- array: [ { "option": "Vendor A", "scores": { ... } }, ... ]
- inline on each option object.
method — weighted_sum (default) · weighted_product · topsis (aliases like saw, wpm, ideal also resolve).

`score_options(options, criteria, scores, method)`

Same inputs as create_decision; returns the full scored matrix (per-option, per-criterion normalized scores + totals) without the winner narrative.

`sensitivity_analysis(options, criteria, scores, method, variation=0.2, steps=10)`

Sweeps each criterion's weight from -variation to +variation (fractional, e.g. 0.2 = ±20%) in steps increments (2–100), renormalizing the others, and recomputes the winner each time. Returns a robustness_score (share of scenarios the baseline winner stays #1), the fragile_criteria, and per-criterion flip points.

`compare_two(option_a, option_b, criteria, scores, method)`

Head-to-head between exactly two options (pass option_a/option_b names, or a 2-element options array). Returns the winner, score margin, criteria_wins, and a per_criterion breakdown showing which option each criterion favours.

`list_methods()` / `health_check()`

Discovery + status. No parameters.

Example tool-call payloads

Choose a laptop (price & weight are cost criteria):

{ "name": "create_decision", "arguments": {
  "options": ["Alpha", "Beta", "Gamma"],
  "criteria": [
    { "name": "Price",   "weight": 3, "direction": "cost" },
    { "name": "Battery", "weight": 2, "direction": "benefit" },
    { "name": "Weight",  "weight": 1, "direction": "cost" }
  ],
  "scores": {
    "Alpha": { "Price": 1000, "Battery": 8,  "Weight": 1.5 },
    "Beta":  { "Price": 1200, "Battery": 12, "Weight": 1.8 },
    "Gamma": { "Price": 900,  "Battery": 6,  "Weight": 1.2 }
  }
} }

Test how robust the winner is:

{ "name": "sensitivity_analysis", "arguments": {
  "options": ["Alpha", "Beta", "Gamma"],
  "criteria": [
    { "name": "Price", "weight": 3, "direction": "cost" },
    { "name": "Battery", "weight": 2 }
  ],
  "scores": { "Alpha": {"Price":1000,"Battery":8}, "Beta": {"Price":1200,"Battery":12}, "Gamma": {"Price":900,"Battery":6} },
  "variation": 0.3, "steps": 8
} }

Head-to-head:

{ "name": "compare_two", "arguments": {
  "option_a": "Alpha", "option_b": "Beta",
  "criteria": [ { "name": "Price", "weight": 3, "direction": "cost" }, { "name": "Battery", "weight": 2 } ],
  "scores": { "Alpha": {"Price":1000,"Battery":8}, "Beta": {"Price":1200,"Battery":12} }
} }

Deploy on Cloudflare Pages

Same pattern as PrecisionCalc — one build step bundles worker-src/ into site/_worker.js (Pages "advanced mode" Function), then Wrangler deploys the site/ directory.

npm install
npx wrangler login          # once

# Build + deploy in one shot
npm run deploy              # esbuild -> site/_worker.js, then wrangler pages deploy

Or wire it to Git: create a Pages project, set the build command to npm run build and the output directory to site. Every push deploys automatically. The compatibility_date and project name live in wrangler.toml.

To run fully free / private, you need no bindings, secrets, or env vars — the scoring engine is stateless and the server fails open (free tier, quota disabled).

Enabling billing (already live on the hosted server)

The hosted server uses these — replicate them for your own paid deployment:

KV namespace for API keys + daily usage counters, bound as DECISIONMATRIX_KV in wrangler.toml.
Stripe products/prices (subscription) — put the price IDs in [vars] (PRICE_STARTER, PRICE_PRO) and the daily limits (FREE_DAILY, STARTER_DAILY, PRO_DAILY).

Stripe secrets (never in the repo):

wrangler pages secret put STRIPE_SECRET_KEY     --project-name decisionmatrix-mcp
wrangler pages secret put STRIPE_WEBHOOK_SECRET  --project-name decisionmatrix-mcp

Webhook → create a Stripe webhook endpoint at https://<your-domain>/webhook for customer.subscription.updated + customer.subscription.deleted.

Routes wired up: /checkout?plan=starter|pro → Stripe Checkout, /success provisions and shows the API key (idempotent), /portal opens the Stripe billing portal, /webhook handles subscription lifecycle (revoke/restore), /metrics reports usage.

Auth & rate limiting

The hosted server enforces tiered quotas in worker-src/billing.mjs:

Identity — identify() reads X-API-Key / Authorization: Bearer, looks the key up in KV, and falls back to per-IP free tier.
Quota — consumeQuota() is a KV daily counter (resets 00:00 UTC); the single gating point in handleRpc where method === "tools/call".
Paywall response — over-quota / invalid / revoked keys get a structured upsell envelope with pricing + checkout URLs (agents can read and act on it).
Usage metering — in-memory counters at /metrics.

DecisionMatrix has no paid-only tools — every tool works on every tier; paid plans only raise the daily quota. To make a tool paid-only, add its name to PAID_ONLY_TOOLS in index.mjs. Because the engine is pure and stateless, none of this touches the scoring logic.

Design decisions & assumptions

Deterministic by construction. 40-digit decimal math, ROUND_HALF_UP everywhere, and stable input-order tie-breaking. No floats, no randomness, no clocks in the result.
Normalization is per-criterion and direction-aware. weighted_sum uses min-max (best→1, worst→0); if a criterion is identical across all options it's treated as neutral (normalized to 1) and noted. weighted_product uses ratio normalization and requires strictly positive scores (clear error otherwise). topsis uses vector normalization and ranks by closeness to the ideal/anti-ideal.
Weights are relative — normalized to sum to 1, so [3,2,1] and [30,20,10] give identical results.
Scores are relative to the option set — they measure standing within the provided alternatives, not an absolute grade. This is stated in notes.
Errors are data, not exceptions — every tool returns status:"error" with a machine type and an actionable hint. Validation covers duplicate names, missing cells (listing exactly which), non-numeric scores, bad weights/directions, and unknown methods.
Stateless & side-effect-free — trivially cacheable, horizontally scalable, and safe to run anywhere (Cloudflare, Node, Deno, Bun).

Testing

npm test          # node --test tests/*.test.mjs  (21 tests, no network)

The suite pins the hand-verifiable weighted_sum arithmetic, checks determinism, weight-relativity, direction handling, ties, all three methods, compare_two, sensitivity_analysis, the multiple score-input shapes, and every error path.

Roadmap (post-MVP)

More methods: AHP (pairwise weight elicitation), ELECTRE, PROMETHEE, Borda count.
Group decisions: aggregate multiple stakeholders' weight/score sets.
Monte-Carlo sensitivity (perturb all weights jointly) alongside one-at-a-time.
Per-key usage dashboard + Redis/Durable-Object quotas for stronger consistency.
Published npm package + a hosted multi-tenant tier.

License

MIT — see LICENSE.

Available Tools

6 tools

compare_twoAInspect

Head-to-head comparison of exactly two options. Returns the winner, score margin, how many criteria each option wins, and a per-criterion breakdown. Pass option_a/option_b (names) or a 2-element options array, plus criteria and scores.

ParametersJSON Schema

Name	Required	Description	Default
`method`	No		weighted_sum
`scores`	Yes	Score matrix. {"Option A": {"Criterion 1": 8, ...}, ...} or array form or inline on options.
`options`	No	Named alternatives. Strings or {name, scores} objects.
`criteria`	Yes	Weighted criteria. Each: {name, weight (relative, >=0), direction: 'benefit' (higher better, default) \| 'cost' (lower better)}.
`option_a`	No
`option_b`	No

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral burden. It discloses the exact outputs (winner, score margin, criteria wins, breakdown) and input flexibility. It does not mention error handling or tie-breaking behavior, but for a pure computation tool, the disclosure is solid and non-misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose, and every clause adds useful information (outputs, input forms). No filler or redundant details.

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?

The tool has 6 parameters, nested objects, and multiple input formats, and no output schema. The description covers the essential usage (how to pass options, what is returned) and the schema documents criteria/scores. It is complete enough for an agent to invoke correctly, though it omits guidance on method selection or behavior for invalid input, which the schema partially addresses via defaults and enums.

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?

Schema description coverage is 50%, with criteria and options already well-documented. The description adds value by explaining the two ways to pass options (option_a/option_b vs 2-element options array), which is not obvious from the schema alone. However, it does little to elaborate on scores or criteria structure beyond what the schema provides, so it only partially compensates for coverage gaps.

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 description opens with 'Head-to-head comparison of exactly two options', which is a specific verb ('comparison') and resource ('two options'), and details the return values (winner, score margin, criteria wins, per-criterion breakdown). This clearly distinguishes it from sibling tools like score_options or sensitivity_analysis.

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 phrase 'exactly two options' sets a clear constraint on usage, and the description clarifies the two acceptable input formats (option_a/option_b or 2-element options array). However, it does not explicitly mention when to use alternative tools like score_options for more than two alternatives, so it stops short of full exclusion guidance.

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

create_decisionAInspect

Rank named options against weighted criteria and return the winner, full ranking, per-criterion breakdowns, methodology, weights used, and a plain-language explanation. Main tool. method defaults to weighted_sum (also weighted_product, topsis). 100% deterministic.

ParametersJSON Schema

Name	Required	Description	Default
`method`	No		weighted_sum
`scores`	Yes	Score matrix. {"Option A": {"Criterion 1": 8, ...}, ...} or array form or inline on options.
`options`	Yes	Named alternatives. Strings or {name, scores} objects.
`criteria`	Yes	Weighted criteria. Each: {name, weight (relative, >=0), direction: 'benefit' (higher better, default) \| 'cost' (lower better)}.

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is 100% deterministic and states the default method (weighted_sum) plus alternatives, which are key behavioral traits. However, it does not discuss error handling, input validation, or side effects, though for a pure calculation tool these are less critical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the primary purpose and outputs. Every sentence contributes: the first details functionality, the second signals priority, and the third notes determinism and default method. No unnecessary words.

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?

For a tool with no output schema, the description adequately covers return values (winner, ranking, breakdowns, explanation) and notes determinism. It does not describe input formatting beyond what the schema provides, but given a rich schema, this is acceptable. Slight gaps remain regarding edge cases or exact response structure.

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?

Schema coverage is 75%, with method lacking a description in the schema. The description adds 'method defaults to weighted_sum (also weighted_product, topsis)', but the schema already includes the enum and default for method, so the added value is minimal. Other parameters are already described well in the schema.

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 description clearly states it ranks named options against weighted criteria and specifies the outputs: winner, full ranking, per-criterion breakdowns, methodology, and explanation. Phrases like 'Main tool' and enumerating return values distinguish it from sibling tools such as score_options and sensitivity_analysis.

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 provides clear context: this is the main tool for ranking options with weighted criteria. It implies use this as the primary decision tool, but it does not explicitly mention alternatives or when not to use it. The 'Main tool' label gives some prioritization, though no explicit exclusions or comparisons to siblings are made.

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

health_checkBInspect

Server health, version, and capabilities.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It mentions that it returns health, version, and capabilities, but does not state whether it is read-only, safe, or has any side effects. This is a significant gap for a tool with zero annotation coverage.

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 extremely concise, using only a few words to convey the core purpose. It lacks verbosity, but it is structured as a noun phrase rather than a complete sentence, which slightly reduces clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (zero parameters, no output schema, no annotations), the description is minimally sufficient. It names the key outputs but leaves 'capabilities' undefined and does not explain any error behavior or return format, which could leave an agent uncertain about what to expect.

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 tool has zero parameters, so there is nothing to explain. The schema with empty properties is fully covered, and the baseline for 0 params is 4, which is appropriate here.

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 names the resource (server) and the specific aspects covered (health, version, capabilities), which is clear enough to distinguish from the sibling decision tools. However, it lacks a verb and reads as a noun phrase rather than a full statement of action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or context in which this tool is appropriate, leaving the agent to infer usage from the name alone.

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

list_methodsAInspect

List scoring methods (weighted_sum, weighted_product, topsis) with normalization details, score ranges, and when to use each.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden of explaining behavior. It discloses the content returned (normalization details, score ranges, and usage guidance), which sets expectations for a list operation. It does not mention potential side effects, but for a read-only listing tool this is not critical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the verb and resource, then succinctly enumerates the key detail categories. Every phrase contributes meaningful information with no waste.

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 simplicity (0 params, no output schema), the description fully covers the relevant context by naming the specific methods and the types of information returned (normalization details, score ranges, usage guidance), making the output predictable.

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 tool has zero parameters and the schema is empty, so the description need not explain any parameters. The baseline of 4 applies because there is no parameter information to add.

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 description uses a specific verb 'List' with the resource 'scoring methods' and enumerates the methods ('weighted_sum, weighted_product, topsis'), making the tool's function clear. It also distinguishes from siblings like 'score_options', which likely use these methods rather than list them.

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 states what the tool returns (normalization details, score ranges, and when to use each method), implying it is used to select/understand methods. However, it does not explicitly contrast this tool with siblings like 'score_options' or state when not to use it, so it lacks a clear exclusion.

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

score_optionsAInspect

Score options against criteria when the score matrix is supplied separately. Returns the full normalized scored matrix + ranking, without the narrative winner explanation.

ParametersJSON Schema

Name	Required	Description	Default
`method`	No		weighted_sum
`scores`	Yes	Score matrix. {"Option A": {"Criterion 1": 8, ...}, ...} or array form or inline on options.
`options`	Yes	Named alternatives. Strings or {name, scores} objects.
`criteria`	Yes	Weighted criteria. Each: {name, weight (relative, >=0), direction: 'benefit' (higher better, default) \| 'cost' (lower better)}.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the transparency burden. It discloses the output: 'full normalized scored matrix + ranking', and explicitly states what is not returned ('without the narrative winner explanation'). This adds meaningful behavioral context beyond input schema, though it doesn't mention normalization details or side effects (which are likely none for a scoring tool).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the action verb 'Score', and every word adds value. It states the purpose, a condition, and the output, with zero redundancy or unnecessary detail.

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?

Given the tool's complexity (nested objects, 4 params, no output schema), the description covers the essential purpose and return format (normalized matrix + ranking). It doesn't explain method-specific behavior or the ranking structure, but that is likely out of scope for a brief description. It is sufficiently complete for an AI to select and invoke correctly in most cases.

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?

Schema description coverage is 75%, so the schema already documents most parameters (options, criteria with direction and weight, scores matrix). The description adds a small but useful nuance: 'when the score matrix is supplied separately', clarifying the scores parameter's role. However, it doesn't elaborate on the method parameter or how criteria directions affect scoring, which the schema partially covers. This earns a solid baseline 3.

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 description clearly states the tool's function with a specific verb 'Score' and resource 'options against criteria'. It distinguishes itself from siblings by specifying the separate score matrix input and the exclusion of narrative explanation, making its scope unambiguous.

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 a clear condition for use: 'when the score matrix is supplied separately', which implies when to apply this tool. It also implicitly contrasts with a version that includes narrative winner explanation, but it doesn't explicitly name alternatives or exclusions. This is solid guidance but not exhaustive.

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

sensitivity_analysisAInspect

Test how robust the winner is to criteria-weight changes. Sweeps each weight +/- 'variation' (default 0.2) over 'steps' (default 10), recomputes the ranking, and reports a robustness score, the criteria most likely to flip the result, and flip points.

ParametersJSON Schema

Name	Required	Description	Default
`steps`	No
`method`	No		weighted_sum
`scores`	Yes	Score matrix. {"Option A": {"Criterion 1": 8, ...}, ...} or array form or inline on options.
`options`	Yes	Named alternatives. Strings or {name, scores} objects.
`criteria`	Yes	Weighted criteria. Each: {name, weight (relative, >=0), direction: 'benefit' (higher better, default) \| 'cost' (lower better)}.
`variation`	No

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the sweep mechanism, the recomputation of rankings, and the specific outputs (robustness score, critical criteria, flip points). It does not mention side effects or prerequisites explicitly, but the read-only analysis nature is implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences, front-loaded with the core purpose, and includes specific details about defaults and outputs without any redundancy. Every sentence contributes substantive information, making it highly concise and effective.

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?

The description provides a clear overview of the tool's function, process, and outputs, which is sufficient for an agent to understand its role. It lacks explicit mention of prerequisites (e.g., needing a prior decision with weights and scores) and does not specify how to interpret the robustness score, but the description covers the essential behavior.

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?

The description explicitly explains 'variation' and 'steps' with defaults, adding meaning beyond the schema. However, it does not mention the 'method' parameter or clarify how options/criteria/scores are used beyond what the schema already describes. With 50% schema coverage, the description only partially compensates for undocumented parameters.

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 description starts with a specific verb-resource pairing: 'Test how robust the winner is to criteria-weight changes.' This clearly distinguishes it from sibling tools like score_options or compare_two, which focus on scoring or pairwise comparison. The method details further reinforce its unique purpose.

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 clearly implies its use case: testing robustness after a winner has been determined. It provides clear context for when to invoke this tool but does not explicitly name alternatives or exclusions. Since siblings like compare_two and score_options exist, a direct alternative would improve it, but the purpose is self-explanatory.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv1.0.2Aug 12, 2026
- First observedcompare_two
- First observedcreate_decision
- First observedhealth_check
- First observedlist_methods
- First observedscore_options
- First observedsensitivity_analysis

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation4/5

Most tools are clearly distinct: create_decision is the main ranking tool, score_options is a stripped-down variant for when the score matrix is supplied separately, and sensitivity_analysis and compare_two serve specialized purposes. There is minor overlap between create_decision and score_options since both return rankings, but the descriptions help differentiate them.

Naming Consistency4/5

All tools use snake_case, and most follow a verb_noun pattern (create_decision, score_options, compare_two, list_methods). sensitivity_analysis and health_check are noun-style rather than verb_noun, but the naming is still predictable and consistent in style.

Tool Count5/5

With 6 tools, the server is well-scoped for a decision-analysis domain. Each tool serves a clear analytical or utility purpose, and there are no redundant or unnecessary additions.

Completeness5/5

The tool set covers the full decision-analysis workflow: creating decisions, scoring options, sensitivity testing, head-to-head comparison, method reference, and health checks. No obvious gaps exist for the stated purpose, as this appears to be a stateless analysis service rather than a persistent data store.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Related MCP Connectors

Meta Council A
com.meta-council
Multi-expert decision intelligence with transparent synthesis and auditable workflows.
Autonomous Agents Agent Orchestration
1502
Fify B
io.github.renfei-design
Turn grounded AI answers into trusted comparisons, plans, timelines, and decision views.
AI & Machine Learning Data Visualization
211
Quesen Deterministic Agent Decision Layer A
io.github.Shxnque
Deterministic decision layer for autonomous agents. Reproducible PROCEED, REVIEW, SKIP verdicts.
Autonomous Agents Finance
52
agentstack-mcp A
io.github.inity13
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Autonomous Agents Agent Orchestration
241

Related MCP Servers

Boundary MCP
Autonomous Agents Developer Tools
wh131462
A
license
A
quality
D
maintenance
A decision structure analysis engine that transforms emotional dilemmas into structured frameworks by identifying variables, constraints, and strategy paths. It helps users evaluate risk distributions and cognitive biases without offering subjective advice or definitive answers.
Updated 8 months ago (2026-01-17 12:57 UTC)
2
16
1
MIT
Cruxible Coreofficial
Autonomous Agents Developer Tools Knowledge & Memory
cruxible-ai
A
license
Not graded
quality
A
maintenance
Deterministic decision engine with DAG-based receipts. Build entity graphs, query with MCP, get auditable proof.
Updated 2 days ago (2026-09-04 15:01 UTC)
16
Apache 2.0
decisio-mcp-serverofficial
Product Management Research & Data
decisio-app
F
license
A
quality
D
maintenance
Enables AI assistants to perform structured decision-making using the Analytic Hierarchy Process (AHP), allowing users to define criteria, compare options pairwise, and calculate ranked results with consistency validation.
Updated 5 months ago (2026-03-28 07:40 UTC)
6
-
mcp-decision-lab
Product Management Project Management
AleBrito124356
A
license
Not graded
quality
C
maintenance
MCP server that enables structured decision-making using weighted decision matrices, sensitivity analysis, and robust recommendations.
Updated a month ago (2026-07-27 00:23 UTC)
1
MIT

Appeared in Searches

Search results for Balance Engine

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/inity13/decisionmatrix-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

DecisionMatrix MCP

🌐 Live hosted server (free, no install)

What it does

Scoring methods

Consistent response envelope

Project structure

Requirements

Run it locally

Install via npm (stdio, no hosting)

Client configuration

Cursor — ~/.cursor/mcp.json

Claude Desktop — claude_desktop_config.json

VS Code — .vscode/mcp.json

Any Streamable-HTTP MCP client

Tools & parameters

create_decision(options, criteria, scores, method="weighted_sum")

score_options(options, criteria, scores, method)

sensitivity_analysis(options, criteria, scores, method, variation=0.2, steps=10)

compare_two(option_a, option_b, criteria, scores, method)

list_methods() / health_check()

Example tool-call payloads

Deploy on Cloudflare Pages

Enabling billing (already live on the hosted server)

Auth & rate limiting

Design decisions & assumptions

Testing

Roadmap (post-MVP)

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Cruxible Coreofficial

decisio-mcp-serverofficial

Appeared in Searches

Latest Blog Posts

MCP directory API

Cursor — `~/.cursor/mcp.json`

Claude Desktop — `claude_desktop_config.json`

VS Code — `.vscode/mcp.json`

`create_decision(options, criteria, scores, method="weighted_sum")`

`score_options(options, criteria, scores, method)`

`sensitivity_analysis(options, criteria, scores, method, variation=0.2, steps=10)`

`compare_two(option_a, option_b, criteria, scores, method)`

`list_methods()` / `health_check()`