114 typed tools, one drop-in

The registry is 45 global tools, 23 market-typed tools minted once for spot and once for futures, and 23 venue operations — 114 in total. Market-typed tools are named {spot|futures}_{tool}, so a model never has to remember to pass a market type and can never pass the wrong one.

Stateless by design. Every call stands on its own there is no session to establish, resume or lose, and nothing to clean up after a client goes away. Point as many clients at it as you like; they cannot interfere with each other.

More tools than routes. 114 tools sit over 104 routes, and the difference is almost entirely one path: POST /api/{marketType}/exchange/{method} is a single route per market type and 23 separately named tools, because a model picks a tool by name and should never have to assemble one out of a parameter.

A couple of capabilities run the other way. get_agent_capabilities mirrors GET /api/agent/capabilities exactly, and it is the one tool no narrowing can take away. delete_backtest does not exist at all: permanently removing a stored backtest report is a REST-only operation. cancel_backtest stops a running job and is idempotent, but it never removes one.

Most of the surface is modular. 45 of the 114 tools are registered by the engine’s 5 feature modules. A module that is switched off in a build does not register its tools at all, which is the same absence a narrowed scope produces. The Modules group in the contents documents them one at a time.

Every tool carries a full description and a typed input schema, which is how a model learns the surface without you writing a prompt about it. The list your engine returns from tools/list is the authoritative one this page names the tools, and the engine ships their schemas.

The server key is pricesylo, the transport is http, and the path is /mcp. Anything that speaks Streamable HTTP MCP works; nothing is client-specific.

Not in the demo build. The demo serves REST and the WebSocket only. Its MCP server is never mounted and it ships no command line either, so the configuration above will simply fail to connect against a demo engine. Everything on this page needs a licensed build.

That is authentication, and there is deliberately none of it. Authorization is a different question and it does have an answer: scopes narrow what a client is allowed to reach, and 2 of those scopes will not act at all until the call says so explicitly. An engine on a machine you share with anyone should be narrowed by the header before it is trusted by the network.

Narrowing is one header. X-PS-Scopes on the POST /mcp request carries a comma-separated list of the scopes this client is willing to use. The engine intersects it with the grant the build already carries, and the intersection is final for that request. An empty list is legal, and leaves an agent with nothing but the capability probe.

A denied tool is absent, not refused. This is the difference that matters on MCP. REST answers a scope failure with a refusal you have to handle; MCP simply never registers the tool, so it does not appear in tools/list and a model never learns the name of something it is not allowed to call. Narrow the scopes and the surface shrinks in front of the model rather than failing underneath it.

2 scopes need a second signal. exchange.trade and orders.write are behind a confirmation gate. A call that needs it carries "_meta": { "autoApprove": true } in the tools/call parameters, or the request carries an X-PS-Confirmed: 1 header. Without one of the two the tool answers with a refusal instead of acting. The scope check runs first, so a scope you never asked for cannot be confirmed into existence.

In practice the gate covers the venue operations marked as moving value in the Venue operations section, plus {spot|futures}_refresh_orders and {spot|futures}_clear_order_history. No module tool is gated at all: creating an indicator, saving a strategy, queueing a backtest and writing a journal entry each need their own write scope and nothing more.

Every tool is annotated. Annotations follow the scope a tool sits on. A tool on a read scope is marked readOnlyHint ; a tool that trades, writes orders or edits the favorites list is marked destructiveHint, as is anything whose name deletes, removes, clears or cancels. A client that surfaces annotations can therefore ask a human before a destructive call without knowing anything at all about this engine.

Discovery is unscoped. get_agent_capabilities is the one tool narrowing can never remove, and it mirrors GET /api/agent/capabilities. It answers with the whole scope vocabulary and, per scope, whether this client currently holds it, whether it is gated, and which tools and routes it covers plus the confirmation contract, the socket contract, where narrowing is read from, and the modules this build loaded. An agent that has just narrowed itself calls this to find out what it has left.

One difference is worth spelling out. The engine’s 5 feature modules name their failures in upper snake case — STRATEGY_NOT_FOUND, BACKTEST_JOB_NOT_FOUND, CUSTOM_INDICATOR_INVALID while the core surface names its own in lower snake case. Both arrive the same way and both name the thing you got wrong; only the spelling differs.

