senti-mcp-server

List deal history for an account

list_deals

Read-only

Retrieve closed deal history for an MT5 account, newest first. Filter by opening/closing entry or time range; paginate with cursor.

Instructions

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.

Input Schema

TableJSON 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

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv2.9.0Sep 16, 2026
- removedOutput schema / properties / nextCursor / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / nextCursor / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / syncedThrough / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / syncedThrough / type
```
Added value: +[
+  "string",
+  "null"
+]
```
Addedv1.2.0Aug 11, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=true, already conveying safety and variability. The description adds valuable behavioral detail: endpoint is paginated, limit defaults to 50/max 500, one call returns one page, tool never pages on its own, cursor semantics, and case sensitivity for entry. It does not go into rate limits or error scenarios, but given annotation coverage, the description adds substantial non-redundant context.

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 about 150 words, well-structured: purpose first, then sibling routing, then accountId note, then pagination, then narrowing advice. Every sentence adds functional value; there is no fluff. The most critical info (what it does and when to use it) is front-loaded.

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 (6 params, pagination, output schema exists), the description covers: what it returns, how to navigate pagination, how to narrow results, and how to identify the account correctly. It also directs users to appropriate alternatives. Output schema is present so return structure is not needed in the description. This is a complete and self-sufficient definition 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?

Schema coverage is 100% — every parameter already has a description. The tool description reinforces and contextualizes: clarifies accountId is the id from list_accounts not login (though schema says the same), adds the 'one call returns exactly one page' nuance for limit, explains cursor as nextCursor from a previous call, and emphasizes lowercase for entry. This goes beyond mere repetition by tying parameters to the pagination behavior, though some of it mirrors schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('closed deal history of one MT5 account'), enumerates the fields returned (symbol, direction, entry kind, volume, price, realized profit, costs, time), and explicitly distinguishes from siblings list_positions, list_pending_orders, and get_account_performance. An agent can immediately grasp what this does and how it differs.

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 names alternatives and when to use them: '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.' Also provides clear guidance on pagination (must call again with cursor) and advises narrowing (via entry and from/to) instead of paging. This is textbook usage guidance.

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

Deploy Server