What can you do with this server?

This server provides read-only access to trading data from the Senti Quant Public API via MCP tools. It allows an AI assistant to: * List linked MT5 accounts, including balances, equity, terminal status, and running strategies * List supported brokers and their MT5 server details * Browse available trading strategies (expert advisors) with ratings and presets * View strategies deployed on a specific account, showing symbol, timeframe, and status * Retrieve open positions on an account, including symbol, volume, prices, stop loss/take profit, and floating profit * Retrieve pending limit and stop orders, showing order type, trigger price, volume, and more All tools are read-only; no write operations (closing positions, cancelling orders, etc.) are exposed. A valid Senti Quant API key is required, and some endpoints may return a 409 error if the MT5 terminal is offline.

How do I use senti-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@senti-mcp-server list my MT5 accounts" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

senti-mcp-server

by Koniverse

Overview Schema Related Servers Score Discussions

TypeScript

Remote

senti-mcp-server

A Model Context Protocol server that lets an AI assistant (Claude Code, Claude Desktop, Cursor, …) read trading data from the Senti Quant Public API.

Tools

Tool	Input	What it does
`list_accounts`	none	Lists the MT5 accounts linked to the configured API key: id, login, broker, last known balance and equity, sync state, running strategies.
`list_brokers`	none	Lists the platform-wide catalog of brokers Senti Quant supports — not the accounts this API key already has — with each broker's MT5 server names and account types.
`list_strategies`	none	Lists the platform-wide catalog of strategies (expert advisors) available to deploy — not the strategies currently running on any account — with each strategy's supported symbols, timeframes, rating and presets.
`list_account_strategies`	`accountId` (the `id` from `list_accounts`, not `login`)	Lists the strategies currently deployed on one MT5 account, with each deployment's symbol, timeframe and status.
`list_positions`	`accountId` (the `id` from `list_accounts`, not `login`)	Lists the positions currently open on one MT5 account, read live from the terminal: symbol, direction, volume, open/current price, stop loss, take profit, swap and floating profit. A `409` means the account's terminal is offline — not that the account holds no positions.
`list_pending_orders`	`accountId` (the `id` from `list_accounts`, not `login`)	Lists the pending limit and stop orders resting on one MT5 account, read live from the terminal: symbol, order type, volume, trigger price, stop loss, take profit and stop-limit price. These are orders that have NOT been filled — for open positions, use `list_positions`. A `409` means the account's terminal is offline — not that the account has no pending orders.
`list_deals`	`accountId`, plus optional `limit` (1–500, default `50`), `cursor`, `entry` (`in` or `out`), `from` and `to` (ISO-8601)	Lists one page of an MT5 account's closed deal history — the fills that already happened: symbol, direction, entry kind, volume, price, realized profit, costs, the linked position and order. Paginated, and it never pages on its own: one call is exactly one request, and when more deals exist the answer reports a `cursor` you must pass back to read the next page. For totals over a period use `get_account_performance` rather than adding these rows up.
`get_account_performance`	`accountId`, plus optional `from`, `to` (`YYYY-MM-DD`, UTC) and `reporting` (an ISO-4217 currency code, default `USD`)	Summarizes how one MT5 account performed over a date window: net P&L, win rate, profit factor, gross profit and loss, deal counts, costs, cash flow, period ROI and IRR, lifetime IRR, and the live terminal state. Omit `from`/`to` for the last 30 days. Unlike `list_positions` and `list_pending_orders` there is no `409` — an unreachable terminal arrives as a null `live` block inside a success, and is reported as unreachable rather than as zeroes.
`get_performance_breakdowns`	`accountId`, plus the same optional `from`, `to` and `reporting` as `get_account_performance`	Breaks one MT5 account down three ways over a date window: a day-by-day P&L, volume and notional series; a per-symbol P&L and deal-count series; and P&L by hour of the day. Answers "which symbol is losing me money" and "what hour do I trade worst". This response is shaped. The endpoint is the largest the API serves — 87 KB for a 63-day window on a single-symbol account — so per-account rows and running totals are dropped, at most 10 symbols are kept (those with the largest absolute net P&L), and the hourly grid is totalled across the window. Whatever that costs is listed in `notes` and repeated in the text; `notes` is empty when nothing was cut. For a single whole-account figure use `get_account_performance` — it is smaller and it is the default for a performance question.
`get_equity_timeseries`	`accountId`, plus the same optional `from`, `to` and `reporting` as `get_account_performance`	Returns the reconstructed equity curve and floating drawdown for one MT5 account over a date window, as a series of points — answers "how has my equity moved" and "what was my worst drawdown". This response is shaped. A wide window returns a point per interval and grows without bound, so the series is downsampled to at most 200 points — but the first point, the last point and the point of deepest drawdown are always retained, so the start, the end and the worst of the curve are exact rather than sampled near. Measured live on 2026-08-12: 499 points over 63 days → 200. Every downsample is recorded in `notes`, which is empty when the series was short enough to return whole; narrow `from`/`to` for finer resolution. `caveats` and `portfolioCaveats` — the API's own statements about figures it could not fully reconstruct — are always returned in full, never shortened.
`get_authoring_conventions`	none	Reads the Senti Quant MQL5 authoring contract as data: hard-safety constraints, trading-safety requirements, the static analyzer's forbidden-construct list, and the platform limits on draft count and source size. Call this before generating any MQL5 source — code that breaks these rules is rejected by a static scan before it reaches the compiler, and compile slots are globally serial, so discovering a rule by failing a compile is expensive and still fails. Limits are reported exactly — a ceiling that is not a whole multiple of 1024 stays in bytes rather than being rounded into a KiB figure the API does not honour. The response is small (~2 KB) and static per deploy; `forbiddenConstructs[].pattern` values are regular expressions reported verbatim, never evaluated.
`get_draft`	`draftId` (the `id` field from `list_drafts`)	Reads one MQL5 draft the API key owns: its full source code, its compiler log, its diagnostics, and whether the last compile still matches the current source. Answers "why did this fail to compile" or "show me the code". The response can be large — a draft may hold up to 192 KiB of source plus 16 KiB of compiler log, and this server returns that content twice, once as text and once as structured data — roughly 105,000 tokens worst case. Attachment source is NOT included; attachments are listed with their size, and `list_draft_attachments` returns their code — `notes` points there only when an attachment actually carried source to lose.
`list_drafts`	none	Lists the MQL5 drafts this API key owns, most recently updated first, with each draft's compile status, size, attachment count and registered-EA id. Use it to find a `draftId`, or to answer "what am I working on" and "which of my drafts are broken". This response is shaped. `GET /api/v1/drafts` is the largest payload the API can produce — up to 10.3 MiB across 20 drafts — so source code, compiler logs and diagnostics are ALL dropped; what was cut is listed in `notes`, and the note only ever names a category that actually lost something — with a byte figure only where bytes were measured. Measured live on 2026-08-20: 19,853 B → 1,898 B, 90.4% removed; worst case at `maxDrafts` with 5 attachments per draft is roughly 5,000–7,000 tokens, counting both response channels. Call `get_draft` for one draft's source and compiler output, or `list_draft_attachments` for its indicator sources. There is no option to request the unshaped response.
`list_draft_attachments`	`draftId` (the `id` field from `list_drafts`), plus optional `filename`	Reads the indicator source files a draft's EA embeds via `#resource` — the source `get_draft` deliberately leaves out. Pass `filename` to read at most one attachment whole, by exact name; that is also how to read one a default call had to leave out — if more than one attachment shares that filename, only the first is returned and `notes` says how many were skipped. A filtered read says so in its text and names the draft's real attachment count, so `content` alone is never read as the whole set. This response is budgeted, not truncated. With `filename` omitted, attachments are returned whole while the running total stays within a 64 KiB budget — the first attachment is always returned whole regardless of size, and once one is cut every later one is cut too, and `notes` says exactly that rather than claiming each cut file exceeded the budget; a cut attachment keeps its metadata and reports `sourceCode: null`, never a partial source. `notes` says whether a cut happened. Worst case, counting both response channels, is roughly 33,000 tokens.
`create_draft`	`name` (1–120 chars, unique per user), `sourceCode` (the complete EA)	Write tool — registered only when `SENTI_ENABLE_AUTHORING_WRITE` is set (see Enabling the write path). Creates a new MQL5 draft from source you have written, and returns its `id`. Call `get_authoring_conventions` first: code that breaks the platform rules is rejected by a static scan before it reaches the compiler, and this tool does not check them for you. The response does not echo your source back — you just sent it — so it returns the new id, the byte count written and the compile state, and `notes` points at `get_draft` for a read-back. Nothing is compiled until you call `compile_draft`. A `409` means the name is taken; a `403` means either the key lacks `authoring:write` or your draft cap is full, and the message says both because the API does not distinguish them.
`update_draft`	`draftId`, `name`, `sourceCode`	Write tool, behind the opt-in. Replaces an existing draft. THIS IS A FULL REPLACE, NOT A PATCH — both fields are always written, so send the complete draft every time; sending only what you changed deletes the rest of the file, because the API has no partial-update verb. Call `get_draft` first if you do not have the current source. Annotated `destructiveHint` for exactly that reason, despite the name. Reports the bytes written, not a before/after delta — the `PUT` response carries only the new draft, and this server does not make a hidden second request to invent the missing figure. Compiles nothing; if a previous compile no longer matches, the text says so and points at `compile_draft`.
`delete_draft`	`draftId`	Write tool, behind the opt-in — and it asks first. Deletes one draft and every indicator attached to it. Cannot be undone, and no tool here restores one, so it pauses for an explicit human confirmation before anything is sent; declining returns a success saying nothing was deleted, not an error. An EA already registered from the draft is unaffected — a separate resource. Use it to free a slot when `create_draft` reports the draft cap is full. Needs a host that supports MCP elicitation; on one that does not, this tool cannot be used, and that is deliberate rather than degraded to a silent delete.
`add_draft_attachment`	`draftId`, `filename` (a bare `.mq5` basename), `sourceCode`	Write tool, behind the opt-in. Attaches one MQL5 indicator source to a draft so the EA can embed it. Filenames are unique within a draft case-insensitively — `MyInd.mq5` collides with `myind.mq5`, because the compile host writes them into one flat Windows directory. Attaching does not wire it up: the text names the exact `#resource "<stem>.ex5"` and `iCustom(…)` lines the EA still needs, which means an `update_draft` afterwards, or the file is compiled and never used. The response does not echo your source back.
`update_draft_attachment`	`draftId`, `attachmentId`, `sourceCode`	Write tool, behind the opt-in. Replaces one indicator's source. The filename cannot be changed and this tool takes no filename — an EA embeds an indicator by name, so a rename would orphan every reference; to rename, delete, re-add and update the EA source. A full replace of that file's contents, so send the complete indicator. A `404` here may also mean the attachment belongs to a different draft.
`delete_draft_attachment`	`draftId`, `attachmentId`	Write tool, behind the opt-in — and it asks first. Removes one indicator from a draft. Cannot be undone. Afterwards the EA still references it: remove its `#resource` and `iCustom` lines with `update_draft`, or the next `compile_draft` fails on a file that is no longer there — the text says so. Also how to free a slot when the attachment cap is full, and the only way to rename a file. Needs a host that supports MCP elicitation.
`compile_draft`	`draftId`	Write tool, behind the opt-in. Runs the static-safety scan and the MQL5 compiler over a draft and every indicator attached to it, and returns the verdict, the diagnostics and the compiler log. A check only — it registers and deploys nothing. A failed build is not an error: the tool succeeds and reports `ok: false` with diagnostics, so read the result rather than retrying. The compile slot is one per account and the compile server is globally serial, so a second concurrent call is a `409` and contention is a `503` with a wait — this server reports both and retries neither. If the 15s client timeout fires, the compile keeps running on the server: the message says so and sends you to `get_draft` for `lastCompileStatus`.

