mcp-decision-lab

Overview Schema Source Related Servers Discussions Admin

Analyze the decision

analyze

Idempotent

Turn a fully scored decision matrix into a defensible recommendation with rankings, flip thresholds, and Monte Carlo win probabilities for each option. Flags if the winner is robust or fragile.

Instructions

Analyze a fully scored matrix and give a defensible recommendation.

Returns the ranking and margin; for each criterion the exact weight at which the winner would flip (closed form); the cells whose score alone could change the winner, with the threshold and the rationale behind them; Monte Carlo win probabilities under joint weight and score perturbation; per-option strengths/weaknesses; and a verdict: "robust", "fragile" (a ±50% single-weight change, a ≤1-point single-score change, or a win probability below 80% flips it) or "tie" (winner is null and the tie-breakers are listed). Fails with the list of missing cells if the matrix is incomplete.

Input Schema

TableJSON Schema

Name	Required	Description
`seed`	No	Random seed; same seed, same numbers.
`decision_id`	Yes	Id returned by start_decision, e.g. 'dec-a3f2'.
`score_noise`	No	Uniform ± noise added to every score in the simulation.
`simulations`	No	Monte Carlo samples (0 disables the simulation).
`weight_concentration`	No	Dirichlet concentration of the simulated weights; lower = more weight uncertainty.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 28, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, but the description adds rich behavioral context beyond that: exact returned artifacts (ranking, margin, closed-form flip weights, Monte Carlo probabilities, strengths/weaknesses, verdict categories with specific thresholds), failure mode (incomplete matrix), and the robustness criteria that define 'fragile.' This is substantial additional disclosure.

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 purpose, then a dense but well-organized list of outputs and the verdict taxonomy. No filler sentences. The long enumeration of returns is justified by the tool's complexity, though it could be trimmed slightly by relying on the output schema.

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 mutation-like tool with annotations covering safety, a complete 100%-covered parameter schema, an output schema, and sibling tools, the description provides exactly what's needed: what it produces, when it fails, and how to interpret the verdict. Nothing an agent needs to call 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?

Schema description coverage is 100%, so the schema fully documents all five parameters including defaults and bounds. The description adds no syntax or format details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Analyze a fully scored matrix and give a defensible recommendation.' Distinct from siblings like get_matrix (retrieve) and what_if (single perturbation) by emphasizing the full defense-quality output. An agent can distinguish this from what_if without opening either 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 implies usage by requiring a 'fully scored matrix' and noting it 'Fails with the list of missing cells if the matrix is incomplete,' which implicitly tells the agent to finish scoring first. However, it never explicitly names what_if or get_matrix as alternatives, nor states when-not to use this tool. Minimal viable guidance.

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

Deploy Server