Skip to main content
Glama
Stochastly

Stochastly MCP

by Stochastly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

analyze_dependence

Read-onlyIdempotent

Measure dependence between two equity curves by fitting a copula or mutual information to paired increments, so you can check if strategies or markets move together before combining them.

Instructions

Requires the Stochastly desktop app: this tool runs inside the app, which is not installed on this machine. Install it from https://stochastly.com/pricing, open it and activate a licence.

Measure the dependence between two equity curves you supply, by fitting one copula or the mutual information to their paired increments (only timestamps present in both curves count).

Use it to ask whether two strategies or markets move together before combining them; to actually build and judge a combined book from finished runs, use portfolio_combine instead. Descriptive only: it reports the fit, it does not run a hypothesis test or take a decision. Malformed curves are refused with a named error (wrong count, missing unit, unordered dates, non-finite values). Needs Stochastly open with an Atelier or Portfolio licence.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYesDependence model: a gaussian, student, clayton or gumbel copula fit, or mutual_information on the ranks.
instrumentsYesExactly two curves. Each is an object with `equity` (list of finite numbers, at least 2), an optional `symbol`, `timestamps` or `dates` (ISO dates, same length, unique, increasing) and `pnl_unit` set to "R" or "return".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds substantially beyond them: the runtime prerequisite (desktop app installed, licence of a specific tier), the timestamp-intersection semantics of the join, and the named-error refusal for malformed curves. That is exactly the kind of operational context structured fields cannot carry.

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 the blocking precondition (app not installed, how to fix), then purpose, then routing, then edge behavior. Dense but each sentence carries information; the install/activation sentence and URL are slightly verbose for a precondition note.

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?

For a two-parameter, read-only tool this covers prerequisites, routing, input constraints and failure modes well. The one soft spot is that with no output schema the description only says it 'reports the fit' without indicating what that report contains.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by stating the curves are compared on paired increments and that only timestamps present in both curves count, which clarifies the effective input domain rather than restating field names.

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: measure dependence between two supplied equity curves by fitting a copula or mutual information on paired increments. It also names the sibling it is not (portfolio_combine), so an agent can discriminate 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gives the when ('ask whether two strategies or markets move together before combining them'), the when-not ('to actually build and judge a combined book, use portfolio_combine instead'), and a scope exclusion ('descriptive only, no hypothesis test or decision').

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