The id a tool returns is the accountId other Senti endpoints take. login is the MT5 account number, not a key.

Related MCP server: ctrader-mcp-server

Requirements

Node.js ≥ 22.11.0 — the first LTS release of the Node 22 "Jod" line, supported until 2027-04-30. The floor is a support-lifetime choice, not an API one: the newest runtime feature this server actually uses is AbortSignal.any() (Node 20.3.0), on the path of every tool call, and npm run test:smoke uses node --env-file (20.6.0). Raised from the old 20.6.0 floor in v2.0.0 because Node 20 reached end of life on 2026-04-30 (CONTEXT D27)
A Senti Quant API key (sq_live_…). As of v2.1.0 the tool surface needs six read scopes: accounts:read, brokers:read, strategies:read, performance:read, trading:read, authoring:read — create one with all six at the API Keys dashboard. There is no key-introspection endpoint, so a missing scope isn't caught at startup: it surfaces as a 403 naming the scope the first time the affected tool is called, and every other tool keeps working. All six are exercised by a shipped tool: accounts:read (list_accounts), brokers:read (list_brokers), strategies:read (list_strategies, list_account_strategies), trading:read (list_positions, list_pending_orders, list_deals), performance:read (get_account_performance, get_performance_breakdowns, get_equity_timeseries) and authoring:read (get_authoring_conventions, get_draft, list_drafts, list_draft_attachments).
A seventh scope, authoring:write, only if you turn the write tools on. As of v2.5.0 SENTI_ENABLE_AUTHORING_WRITE registers tools that create and change MQL5 drafts, and those need it. A key without it runs the entire read surface unaffected, and a key with it changes nothing while the flag is unset — no write tool is registered, so none can be called.

