P2predict-mcp

Overview Schema Source Related Servers Discussions Admin

predict_from_csv

Batch-predict prices for every row in a local CSV file. Returns point estimates per row, with optional confidence intervals and price-driver explanations.

Instructions

Batch-predict from a CSV file on the local filesystem.

The file-based sibling of predict_batch — use it when the user drops a
spreadsheet of parts. Reads csv_path, predicts every row, and returns one
prediction per row (point estimates by default).

The same opt-in enrichments as predict_batch apply per row:
  - coverage (1-99): adds a likely-price range per row (conformal interval)
    with its `interval.reliability` / `interval.say_to_user` read. Requires
    a model with calibration data; an explicit coverage on an uncalibrated
    model returns a no_calibration error. Left None (default) for plain
    point predictions.
  - with_explanation: adds the per-row price drivers (same `explanation`
    shape as explain). State drivers in dollars/percent; never say 'SHAP'
    to a category manager.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`coverage`	No
`csv_path`	Yes
`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

A4.1/5.0

Behavior4/5

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

With no annotations present, the description carries the behavioral burden and performs well. It discloses that it reads csv_path, predicts every row, returns one prediction per row with point estimates by default, and explains both opt-in enrichments. It also reveals error behavior (no_calibration when coverage is requested on an uncalibrated model) and the internal reliability/say_to_user fields, providing richer transparency than typical definitions.

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 efficiently organized: a purpose statement and usage cue in the first two sentences, then the default behavior, followed by the two optional enrichments in a scannable list. Every sentence provides substantive information, though the with_explanation guidance ("never say 'SHAP'") is a contextual nicety rather than core mechanics. It is longer than strictly necessary but remains tight and front-loaded.

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 has 4 parameters and an output schema, the description covers the essential calling context: input file, per-row predictions, default point estimates, both optional enrichments with their constraints and errors. The output schema accounts for return-value details, so the description does not need to repeat them. Minor omissions such as CSV format requirements or file-not-found behavior are acceptable at this level of complexity.

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, and it does for the optional parameters: coverage is specified as 1-99, its default is None, its interval fields are named, and the no_calibration error condition is given; with_explanation is tied to the explanation shape from explain. However, the required parameters, model_id and csv_path, only appear in the flow of the text without additional format or constraint details, which is a modest gap given their importance.

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 a specific verb and resource: 'Batch-predict from a CSV file on the local filesystem.' It then explicitly differentiates itself from siblings by calling itself 'the file-based sibling of predict_batch' and giving the exact trigger condition ('when the user drops a spreadsheet of parts'). This leaves no ambiguity about what the tool does or how it differs from predict_batch and predict.

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 explicit when-to-use guidance: 'use it when the user drops a spreadsheet of parts' and names the sibling alternative (predict_batch). It does not enumerate exclusions (e.g., when not to use it versus predict or predict_interval), but the file-based context and reference to predict_batch provide a clear decision point. This is strong usage guidance, though not exhaustive about all alternatives.

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

Deploy Server