MyDataHub

Account and balance

get_account

Read-onlyIdempotent

Returns the organisation's credit balance by source, plan, per-action prices and rate limit, and for an agent key its monthly budget and per-order cap. Use it before quoting a large order, or when a spend is refused, to see what remains. Free; it needs a token with account:read. Top-ups happen on mydatahub.emailmovers.com, never inside a tool. Lawful basis is UK GDPR Article 6(1)(f) legitimate interests; email audiences include corporate subscribers only by default (PECR), so sole traders and ordinary partnerships are left out unless the toggle is changed.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`key`	Yes	The calling key and, for an agent key, its budget; null for a person.
`demo`	Yes	A demo organisation: everything runs in test mode, nothing is charged, order records are invented, and it stops working at expires_at. null for a real account.
`mode`	Yes	live keys (mdh_live_) spend real credits; test keys (mdh_test_) return synthetic data and never charge.
`plan`	Yes
`user`	Yes	The signed-in person; null when the caller is an API key.
`prices`	Yes	What each action costs in credits.
`balance`	Yes	Credits by source.
`agreements`	Yes	The Terms of Sale (accepted at sign-up; accepted: null for an organisation Emailmovers set up), the Data Licence and Sharing Agreement (the licence: accepted with every order, or with an agent key that orders on its own) and the Article 28 DPA (accepted with the first suppression list).
`rate_limit`	Yes
`organisation`	Yes
`gbp_per_credit`	Yes	Your plan's price per credit, excluding VAT.
`account_manager`	Yes	The named person behind Talk to us.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 9, 2026

addedOutput schema / $defs / Agreement / properties / accepted_version

Added value: +{
+  "description": "The latest version accepted, accepted.version; null when none was.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / $defs / Agreement / properties / in_force

Added value: +{
+  "description": "Whether the version accepted is the version in force. false when none was accepted, or an older one.",
+  "type": "boolean"
+}

changedOutput schema / $defs / Agreement / required

Previous value: -[
-  "name",
-  "version",
-  "url",
-  "accepted"
-]New value: +[
+  "name",
+  "version",
+  "url",
+  "accepted",
+  "accepted_version",
+  "in_force"
+]

changedOutput schema / properties / agreements / description

Previous value: -"The Data Licence and Sharing Agreement (accepted with every order, or with an agent key that orders on its own) and the Article 28 DPA (accepted with the first suppression list)."New value: +"The Terms of Sale (accepted at sign-up; accepted: null for an organisation Emailmovers set up), the Data Licence and Sharing Agreement (the licence: accepted with every order, or with an agent key that orders on its own) and the Article 28 DPA (accepted with the first suppression list)."

addedOutput schema / properties / agreements / properties / terms
```
Added value: +{
+  "$ref": "#/$defs/Agreement"
+}
```

changedOutput schema / properties / agreements / required

Previous value: -[
-  "dlsa",
-  "dpa"
-]New value: +[
+  "terms",
+  "dlsa",
+  "dpa"
+]

addedOutput schema / properties / demo

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "expires_at": {
+          "format": "date-time",
+          "type": "string"
+        }
+      },
+      "required": [
+        "expires_at"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "A demo organisation: everything runs in test mode, nothing is charged, order records are invented, and it stops working at expires_at. null for a real account."
+}

changedOutput schema / required

Previous value: -[
-  "organisation",
-  "user",
-  "mode",
-  "plan",
-  "balance",
-  "prices",
-  "gbp_per_credit",
-  "rate_limit",
-  "key",
-  "account_manager",
-  "agreements"
-]New value: +[
+  "organisation",
+  "user",
+  "mode",
+  "demo",
+  "plan",
+  "balance",
+  "prices",
+  "gbp_per_credit",
+  "rate_limit",
+  "key",
+  "account_manager",
+  "agreements"
+]

First observedNov 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

The annotations already establish read-only, idempotent, non-destructive behavior, and the description adds useful context beyond them: the call is free, requires a token with account:read, and top-ups cannot be performed inside a tool. These are real operational facts, not restatements, though nothing is said about response shape or freshness of the balance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first three sentences are tightly front-loaded and earn their place, covering purpose, usage and auth. The final sentence on UK GDPR Article 6(1)(f) legitimate interests and PECR treatment of sole traders is unrelated to invoking the tool and dilutes an otherwise efficient description.

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 an output schema present and no parameters, the description need only cover access and semantics, and it does: auth scope, cost, where top-ups happen, and when to consult the result. The compliance paragraph adds bulk without improving the agent's ability to call the tool correctly.

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 takes zero parameters, so the baseline is 4 and there is nothing for the description to explain. It correctly does not waste words on arguments, instead spending them on what the parameterless call yields.

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?

The description opens with a specific verb and resource and enumerates exactly what is returned: credit balance by source, plan, per-action prices, rate limit, and for agent keys the monthly budget and per-order cap. It is clear what the tool does, though it does not distinguish itself from the sibling get_credits, leaving the agent to infer the difference.

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?

It gives concrete usage contexts: before quoting a large order, or when a spend is refused, to see what remains. That is actionable guidance rather than vague context. It stops short of naming an alternative tool or stating when not to call it, so it is not a full 5.

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

All MyDataHub 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.

Resources

Need Help?