Configuration

Variable	Required	Default	Purpose
`SENTI_API_KEY`	✅	—	First-party key. The server exits at startup without it.
`SENTI_API_BASE_URL`		`https://api.sentitrade.xyz`	Set to `https://be-dev.sentitrade.xyz` for development.
`SENTI_ENABLE_AUTHORING_WRITE`		unset (off)	`1` or `true` registers the authoring write tools. See below.

Enabling the write path

Every tool is read-only unless you opt in. Set SENTI_ENABLE_AUTHORING_WRITE=1 in the server's env block and the authoring write tools are registered; leave it unset — or set it to 0, false, no or off — and they are not. A host that never sets it never sees one in tools/list, so there is nothing for a model to call by accident.

Turning it on gives an agent the ability to create, replace and delete MQL5 drafts and their indicator files, and to compile them — the whole write → build → read the errors → write again loop, without leaving the editor. The key must also hold authoring:write.

The two delete tools pause for a human. delete_draft and delete_draft_attachment ask for an explicit confirmation through MCP elicitation before anything is sent, because they are the only operations here that no other tool can undo. The other five do not ask: update_draft fires on every save in an edit loop, and a prompt seen fifty times a session gets rubber-stamped, which is worse than no prompt. On a host that does not support elicitation the two delete tools cannot be used — deliberately, rather than degraded to a silent delete.

It does not enable any trading write. Closing a position, cancelling an order and deploying a strategy to an account are a different surface, gated by a different scope (strategies:write, trading:write) and by a flag that does not exist yet — see EPIC-3. No setting of SENTI_ENABLE_AUTHORING_WRITE reaches them. Registering an authored EA as a private strategy is also not available: that is POST …/register, deliberately left out of EPIC-8 because no operation in the authoring surface can delete what it creates.

The key and the base URL must belong to the same environment. Keys are environment-bound: a key is issued by whichever backend the dashboard you used talks to, and it returns 401 against any other, however valid it is. So when a correct-looking key is rejected, check SENTI_API_BASE_URL before regenerating the key — a 401 is far more often a mismatched environment than a bad key.
Verified pairing: a dashboard-issued key against https://be-dev.sentitrade.xyz — that is the pairing npm run test:smoke exercises, and it has passed twice. Whether the default, https://api.sentitrade.xyz, accepts the same key is not established here, so if you are unsure, set SENTI_API_BASE_URL to the host you know your key was issued against.

See docs/SETUP.md for a full local setup walkthrough.

Use with an MCP client

No install step — npx fetches the published package on first run:

{
  "mcpServers": {
    "senti": {
      "command": "npx",
      "args": ["-y", "senti-mcp-server"],
      "env": {
        "SENTI_API_KEY": "sq_live_..."
      }
    }
  }
}

Restart the client; all fourteen tools should appear — every GET operation the Senti Quant Public API exposes now has one, the last four added over the Authoring tag EPIC-7 shipped. npx -y senti-mcp-server resolves to whatever npm's latest tag points at — 2.8.1 as of this release. It carries 2.4.0's fourteen read tools plus seven write tools — create_draft, update_draft, delete_draft, add_draft_attachment, update_draft_attachment, delete_draft_attachment and compile_draft — which are registered only when SENTI_ENABLE_AUTHORING_WRITE is set, so an installation that does not set it sees the same fourteen tools 2.4.0 did. 2.4.0 carries the ten tools of 1.4.0 plus get_authoring_conventions, get_draft, list_drafts and list_draft_attachments, fourteen in total, and no write tool at any setting. 2.3.0 carries those same ten tools plus get_authoring_conventions, get_draft and list_drafts, thirteen in total. 2.2.0 carries those same ten tools plus get_authoring_conventions and get_draft, twelve in total. 2.1.0 carries those same ten tools plus get_authoring_conventions only, eleven in total. 2.0.1 and 2.0.0 carry the same ten tools as 1.4.0 and differ from it only in requiring Node ≥ 22.11.0; the 2.0.1 patch on top of 2.0.0 carries only build-toolchain and documentation changes. 1.4.0 is the last version declaring the old 20.6.0 floor and is the one to pin if you are stuck on Node 20; it carries ten tools. 1.3.0 carries nine, without get_equity_timeseries; 1.2.0 carries eight, without get_performance_breakdowns as well; 1.1.0 carries seven, without list_deals on top of that; 1.0.1 carries six, without get_account_performance too; and only list_accounts is reachable on 0.1.0, which was published before the others existed, so check npm view senti-mcp-server dist-tags if a tool you expect is missing.

Pin the version in args if you want to hold one — ["-y", "senti-mcp-server@2.8.1"]. To put it on your PATH instead:

npm install -g senti-mcp-server

Then the client block becomes "command": "senti-mcp-server" with no args.

From a git checkout

Point the client at your own build — useful while developing:

npm install
npm run build

{
  "mcpServers": {
    "senti": {
      "command": "node",
      "args": ["/absolute/path/to/senti-mcp-server/dist/index.js"],
      "env": {
        "SENTI_API_KEY": "sq_live_..."
      }
    }
  }
}

Security

The API key is read from the environment and never appears in a tool's input schema. A tool parameter would live in the model's context, and from there in transcripts and logs; an environment variable does not. The test suite asserts the key appears in no error message.

The trading write operations are not exposed. Closing positions, cancelling orders and stopping strategies have no tool, deliberately, and adding one needs its own design. The authoring writes that SENTI_ENABLE_AUTHORING_WRITE turns on (v2.5.0) are the only writes this server can make: they create, replace, delete and compile MQL5 drafts, and touch no account, position or order. They ship with the three things this section has always demanded of a write — an opt-in switch, Idempotency-Key support, and user confirmation before either delete. Left unset, the server registers read-only tools only.

Development

npm test           # unit tests (stubbed fetch)
npm run test:watch
npm run test:smoke # one live call against the dev API; needs .env.local
npm run typecheck
npm run dev        # run from source, e.g. SENTI_API_KEY=… npm run dev

npm run test:smoke reads SENTI_SMOKE_KEY from .env.local, which is gitignored. If .env.local exists but doesn't set SENTI_SMOKE_KEY, the smoke test skips cleanly. If .env.local doesn't exist at all, node --env-file fails to start (node: .env.local: not found, exit 9) rather than skipping — create the file, even empty, to get the skip instead of the failure.

License

MIT

Available Tools

14 tools

get_account_performanceGet an account performance summaryA

