Boardroom Revenue Control

Voice calls

voice_calls

Read-onlyIdempotent

Calls with direction, disposition and talk time. Customer numbers masked. [scope: crm:read]

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum number of rows to return.
`since`	No	today \| week \| month \| 7d \| ISO timestamp (Asia/Dubai days).

Output Schema

Name	Required	Description
`ok`	No	False when the call was refused or failed; see error.
`error`	No	Machine-readable refusal code (a string), present only when ok is false.
`message`	No	Human-readable explanation of a refusal (a string).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 9, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "error": {
+      "description": "Machine-readable refusal code (a string), present only when ok is false."
+    },
+    "message": {
+      "description": "Human-readable explanation of a refusal (a string)."
+    },
+    "ok": {
+      "description": "False when the call was refused or failed; see error.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedOct 9, 2026
- addedInput schema / properties / limit / description
```
Added value: +"Maximum number of rows to return."
```
First observedOct 9, 2026

TDQS

B3.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds value beyond the schema by disclosing that customer numbers are masked in the output and that the call requires the crm:read scope — both real behavioral facts an agent can't get from annotations alone. It stops short of describing pagination/truncation behavior at the 200-row cap.

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?

Three short fragments, front-loaded with the returned dimensions and no filler. It is efficient, though the terseness borders on under-specification since no sentence states the operation itself.

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

Completeness3/5

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

An output schema exists, so return values needn't be spelled out, and the masking and scope notes cover the non-obvious behavior. What is still missing for reliable invocation is a clear statement of what the tool does (list recent calls?) and whether results are ordered or windowed by the since parameter.

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%: 'limit' documents the row cap and 'since' documents the accepted values (today | week | month | 7d | ISO timestamp in Asia/Dubai days). The description contributes nothing about either parameter, so the baseline of 3 for fully documented schemas applies.

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 description lists returned fields (direction, disposition, talk time) rather than stating the operation — there is no verb such as 'list' or 'retrieve', so an agent must infer that this returns voice call records. The noun 'calls' plus the field list gives a workable sense of the resource, but it never distinguishes itself from siblings like agent_conversations or crm_list_leads.

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

Usage Guidelines2/5

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

No when-to-use guidance at all: nothing says this is the right tool for pulling voice-call metrics versus agent_conversations or the crm_* tools. The only implicit signal is the crm:read scope tag, which hints at the domain but not the selection criteria.

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

All Boardroom Revenue Control 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.