P2predict-mcp

Overview Schema Source Related Servers Discussions Admin

predict_batch

Predict target values for multiple parts in one batch call. Pass feature dictionaries for each part to get per-row predictions, with optional confidence intervals and explanations.

Instructions

Predict the target value for multiple parts at once.

More efficient than calling predict repeatedly. Pass a list of
feature dictionaries, one per part. Returns one prediction per row.

Optionally enriches every row with the same views the single-part tools
give, so you don't have to fan out to explain / predict_interval:
  - coverage (1-99): adds a likely-price range per row (conformal interval)
    when the model carries calibration data; read `interval.reliability`
    and `interval.say_to_user` per row exactly as predict_interval does.
    Left None (default) for plain point predictions.
  - with_explanation: adds the per-row price drivers (same `explanation`
    shape as explain). Surface the high-importance, correctly-signed
    drivers in dollars/percent; never say 'SHAP' to a category manager.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`rows`	Yes
`coverage`	No
`model_id`	Yes
`with_explanation`	No

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

A5/5.0

Behavior5/5

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

With no annotations, the description carries the full disclosure burden and meets it well. It explains the conditional behavior of coverage (only when the model carries calibration data), names the interval fields to read per row, and describes the exact shape of with_explanation output as matching explain. It even adds user-facing guidance about avoiding the term 'SHAP'.

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 front-loaded with the core purpose, then moves into a clean bulleted list for the optional enrichment behaviors. Every sentence carries operational value, including the final output-guidance note about never saying 'SHAP' to a category manager.

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?

The tool has an output schema, so return-format details are covered structurally; the description focuses on what an agent needs to decide and invoke it correctly. It covers batching semantics, row-to-prediction correspondence, optional behavior, and edge conditions such as missing calibration data. Nothing essential is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so this dimension depends entirely on the description. It defines rows as 'a list of feature dictionaries, one per part,' clarifies coverage as an optional integer 1-99 that toggles conformal intervals, and links with_explanation to the explain output shape. Model_id is not elaborated, but its purpose is evident and the other three parameters gain substantial semantic meaning.

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?

Opens with a specific verb and resource: 'Predict the target value for multiple parts at once.' It immediately distinguishes itself from the single-part tools by framing the batching and efficiency gain, and explicitly references predict, explain, and predict_interval as the alternatives it replaces.

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?

Clearly states when to use the tool ('more efficient than calling predict repeatedly') and how the optional flags avoid fanning out to explain / predict_interval. The description tells the agent to pass a list of feature dictionaries and that each row returns one prediction, so the invocation pattern is unambiguous.

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

Deploy Server