Read-only

Summarize how one MT5 account has performed over a date window: net P&L, win rate, profit factor, gross profit and loss, deal counts, costs, cash flow, period ROI and IRR, lifetime IRR, and the live terminal state. This is the default tool for any performance question — the response is a fixed-size summary that does not grow with the window. accountId is the id field from list_accounts — NOT login. Omit from/to for the last 30 days. reporting is an ISO-4217 currency code (default USD), not a reporting period. A null live block means the terminal was unreachable, not that the account is empty.

ParametersJSON Schema

Name	Required	Description
`to`	No	Window end, inclusive (UTC, YYYY-MM-DD).
`from`	No	Window start (UTC, YYYY-MM-DD).
`accountId`	Yes	The `id` field from list_accounts. Not the `login` (MT5 account number).
`reporting`	No	ISO-4217 currency the money figures are normalized to. Defaults to USD.

Output Schema

ParametersJSON Schema

Name	Required	Description
`live`	Yes
`notes`	Yes
`metrics`	Yes
`lifetimeIrr`	Yes
`portfolioReturn`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Beyond the readOnlyHint annotation, the description adds useful behavioral context: the response is a fixed-size summary that does not grow with the window, and a null live block means the terminal was unreachable (not that the account is empty). It also clarifies the ambiguous reporting parameter. No contradiction with annotations.

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 concise yet dense, front-loaded with the core purpose, followed by a compact list of included metrics, then practical usage notes. Every sentence adds value—parameters, defaults, null handling, and a common pitfall—without fluff or redundancy.

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?

For a summary tool with an output schema, the description fully covers what the agent needs to know: the exact metrics returned, the default time window, default currency, the accountId pitfall, and the meaning of a null live block. Given the low complexity (no nested objects) and rich schema/output schema, this is highly complete.

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 parameters are documented, but the description adds valuable semantic clarifications: accountId is the id field from list_accounts, NOT the login; reporting is a currency code (default USD), not a period; from/to are in UTC YYYY-MM-DD. This goes beyond the schema's descriptions and addresses likely user confusion.

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 clearly states the tool's function: 'Summarize how one MT5 account has performed over a date window' and enumerates the specific metrics returned (net P&L, win rate, profit factor, etc.). It explicitly labels itself as 'the default tool for any performance question,' distinguishing it from sibling listing tools like list_deals and list_positions.

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?

Provides concrete usage guidance: default 30-day window when from/to are omitted, reporting is an ISO-4217 currency code not a period, and accountId must come from list_accounts (not login). It names the tool as the default for performance questions, implying alternatives for other needs, but does not explicitly mention when-not to use it or name sibling alternatives.

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

get_authoring_conventionsRead the MQL5 authoring rulesA

Read-only

Read the Senti Quant MQL5 authoring contract as data: the hard-safety constraints, the trading-safety requirements, the static analyzer's forbidden-construct list, and the platform limits on draft count and source size. CALL THIS BEFORE GENERATING ANY MQL5 SOURCE. Code that breaks these rules is rejected by a static scan before it reaches the compiler, and compile slots are globally serial, so discovering a rule by failing a compile is expensive and still fails. The response is small (~2 KB) and static per deploy. forbiddenConstructs[].pattern values are regular expressions reported verbatim — this tool does not evaluate them.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`limits`	Yes
`forbiddenConstructs`	Yes
`hardSafetyConstraints`	Yes
`tradingSafetyRequirements`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description adds behavioral specifics: the response is small (~2 KB) and static per deploy, and forbiddenConstructs[].pattern values are regular expressions reported verbatim without evaluation. These details give an agent accurate expectations about call cost, response stability, and the tool's pass-through behavior, all of which are not visible in annotations or the empty input schema.

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?

Every sentence earns its place. The first sentence defines the resource, the second gives a direct action, the third provides the cost rationale, and the final two disclose response size and regex handling. The content is front-loaded with the most important information and uses imperative language for the critical instruction.

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 description is complete for a read-only, zero-parameter tool. An output schema exists, so return-value detail is not the description's responsibility, but it still tells the agent the response is small, static, and that regexes are verbatim. The sibling-tool context shows no overlap, so no alternative-routing information is needed. An agent knows exactly when to call it and what to expect.

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?

The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings; instead it clarifies what the returned data represents, which is the closest equivalent. It names the four content categories and the pattern semantics, adding meaning beyond the empty schema.

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: 'Read the Senti Quant MQL5 authoring contract as data'. It enumerates four concrete components of that contract and the platform limits on draft count and source size. This clearly differentiates it from all sibling tools, which deal with drafts, accounts, brokers, strategies, positions, and performance—not authoring rules.

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?

The description gives an explicit, imperative trigger: 'CALL THIS BEFORE GENERATING ANY MQL5 SOURCE.' It also explains the cost of ignoring that guidance: rule-breaking code is rejected by a static scan before the compiler, and compile slots are globally serial, making compile-time discovery expensive. This is unambiguous when-to-use guidance with a clear rationale.

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

get_draftRead one MQL5 draftA

Read-only

Read one MQL5 draft the API key owns: its full source code, its compiler log, its diagnostics, and whether the last compile still matches the current source. Use it to answer "why did this fail to compile" or "show me the code". draftId is the id field from list_drafts. THE RESPONSE CAN BE LARGE — a draft may hold up to 192 KiB of source plus 16 KiB of compiler log, and this server returns that content twice (once as text, once as structured data) — roughly 105,000 tokens worst case. Attachment source is NOT included; the attachments are listed with their size, and list_draft_attachments returns their code. For a cheap overview of every draft, call list_drafts instead.

ParametersJSON Schema

Name	Required	Description	Default
`draftId`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`notes`	Yes
`createdAt`	Yes
`updatedAt`	Yes
`sourceCode`	Yes
`attachments`	Yes
`logTruncated`	Yes
`eaDefinitionId`	Yes
`lastCompileLog`	Yes
`compiledUpToDate`	Yes
`lastCompileStatus`	Yes
`lastCompileDiagnostics`	Yes

TDQS

A5/5.0

Behavior5/5

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

Even though readOnlyHint=true is already annotated, the description adds significant behavioral warnings: the response can be extremely large (up to ~105,000 tokens) because content is returned twice, attachment source code is excluded, and only attachment metadata is included. This gives the agent crucial execution-hazard information beyond the annotations.

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?

Although it is longer than average, every sentence contributes: what is returned, why to use it, how to reference the parameter, the large-response warning, the attachment behavior, and the cheaper alternative. The most important caveat, response size, is highlighted and placed prominently.

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?