A module failure can also carry more than a message. A validation refusal attaches an errors list with one entry per problem, each naming the path it sits on, and some attach a data object with the specifics. Where a refusal is expected rather than exceptional an invalid custom indicator, an invalid strategy the answer arrives as ordinary tool DATA with a false ok flag and that list, not as an error result, so a model can read the problems and try again without unwinding anything.

Context tools serve tracked pairs only, and answer thinly for the first seconds after add_favorite while the pair warms up. The two exceptions are get_chart_screenshot and get_klines: both can backfill, so both work on any catalogued pair.

Parameter names are identical to the REST passthrough — the full parameter list is on the REST page. A dotted chip marks an operation that moves value.

33 indicators ship built in, filed under 7 categories. Anything you write yourself lands in the first of them and is indistinguishable from the rest afterwards: it lists, it computes by id, and the strategy validator resolves it.

The formula language. 41 series functions run over 10 bar fields, and all 33 built-ins are callable from inside a formula. A formula is never evaluated as source, and every one of them is bounded: no loops, no recursion, constant windows, and a null that propagates rather than a number that lies. Ids are namespaced cx_, and one custom indicator cannot call another.

The lifecycle is guide, validate, preview, store. get_custom_indicator_guide teaches the language, validate_custom_indicator type-checks a draft, {spot|futures}_preview_custom_indicator runs it against a real pair so you can look at the numbers, and create_custom_indicator stores it. Skipping the middle two is allowed and is how most first attempts fail.

Invalid definitions come back as data. This is deliberate and it is the one place this server bends the usual rule. Creating or updating an indicator the engine cannot compile answers with a normal result carrying a false ok flag and an errors list, not with a tool error so a model reads what was wrong, fixes it and calls again inside the same turn.

Refinement is a list of operations, not a rewrite. Each one names a dotted path into the definition and what to do to it, which is what lets a model change a risk floor without restating a strategy it might get wrong. refine_strategy accepts these verbs:

There is no delete tool. delete_backtest is not part of this surface: permanently removing a stored job and its report is a REST-only operation, because it is the one thing on this module an agent should not be able to do on its own. cancel_backtest stops a job and can be called as many times as you like, but it never removes one.

Only one code means the job is gone. BACKTEST_JOB_NOT_FOUND A job that failed, was cancelled or whose report is no longer available still answers. Treat anything else as a job that still exists.

Do not write what was already captured. captured entries derive themselves from the engine’s own order stream and are idempotent; manual entries are for trades placed somewhere else. Writing an entry for a trade this engine watched gives you the same trade twice, and every statistic downstream believes both.

Identity cannot be patched. The symbol, the direction and the entry facts are what an entry IS: to change one of them, delete the entry and write it again. Everything else the notes, the tags, the grades, the mood, the reflection is patchable for as long as you keep the entry. Attachments carry a reference, never bytes.

Every event carries a score. It runs from 0 to 100, and it is what urgency is derived from. Filter on urgency for a human-sized feed and on minScore when you want a hard floor. The thresholds are published by list_market_event_types, so a client never has to hard-code them.

Repeats are updates, not duplicates. An event that keeps happening at the same price is re-scored and re-emitted rather than appended, and it says how many times it has been seen and over what window. For a live feed rather than a query, the socket carries a market-events channel.

create_subscription, list_subscriptions, get_subscription, update_subscription, delete_subscription, test_subscription and list_events are the same code path as the REST subscription routes, and they return the same records.

enabled is the only mutable field: changing a rule means delete and create. test_subscription proves an endpoint is reachable without waiting for a rule to fire, and it succeeds even when the delivery fails read the result rather than the absence of an error.

Creating, updating and deleting a subscription all sit on the subscriptions.write scope, and none of them is behind the confirmation gate: a rule that fires only sends an HTTP request to an endpoint you nominated yourself.

<path> addresses a value inside the pair’s published context. Call spot_get_compiled_context to see exactly which paths a pair currently exposes, then write the dotted route to the value you care about. Paths are case-sensitive, and the timeframe field is always required because it routes the rule into the evaluation index.