P2predict-mcp

Overview Schema Source Related Servers Discussions Admin

what_if

Compare a base scenario against a counterfactual with changed features to see the price impact, savings, or added cost, plus per-driver attribution and a reliability grade for the direction of the move.

Instructions

Compare a base scenario with a counterfactual where features change.

Returns a plain `summary` to quote directly (does the change add or save,
how many dollars, what percent, old vs. new price), plus both predictions,
the delta, and per-driver attribution of each change for your reasoning.
Answers "what if we switch from supplier A to B?" Set coverage to null to
skip intervals.

`summary.reliability` grades how far to trust the DIRECTION of the move —
'trust' | 'caution' | 'quote' — with a plain `summary.say_to_user` line to
quote. It fires when the changed spec is thinly sampled, or when the swing
is driven by knock-on effects rather than the change itself (a `quote` here
means the number is unstable — relay the caution, don't present the
direction as fact). It flags instability, not a wrong domain sign, so still
sign-check a 'trust' result against intuition.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`changes`	Yes
`coverage`	No
`features`	Yes
`model_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.1Sep 16, 2026

TDQS

A4.3/5.0

Behavior5/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 return structure (summary, both predictions, delta, per-driver attribution), the meaning of summary.reliability ('trust' | 'caution' | 'quote'), when reliability fires (thin sampling, knock-on effects), and how to interpret a 'quote' (unstable number, relay caution). It even warns to sign-check 'trust' results. This goes far beyond basic transparency and is exceptionally detailed.

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 moderately long but every sentence adds meaningful information. It opens with the core purpose, then details the return format and reliability interpretation. The structure is logical and front-loaded. It could be slightly more concise, but it avoids fluff and each clause serves a purpose.

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 (4 params, nested objects, output schema present), the description covers the key operational details: what the summary contains, how to quote it, how reliability works, and the coverage null behavior. It does not cover error cases or edge scenarios, but the output schema presumably handles return values. The description is sufficient for an agent to call the tool correctly in most situations.

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 0%, so the description must compensate. It does explain the coverage parameter ('Set coverage to null to skip intervals') and hints at the shape of features/changes via the supplier example, but it does not detail the structure of the 'changes' object or how features are specified. This leaves room for ambiguity, but the example provides some semantic guidance. The description adds value but is not fully compensatory.

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 states a specific verb ('Compare') and resource ('base scenario with counterfactual'), and immediately gives a concrete example ('switch from supplier A to B?'). It clearly distinguishes this tool from siblings like predict (which predicts without counterfactual comparison) and explain (which explains without scenario changes). The purpose is unambiguous and action-oriented.

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 a clear use case with a concrete example ('what if we switch from supplier A to B?') and explains when to use it (comparing scenarios with feature changes). It does not explicitly state when NOT to use it or mention alternative tools, but the example and the tool's name make the usage context clear. Minor gap: no explicit exclusion of cases better suited for predict or explain.

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

Deploy Server