For a read operation with an output schema and readOnlyHint annotations, the description provides all the context an agent needs: return contents, size hazard, attachment source exclusion, and sibling routing. The attachment exclusion is especially important because otherwise an agent would assume the returned source includes attachment code.

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?

The schema offers 0% description coverage, so the description carries the full burden of explaining the only parameter. It directly defines `draftId` as the `id` field from list_drafts, which is precise, actionable, and sufficient for an agent to invoke the tool correctly.

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 uses a specific verb and resource, 'Read one MQL5 draft', and lists exactly what the tool returns: source code, compiler log, diagnostics, and compile-match status. It distinguishes itself from sibling tools by explicitly saying how it differs from list_drafts and list_draft_attachments. This allows an agent to confidently select it for showing code or diagnosing compile failures.

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?

It explicitly tells the agent when to call it: to answer 'why did this fail to compile' or 'show me the code'. It also gives routing alternatives: use list_draft_attachments for attachment source code and list_drafts for a cheap overview. This is strong, actionable usage guidance.

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

get_equity_timeseriesTrack an account's equity curve and drawdown over timeA

Read-only

Return the reconstructed equity curve and floating drawdown for one MT5 account over a date window, as a series of points. Use it for "how has my equity moved" or "what was my worst drawdown". For a single whole-account figure — net P&L, win rate, ROI — use get_account_performance; for a breakdown by day, symbol or hour use get_performance_breakdowns. THIS RESPONSE IS SHAPED. A wide window holds more points than an answer can carry, so the series is downsampled to at most 200 points — but the first point, the last point and the point of deepest drawdown are always retained, so the start, the end and the worst of the curve are exact rather than approximate. Every downsample is recorded in notes, which is empty when the series was short enough to return whole. A short move between two kept points may not be visible; narrow from/to for finer resolution. caveats and portfolioCaveats are the API's own statements about figures it could not fully reconstruct — read them before quoting a number. accountId is the id field from list_accounts — NOT login. Omit from/to for the last 30 days. reporting is an ISO-4217 currency code (default USD), not a reporting period.

ParametersJSON Schema

Name	Required	Description
`to`	No	Window end, inclusive (UTC, YYYY-MM-DD).
`from`	No	Window start (UTC, YYYY-MM-DD).
`accountId`	Yes	The `id` field from list_accounts. Not the `login` (MT5 account number).
`reporting`	No	ISO-4217 currency the money figures are normalized to. Defaults to USD.

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	Yes
`caveats`	Yes
`portfolio`	Yes
`portfolioCaveats`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint, openWorldHint), the description discloses key behavioral traits: the series is downsampled to at most 200 points, but first/last/deepest-drawdown points are always retained. It explains the `notes` field records downsampling and warns that short moves may not be visible. It also tells users to read `caveats` and `portfolioCaveats` before quoting numbers, which is critical for data quality.

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 dense but well-structured: purpose first, then alternatives, then downsampling behavior, then parameter clarifications. Every sentence adds value, though the length is substantial. The all-caps 'THIS RESPONSE IS SHAPED' is attention-grabbing but slightly jarring; however, it emphasizes an important limitation. Overall it's appropriately sized for a tool with these nuances.

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?

Given the output schema exists and annotations are present, the description covers all necessary operational context: how the response is shaped, downsampling rules, the meaning of `notes` and `caveats`, and parameter gotchas. It leaves no major ambiguity about selecting, invoking, or interpreting the tool's results.

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?

The input schema already describes parameters, but the description adds crucial disambiguation: `accountId` is the `id` field from list_accounts (NOT `login`), and `reporting` is an ISO-4217 currency code, not a reporting period. It also notes omitting from/to gives the last 30 days. These clarifications prevent common misuse and go well beyond the schema's stated descriptions.

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 starts with a specific verb and resource: 'Return the reconstructed equity curve and floating drawdown for one MT5 account over a date window, as a series of points.' It clearly distinguishes from siblings by naming get_account_performance for whole-account figures and get_performance_breakdowns for day/symbol/hour breakdowns, so the tool's role is unambiguous.

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?

Explicit guidance says when to use it ('how has my equity moved' or 'what was my worst drawdown') and when not to (for net P&L, win rate, ROI use get_account_performance; for breakdowns use get_performance_breakdowns). It also adds practical tips like omitting from/to for the last 30 days and narrowing the window for finer resolution.

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

get_performance_breakdownsBreak an account down by day, symbol and hourA

Read-only

Break one MT5 account down three ways over a date window: a day-by-day P&L, volume and notional series; a per-symbol P&L and deal-count series; and P&L by hour of the day. Use it for "which symbol is losing me money" or "what hour do I trade worst". For a single whole-account figure — net P&L, win rate, ROI, the live terminal — use get_account_performance instead: it is smaller and it is the default for a performance question. THIS RESPONSE IS SHAPED. The endpoint returns a chart-sized payload, so per-account rows and running totals are dropped, at most ten symbols are kept, and the hourly grid is totalled across the window. Whatever that cost is listed in notes, which is empty when nothing was cut — read it before concluding that a symbol was not traded. accountId is the id field from list_accounts — NOT login. Omit from/to for the last 30 days; a narrower window is also how you see a symbol that was cut. reporting is an ISO-4217 currency code (default USD), not a reporting period.

ParametersJSON Schema

Name	Required	Description
`to`	No	Window end, inclusive (UTC, YYYY-MM-DD).
`from`	No	Window start (UTC, YYYY-MM-DD).
`accountId`	Yes	The `id` field from list_accounts. Not the `login` (MT5 account number).
`reporting`	No	ISO-4217 currency the money figures are normalized to. Defaults to USD.

Output Schema

ParametersJSON Schema

Name	Required	Description
`daily`	Yes
`notes`	Yes
`hourly`	Yes
`perSymbol`	Yes

TDQS

A5/5.0

Behavior5/5

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

Discloses response shaping: chart-sized payload, dropped running totals, at most ten symbols kept, hourly grid totalled across the window, and the use of `notes` to signal truncation. This is significant behavioral context far beyond the readOnlyHint/openWorldHint annotations, and it does not contradict any annotation.

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 paragraph is dense but every clause serves a purpose: purpose, use case, alternative, shaping warning, and parameter clarifications. It is front-loaded with the core breakdown, then practical guidance, and no filler words. The length is justified by the tool's complexity.

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?

Given the tool's complexity, the description covers the main output structure (three series), the shaped/truncated behavior, the most important parameter pitfalls, and the recommended alternative tool. Combined with the rich schema and annotations, this leaves no major contextual gap for agent selection or invocation.

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?

