Skip to main content
Glama
Sign In

Convocore

by app.convocore.mcp
OverviewDiscussionsAdmin

usage_read

Read-onlyIdempotent

Read usage, credits and activity — everything the dashboard Usage and Analytics pages show — for the whole workspace and per agent. Read only. Time range: days back from now (default 30, max 400) or an explicit from / to (ISO date like 2026-10-01, or a full ISO datetime). overview: ONE call with credit balance, plan quota and limits, credits consumed in the range, tokens per model, the top agents (with names) and total activity (conversations, messages, calls, call minutes) — start here for "how is my usage". top_agents: agents ranked by credits consumed, with share of the total (topN up to 15). credits: current credit balance. quota: plan limits and current usage (conversations, messages, agents, KB…). workspace_usage: the Usage page — creditsCharged and creditsConsumed, input/output tokens per model, credits per agent with per-agent models, plus the chart list; add includeCharts for the chart data and includeLogs or logsPage for the credit usage log (what charged how much, and why). agent_usage (agentId): credits and tokens per model for one agent, plus call minutes. agent_analytics (agentId): that agent's analytics — loads, conversations, metrics, token usage, containment and human-handover stats. agents_analytics: activity totals for all agents (or agentIds), and per agent with includePerAgent (default true). clients_analytics: agency only — usage, leads and funnel per whitelabel client and per agent (clientIds to narrow). email_analytics (agentId): email channel analytics for one agent. WhatsApp and SMS analytics are in whatsapp_numbers_read / sms_numbers_read, voice calls in call_logs_read, knowledge-base quota in get_kb_quota.

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": {
      "action": "<action>"
    },
    "name": "usage_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoRange end: ISO date (2026-10-31 = end of that UTC day) or datetime. Default now.
daysNoLook back this many days from now (1-400, default 30). Ignored when from is set.
fromNoRange start: ISO date (2026-10-01 = start of that UTC day) or datetime.
modeNocompact (default) = long text is cut and bulky blobs are replaced by a size marker. full = complete response.
topNNoFor overview / top_agents: how many top agents to return (1-15; default 8 for overview, 15 for top_agents).
actionYes
agentIdNoFor agent_usage / agent_analytics / email_analytics: the agent (list_agents or search_agents).
agentIdsNoFor agents_analytics: only these agents (max 500). Default all agents in the workspace.
logsPageNoFor workspace_usage: usage log page number (implies includeLogs).
clientIdsNoFor clients_analytics: only these whitelabel clients (clients_read list).
includeLogsNoFor workspace_usage: include the credit usage log (first page).
includeChartsNoFor workspace_usage: include the chart data (credits over time, usage by feature / agent, tokens).
includePerAgentNoFor agents_analytics: also return one row per agent (default true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/destructive, so the marginal bar is lower; the description still adds time-range defaults and caps (default 30, max 400 days), agency-only scoping for clients_analytics, and per-agent limits. It does not describe the compact/full truncation behaviour, the most consequential non-obvious behavior, leaving that to the schema.

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?

Front-loaded with the core statement and the "start here" routing, then a dense action-by-action enumeration where each clause carries distinct information. It is a single long paragraph rather than a scannable list, which makes it harder to parse for ten actions, but there is little filler.

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?

With ten actions, thirteen parameters and no output schema, the description must explain return payloads itself — and it does per action (credit balance, tokens per model, containment/handover stats, funnel per client). Nothing an agent needs to choose an action and call it correctly is missing.

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 92% so the baseline is 3; the description goes further by binding parameters to action branches — agentId for agent_usage/agent_analytics/email_analytics, clientIds to narrow clients_analytics, includePerAgent for agents_analytics, includeCharts/includeLogs for workspace_usage. This action-to-parameter mapping is genuine value the flat schema doesn't express.

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+resource ("Read usage, credits and activity") and then enumerates all ten actions with what each returns. It explicitly differentiates itself from siblings by naming where other channel analytics live (whatsapp_numbers_read, sms_numbers_read, call_logs_read, get_kb_quota).

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?

Gives explicit routing: "start here for 'how is my usage'" points to overview as the default entry, and the closing sentence redirects channel-specific analytics to specific sibling tools. Each action line implicitly says when to pick it (credits = balance, quota = limits, top_agents = ranking).

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

All Convocore toolsInspect
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