Spaces

Get usage and limits

get_messaging_usage

Read-onlyIdempotent

Sends and new chats per account against the ceilings. Spaces reduces ban risk with per-action limits, warm-up and pacing. A limit on one action does not use up reading conversations. It cannot guarantee the platform will not restrict the account. Do not work around a limit. On 429, wait retry_after for that action and retry with the same idempotency key. If the account needs a sign-in or a security check, stop. Check get_messaging_usage (GET /v1/messaging/usage) before bulk work. Every answer carries account_budget: wait next_check_after_seconds before checking for new messages again, and never poll faster. Replies to people who wrote in go out from the first day, paced and with their own generous daily and hourly caps (replies_left_today); they never use up the room for new messages. On WhatsApp, new chats wait up to 24 hours after connecting or reconnecting; replies in existing chats still go out.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_messaging_usage"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.6/5.0

Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses crucial operational behavior: 429 handling with retry_after and the same idempotency key, stopping on sign-in or security checks, the account_budget polling field with next_check_after_seconds, and WhatsApp's 24-hour wait for new chats. These details materially help an agent avoid misuse.

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

Conciseness2/5

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

The description is long and rambling, with the core purpose buried in a fragment. Several sentences cover platform policy tangents rather than directly explaining the tool, and the structure is not front-loaded.

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?

For a zero-parameter, read-only usage tool with no output schema, the description supplies enough to understand return-relevant behavior (account_budget, next_check_after_seconds) and error handling. It could be clearer on the exact shape of the usage answer, but it is largely 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?

The tool takes zero parameters, so the baseline is 4. There is no parameter meaning to add, and the description does not need to compensate for schema gaps.

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

Purpose3/5

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

The phrase "Sends and new chats per account against the ceilings" conveys that this retrieves messaging usage limits, but it is a sentence fragment buried after warnings. It does not clearly distinguish this tool from siblings like get_account_limits or export_messaging_usage, leaving the agent to infer which limit view to use.

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 explicitly says to "Check get_messaging_usage ... before bulk work" and warns "Do not work around a limit," which gives a clear when-to-use. However, it names no alternative tools and provides no when-not-to-use conditions or explicit routing against siblings, so the guidance is partial.

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

All Spaces 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?