Even though schema coverage is 100%, the description adds meaningful parameter semantics: explains that omitting `from`/`to` defaults to the last 30 days, that a narrower window is the remedy for truncated symbols, and clarifies that `reporting` is a currency code, not a reporting period. These go beyond the schema descriptions.

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: 'Break one MT5 account down three ways over a date window' and enumerates the exact breakdown series (day-by-day P&L/volume/notional, per-symbol P&L/deal-count, hourly P&L). It further differentiates from the sibling tool get_account_performance by explicitly stating that is for a single whole-account figure.

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?

Provides explicit use cases ('which symbol is losing me money', 'what hour do I trade worst') and explicitly names the alternative tool for whole-account performance. It also gives practical guidance on date window omission and using a narrower window to reveal cut symbols.

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

list_accountsList linked MT5 accountsA

Read-only

List the MT5 trading accounts linked to the configured Senti Quant API key. Returns each account's id, login, broker, last known balance and equity, sync state, and running strategies. The id field is the accountId every other Senti endpoint takes — pass id, not login, when a tool asks for an account.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`accounts`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds transparency about what the tool returns (id, login, broker, balance, equity, sync state, strategies) and the critical id-vs-login distinction, going beyond annotation-only disclosure.

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?

Three sentences with no wasted words: the first states the action, the second enumerates return fields, and the third delivers essential integration guidance. It is front-loaded, compact, and every sentence earns its place.

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?

With zero parameters and an output schema available, the description fully covers what an agent needs: what accounts are included, what data is returned, and how the returned `id` connects to other tools. No gaps are apparent for the tool's intended read-only listing use case.

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?

The tool has zero parameters, so the baseline is 4 per the rubric. The description appropriately focuses on output semantics and the meaning of the returned `id` field instead, which is more valuable than parameter details in this case.

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: 'List the MT5 trading accounts linked to the configured Senti Quant API key.' It clearly defines the tool's scope and purpose, and the lack of sibling tools removes any differentiation concern.

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?

There are no explicit alternative tools to compare against, but the description gives practical usage context by explaining that the returned `id` field is the accountId required by every other Senti endpoint. This implicit guidance about when to use the tool and how to use its output earns above-average marks.

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

list_account_strategiesList strategies deployed on an accountA

Read-only

List the strategies (expert advisors) currently deployed on one MT5 account, with each deployment's symbol, timeframe and status. accountId is the id field from list_accounts — NOT login, which is the MT5 account number and is not a valid accountId. For the platform-wide catalog of strategies available to deploy, use list_strategies instead.

ParametersJSON Schema

Name	Required	Description	Default
`accountId`	Yes	The `id` field from list_accounts. Not the `login` (MT5 account number).

Output Schema

ParametersJSON Schema

Name	Required	Description
`strategies`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already provide readOnlyHint=true and openWorldHint=true, so the read-only nature is known. The description adds useful context about the returned data (symbol, timeframe, status) and the accountId caveat. No contradictions; missing only minor details like error behavior or pagination, which are less critical given the output schema exists.

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?

Three sentences, each delivering distinct value: purpose, accountId clarification, and alternative tool reference. No fluff or repetition, well front-loaded with the core function.

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?

Given the simple list tool, rich annotations, existing output schema, and exact parameter guidance, the description is fully complete. It covers purpose, usage, parameter caveats, and alternatives without needing to explain return values since an output schema is present.

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 coverage is 100% and the schema already documents accountId as the id field from list_accounts, not the MT5 login. The description reiterates this same information, adding no new meaning beyond the schema; thus baseline 3 is appropriate.

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 clearly states the tool lists strategies (expert advisors) deployed on one MT5 account, including symbol, timeframe, and status. It distinguishes this from the platform-wide catalog via the explicit reference to list_strategies, making sibling differentiation clear.

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?

The description provides explicit guidance on when to use this tool versus list_strategies, and clarifies the exact accountId format with a warning against using login. This gives the agent clear context and exclusion criteria for tool selection.

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

list_brokersList brokers available to linkA

Read-only

List the brokers Senti Quant supports, with each broker's MT5 server names and account types. This is the platform-wide catalog of what can be linked — it is NOT the set of accounts this API key already has, which is list_accounts. Use accountTypes[].id as brokerAccountTypeId and a servers[] value as server when linking a new account.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`brokers`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already indicate read-only and open-world behavior. The description adds meaningful context by explaining it is a catalog, not user-specific accounts, and shows how to consume the output for account linking. This goes beyond the annotations.

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 concise and well-structured: first states the main purpose, then clarifies scope, and finally gives practical usage guidance. Every sentence adds value without redundancy.

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?

With no parameters, an output schema, and clear annotations, the description fully addresses the tool's behavior and use. It explains what is returned and how to apply it, making it complete for an agent.

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?

There are no parameters, so the baseline per guidelines is 4. The description still implicitly covers the output usage, but since no parameters exist, no additional parameter semantics are needed.

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 clearly states the tool's function: listing supported brokers with their MT5 server names and account types. It also explicitly differentiates this from `list_accounts`, making the purpose unambiguous.

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?

It provides clear usage context: this is the platform-wide catalog for linking accounts, and explicitly contrasts with `list_accounts`. It also gives actionable guidance on using output fields (`accountTypes[].id` and `servers[]`) when linking a new account.

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

list_dealsList deal history for an accountA

Read-only

List the closed deal history of one MT5 account — the fills that already happened, newest first: symbol, direction, entry kind, volume, price, realized profit, costs and time. For what is open right now use list_positions, and for orders still resting use list_pending_orders. For totals and ratios over a period use get_account_performance rather than adding these rows up. accountId is the id field from list_accounts — NOT login. This endpoint is paginated: limit defaults to 50 and may not exceed 500, and one call returns exactly one page. If the answer reports that more deals are available, it also reports a cursor — you must call this tool again passing that value as cursor to read the next page. This tool never pages on its own. Narrow instead of paging where you can: entry takes lowercase in (opening) or out (closing), and from/to take ISO-8601 timestamps.

ParametersJSON Schema

Name	Required	Description
`to`	No	Window end (ISO-8601). Omit for no bound on this side.
`from`	No	Window start (ISO-8601). Omit for no bound on this side.
`entry`	No	Narrow to opening deals (`in`) or closing deals (`out`). Lowercase — the `entry` field in the response is uppercase and is not valid here. Omit for both.
`limit`	No	Deals per page, 1 to 500. Defaults to 50. One call returns one page; it is never a total.
`cursor`	No	The `nextCursor` from a previous call to this tool, to retrieve the page after it. Omit for the first page. Opaque — do not construct or edit one.
`accountId`	Yes	The `id` field from list_accounts. Not the `login` (MT5 account number).

Output Schema

ParametersJSON Schema

Name	Required	Description
`deals`	Yes
`nextCursor`	Yes
`syncedThrough`	Yes

TDQS

A5/5.0

Behavior5/5

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

