Dynamoi

Get Distribution Earnings

dynamoi_get_earnings

Read-only

Read distribution earnings for the authenticated payee only, optionally restricted to their artistIds. Team or artist access never grants payee access. action=overview returns the payee's own share in USD, range totals, monthly totals and at most 50 detail rows, narrowed by trackKey, storeKey, storeFamily and countryCode (totals remain for the whole range). action=ranking returns up to 300 rows by dimension (track, artist, store, country), with their filtered totalUsd, narrowed by trackKey, storeFamily and countryCode. action=geography returns {rows} of the country map with optional prior-window comparison. action=statement returns the aggregate monthly statement for one statement month: use axis=statement and equal fromMonth/toMonth, with no exploration filters or cursor. No new files are created. The detailed CSV is a bulk file download; the human downloads it on web at https://dynamoi.com/dashboard/user/royalties. Rankings and prior-window geography read an equal preceding window within the owner's 60-month bound. For overview pagination, pass nextCursor unchanged to continue with the same range, axis, artists and filters. fromMonth/toMonth are inclusive YYYY-MM, at most 60 months. axis=statement groups by statement month; earned groups by royalty month, while payee share always follows statement month. Nullable amounts or counts mean unavailable; an explicit 0 is measured zero. Empty rows mean no matching data; an error means unavailable, never zero earnings. This grants no payout or tax authority and performs no writes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "fromMonth": "<fromMonth>",
      "toMonth": "<toMonth>"
    },
    "name": "dynamoi_get_earnings"
  }
}

Input Schema

Name	Required	Default
`axis`	No	statement
`limit`	No
`action`	No	overview
`cursor`	No
`toMonth`	Yes
`storeKey`	No
`trackKey`	No
`artistIds`	No
`dimension`	No	track
`fromMonth`	Yes
`withPrior`	No
`countryCode`	No
`storeFamily`	No

Output Schema

Name	Required	Description	Default
`code`	No
`data`	No
`kind`	No
`field`	No
`status`	Yes
`draftId`	No
`message`	No
`retryable`	No
`nextAction`	No
`failureStage`	No
`prerequisite`	No
`screeningResult`	No
`retryAfterSeconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnly/non-destructive/closed-world; the description goes well beyond by stating no new files are created, no payout or tax authority is granted, and no writes occur. It also discloses the 60-month bound, that ranking and prior-window geography read an equal preceding window, and how errors versus empty rows versus explicit zeros should be interpreted.

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?

Purpose and access scope are front-loaded, then actions in sequence, then semantics and guardrails — a logical order with little filler. It is a dense wall of prose for a 13-parameter tool, and bullet-per-action formatting would improve scanability without adding length.

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 four action modes, 13 parameters, a nested cursor object and an output schema, the description covers everything an agent needs to choose an action and call it correctly, including pagination continuation and the null-versus-zero-versus-error distinction. It explains return shapes even though the output schema exists, which is redundant but harmless.

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 0% across 13 parameters, so the description carries the burden, and it largely does: action, axis, fromMonth/toMonth as inclusive YYYY-MM capped at 60 months, artistIds, the filter keys per action (trackKey, storeKey, storeFamily, countryCode), withPrior, dimension values and cursor reuse are all explained. Gaps remain for limit (1-300 default) and the cursor object's constituent fields, which are only vaguely covered by 'pass nextCursor unchanged'.

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?

Opens with a specific verb+resource+scope: read distribution earnings for the authenticated payee only, with artistIds as an optional restriction. It immediately draws the boundary that team/artist access never grants payee access, which distinguishes it from sibling reporting tools like dynamoi_get_artist_analytics and dynamoi_get_billing.

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?

Each action value is routed explicitly: overview for the payee's own share plus range/monthly totals, ranking for up to 300 dimension rows, geography for the country map, statement for the aggregate monthly statement with axis=statement and equal fromMonth/toMonth. It also states exclusions (no exploration filters or cursor for statement) and points bulk CSV download to the web dashboard instead of this tool.

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

All Dynamoi tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.