Skip to main content
Glama
slemos

eToro MCP Server

by slemos

Get eToro account PnL

etoro_get_pnl
Read-onlyIdempotent

Unrealized profit/loss of the demo account: the total, and for each position its profit/loss, exposure, margin and current rate.

Instructions

Unrealized profit/loss of the demo account: the total, and for each position its profit/loss, exposure, margin and current rate. Same views and paging as etoro_get_portfolio_breakdown; the default view is compact and copied traders' positions are in the 'mirror' view.

Input Schema

NameRequiredDescriptionDefault
viewNosummary: compact own positions plus a summary of each copied trader (no copied positions). mirror: the positions of one copied trader (needs mirrorId). raw: eToro's full JSON (very large with copy trading; arrays are shortened to fit).summary
limitNoPositions per page.
offsetNoPositions to skip, for paging.
mirrorIdNoCopy-trading relationship to open when view is 'mirror'. Listed in the summary view.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.10.0
    • addedInput schema / properties / limit
      Added value: +{
      +  "default": 50,
      +  "description": "Positions per page.",
      +  "maximum": 200,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / mirrorId
      Added value: +{
      +  "description": "Copy-trading relationship to open when view is 'mirror'. Listed in the summary view.",
      +  "exclusiveMinimum": 0,
      +  "maximum": 9007199254740991,
      +  "type": "integer"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Positions to skip, for paging.",
      +  "maximum": 9007199254740991,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / view
      Added value: +{
      +  "default": "summary",
      +  "description": "summary: compact own positions plus a summary of each copied trader (no copied positions). mirror: the positions of one copied trader (needs mirrorId). raw: eToro's full JSON (very large with copy trading; arrays are shortened to fit).",
      +  "enum": [
      +    "summary",
      +    "mirror",
      +    "raw"
      +  ],
      +  "type": "string"
      +}
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new traits beyond that: the data is specifically the demo account, the default view is compact, mirror data lives in a separate view, and results are paged like the portfolio breakdown.

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?

Two sentences, zero waste. The returned-data scope is front-loaded, and the second sentence efficiently bundles view defaults, the mirror-view caveat and the paging analogy in one clause.

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

Completeness4/5

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

With no output schema, the description carries the return-value burden and does state the shape (account total plus per-position fields) and paging. Only minor gaps remain, e.g. whether this covers real as well as demo accounts and any freshness or rate-limit notes.

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 description coverage is 100%, so the schema already documents view, limit, offset and mirrorId in more detail than the description does (including the raw view sizing warning). The description's view/paging remarks largely restate schema content, so the baseline 3 applies.

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

Purpose4/5

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

It names a specific resource (unrealized PnL) and enumerates the per-position fields returned (profit/loss, exposure, margin, current rate), plus the account scope (demo). It references etoro_get_portfolio_breakdown only to borrow its view/paging semantics, so it never explicitly separates its purpose from that sibling's.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It explains which view to pick for copied-trader data ('copied traders' positions are in the mirror view') and notes the compact default, which is real routing guidance. But it gives no explicit when-to-use/when-not-to-use versus etoro_get_portfolio_breakdown or etoro_get_portfolio, leaving the choice to inference.

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