Despite readOnlyHint and openWorldHint annotations, the description adds substantial behavioral context: pagination is manual ('never pages on its own'), exactly one page per call, cursor semantics, and limit defaults/ceiling. It also clarifies that the response reports availability of more deals via a cursor, and that entry is lowercase in the parameter unlike the response field. This goes well beyond annotation signals.

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?

Every sentence earns its place. The description starts with the core purpose, then moves to alternatives, pagination rules, and filter guidance. It is appropriately sized for a paginated, filterable tool with six parameters and a cursor, and the structure is logical and easy to scan.

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 is complex (pagination, cursor, multiple filters, sibling differentiation), but the description addresses all key behaviors: what is returned, how pagination works, how to narrow results, and which parameters to use. The existence of an output schema reduces the need to spell out return fields, and the description still lists the main deal attributes. It is fully complete for an agent to invoke correctly without guessing.

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 already covers all six parameters (100% coverage), but the description enriches each: accountId is explicitly tied to list_accounts.id 'not login', entry warns about lowercase vs uppercase response field, from/to require ISO-8601, limit is per-page not total, and cursor is opaque and must be reused. These clarifications prevent common misuse and are not present in the schema alone.

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 begins with a specific verb-resource-scope pair: 'List the closed deal history of one MT5 account — the fills that already happened, newest first' and enumerates the fields returned. It clearly distinguishes itself from sibling tools by naming list_positions and list_pending_orders for open/resting state and get_account_performance for aggregates.

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?

Explicit when-to-use vs alternatives: 'For what is open right now use list_positions, and for orders still resting use list_pending_orders. For totals and ratios over a period use get_account_performance rather than adding these rows up.' It also gives pagination guidance and filter-narrowing advice, so the agent knows exactly when to choose this tool and how to use it effectively.

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

list_draft_attachmentsRead a draft's indicator sourcesA

Read-only

Read the indicator source files a draft's EA embeds via #resource. draftId is the id field from list_drafts. Pass filename to read at most one attachment whole, by exact name — that is also how to read one the default call had to leave out. Filenames are not guaranteed unique within a draft: if more than one attachment shares the requested name, only the first is returned and notes says how many were skipped. With filename omitted this returns every attachment's source up to a 64 KiB budget and lists the rest by name and size only; notes says whether that happened. THE RESPONSE CAN BE LARGE — up to 64 KiB of source, returned in both content and structuredContent — roughly 33,000 tokens worst case. Use get_draft for the EA's own source, which this tool never returns.

ParametersJSON Schema

Name	Required	Description	Default
`draftId`	Yes
`filename`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	Yes
`attachments`	Yes

TDQS

A5/5.0

Behavior5/5

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

Annotations cover readOnlyHint and openWorldHint, but the description adds crucial behavioral details: the 64 KiB budget, the response size warning (~33k tokens), handling of duplicate filenames (first only, notes skipped count), and the note about truncation. This goes well beyond annotations and is fully transparent.

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?

