Skip to main content
Glama
qxkt222

sci-mcp

by qxkt222
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

monte_carlo

Sample scipy.stats distributions and evaluate a SymPy expression over those samples to run reproducible probabilistic simulations and compute percentiles or histograms.

Instructions

Sample distributions with scipy.stats and evaluate a sympy expression over the samples.

``variables`` maps each symbol used in ``expression`` to a dict whose ``dist``
entry names a scipy.stats distribution; the remaining entries are passed to
``dist.rvs`` as keyword arguments (``uniform`` additionally accepts
``low``/``high``). The same ``seed`` always reproduces the same output.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNo
seedNo
filenameNo
variablesYes
expressionYes
percentilesNo
save_histogramNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses that the same seed reproduces identical output, which is a genuine behavioral trait. However it says nothing about cost (n defaults to 10000 samples), what filename/save_histogram do on write, or how invalid distributions/expressions fail.

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?

Short, front-loaded, and free of filler; the nested-variable explanation is placed where it is needed. The reST markup adds mild noise but no wasted sentences.

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

Completeness2/5

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

For a 7-parameter tool with nested objects, no annotations, and no output schema, the description covers only the two hardest-to-guess params. Nothing explains n, expression syntax, percentile selection, or file output, so an agent cannot invoke it confidently beyond the happy path.

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

Parameters2/5

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

Schema coverage is 0% across 7 parameters, so the description must compensate. It explains variables (the nested object) and seed well, but leaves n, expression, percentiles, filename, and save_histogram entirely undocumented in both schema and prose.

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 gives a specific compound verb+resource: sample scipy.stats distributions and evaluate a sympy expression over the samples. That is clearly distinguishable from siblings like symbolic_evaluate or distribution, though no sibling is named explicitly.

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?

It documents mechanics but never says when to reach for this over alternatives such as run_python, symbolic_evaluate, or distribution. No preconditions (e.g., expression must be a valid sympy string, symbols must match variables keys) are stated.

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

Deploy Server

Other Tools