While long, every sentence serves a purpose: main function, parameter behavior, edge cases, size warning, and alias. Information is front-loaded and logically ordered, with the critical warning in caps. Efficient and well-structured.

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 description fully covers all invocation scenarios (with and without filename), duplicates, budget limits, and what the tool does not return. An output schema exists, so no need to detail return fields. Nothing essential is missing for correct invocation.

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 coverage is 0%, so the description bears full responsibility. It explains draftId as the id from list_drafts and filename as an exact-name filter with clear semantics (including the omission case). This adds meaning that the schema lacks entirely.

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 clearly states the verb (read) and resource (indicator source files a draft's EA embeds via #resource), and explicitly contrasts with get_draft. It distinguishes itself from siblings without ambiguity.

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?

The description explicitly explains when to pass filename (to read one attachment whole by exact name) and when to omit it (to get all sources up to a budget), and directs users to get_draft for the EA's own source. It also clarifies how to handle non-unique filenames.

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

list_draftsList MQL5 authoring draftsA

Read-only

List the MQL5 drafts this API key owns, most recently updated first, with each draft's compile status, size, attachment count and registered-EA id. Use it to find a draftId, or to answer "what am I working on" and "which of my drafts are broken". THIS RESPONSE IS SHAPED: source code, compiler logs and diagnostics are ALL dropped — the endpoint can return over 10 MB otherwise — and what was cut is listed in notes. Call get_draft for one draft's source and compiler output, or list_draft_attachments for its indicator sources. There is no option to request the unshaped response.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	Yes
`drafts`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations provide readOnlyHint and openWorldHint, but the description goes further by disclosing that source code, compiler logs, and diagnostics are dropped to avoid >10MB responses, that the cut content is listed in `notes`, and that there is no option to request the unshaped response. This is essential behavioral context beyond the annotations.

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 succinct yet information-dense. It front-loads the core purpose, then use cases, then the critical shaping caveat, all in four sentences. No filler or redundancy; every sentence earns its place.

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?

With an output schema present, the description need not repeat return types, but it adds critical context about dropped fields and size limits that the schema cannot convey. It also covers usage scenarios, ordering, and alternatives, making it complete for an agent to correctly select and invoke this tool.

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?

There are zero parameters, so baseline is 4 per rubric. The description doesn't need to explain parameters, but it effectively communicates the response shape and its implications. Since the schema has no properties to describe, the description adds value by clarifying output details, which is more relevant to contextual completeness.

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 clearly states the verb (List), the resource (MQL5 drafts), and ownership scope (this API key owns). It also specifies ordering (most recently updated first) and the fields included. It differentiates from siblings by naming get_draft and list_draft_attachments as alternatives for specific needs.

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 tells the agent when to use this tool: to find a draftId, answer 'what am I working on', or identify broken drafts. It also points to sibling tools (get_draft, list_draft_attachments) for source/attachment retrieval, giving clear when-to-use vs. when-not-to-use guidance.

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

list_pending_ordersList pending orders on an accountA

Read-only

List the pending limit and stop orders resting on one MT5 account, read live from the terminal: symbol, order type, volume, trigger price, stop loss and take profit. These are orders that have NOT been filled — for filled positions currently open, use list_positions. accountId is the id field from list_accounts, NOT login. Each order's ticket is the handle used to cancel it. An sl, tp or priceStopLimit of 0 means that level is not set.

ParametersJSON Schema

Name	Required	Description	Default
`accountId`	Yes	The `id` field from list_accounts. Not the `login` (MT5 account number).

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	Yes
`orders`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds valuable behavioral context: reads live from the terminal, zero-valued sl/tp/priceStopLimit meaning not set, and ticket being the cancellation handle. This goes beyond annotations without contradicting them.

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?

Three sentences, each earning its place: core purpose, live-read clarification, unfilled-vs-filled distinction and alternative, parameter guidance, and zero-value semantics. No redundant or filler content.

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?

Given the simple one-parameter tool, presence of an output schema, and thorough annotations, the description covers all necessary context: purpose, usage, edge cases (zero values), and cross-reference to list_positions. Nothing missing.

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?

The schema covers 100% of parameters and already explains accountId as the id field from list_accounts and not login. The description repeats this guidance, providing no additional meaning beyond the schema. Baseline 3 is appropriate for full schema coverage.

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 clearly states the tool lists pending limit and stop orders on one MT5 account, with a specific verb ('List') and resource ('pending limit and stop orders'). It distinguishes from related tools by explicitly noting these are unfilled orders, unlike list_positions for open positions.

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?

Provides clear when-to-use context: it explains that the tool reads live pending orders and explicitly offers an alternative, 'use list_positions' for filled positions. Also clarifies the correct accountId parameter and how to interpret ticket for cancellation.

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

list_positionsList open positions on an accountA

Read-only

List the positions currently open on one MT5 account, read live from the terminal: symbol, direction, volume, open and current price, stop loss, take profit, swap and floating profit. accountId is the id field from list_accounts — NOT login. Each position's ticket is the handle used to close it. An sl or tp of 0 means no stop loss or take profit is set.

ParametersJSON Schema

Name	Required	Description	Default
`accountId`	Yes	The `id` field from list_accounts. Not the `login` (MT5 account number).

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	Yes
`positions`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate read-only and open-world hints. The description adds valuable behavioral context: data is read live, sl/tp of 0 means no stop/take profit, and ticket is the handle for closing. This goes beyond the structured annotations.

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 concise and well-structured: the first sentence states the core purpose, the second clarifies the parameter, the third explains edge cases of sl/tp. Every sentence adds value with no redundancy.

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?

Given the tool's simplicity (one parameter, output schema present), the description fully covers the needed context: what data is returned, how to identify the account, how to use the ticket, and edge cases like sl/tp = 0. Nothing essential is missing.

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 coverage is 100% and the schema description already explains that accountId is the id from list_accounts, not login. The tool description repeats this, adding no new parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

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 clearly states the tool lists open positions on one MT5 account, with a specific verb and resource. It distinguishes from sibling tools like list_pending_orders and list_deals by focusing on positions, and adds scope details ('read live from the terminal').

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 provides a clear prerequisite: accountId must be the id from list_accounts, not login. It implies when to use the tool (to see open positions) and how to use the output (ticket for closing). However, it does not explicitly mention alternatives or when not to use it.

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

list_strategiesList deployable strategiesA

Read-only

List every strategy (expert advisor) available to deploy on Senti Quant, with its supported symbols, timeframes, rating and presets. This is the platform-wide catalog of what COULD be deployed — it is NOT what is currently running on an account. For the strategies running on a specific account, use list_account_strategies. Use id as eaDefinitionId when deploying.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`strategies`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description adds key behavioral context: this is the global catalog of what COULD be deployed, not what is account-specific. It also clarifies the meaning of the returned `id` with a deployment instruction, preventing misinterpretation.

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 composed of two sentences, each serving a distinct purpose: stating the main action, then providing caveat and alternative, then a deployment tip. It is front-loaded and every sentence earns its place.

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?

With no parameters, an output schema present, and annotations confirming safe read-only behavior, the description fully covers the tool's purpose, scope, and usage context. It even includes a helpful cross-reference and usage tip, making it complete for the tool's complexity.

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?

The tool has zero parameters, so the schema fully covers them (vacuously). The description does not need to explain parameters, and the baseline for 0 params is 4. No additional parameter semantics are required.

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 clearly states the verb 'List' and the resource 'every strategy (expert advisor) available to deploy on Senti Quant', with specific attributes (symbols, timeframes, rating, presets). It explicitly distinguishes from the sibling tool list_account_strategies, making the purpose unambiguous.

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?

The description explicitly tells when to use this tool (platform-wide catalog of deployable strategies) and when not to (not currently running on an account), and names the alternative list_account_strategies. It also provides a concrete usage hint: 'Use `id` as `eaDefinitionId` when deploying.'

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

Every tool maps to a distinct resource and view: drafts vs attachments vs conventions, accounts vs brokers vs strategies, positions vs pending orders vs deals, and the three performance tools are explicitly differentiated (single summary vs breakdowns vs equity curve). The descriptions repeatedly cross-reference alternatives, so an agent should not confuse any two tools.

Naming Consistency5/5

All fourteen tools use a consistent snake_case verb_noun pattern, with list_ for collection queries and get_ for single-item or summary queries. Compound resource names like list_draft_attachments and list_account_strategies follow the same predictable construction.

Tool Count5/5

Fourteen tools sits comfortably within the ideal 3–15 range and matches the server's two clear domains: MQL5 draft authoring and MT5 account inspection. Each tool has a unique purpose and none feel redundant.

Completeness3/5

The read side is thorough: conventions, drafts, attachments, accounts, brokers, strategies, positions, orders, deals, and three performance views are all covered. However, the surface is entirely read-only — there are no create/update/delete tools for drafts, no close/cancel tools for positions or orders, and no account-linking or strategy-deployment tools, even though descriptions reference those actions. This creates dead ends for any workflow that needs to act on the platform rather than merely observe it.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
openmm-mcp A
io.github.QBT-Labs
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Finance
1513
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42

Related MCP Servers

Deriv API MCP Server
Finance API Testing Autonomous Agents
raju-deriv
F
license
D
quality
D
maintenance
A Model Context Protocol server that enables AI assistants to interact with the Deriv trading API, providing access to active trading symbols and account balance information.
Updated 2 years ago (2025-01-07 09:21 UTC)
2
ctrader-mcp-server
Finance Research & Data
akinabudu
F
license
Not graded
quality
F
maintenance
A standalone Model Context Protocol (MCP) server that enables AI assistants to interact with the cTrader trading platform.
Updated a year ago (2025-10-10 23:29 UTC)
14
hyperliquid-mcp
Blockchain Cryptocurrency Finance
midodimori
A
license
Not graded
quality
C
maintenance
A Model Context Protocol (MCP) server for the Hyperliquid decentralized exchange, enabling AI assistants to perform trading operations, manage accounts, and retrieve market data.
Updated 7 months ago (2026-02-16 06:11 UTC)
3
MIT
MetaTrader 5 MCP Server
Finance
Qoyyuum
F
license
Not graded
quality
A
maintenance
Enables AI assistants to connect to MetaTrader 5 for trading, market data access, and account management through the Model Context Protocol.
Updated 10 days ago (2026-08-24 06:24 UTC)
213

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Koniverse/Senti-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server