The Pexip Infinity MCP Server connects to Pexip Infinity's Management API to provide ~122 tools for managing and operating a Pexip Infinity video conferencing deployment. By default, mutating tools are disabled (read-only) until explicitly enabled.
Configuration Management Create, read, update, and delete VMRs, aliases, automatic participants, devices, end users, gateway rules, IVR themes, LDAP sources, locations, conferencing nodes, and ~70 additional resource types (SIP/H.323 proxies, TURN/STUN, Teams Connectors, Azure tenants, certificates, admin roles, backups, policy profiles, and more) via generic CRUD tools.
Live Status Monitoring Access real-time data including active conferences and participants (with call quality metrics, mute/role filters), system alarms, node load/sync/version, licensing (port usage vs. entitlement), inter-node backplane connections, registered endpoints/aliases, cloud overflow status, Exchange scheduler, MJX (One-Touch Join) endpoints and meetings, and Teams Connector node/call status.
Historical Data (CDRs)
Query completed conferences and participant call legs with filters (time range, protocol, quality, disconnect reason, direction). Retrieve per-participant quality forensics and use the summarize_calls tool to aggregate metrics grouped by direction, quality, protocol, location, or disconnect reason.
Alarm & Event History Browse past alarms, backplane connections, registration events, and node status change events.
Command & Control (requires enabling write mode) Dial, disconnect, mute/unmute participants (individual or all guests), lock/unlock conferences, change layouts, set roles, transfer calls, send messages, trigger LDAP sync, send provisioning emails, manage backups (create/restore), import certificates, take snapshots, and upgrade the platform.
Schema Introspection Fetch live JSON schemas for any Pexip configuration resource to discover available fields, types, required parameters, and allowed enum values.
Manages Google Meet tokens within Pexip Infinity, enabling configuration of Google Meet integration for video conferencing.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Pexip Infinity MCP Server List all active conferences"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server for the Pexip Infinity Management API. It gives an LLM-based agent everything it needs to manage and operate a Pexip Infinity deployment, exposing 122 curated tools and covering all four admin API categories: Configuration, Status, History, and Command.
Disclaimer: This is an independent, community-built project. It is not affiliated with, endorsed by, or sponsored by Pexip. It uses Pexip's public Management API and sends no telemetry or analytics. The server needs no external network access beyond the Pexip Management Node you configure, plus your own identity provider if you choose to use OIDC. It never sends your data anywhere else.
You'll need your Pexip Management Node hostname plus credentials. OAuth2 is recommended for production; basic auth (admin username + password) is recommended only for dev/lab environments. See Configuration to set up an OAuth2 client.
The server starts read-only by default: it can list and report, but every create / update / delete / control tool is removed from the catalog until you explicitly enable writes. Connect first, confirm it works, then decide.
The simplest path: no terminal, no JSON.
Download the .mcpb bundle for your OS (macOS or Windows) from the
latest release.
Double-click it. Claude Desktop opens an install dialog showing the server and the permissions it requests.
Fill in the form with your Management Node host and either an OAuth2 client (recommended) or an admin username + password (dev/lab only). Leave read-only on. Click install.
Try it. Ask Claude: "List the VMRs on my Pexip node" or "Show me the Pexip system status."
To enable writes later, edit the server in Claude Desktop's settings and turn read-only off.
For Claude Code, Cursor, or any MCP host that takes a JSON server config.
1. Install the server (needs Python 3.11+):
git clone https://github.com/Josh-E-S/pexip-mgmt-mcp.git
cd pexip-mgmt-mcp
pipx install . # installs the `pexip-mgmt-mcp` command on your PATH2. Add it to your MCP host by pointing its config at the pexip-mgmt-mcp
command. Use OAuth2 for production:
{
"mcpServers": {
"pexip-mgmt": {
"command": "pexip-mgmt-mcp",
"env": {
"PEXIP_HOST": "pexip-mgr.example.com",
"PEXIP_AUTH_MODE": "oauth2",
"PEXIP_OAUTH2_CLIENT_ID": "your-client-id",
"PEXIP_OAUTH2_PRIVATE_KEY": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----\n"
}
}
}
}For dev/lab, use basic auth instead: swap the PEXIP_AUTH_MODE /
PEXIP_OAUTH2_* keys for "PEXIP_USERNAME": "admin" and "PEXIP_PASSWORD": "...".
See Configuration for all options.
Enable writes: add "PEXIP_READ_ONLY": "false" to env (read-only is the
default).
Claude Code shortcut (instead of hand-editing JSON):
# OAuth2 (recommended for production)
claude mcp add pexip-mgmt \
-e PEXIP_HOST=pexip-mgr.example.com \
-e PEXIP_AUTH_MODE=oauth2 \
-e PEXIP_OAUTH2_CLIENT_ID=your-client-id \
-e PEXIP_OAUTH2_PRIVATE_KEY="$(cat oauth2_private_key.pem)" \
-- pexip-mgmt-mcp
# basic auth (dev/lab only)
claude mcp add pexip-mgmt \
-e PEXIP_HOST=pexip-mgr.example.com \
-e PEXIP_USERNAME=admin \
-e PEXIP_PASSWORD=... \
-- pexip-mgmt-mcpDocker (self-hosted HTTP transport): run the container alongside your
Infinity, serving on 127.0.0.1:8000. For lab/dev, fronting it with a
tunnel or proxy is fine. For production, run it as a proper service behind
a hardened reverse proxy (TLS, authentication, access control) on a managed
host, not a dev tunnel. See DEPLOY.md.
From source (developers): clone the repo, then:
pip install -e .
cp .env.example .env # edit with your Management Node details
python -m pexip_mcp --healthcheck
# OK: connected to pexip-mgr.example.com as admin, schema fetchedSee Testing for the full dev workflow.
Related MCP server: Equinix Fabric MCP
API | Tools | What it covers |
Configuration | 46 | VMRs + aliases, end users, devices, gateway rules, automatic participants, IVR themes, LDAP sync, locations + Conferencing Nodes, global settings, schema introspection, plus generic CRUD ( |
Status | 39 | Live conferences + per-node shards, participants + media streams, per-participant call quality, registrations, node/location status + load stats, backplanes, alarms, licensing, cloud overflow, Exchange scheduler, MJX endpoints + meetings, Teams Connector nodes + calls |
History | 14 | Conference + participant CDRs, server-side aggregation ( |
Command | 23 | Active call control: dial, disconnect, mute/unmute (participant or all guests), set role, lock/unlock, transfer, layout, messages, LDAP sync, provisioning emails, backup create/restore, certificate import, snapshot, upgrade |
The full catalog with per-tool annotations and parameters is in
TOOLS.md (regenerate with uv run python scripts/generate_tools_md.py).
This MCP server is designed to optimize tool use. High-traffic resources (VMRs, users, devices, rules) get dedicated typed tools; the ~70 remaining configuration resources share five generic CRUD tools backed by a resource registry. That keeps the catalog at 122 tools, which lowers per-request token use and improves the agent's tool selection (verified by the eval suite).
Source layout:
src/pexip_mcp/
├── client.py # Async PexipClient (all 4 API categories), 429-aware retry
├── config.py # PexipSettings (env-driven, pydantic-settings)
├── mcp_app.py # FastMCP instance + lifespan
├── server.py # Imports tool modules to trigger registration
├── __main__.py # Entry point + --healthcheck + --http
└── tools/
├── _helpers.py # get_client, resolve_id_by_field, paginate_all, annotation presets
├── command.py # Active call control + name→UUID resolvers
├── status.py # Live state + per-participant quality
├── history.py # CDRs + summarize_calls aggregation
├── resource_crud.py # Generic CRUD + resource registry (~70 resources)
├── schema.py # Live schema introspection
└── conference.py, end_user.py, device.py, gateway_rule.py, alias.py,
automatic_participant.py, infrastructure.py, ldap.py,
ivr_theme.py, global_settings.py # dedicated typed CRUD per resourceReal Claude Desktop conversations against a lab Pexip node.
A status question, answered directly:
Config inventory across multiple resources in one ask:
CDRs turned into an interactive dashboard, not a data dump:
All env vars are PEXIP_* prefixed and loaded from .env (or the process
environment). See .env.example for an annotated template.
Variable | Default | Purpose |
| required | Management Node hostname or IP, no scheme |
|
|
|
| oauth2 only | OAuth2 Client ID from the Pexip UI |
| oauth2 only | OAuth2 client "Private key" (ES256, shown once) |
|
| Override the token endpoint |
|
| OAuth2 scopes requested |
| basic only | Admin username (typically |
| basic only | Admin password |
|
| Set |
|
| HTTP timeout in seconds |
|
| Retries on 429 rate-limit responses |
|
| Expose only read tools; remove all write/control tools. On by default; set |
|
| Allow generic CRUD to mutate security-critical resources (SSH keys, roles, auth, certs). Only relevant when writes are enabled |
|
| Expose platform-lifecycle command tools (backup/restore, upgrade, cert import, software upload, cloud-node start, snapshot). Removed at startup unless enabled, even with writes on |
|
| How HTTP clients authenticate to this server: |
| unset | Bearer token for the |
| unset | Issuer URL; required when |
| unset | Expected token audience; required when |
| unset | Space-separated scopes the JWT must carry (optional) |
| discovered | Override the JWKS endpoint (default: discovered from the issuer) |
The server runs in read-only mode by default: only the read tools
(list / get / schema) are exposed. Every create, update, delete, and Command-API
control tool is removed from the catalog at startup, so the LLM cannot mutate the
deployment even if it tries. This is enforced server-side: the tools are gone
from the catalog, not merely flagged with an advisory readOnlyHint.
To enable the mutating admin surface, set PEXIP_READ_ONLY=false (logged loudly
at startup). Even then, generic CRUD refuses to touch security-critical
resources (SSH keys, admin roles/permissions, authentication/SSO, TLS/CA certs)
unless you also set PEXIP_ALLOW_SECURITY_RESOURCES=true. Pair writes with a
least-privilege Pexip Administrator Role for defense in depth.
Two modes, selected by PEXIP_AUTH_MODE:
oauth2 (recommended for production): an OAuth2 JWT bearer assertion
(ES256). The server signs a short-lived JWT with the client's private key and
exchanges it at https://<host>/oauth/token/ for a 1-hour bearer token (cached
and auto-refreshed). It authenticates once per hour instead of on every request
and keeps a reusable admin password out of the server's environment.
basic (dev/lab only): a local Management Node admin username + password.
Works out of the box on every Infinity deployment and is the quickest way to
get started, but sends admin credentials on each request. Not recommended for
production.
Set up an OAuth2 client in the Pexip admin UI under Users & Devices >
OAuth2 Clients: add a client, then copy its Client ID and Private key
(the private key is shown only once). You also enable Management API OAuth2 and
attach an Administrator Role, per Pexip's
Managing API access via OAuth2.
Then set PEXIP_AUTH_MODE=oauth2, PEXIP_OAUTH2_CLIENT_ID, and
PEXIP_OAUTH2_PRIVATE_KEY.
The evals/ suite measures whether an LLM can drive these tools
correctly from natural language. It defines 156 scenarios written as real
admin requests ("mute all the guests in AllHands", "point the syslog server at
10.0.0.99"), graded automatically across three layers:
Layer | What runs | Cost |
Deterministic (332 checks) | Every eval case is validated against the live tool registry (tools exist, parameter names match signatures) | free, in CI |
LLM-graded ( | Each prompt goes to Claude with the full tool catalog; multi-turn conversations with mocked API responses; graded on tool choice, parameters, and chain order | ~$2 / full run (tool catalog is prompt-cached) |
Live ( | CRUD, status reads, and call commands against a real Infinity node, including auto-dialing a test call and moderating it by name | free (your lab) |
Scoring supports exact / subset / ordered-subset / any-of tool matching, per-step parameter checks with acceptable-alternative values, and optional steps for chains where server-side name resolution makes a lookup legitimate but unnecessary. See evals/README.md for the case format and how to add scenarios.
Current state: the full suite passes: 698 passed, 12 skipped, 0 failures
across all four layers (208 unit + 332 deterministic eval checks + LLM-graded +
33 live), 86% coverage. The 12 skips are env-gated live cases (e.g. no dial
target set). Reproduce the full run with uv run pytest tests/ evals/ --llm --live, or the free deterministic subset (540 checks) with
uv run pytest tests/ evals/.
pexip-mgmt-skills/ is a self-contained
Agent Skills (open standard) + Claude Code plugin
package that wraps this MCP server with operator runbooks and
developer-reference skills. Built to be extractable: cp -r pexip-mgmt-skills/
out and you have a complete, plug-installable SDK that loads in Claude Code,
Gemini CLI, Codex CLI, Cursor, or any other compliant host.
Currently ships 9 skills across 6 domains:
Domain | Skill | Audience |
router |
| both, start here for open-ended requests |
operations |
| operator: kick / lock / report / configure |
management-api |
| developer: modify Configuration API tool code |
management-api |
| developer: Status API |
management-api |
| developer: History API |
management-api |
| developer: Command API |
events |
| both, configure Pexip's webhook push-event destinations |
policy |
| developer: external policy server config (via generic CRUD) |
room-integration |
| both, One-Touch Join |
See pexip-mgmt-skills/README.md for the
install instructions and
pexip-mgmt-skills/ARCHITECTURE.md
for the design rules. The companion
awesome-pexip-skills
covers the client-side (webapp3, @pexip/infinity, @pexip/media).
Install both for full Pexip coverage.
uv run pytest # 208 unit + 332 deterministic eval checks, 86% coverage
uv run pytest tests/ # 208 unit tests (mocked HTTP via respx), ~2s
uv run pytest evals/ # 332 deterministic eval checks, free
uv run pytest evals/ --llm # LLM-graded evals (needs ANTHROPIC_API_KEY, ~$2)
uv run pytest evals/ --live # integration against a real node (needs .env)
uv run ruff check src tests evalsEvery run prints a coverage report, but the 80% gate is enforced only in CI on the
full suite (--cov-fail-under=80 in .github/workflows/ci.yml), so subset runs
like uv run pytest evals/ show partial coverage without failing. Unit tests mock
the Pexip Management API with respx; the retry
suite monkeypatches asyncio.sleep so backoff tests run instantly.
Retrieve a single active participant.
Args: participant_id: UUID, or the participant's display name (e.g. "Bob") — names are resolved against currently connected participants automatically, so there is no need to call list_active_participants first. conference: Optional conference name to scope a display-name lookup when the name might not be unique across meetings.
| Name | Required | Description | Default |
|---|---|---|---|
| conference | No | ||
| participant_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context about automatic name resolution and conference scoping, but does not disclose error handling or what happens if a participant is not found. Given the annotations, the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (around 50 words) and well-structured, starting with a clear purpose and then detailing each parameter. Minor improvement could be to avoid list formatting and use prose, but it is effective and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's simplicity (2 parameters, no nested objects), the description is fairly complete. It covers parameter usage and context (resolution behavior, conference scoping). Missing are edge cases or typical usage scenarios, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining participant_id can be UUID or display name with automatic resolution, and conference scopes the lookup. This adds critical meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single active participant, explains the parameter flexibility (UUID or display name), and explicitly distinguishes from list_active_participants, making it easy to differentiate from siblings like get_history_participant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool (retrieve single active participant) and explains that list_active_participants is unnecessary if using display names. However, it does not explicitly state when not to use it or suggest alternatives like get_history_participant for historical data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one historical alarm by id.
| Name | Required | Description | Default |
|---|---|---|---|
| alarm_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds no extra behavioral context beyond 'Retrieve', which is consistent but not additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, one sentence, front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup by ID with output schema and clear annotations, the description is fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but parameter 'alarm_id' is simple and the description mentions 'by id', adding no new meaning. Baseline score 3 due to simplicity and self-explanatory nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Retrieve', resource 'one historical alarm', and method 'by id'. Distinguishes from sibling 'list_alarm_history' which lists multiple alarms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly indicates usage for a specific alarm by ID, but does not explicitly mention alternatives like 'list_alarm_history' for browsing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single backplane by id.
| Name | Required | Description | Default |
|---|---|---|---|
| backplane_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds no additional behavioral context beyond these annotations. Since the description does not contradict annotations (score 1 would be for contradiction), a 3 is appropriate as it meets the basic expectation without adding extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key action and resource. No unnecessary words, and it earns its place by providing essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no nested objects, and an output schema exists), the description is adequately complete. The annotations cover behavioral aspects, and the output schema likely defines return values. While the description could briefly mention the output, it is not critical for this simple get-by-id tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate for parameter documentation. However, the description adds no meaning beyond the schema's parameter name 'backplane_id'. For a single required parameter, the name is somewhat self-explanatory, but the lack of any additional info (e.g., format, example) results in a score of 2.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve a single backplane by id' clearly states the verb (retrieve) and specific resource (single backplane by id). It distinguishes itself from sibling 'list_backplanes' which returns multiple backplanes, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a specific backplane via its id, but it does not explicitly state when to use this tool over alternatives like 'get_backplane_history' or when not to use it. No exclusions or context are provided, so the guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one historical backplane connection by id.
| Name | Required | Description | Default |
|---|---|---|---|
| backplane_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds minimal behavioral info beyond confirming it's a retrieve operation. The word 'historical' clarifies the scope, but no additional traits (e.g., error handling, auth requirements) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-crafted sentence that immediately conveys the tool's purpose. There is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, output schema exists), the description covers the core purpose but omits important context about the parameter semantics and return value. The output schema helps, but the parameter gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only says 'by id' without explaining what the 'backplane_id' represents (e.g., the unique identifier from 'list_backplane_history'). The parameter title 'Backplane Id' is not expanded upon, so the description fails to compensate for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('retrieve'), identifies the resource ('historical backplane connection'), and specifies the lookup key ('by id'). This clearly distinguishes it from the sibling 'list_backplane_history' (which returns multiple) and 'get_backplane' (which returns current, not historical).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching a single historical record by its ID, but it does not explicitly state when to use it over alternatives like 'list_backplane_history' or 'get_backplane_history_media_streams'. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get media stream statistics for a historical backplane connection.
Args: backplane_id: Backplane id from list_backplane_history.
| Name | Required | Description | Default |
|---|---|---|---|
| backplane_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and no destructive action, so the description's 'Get' assertion adds no new behavioral context. No additional traits (e.g., auth needs, rate limits) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two clear sentences: one for purpose and one for parameter details. No extraneous information, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a single parameter and an output schema, the description is complete. It specifies the required argument and its source, and the output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides minimal parameter info (name and type) with 0% schema description coverage. The description adds value by clarifying that the backplane_id originates from list_backplane_history, compensating for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves media stream statistics for a historical backplane connection, distinguishing it from siblings like get_backplane_media_streams (for current connections) and list_backplane_history (which lists backplane history).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the backplane_id should come from list_backplane_history, providing a prerequisite. However, it does not explicitly state when to use this tool versus alternatives like get_backplane_media_streams.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get media stream statistics for a backplane connection.
Args: backplane_id: Backplane id from list_backplanes.
| Name | Required | Description | Default |
|---|---|---|---|
| backplane_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool's behavior as a read operation ('Get media stream statistics'), which is consistent with the annotations (readOnlyHint=true, destructiveHint=false). The annotations already cover safety and idempotency, so the description adds sufficient context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first states the purpose, the second documents the parameter with a dependency hint. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and comprehensive annotations, the description provides the essential context: the tool's purpose and parameter source. It does not detail return values, but the output schema presumably covers that. Slightly lacking in broader usage context, but still sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, backplane_id, has 0% schema description coverage. The description adds meaningful guidance by stating 'Backplane id from list_backplanes', informing the agent that the ID comes from that specific source. This compensates for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Get'), resource ('media stream statistics'), and context ('for a backplane connection'). This distinguishes it from siblings like 'get_backplane' which retrieves the backplane itself, and 'get_backplane_history_media_streams' which likely retrieves historical data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a helpful guideline for the backplane_id parameter, instructing to obtain it from 'list_backplanes'. However, it does not explicitly compare to other tools like 'get_backplane_history_media_streams' or indicate when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single cloud monitored location by id.
| Name | Required | Description | Default |
|---|---|---|---|
| location_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds no extra behavioral context (e.g., errors, permissions, return format).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single 8-word sentence, front-loaded with action. Efficient, but could include more parameter detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but not shown. Annotations cover safety. For a simple get-by-id, description is adequate but lacks parameter documentation, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no description for location_id (0% coverage). Description says 'by id' but doesn't specify id format, source, or constraints. Minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'Retrieve', resource 'cloud monitored location', and key 'by id'. Clearly distinguishes from sibling 'list_cloud_monitored_locations' and other get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when a single location by ID is needed, but no explicit when-to-use/alternatives guidance. No mention of not using for other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single cloud overflow node by id.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering behavioral traits. The description adds no extra context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with no superfluous words. Front-loaded verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Low complexity, one parameter, output schema present. Description is sufficient to understand the tool's purpose given annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter node_id is self-explanatory; the description says 'by id' which aligns with the schema. Schema coverage is 0% but the parameter's purpose is clear, so no additional value but adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Retrieve a single cloud overflow node by id" clearly states the action (retrieve), resource (cloud overflow node), and identifier method (by id). This distinguishes it from sibling tools like list_cloud_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using the tool when you have a specific node_id, but does not explicitly state when to use this over alternatives or any exclusions. No guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single cloud overflow location by id.
| Name | Required | Description | Default |
|---|---|---|---|
| location_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds no additional behavioral context beyond 'retrieve', which is consistent and adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words; it is maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description is minimally complete for a simple get-by-id tool, but it does not confirm that a single object is returned or mention error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage for the parameter, the description only says 'by id' without explaining the format, source, or meaning of the location_id parameter, failing to compensate for the lack of schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve a single cloud overflow location by id' clearly states the verb (retrieve), resource (cloud overflow location), and distinguishes from the sibling 'list_cloud_overflow_locations' tool which returns multiple records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a specific location by ID, but does not explicitly state when to use this tool versus alternatives (e.g., the list tool) or any conditions/exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single conference shard by id.
| Name | Required | Description | Default |
|---|---|---|---|
| shard_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no behavioral context beyond the annotations, not even addressing the open world hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the purpose efficiently with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are present, the description is minimally adequate but could add context about the resource or expected return to improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'by id' without explaining the format or constraints of the shard_id parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve a single conference shard by id' clearly states the action, resource, and identifier. It distinguishes from sibling 'list_conference_shards' which retrieves multiple.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific shard_id, but does not explicitly state when to use or not use this tool compared to alternatives like list_conference_shards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single conference sync entry by id.
| Name | Required | Description | Default |
|---|---|---|---|
| sync_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds no behavioral context beyond 'Retrieve... by id', which does not contradict annotations. However, there is no extra information on behavior like rate limits or response handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single sentence with no wasted words. Front-loads the action and resource, which is efficient for an agent scanning multiple tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (1 param, output schema present) and sibling tools include a list variant. The description is minimal but covers the essential purpose. It is complete enough for a simple retrieval operation, though more context on the data model would improve usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 1 required parameter (sync_id) with 0% schema description coverage. The description does not explain what 'sync_id' represents or how to obtain it, leaving the agent without key context for the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'conference sync entry', with the criterion 'by id'. This distinguishes it from the sibling tool 'list_conference_sync_status' which retrieves multiple entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The sibling 'list_conference_sync_status' exists but is not mentioned, and there is no exclusion criteria or context for when a single entry is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a Conferencing Node by integer id or by exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| node | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which provide a strong safety profile. The description adds behavioral context by specifying retrieval by integer id or exact name, which is more specific than the schema alone. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys all necessary information without any redundant or extraneous content. It is front-loaded and efficiently communicates the tool's purpose and input semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with an existing output schema (unknown details), the description covers the key input semantics. It lacks mention of expected behavior when the node is not found or response structure, but given the annotations and output schema, this is acceptable. Slight improvement could be made in error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It states that the 'node' parameter can be an integer id or exact name, which essentially restates the schema's anyOf type. However, it adds value by clarifying that strings represent 'exact name', providing semantic guidance not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve a Conferencing Node by integer id or by exact name.' It specifies the action (Retrieve), the resource (Conferencing Node), and the identification method (id or exact name). This distinguishes it from sibling tools like 'list_conferencing_nodes' which retrieve multiple nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. Usage is implied from the tool name and context (get vs list), but no explicit when-not or guidance is provided. This leaves some ambiguity for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a device by integer id or by exact alias.
| Name | Required | Description | Default |
|---|---|---|---|
| device | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to reiterate safety. However, it adds the lookup methods but omits behavior on not found or multiple matches. The description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 8 words efficiently conveys the tool's purpose and parameter semantics. Every word serves a purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description covers the essential functionality. It lacks mention of error cases or return value details, but those are partially addressed by the output schema and annotations. Minor gaps prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description compensates by specifying that the 'device' parameter accepts either an integer id or an exact alias string. This adds crucial meaning beyond the schema's anyOf type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve', the resource 'device', and specifies two distinct lookup methods (integer id or exact alias). This distinguishes it from sibling 'get_*' tools which may use different identifiers or resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like list_devices. The usage is implied (to retrieve a single device), but no when-not or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve an end user by integer id or by primary_email_address.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description only states 'retrieve', adding no additional behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 10 words, front-loaded with verb and resource. Every word is necessary and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with good annotations and output schema present, the description is almost complete. Lacks details on email matching behavior (case sensitivity, exact match) but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one property 'user' of anyOf integer/string with no description. Description clarifies that integer means ID and string means primary_email_address, adding meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'retrieve' and resource 'end user'. Specifies two valid identifiers (integer id or primary_email_address), distinguishing it from other get tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicit usage for retrieving a single end user by identifier. No explicit guidance on when to use vs alternatives like list_end_users, but the purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single Exchange scheduler entry by id.
| Name | Required | Description | Default |
|---|---|---|---|
| scheduler_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so description does not need to repeat. The description adds no additional behavioral context beyond 'Retrieve', which is consistent. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. Every word adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (only one parameter, annotations present, output schema exists), the description is adequately complete for a basic retrieval. It lacks minor details like what happens if not found, but is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. However, it only repeats that the tool retrieves 'by id', which is already clear from the required parameter. It does not provide extra meaning like format or constraints for the scheduler_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'Exchange scheduler entry' with the method 'by id'. It distinguishes from sibling 'list_exchange_scheduler_status' which lists multiple entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific id is known, but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. No clear context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a gateway routing rule by integer id or exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| rule | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds no behavioral context beyond the retrieval action, such as error scenarios, rate limits, or side effects, leaving the agent reliant on annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with the verb and resource front-loaded. No wasted words; every part is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, robust annotations, and an output schema, the description is fully adequate. It tells the agent exactly how to identify the rule.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by clarifying that the 'rule' parameter accepts an integer id or exact name. This adds meaning beyond the schema's anyOf type, though it could specify behavior for ambiguous inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Retrieve', the resource 'gateway routing rule', and the criteria 'by integer id or exact name'. This distinguishes it from sibling tools like get_device or list_gateway_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like list_gateway_rules. It only implies usage for retrieving a single known rule, but no explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the platform-wide global configuration singleton.
Includes things like default themes, default join PIN behavior, bandwidth caps, banner text, MSSIP domain, and call-create permissions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read operation (readOnlyHint, idempotentHint, destructiveHint). The description adds behavioral context by specifying that it retrieves a singleton and listing example fields, which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and provides illustrative examples in the second sentence. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the description is fully complete. It clearly states the purpose and gives representative examples of the output contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100%. The description does not need to explain parameters; the baseline is 4 for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and clearly identifies the resource as 'platform-wide global configuration singleton'. It distinguishes itself from sibling tools which retrieve specific entities like devices or participants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly defines usage context by listing example contents (e.g., default themes, bandwidth caps), but it does not explicitly state when to use this tool versus alternatives. The differentiation is clear from sibling names, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one past conference instance by id.
| Name | Required | Description | Default |
|---|---|---|---|
| conference_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds only the qualifier 'past', but does not disclose potential behavior like missing ID handling, rate limits, or authentication needs beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource, no extraneous words. Efficiently communicates core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter structure and presence of output schema (not shown), the description is minimally adequate. However, it omits mention that the tool returns a single object and does not explain the 'past' qualifier (e.g., time bounds).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description does not explain the conference_id parameter format, type constraints, or examples, leaving the agent without necessary usage details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Retrieve' and identifies resource as 'one past conference instance by id'. It clearly distinguishes from sibling 'list_history_conferences' which returns multiple conferences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_history_participant for participant details, or list_history_conferences for enumeration). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one past participant by id.
Returns full quality forensics: historic_call_quality (per-window timeline)
and bucketed_call_quality ([unknown, good, ok, bad, terrible] counts).
These deep fields are only populated on individual GET, not list responses.
| Name | Required | Description | Default |
|---|---|---|---|
| participant_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds important context that full quality forensics are available only on individual GET, which is not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then specific details about return fields and availability. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and presence of an output schema, the description adequately covers return values and key behavioral nuance (deep fields only on GET). No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (participant_id) with schema coverage 0%. The description does not elaborate on the parameter beyond 'by id', but the schema defines it as string or integer, which is minimal but sufficient. No additional context added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Retrieve one past participant by id', which is a specific verb-resource combination. It clearly differentiates from sibling tools like get_active_participant and list_history_participants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that deep quality forensics fields are only populated on individual GET, not list responses, providing clear guidance on when to use this tool vs list_history_participants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve an IVR theme by id or exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds the behavioral detail of retrieval by id or exact name, but does not disclose other behavioral traits like rate limits or authentication requirements. Since annotations cover safety and idempotency, the description's addition is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and to the point. It contains no extraneous information and is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and an output schema, the description is mostly adequate. However, it could include a brief note about the expected output or any special behavior, though the existence of an output schema reduces the need for that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage (no inline descriptions). The description explains that the 'theme' parameter is used to specify the id or exact name, which adds semantic meaning beyond the schema's type definition. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'IVR theme', and specifies the lookup methods (by id or exact name). It distinguishes from the sibling 'list_ivr_themes' which would return multiple themes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly differentiates retrieval by id or exact name, but does not explicitly state when to use this tool versus alternatives like list_ivr_themes. No when-not or alternative tool guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve an ldap_sync_source by id or exact name.
Includes last sync status / errors when available — useful for answering 'is LDAP sync working?'.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Consistent with readOnlyHint and destructiveHint annotations. Adds behavioral details about including last sync status/errors, which annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core action, then additional value. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool with output schema, description provides sufficient context (how to identify source and key return value). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'source' is clarified as id (integer) or exact name (string). Schema has 0% description coverage, so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves an ldap_sync_source by id or exact name, and distinguishes it from list_ldap_sources. Specific verb and resource with added context of sync status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions retrieval by id or exact name and provides use case ('is LDAP sync working?'). Lacks explicit when-not-to-use or alternative comparison, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current concurrent port usage vs entitlement (audio + video ports, per location).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds meaningful context: it reports current usage vs entitlement and per-location breakdown, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense sentence with no wasted words: conveys purpose, scope (audio+video ports), granularity (per location), and comparison (usage vs entitlement).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations provide safety profile, the description covers all essential context for the agent to understand what the tool returns and at what level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description does not need to add parametric detail. Baseline is 4 for zero parameters, and the description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows 'current concurrent port usage vs entitlement' for 'audio + video ports, per location,' specifying exactly what data is returned and the granularity. It distinguishes from sibling tools, none of which focus on licensing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking licensing status, but does not explicitly state when to use or when not to use. However, no direct alternative tool exists among siblings, so the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a system location by integer id or by exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds the identification methods (integer or string) but no additional behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 12 words, no filler, perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with annotations (safe, idempotent) and presence of output schema, provides sufficient context for a simple retrieval. Minor gaps might include what happens on not found, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning by explaining the dual type (integer or string) for the 'location' parameter. However, it lacks details like case-sensitivity or accepted formats, so it partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Retrieve' and resource 'system location', and specifies two identification methods (integer id or exact name). This clearly distinguishes it from sibling tools like list_locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single location by id or name but does not explicitly state when to use this tool versus alternatives like list_locations. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get load statistics for one system location (call counts, port usage).
Args: location: Location id or exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds that the tool returns load statistics, but does not disclose additional behavioral traits like pagination or defaults. With strong annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two lines of main text plus an Args line. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter, read-only behavior is covered by annotations, and an output schema exists. The description sufficiently covers the tool's purpose and parameter, leaving no critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, but the description explicitly documents the 'location' parameter, explaining it can be an id or exact name. This adds crucial meaning beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'load statistics for one system location', with examples of returned data ('call counts, port usage'). It effectively distinguishes from sibling tools like get_location and get_location_status which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single location but does not explicitly compare with alternative tools such as list_locations or summarize_calls. No when-to-use or when-not-to-use guidance is provided, so it's adequate but lacks explicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live status for one system location by id or exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide safety (readOnlyHint, destructiveHint) and idempotency hints. The description adds 'live status' but no additional behavioral context like authorization, rate limits, or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no wasted words, front-loaded with key information. Perfectly concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, output schema exists) and rich annotations, the description is largely complete. It covers the what and how, though could mention rate limits or that output schema provides status details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by clarifying that the 'location' parameter can be an id (integer) or exact name (string), which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get live status'), the resource ('for one system location'), and the method ('by id or exact name'). It distinguishes from siblings like 'get_location' and 'list_location_status' by specifying 'live status' and 'one'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you have an id or exact name) but does not explicitly state when not to use or mention alternatives. No exclusions or comparative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve live status for a specific Management Node.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's a safe read operation. The description adds 'live status' implying real-time data, which is useful context. No additional behavioral traits disclosed beyond annotations, and no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action. No wasted words, but could be slightly expanded to include usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return values are covered. The description is adequate for a simple status retrieval tool, but lacks usage guidance which would make it more complete. It is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description does not explain the node_id parameter beyond its name and type. The parameter name is self-explanatory, but the description should guide on valid values or how to obtain them. It adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and the resource 'live status for a specific Management Node'. It distinguishes from siblings like 'list_management_node_status' (list all) and 'get_node_status' (generic) by specifying 'specific' and 'Management Node'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The sibling list includes 'get_node_status' and 'list_management_node_status', but the description does not explain when to prefer this over those or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve live status for a single MJX endpoint by id.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds 'live status' suggesting real-time data, which is a useful behavioral trait. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core function. It is not verbose, but could be slightly more detailed without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While annotations and output schema (present but not seen) reduce the burden, the description lacks parameter details and usage guidance. For a simple retrieval tool, it is marginally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter 'endpoint_id'. The description only says 'by id' without explaining format, source, or constraints. The description fails to add meaningful context to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve live status'), the resource ('MJX endpoint'), and the uniqueness ('single' by id). It effectively distinguishes from the sibling tool 'list_mjx_endpoint_status' which retrieves multiple endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'by id', implying usage when an endpoint ID is known. However, it does not explicitly state when to use this tool versus alternatives like 'list_mjx_endpoint_status', leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve status for a single MJX meeting by id.
| Name | Required | Description | Default |
|---|---|---|---|
| meeting_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds no further behavioral context (e.g., latency, data freshness, or response structure). Given annotations cover safety, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with key information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and low complexity (single parameter), the description is adequate. However, it omits any prerequisites or conditions for status retrieval, and might benefit from mentioning that the status is real-time or cached.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining the 'meeting_id' parameter format, constraints, or example. It only says 'by id', providing minimal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve', the resource 'status for a single MJX meeting', and the method 'by id'. It effectively distinguishes from the sibling tool 'list_mjx_meeting_status' which retrieves multiple meetings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage when you have a specific meeting ID and need a single status, it does not explicitly state alternatives or when not to use. The sibling list tool provides context, but the description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one Conferencing Node status event by id.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it retrieves a single event by id, which is consistent. No contradictions; the description provides minimal additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence of 9 words, extremely concise with no unnecessary information. It effectively communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no nested objects, output schema exists, annotations cover safety), the description is sufficient for basic understanding. It could mention common use cases or what the returned event contains, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'by id', which implies event_id is an identifier, but no further details like format, range, or examples. For a single parameter, more specific guidance could be provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve', the resource 'Conferencing Node status event', and the method 'by id'. It distinguishes from sibling tools like list_node_event_history (which lists all events) and other get_* tools for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific event_id, but does not explicitly state when to use or not use alternatives like list_node_event_history. No explicit when-not or alternative tool mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get load statistics for one Conferencing Node (CPU, media load, call counts).
Args: node: Node id or exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| node | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds value by specifying the exact metrics returned (CPU, media load, call counts), providing behavioral context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no extraneous information. The first sentence states the tool's purpose, and the second describes the parameter. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, output schema present), the description is fairly complete. It names the key metrics returned. The output schema likely covers the exact format, so the description need not detail it further. Minor gap: no explicit mention of return values, but sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by explaining the single parameter 'node' as 'Node id or exact name.' This adds meaning beyond the schema's type definition, clarifying that both id and name are acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'load statistics for one Conferencing Node', and specifies the exact metrics (CPU, media load, call counts). This distinguishes it from sibling tools like get_node_status or get_conferencing_node which provide different information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions or comparisons with other tools like get_node_status or list_node_status, leaving the agent to infer usage based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live status for one Conferencing Node by integer id or exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| node | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds value by specifying 'live status', which hints at real-time data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-constructed sentence that front-loads the key information. Every word serves a purpose, with no verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), return values need not be explained. The description, combined with annotations and the simple parameter, provides adequate context. A slight improvement would be mentioning that list_node_status is the alternative for multiple nodes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the single parameter 'node': it can be an integer id or exact name. This adds meaning beyond the schema's anyOf type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get live status'), the specific resource ('Conferencing Node'), and the selection method ('by integer id or exact name'). This distinguishes it from siblings like list_node_status which retrieves multiple nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific node ID or name, but lacks explicit when-to-use or when-not-to-use guidance, and does not mention alternatives like list_node_status for listing all nodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live call quality for one active participant.
Combines two Status API endpoints into one response:
the participant record (call_quality, connect_time, conference, role, protocol, remote_address, location, current packet loss summary)
all media streams for the participant (per-stream rx/tx bitrate, packet loss, jitter, codec, resolution).
For "is Alice's call OK right now?" use cases — pass the name directly. For post-call quality forensics, use get_history_participant which exposes bucketed_call_quality.
Args: participant_id: UUID, or the participant's display name (e.g. "Bob") — names are resolved against currently connected participants automatically, so there is no need to call list_active_participants first. conference: Optional conference name to scope a display-name lookup when the name might not be unique across meetings.
| Name | Required | Description | Default |
|---|---|---|---|
| conference | No | ||
| participant_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, non-destructive. Description adds context: combines two endpoints, returns participant record and media streams, and explains automatic name resolution. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a summary, then bullet-like details, then parameter info. Could be slightly more concise, but no wasted words. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (not shown but indicated), description covers return fields and contrasts with sibling tool. For a tool that combines two endpoints, it is complete for an agent to understand functionality and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description fully explains both parameters: participant_id as UUID or display name, conference as optional scope for uniqueness. This adds significant meaning beyond the schema's type/title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides live call quality for one active participant, combines two endpoints, and distinguishes from get_history_participant for post-call forensics. The verb 'get' and resource 'participant quality' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use case: 'For is Alice's call OK right now?' and directs to use get_history_participant for post-call forensics. Also explains name resolution vs UUID usage, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single registered alias by id.
| Name | Required | Description | Default |
|---|---|---|---|
| alias_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds no further behavioral context beyond 'retrieve', but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 8 words, no redundancy. Every word serves the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and an output schema, the description is sufficient. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says 'by id' but does not elaborate on the alias_id parameter format or source. With 0% schema description coverage, the description partially compensates by mentioning the identifier role, but lacks details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('retrieve') and the resource ('a single registered alias by id'), distinguishing it from the sibling 'list_registration_aliases' which returns multiple aliases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'list_registration_aliases'. The usage is implied by the singular nature of the operation, but no explicit exclusions or when-not-to-use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one historical registration entry by id.
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, covering safety and idempotency. The description adds minimal behavioral context (retrieve by ID), which is expected but not expanded upon (e.g., no mention of error behavior or required permissions).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource. It is concise but could be slightly expanded (e.g., mentioning return format or behavior) without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return values. However, for a retrieval tool, it could clarify that it returns a single object or what happens if the ID does not exist. The current description is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. However, it only mentions 'by id' without explaining the parameter type, format, or semantics. The schema defines entry_id with anyOf string/integer, but the description adds no meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve'), the resource ('historical registration entry'), and the unique identifier ('by id'). It distinguishes from sibling tools like 'list_registration_history' which returns multiple entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single historical registration by ID, contrasting with listing tools, but lacks explicit guidance on when to use this versus other retrieval tools (e.g., get_registration_alias) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single configuration resource by integer id or by name.
Args: resource: API resource name (see list_resources for the full list). id: Integer id, numeric string, or the resource's name — names are resolved automatically, so there is no need to list first.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| resource | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds automatic name resolution but omits error behavior or response shape details. Moderate added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with clear bullet points. Every sentence is informative with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not needing return explanation) and rich annotations, the description covers essential retrieval semantics. Could mention that it's a generic getter for any resource type, but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains both parameters: 'resource' references list_resources, and 'id' clarifies it can be integer or string and that names resolve automatically. Adds meaning beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get a single configuration resource by integer id or by name.' Includes specific verb and resource type, and distinguishes from siblings like list_resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the method of identification (id or name) and that names are resolved automatically, reducing need to list first. However, does not compare to specific sibling getters (e.g., get_device) and lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the live JSON schema for a Pexip configuration resource.
Use this to discover available fields, types, required vs optional
(nullable: false = required), allowed enum values, filtering options,
and help text for any resource. Pass the resource name as it appears in
the URL path, e.g. "conference", "conference_alias", "end_user",
"system_location", "worker_vm", "gateway_routing_rule",
"automatic_participant".
| Name | Required | Description | Default |
|---|---|---|---|
| resource | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: explains that it fetches a 'live' schema, and clarifies that 'nullable: false' means required. Annotations already indicate safe read-only, idempotent behavior, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first defines the action, second elaborates on usage and examples. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to cover return values. It adequately covers purpose, parameter meaning, and what to expect from the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the 'resource' parameter, including that it should be the name as in the URL path, and gives multiple concrete examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches the live JSON schema for a Pexip configuration resource, with specific verb and resource. Distinguishes itself from sibling get/list tools by being a meta-tool for schema discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to discover...' and provides examples of resource names. While it doesn't mention when not to use or alternatives, the tool's unique purpose makes usage intuitive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve status for a single Teams Connector call by id.
| Name | Required | Description | Default |
|---|---|---|---|
| call_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, etc. Description adds no behavioral traits beyond what it retrieves. No contradiction, but does not add extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 10 words. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description adequately communicates the tool's purpose for a simple retrieval operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; the description adds that call_id is the identifier by mentioning 'by id', but no format or constraints beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Retrieve status' and specific resource 'single Teams Connector call by id'. Distinguishes from sibling list_teams_node_call_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates that a specific call_id is needed, implying use when you have an ID. Does not explicitly state when not to use or mention alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve status for a single Teams Connector node by id.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint; description adds minimal context about focusing on a single node. No additional behavioral traits disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but slightly terse for full clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, description adequately covers the tool's purpose for a simple single-node retrieval. Could mention that it's Teams-specific, which it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter node_id is required but description only says 'by id' without clarifying format or source. Schema coverage is 0%, so description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'retrieve', the resource 'Teams Connector node status', and the identifier method 'by id'. It distinguishes itself from sibling 'get_teams_node_call_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use case by specifying 'by id' for a single node, but no explicit guidance on when to use this vs 'list_teams_node_status' or other retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a VMR by integer id or by exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| vmr | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that the identifier can be integer or string, clarifying input flexibility. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the tool's purpose. Every word is necessary and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and comprehensive annotations, the description provides adequate context. It could mention that exact name match is case-sensitive or that it returns a single VMR, but it is still complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains that the 'vmr' parameter can be an integer id or exact string name, adding essential meaning beyond the schema's anyOf type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single VMR by either integer id or exact name, which is specific and distinguishes it from the sibling list_vmrs tool that lists all VMRs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you have an identifier) but does not explicitly state when not to use or mention alternatives like list_vmrs. The usage guidance is minimal but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List currently-running conference instances.
Empty objects list = nothing is in progress right now.
Args: name: Filter by exact instance name (the dialed alias). service_type: "conference" / "lecture" / "two_stage_dialing" / "gateway" / "test_call". tag: Filter by service tag. limit: Per-page limit (ignored if fetch_all). offset: Pagination offset (ignored if fetch_all). fetch_all: Walk all pages and return up to 5,000 records combined.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | ||
| name | No | ||
| limit | No | ||
| offset | No | ||
| fetch_all | No | ||
| service_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses key behaviors: returns empty list if nothing in progress, pagination behavior (limit/offset ignored when fetch_all is true), and fetch_all returning up to 5,000 records. This adds significant value and no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and well-structured: a one-line summary followed by a bulleted argument list. Every sentence adds value, with no redundant information. The structure is front-loaded for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, pagination) and the presence of an output schema, the description covers all essential aspects: what it returns (empty list if none), parameter usage, and pagination behavior. No gaps remain, making it fully self-contained for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose: name filter by exact instance name, service_type with enumerated values, tag filter, and pagination control (limit, offset, fetch_all). It clarifies the interaction between limit/offset and fetch_all, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists currently-running conference instances, using the specific verb 'list' and resource 'active conferences'. The title further reinforces this. It is distinct from sibling tools like list_active_participants or list_alarms, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., get_conference_shard or list_history_conferences). While the context implies it's for active conferences, there is no mention of when not to use it or conditions for preferring siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List currently-connected participants (active call legs).
Args: conference_name: Restrict to one running conference instance. role: "chair" or "guest". protocol: "api" / "sip" / "h323" / "mssip" / "webrtc" / "rtmp" / "teams" / "gms". is_muted: Filter by mute state. limit, offset, fetch_all: Pagination controls.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | ||
| limit | No | ||
| offset | No | ||
| is_muted | No | ||
| protocol | No | ||
| fetch_all | No | ||
| conference_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description is consistent and adds the context that it lists 'currently-connected' participants and provides parameter examples. However, it does not disclose additional behavioral traits beyond what annotations cover, earning a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, followed by a clean list of parameters. Every sentence is necessary, and the structure front-loads the core action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (reducing need for return value explanation) and annotations covering safety, the description omits context about default behaviors (e.g., what happens without filters, how pagination exactly works, rate limits). For a tool with 7 parameters and many siblings, these gaps reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It lists all 7 parameters with brief explanations (e.g., 'restrict to one running conference instance', filter options for role, protocol, is_muted, and pagination controls). This adds significant value, though it lacks details like value ranges or interaction between pagination parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists currently-connected participants (active call legs), which is a specific verb+resource. While it distinguishes from sibling tools like 'get_active_participant' (singular vs list) and 'list_active_conferences' (participants vs conferences), it does not explicitly differentiate itself, which would be helpful given many similar siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_active_participant' (for a single participant) or other listing tools. It does not specify prerequisites or when not to use this tool, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List historical alarms.
Args: start_time: Lower bound (inclusive) on time_raised. UTC ISO 8601. end_time: Upper bound (exclusive) on time_raised. UTC ISO 8601. level: "error" / "warning" / "info". limit, offset, fetch_all: Pagination controls.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| limit | No | ||
| offset | No | ||
| end_time | No | ||
| fetch_all | No | ||
| start_time | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, no destructiveness. Description adds time bound details (inclusive/exclusive), level values, and pagination controls, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-line purpose followed by parameter list. Every sentence adds value, no fluff. Front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return format is covered. Description lacks default time range behavior or ordering, but is sufficient for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description provides full parameter meanings: start/end time polarity, level enum values, pagination summary. Adds essential context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List historical alarms' with a specific verb and resource. Distinguishes from siblings like 'list_alarms' (likely active) and 'get_alarm_history' (single alarm).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs siblings. Parameters imply usage context but no alternatives or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active platform alarms.
Args: level: "error" / "warning" / "info". node_name: Restrict to one Conferencing Node by name. limit, offset, fetch_all: Pagination controls.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| limit | No | ||
| offset | No | ||
| fetch_all | No | ||
| node_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds the 'active' qualifier and parameter roles but does not disclose additional behavioral traits like pagination behavior or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and a bullet list for parameters. Every line adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description does not need to detail return values. It covers the essential input semantics and scope ('active'), though it could mention default ordering or pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains all parameters: level (with enum values), node_name (filtering), and pagination controls. This adds meaning beyond the schema's type/default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List active platform alarms,' specifying the verb (List) and resource (active platform alarms). It distinguishes from sibling tools like list_alarm_history that deal with historical alarms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_alarm_history or list_alarm_history. The description lacks context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List conference aliases, optionally scoped to one VMR.
Args: vmr: VMR id or exact name to filter by. Omit for all aliases. alias: Exact alias match. alias_contains: Case-insensitive substring match. limit: Max results. offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| vmr | No | ||
| alias | No | ||
| limit | No | ||
| offset | No | ||
| alias_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's role is lighter. It adds the key behavioral context of optional scoping to a VMR and explains each filter parameter, which is sufficient beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and front-loaded: one sentence for purpose followed by parameter documentation in a bullet-like list. No redundant words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters, presence of an output schema, and annotations, the description covers core functionality and all parameters. It does not explain pagination beyond limit/offset or define 'alias', but these are minor omissions for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully documents all 5 parameters: vmr, alias, alias_contains, limit, offset. Each has clear, actionable meaning (e.g., 'VMR id or exact name to filter by' and 'Case-insensitive substring match').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List conference aliases, optionally scoped to one VMR' clearly states the action (list) and resource (conference aliases), with optional filtering. It distinguishes from sibling tools like list_registration_aliases by specifying 'conference' aliases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention when to omit scope or how to choose between exact match vs substring search. The agent must infer usage from parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List automatic participants, optionally scoped to one VMR.
Args: vmr: VMR id or name to filter by (pass the name directly — resolved internally, no need to list_vmrs first). Omit for all. alias_contains: Case-insensitive substring match on alias. limit: Max results. offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| vmr | No | ||
| limit | No | ||
| offset | No | ||
| alias_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the safety profile is clear. The description adds minor context about internal VMR resolution, but no other behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence stating purpose, followed by a structured Args section. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values need not be explained. The description covers filtering and pagination adequately. It could briefly define 'automatic participants' but is otherwise complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: vmr (pass name directly, internal resolution), alias_contains (case-insensitive substring), limit (max results), offset (pagination offset). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'automatic participants', with optional scoping to a VMR. It is specific and stands out among sibling tools, though no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage guidance, such as passing the VMR name directly without needing to call list_vmrs first, and explains omission for all results. However, it does not discuss when not to use the tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List historical backplane connections.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, but the description adds no additional behavioral context beyond stating it lists history. It does not explain pagination, rate limits, or what 'historical' means (e.g., time range criteria).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
At only five words, the description is overly terse. It fails to front-load critical information about parameters or behavior, sacrificing completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of multiple sibling tools with similar names, a paginated list with three parameters, and an output schema (unseen), the description lacks essential details such as what constitutes a 'historical' connection, how pagination works, or what the returned data contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the three parameters (limit, offset, fetch_all), despite a 0% schema description coverage. The parameters control pagination and fetching behavior, but the description provides no hints about their meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'historical backplane connections', which is a specific verb and resource. It distinguishes the historical nature from current backplane tools like 'list_backplanes', but could more explicitly contrast with 'get_backplane_history' (singular) which might retrieve a single entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_backplane_history' or 'list_backplanes'. There is no mention of prerequisites, typical use cases, or scenarios where this tool is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List backplane status (inter-node media connections).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the tool is safe. The description adds minor context about what backplane status represents, but no additional behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler, earning its place by clearly stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be described. However, the description does not address the pagination parameters (limit, offset, fetch_all), which are crucial for effective use of a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for limit, offset, or fetch_all parameters. The description adds no value beyond the parameter names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists backplane status with a parenthetical clarifying 'inter-node media connections'. It distinguishes from siblings like get_backplane (singular) and list_backplane_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. With a large sibling set including get_backplane and list_backplane_history, the description does not clarify when to choose list_backplanes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all locations monitored for dynamic bursting.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds context about the subset of locations but no additional behavioral traits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not mention pagination behavior or the fetch_all parameter, which are important for using the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain the parameters but provides no details about limit, offset, or fetch_all, leaving the agent without guidance on how to paginate or control output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the specific resource 'locations monitored for dynamic bursting', distinguishing it from siblings like 'list_locations' and 'get_cloud_monitored_location'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for locations related to dynamic bursting) but does not explicitly state when not to use it or provide alternatives like 'list_locations' for all locations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all cloud overflow Conferencing Nodes (dynamic bursting).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds the specific object type ('cloud overflow') but does not disclose additional behaviors like pagination limits or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no extraneous words. It is front-loaded with the core purpose. However, it could be slightly expanded to include parameter documentation without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (so return values are documented) and annotations cover safety, the description is minimally adequate. Missing usage guidelines and parameter explanation reduce completeness for a tool with three parameters and many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. However, it provides no information about 'limit', 'offset', or 'fetch_all'. The parameter names are somewhat self-explanatory but an AI agent would benefit from explicit documentation of pagination semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the specific resource 'cloud overflow Conferencing Nodes (dynamic bursting)'. It distinguishes from sibling tools like 'list_conferencing_nodes' by specifying 'cloud overflow' and 'dynamic bursting'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'list_conferencing_nodes' or 'get_cloud_node'. The description does not mention prerequisites, when not to use it, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all locations containing Conferencing Nodes for dynamic bursting.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent; description adds context about content but no additional behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes tool purpose; output schema exists for return values, so no need to detail them. Missing parameter descriptions slightly detract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description does not explain the generic pagination parameters (limit, offset, fetch_all).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists locations containing Conferencing Nodes for dynamic bursting, differentiating it from siblings like 'list_locations' and 'get_cloud_overflow_location'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for dynamic bursting but no explicit guidance on when to use vs other list tools or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List conference instances broken out per Conferencing Node (shards).
Args: conference_name: Filter by conference name. limit, offset, fetch_all: Pagination controls.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No | ||
| conference_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context (e.g., rate limits, auth requirements) beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—one sentence plus a bullet-like list of parameters. It is front-loaded with the main purpose, and every sentence is useful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple list operation with output schema, the description covers the purpose and parameter roles adequately. However, it could briefly mention that it returns shard details (though output schema may cover that).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining conference_name as a filter and grouping limit, offset, fetch_all as pagination controls. This adds meaning beyond schema titles, though fetch_all's precise behavior (overriding pagination) is not fully detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists conference instances broken out per Conferencing Node (shards), which is a specific verb and resource. It distinguishes from sibling tools like list_active_conferences (lists conferences, not shards) and get_conference_shard (gets a single shard).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies it's for listing shards, but does not mention when not to use or provide comparisons to similar list operations like list_active_conferences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List conference synchronization status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no behavioral context (e.g., pagination, rate limits, data freshness). With annotations present, the bar is lower, but zero additional value yields a 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence) but underspecified. It is not efficiently informative; the brevity sacrifices essential details. Every sentence should earn its place, but this sentence adds little beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has pagination parameters and an output schema, the description should explain listing behavior (e.g., pagination defaults, what fetch_all does). It lacks such context, leaving the agent uninformed. Though output schema exists, the description remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 3 parameters (limit, offset, fetch_all) with 0% description coverage. The description does not mention or explain any parameters, failing to compensate for the missing schema descriptions. Baseline would be 3 if coverage high, but here it is low and uncompensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description merely repeats the tool name 'List conference synchronization status' without explaining scope or differentiating from sibling tools like 'get_conference_sync_status'. It lacks specificity about what is listed (e.g., all entries, filtered).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Sibling tools include many list/get variants, but the description does not note when to choose this over similar ones (e.g., get_conference_sync_status for a single item).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Conferencing Nodes (the worker_vm resource).
Args: location: System location id or exact name to filter by. name_contains: Case-insensitive substring match on node name. node_type: "CONFERENCING" or "PROXYING". limit: Max results. offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| location | No | ||
| node_type | No | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, idempotentHint: true, and destructiveHint: false, covering safety and idempotency. The description adds minimal behavioral insight beyond parameter descriptions, but there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a one-line summary followed by a clear bulleted parameter list. Every sentence adds value, and it is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and all parameters adequately. An output schema exists, so return values are implied. However, it does not mention default pagination behavior or ordering, which would be helpful for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains each of the 5 parameters (location, name_contains, node_type, limit, offset) with meaningful context beyond the schema types and defaults, such as 'System location id or exact name' and 'Case-insensitive substring match'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List Conferencing Nodes (the worker_vm resource)', which is a specific verb and resource. It distinguishes from sibling tools like 'get_conferencing_node' (singular retrieval) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as using 'get_conferencing_node' for a single node or other list tools for different resources. The description lacks context about prerequisites or filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List provisioned devices (registration records).
Args: alias_contains: Case-insensitive substring match on the device alias. owner_email: Filter by primary owner's email address (exact). tag: Filter by tag. limit: Max results. offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | ||
| limit | No | ||
| offset | No | ||
| owner_email | No | ||
| alias_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds minimal behavioral context beyond clarifying that it lists 'provisioned devices (registration records)'. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose followed by a clean list of parameters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and all parameters clearly. With an output schema present, return values need not be described. Lacks only usage guidelines against siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining each parameter's purpose (e.g., 'alias_contains: Case-insensitive substring match'). This adds useful meaning beyond the schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List provisioned devices (registration records)' which clearly identifies the resource and action. However, it does not distinguish from the sibling tool 'list_registrations', which may overlap in function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_device' or 'list_registrations'. The description only lists parameters without context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List directory end users.
Args: email_contains: Case-insensitive substring match on primary_email_address. name_contains: Case-insensitive substring match on display_name. sync_tag: Filter by LDAP sync tag. limit: Max results. offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| sync_tag | No | ||
| name_contains | No | ||
| email_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that filters are case-insensitive substring matches and mentions pagination parameters, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear purpose statement followed by parameter details. Could be slightly more concise, but the args block is clear and no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers all necessary input parameters and basic behavior. It omits details like default pagination values but those are in the schema defaults. Adequate for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by clearly explaining each parameter's purpose and behavior (e.g., case-insensitive matching for email_contains and name_contains). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'list' and the resource 'directory end users'. The parameter descriptions further clarify the scope. Differentiates from sibling 'get_end_user' by listing many rather than one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_end_user'. Does not state prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Secure Scheduler for Exchange integration status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, so the description adds minimal behavioral context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but lacks sufficient detail, making it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A list tool with three parameters and no parameter explanation is incomplete; the description fails to provide necessary context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about what limit, offset, or fetch_all mean.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (Secure Scheduler for Exchange integration status), distinguishing it from the sibling get_exchange_scheduler_status, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as when to list vs get a single status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List dial plan gateway routing rules, ordered by priority ascending.
Args: name_contains: Case-insensitive substring match on rule name. enabled_only: If true, returns only enabled rules. limit: Max results. offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| enabled_only | No | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, so safety is clear. Description adds useful ordering information (by priority ascending) beyond the annotations, but does not mention pagination behavior or potential edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief and front-loaded with the main purpose. Parameter list is clean and uses consistent formatting. No redundant or extraneous sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only nature (annotations), presence of output schema, and standard pagination, the description sufficiently covers the tool's behavior. All key aspects—sort order, parameter semantics, and purpose—are addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description fully compensates by explaining each parameter: name_contains (case-insensitive substring match), enabled_only (filters enabled rules), limit (max results), offset (pagination offset). This adds significant meaning beyond the schema's type/default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists dial plan gateway routing rules, ordered by priority ascending. The verb 'List' and specific resource are well-defined, distinguishing it from the sibling 'get_gateway_rule' which retrieves a single rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'get_gateway_rule'. However, the naming convention (list vs get) implies standard list behavior, and the context of sibling tools makes the use case clear. Lacks explicit when-not or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List completed conference instances.
Args: start_time: Lower bound (inclusive) on conference start_time. ISO 8601 in UTC, e.g. "2026-05-07T00:00:00". end_time: Upper bound (exclusive) on conference start_time. UTC ISO 8601. name: Filter by exact instance name. service_type: "conference" / "lecture" / etc. tag: Filter by service tag. limit, offset, fetch_all: Pagination controls.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | ||
| name | No | ||
| limit | No | ||
| offset | No | ||
| end_time | No | ||
| fetch_all | No | ||
| start_time | No | ||
| service_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds valuable behavioral context by specifying that it lists completed instances and supports time-range filtering, pagination, and other filters. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose line followed by parameter explanations in a bullet-like format. It is concise enough, though the 'Args:' block could be slightly more compact. Still, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All 8 parameters are covered, and the output schema exists, so return values need not be described. The description includes filtering options and pagination. However, it does not mention any prerequisites or common use cases, which would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed explanations for all 8 parameters, including format examples for start_time and end_time (ISO 8601), exact-match semantics for name, and pagination controls. This significantly adds value beyond the schema, which has 0% description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List completed conference instances', which is a specific verb-resource combination. It distinguishes itself from sibling tools like list_active_conferences (active vs completed) and get_history_conference (singular, likely by ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as list_active_conferences or get_history_conference. The context of 'completed' is implied, but no direct comparison or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List completed participant call legs (CDR-like records).
Time bounds apply to participant.start_time. All times are UTC ISO 8601.
Args: start_time: Lower bound (inclusive) on start_time. end_time: Upper bound (exclusive) on start_time. conference_name: Restrict to one conference name (string, not id). call_direction: "in" / "out". call_quality: "1_good" / "2_ok" / "3_bad" / "4_terrible". protocol: "sip" / "h323" / "mssip" / "webrtc" / "rtmp" / "teams" / etc. disconnect_reason: e.g. "Call disconnected", "Call failed", "Call rejected". location: system_location id or exact name. service_tag: Filter by tag carried from the parent conference. limit, offset, fetch_all: Pagination. fetch_all caps at 10,000.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| end_time | No | ||
| location | No | ||
| protocol | No | ||
| fetch_all | No | ||
| start_time | No | ||
| service_tag | No | ||
| call_quality | No | ||
| call_direction | No | ||
| conference_name | No | ||
| disconnect_reason | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, covering safety. The description adds behavioral details: pagination cap at 10,000, UTC ISO 8601 time format, and filter specifics. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise yet comprehensive: a one-line summary followed by a list of parameter explanations. Every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, output schema exists, and no nested objects, the description covers input semantics thoroughly. It could optionally define 'CDR-like records' more precisely, but overall complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's meaning, format, and acceptable values (e.g., call_quality options). This provides essential context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List completed participant call legs (CDR-like records)', specifying the resource and action. It distinguishes from siblings like 'get_history_participant' and 'list_active_participants' by focusing on completed calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical data via time bounds and filters but lacks explicit when-to-use vs alternatives. No mention of when not to use or comparisons with other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List IVR themes (branding bundles assignable to VMRs).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description only needs to add context beyond safety. It adds minimal context (that themes are assignable to VMRs), but does not describe pagination behavior or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 11 words, front-loaded with the core action. Every word adds value, and no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description omits key usage details: how pagination works, what the filter parameter does, and what the response contains. For a tool with three parameters, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does not mention any parameters (limit, offset, name_contains) or explain their meaning, leaving the agent to infer from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List IVR themes' with a parenthetical defining what IVR themes are ('branding bundles assignable to VMRs'), distinguishing it from the sibling 'get_ivr_theme' which retrieves a single theme.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that 'get_ivr_theme' should be used for a single theme, nor does it specify any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured LDAP / Active Directory sync sources.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide safety profile (readOnly, idempotent, non-destructive). The description adds no extra behavioral details, such as pagination behavior or result limits, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence that is concise and front-loaded, containing no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema covers return values, the description lacks parameter documentation and context about filtering or pagination, which is needed for a tool with multiple optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any of the three parameters (limit, offset, name_contains), leaving the agent without guidance on their meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists configured LDAP/Active Directory sync sources. It distinguishes itself from sibling tools like 'get_ldap_source' (which retrieves a single source) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage to list LDAP sources but provides no explicit guidance on when to use this tool vs alternatives like 'get_ldap_source', or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List system locations (logical groupings of Conferencing Nodes, typically per datacenter / region).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds context about what a location is, but does not disclose additional behavioral traits beyond annotations (e.g., no mention of pagination, rate limits, or filtering behavior).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having three parameters and filtering/pagination capabilities, the description omits these aspects. It does not mention that name_contains allows filtering or that limit/offset control pagination. The output schema exists but the description does not complete the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation coverage is 0%; the description does not explain any of the three parameters (limit, offset, name_contains). It fails to compensate for the lack of parameter documentation, providing no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'system locations', and explains what a location is (logical groupings per datacenter/region). This distinguishes it from sibling tools like 'get_location'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing locations but provides no explicit guidance on when to use this tool vs alternatives (e.g., get_location, list_location_statistics). The usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List live status for system locations.
Args: name_contains: Case-insensitive substring match on location name. limit, offset, fetch_all: Pagination controls.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's mention of 'live status' adds real-time context. No additional behavioral traits (e.g., rate limits, fetch_all override behavior) are disclosed, which leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose followed by parameter explanations in a clear list. No unnecessary words, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and read-only annotations, the description covers core functionality. It misses clarifying fetch_all's interaction with limit/offset, but overall is sufficient for a filtered-list tool with good structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by explaining name_contains as a case-insensitive substring match and grouping limit/offset/fetch_all as pagination controls. However, it does not detail fetch_all's behavior (e.g., ignoring limit/offset), leaving a semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'live status for system locations', with a specific verb ('List') and resource, distinguishing it from sibling tools like get_location_status (single location) and list_locations (locations without status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives. It does not mention that get_location_status is for a single location or that list_locations lists locations without status. No exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Management Node live status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, idempotent behavior. The description adds only 'live status', implying dynamic data, but provides no additional behavioral context such as rate limits, auth needs, or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but lacks necessary detail. It front-loads the purpose but does not earn its place by adding value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description could skip return value details, but it fails to explain the paging parameters or what 'live status' entails. The tool is simple but the description is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; limit and offset are not explained. The description does not add any meaning about paging or how to use the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists live status of management nodes, matching the name. It distinguishes from 'get_management_node_status' (single node) and other list tools by specifying 'management node', though it could be more explicit about listing all nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_management_node_status' or other list tools. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List One-Touch Join endpoint live status.
Args: name_contains: Case-insensitive substring match on endpoint name. limit, offset, fetch_all: Pagination controls.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, indicating a safe read operation. The description adds context by specifying 'live status' and describing the name filter and pagination, which enhances transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, uses a clear structure with labeled args, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be detailed. The description adequately covers the tool's purpose and main parameters. It could mention the scope (e.g., 'lists all MJX endpoints'), but current text is sufficient for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'name_contains' as case-insensitive substring match and 'limit, offset, fetch_all' as pagination controls, adding meaning beyond the schema titles. However, the pagination description is somewhat generic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists 'One-Touch Join endpoint live status', using a specific verb and resource. It distinguishes from sibling tools like 'get_mjx_endpoint_status' and 'list_mjx_meeting_status' by focusing on live status of endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The pagination controls imply listing, but there's no mention of when to choose this over 'get_mjx_endpoint_status' or other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List One-Touch Join meeting status (upcoming meetings detected by MJX).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about the meeting type ('One-Touch Join') and scope ('upcoming meetings'), but does not disclose additional behavioral traits like pagination behavior or auth requirements. With annotations covering safety, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, concise and front-loaded with the core purpose. No redundant information, but it could be slightly more structured with parameter hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits guidance on pagination and the optional parameters. For a list tool with multiple optional inputs, more context is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for the three parameters (limit, offset, fetch_all). The description only hints at the list content but does not clarify how parameters control the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('One-Touch Join meeting status' and 'upcoming meetings detected by MJX'). It distinguishes from siblings like 'get_mjx_meeting_status' (singular) and 'list_mjx_endpoint_status' (endpoint vs meeting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or scenarios where another tool (e.g., 'get_mjx_meeting_status') would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Conferencing Node status event history.
Args: start_time: Lower bound (inclusive). UTC ISO 8601. end_time: Upper bound (exclusive). UTC ISO 8601. limit, offset, fetch_all: Pagination controls.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| end_time | No | ||
| fetch_all | No | ||
| start_time | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive behavior. The description adds value by clarifying bounds (inclusive/exclusive for start/end times) and pagination controls, but does not disclose other behavioral details like return format or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with purpose, followed by a concise argument list. It is well-structured and avoids redundancy, though the argument list could be integrated into the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and main parameters, but does not explain what fields are in the event history or any special behaviors. An output schema exists, so some context is provided, but more detail on the returned data would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining start_time as lower bound inclusive, end_time as upper bound exclusive, and describing limit/offset/fetch_all as pagination controls. However, individual parameter descriptions are minimal and not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List Conferencing Node status event history,' specifying the verb and resource. It distinguishes from sibling tools like get_node_event_history by implying list vs get, but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_node_event_history or other list tools. The description only states what it does without contextual usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live status (load, sync, version, boot time) for each Conferencing Node.
Args: location: Filter to one system_location by name or id. name_contains: Case-insensitive substring match on node name. limit, offset, fetch_all: Pagination controls.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| location | No | ||
| fetch_all | No | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds that the status is 'live', which provides temporal context. It does not contradict annotations. It could further detail pagination behavior or result ordering, but the combination of annotations and description is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence defining the tool's output, followed by bullet-point parameter explanations. Every sentence serves a purpose with no redundancy. The structure is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (unseen) and rich annotations, the description adequately covers the tool's purpose and key parameters. It does not explicitly state that the result is a list, but 'for each Conferencing Node' implies multiple records. For a read-only listing tool, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains the purpose of 'location' (filter by system_location), 'name_contains' (case-insensitive substring), and groups 'limit, offset, fetch_all' as pagination controls. This adds meaning beyond the raw schema, though it does not specify data formats or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 'Live status (load, sync, version, boot time) for each Conferencing Node'. The verb 'list' aligns with returning multiple items, and the resource 'node_status' is specific. The description effectively distinguishes from sibling tools like 'get_node_status' (single node) and 'list_conferencing_nodes' (node listing without status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains filtering by location and name_contains, and pagination controls, which imply usage scenarios. However, it does not explicitly state when to use this tool over alternatives like 'get_node_status' or 'list_conferencing_nodes'. The guidance is implicit through parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List currently registered aliases on the platform.
Args: alias_contains: Case-insensitive substring match on the alias. limit, offset, fetch_all: Pagination controls.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No | ||
| alias_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context (case-insensitive substring filtering, pagination controls) beyond the annotations, but could be more explicit about result size or limitations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence for purpose plus a brief bullet for arguments. Front-loaded with the core functionality. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations and existing output schema, the description covers the essential function and argument semantics. However, it lacks clarification on how this tool differs from similar siblings (e.g., list_aliases) and does not mention anything about authentication or result ordering, but overall it is sufficient for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'alias_contains' as 'case-insensitive substring match' and groups 'limit, offset, fetch_all' as 'pagination controls'. These add meaning beyond the schema types and defaults, though more detail could be given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List currently registered aliases on the platform' with a specific verb and resource. However, it does not explicitly distinguish itself from siblings like 'list_aliases' or 'get_registration_alias', so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It only lists arguments without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List historical registration events.
Args: alias_contains: Case-insensitive substring match on the alias. limit, offset, fetch_all: Pagination controls.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No | ||
| alias_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe read behavior. The description adds pagination controls and filter details but no additional behavioral traits like data freshness or limits. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one opening sentence and a bullet list of args. It is front-loaded with purpose and wastes no words. Easily scannable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple list operation with filters and pagination, and given that annotations provide full safety context and an output schema likely documents return format, the description covers the essentials. Minor gap: no mention of maximum page size or behavior when fetch_all is true.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description is the sole source of parameter meaning. It explains alias_contains as a case-insensitive substring match and group limit/offset/fetch_all as pagination controls. However, it lacks details on defaults, fetch_all behavior (e.g., ignoring limit), and no explanation of other implicit constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists historical registration events. However, it does not distinguish from sibling tools like 'get_registration_history' or 'list_registrations', which could cause confusion about when to use this tool over alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when-not-to-use, or context about the data scope. The description simply lists parameters without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List endpoints currently registered to the platform (live Status API read).
This is the runtime counterpart to the device records: who is registered right now, on what node and protocol — not the configured allow-list.
Args: alias_contains: Case-insensitive substring match on the registered alias. protocol: "sip" / "h323" / "mssip" / "webrtc". limit, offset, fetch_all: Pagination controls (fetch_all walks all pages).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| protocol | No | ||
| fetch_all | No | ||
| alias_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that this is a 'live Status API read' and 'runtime counterpart,' providing context beyond annotations that it reads current state. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences for purpose and context, plus arg explanations in a bullet-like format. Purpose is front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, useful annotations, and an output schema (not needing return description), the description covers the live view distinction, explains all parameters, and contrasts with sibling tools. No essential information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description fully compensates by explaining all 5 parameters with detailed semantics: alias_contains is case-insensitive substring, protocol lists specific values, and pagination controls include fetch_all for walking all pages. This adds substantial value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'List endpoints currently registered to the platform (live Status API read).' It uses a specific verb ('List') and resource ('endpoints registered'), and distinguishes from siblings by calling itself 'runtime counterpart to the device records' and 'not the configured allow-list,' contrasting with tools like list_devices and list_registration_aliases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear context: it is for live registrations now, as opposed to device records or allow-lists. While it doesn't name alternative tools or state explicit 'when not to use,' the contrast with 'configured allow-list' and 'device records' implies when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List any Pexip configuration resource that has no dedicated tool.
This is the catch-all listing tool. Supported resources by area:
Admin auth & roles: authentication, role, ldap_role, permission, adfs_auth_server, adfs_auth_server_domain, identity_provider, identity_provider_group, user_group, user_group_entity_mapping.
Integrations & signaling: teams_proxy (Microsoft Teams Connectors), azure_tenant (Teams CVI tenant), gms_access_token, gms_gateway_token (Google Meet), ms_exchange_connector, exchange_domain, sip_proxy, sip_credential, mssip_proxy, h323_gatekeeper, turn_server, stun_server, policy_server, policy_profile, break_in_allow_list_address, telehealth_profile.
Scheduling & sync: registration, conference_sync_template, ldap_sync_field, scheduled_conference, scheduled_alias, recurring_conference.
Media library: media_library_entry, media_library_playlist, media_library_playlist_entry.
Platform & certificates: management_vm, licence, licence_request, media_processing_server, diagnostic_graphs, ca_certificate, tls_certificate, certificate_signing_request.
MJX / One-Touch Join: mjx_integration, mjx_endpoint, mjx_endpoint_group, mjx_meeting_processing_rule, mjx_exchange_deployment, mjx_exchange_autodiscover_url, mjx_graph_deployment, mjx_google_deployment.
System infrastructure: dns_server, ntp_server, http_proxy, syslog_server, snmp_network_management_system, smtp_server, static_route, ssh_authorized_key.
Backups & upgrades: system_backup (existing system backups), autobackup (backup schedule), upgrade, software_bundle, software_bundle_revision, scheduled_scaling.
Web app: webapp_alias, webapp_branding, external_webapp_host.
Call get_resource_schema(resource) to discover filterable fields.
Args: resource: API resource name from the list above (e.g. "sip_proxy", "system_backup", "teams_proxy", "dns_server"). name_contains: Case-insensitive substring match on the name field. filters: Additional query filters as key-value pairs (e.g. {"enable": true}). Keys must match the resource's field names. limit: Max results per page (default 20). offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| filters | No | ||
| resource | Yes | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, making the safety profile clear. The description adds no further behavioral details (e.g., pagination defaults, auth requirements) beyond the resource scope, so it does not significantly extend transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured into a purpose statement, categorized resource list, a cross-reference note, and labeled parameter descriptions. While lengthy due to the exhaustive resource list, every section adds necessary value for a catch-all tool. A slight improvement could be a more compact grouping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's broad scope (many configuration resources) and the existence of an output schema, the description covers purpose, all supported resources (key for catch-all), parameter semantics, and cross-reference for filters. It is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It explains each parameter: resource (with reference to the enumerated list), name_contains (case-insensitive substring match), filters (key-value pairs with key constraint), limit, and offset (pagination). This fully compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists any Pexip configuration resource that has no dedicated tool, with a comprehensive categorized list. This distinguishes it from sibling tools that target specific resources or provide different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly calls it a 'catch-all' tool and lists all supported resources, implying usage when no dedicated list tool exists. It also references get_resource_schema for filterable fields, guiding effective use. However, it does not explicitly state when NOT to use it, but the resource list effectively conveys scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Teams Connector call status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no behavioral context, such as what 'call status' encompasses or pagination behavior. It is essentially redundant with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
At only 5 words, the description is concise but under-specified. It lacks necessary information to be useful, so conciseness is not achieved effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, three pagination parameters, and many sibling tools, the description is severely incomplete. It fails to explain the scope of the list (e.g., whether it lists all call statuses or filtered by some criteria) or how it differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any parameter (limit, offset, fetch_all) or their role in pagination. This is a severe gap for a list tool with three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'List' and resource 'Teams Connector call status', so it is clear what the tool does at a basic level. However, it does not differentiate from sibling tools like 'list_teams_node_status' or 'get_teams_node_call_status', lacking specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_teams_node_call_status' for a single status. No context for parameters like limit, offset, or fetch_all is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Teams Connector node status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| fetch_all | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint, which describe safety and idempotency. The description adds no additional behavioral traits (e.g., pagination behavior or rate limits), so it meets a baseline but does not enhance understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one phrase), which is concise but omits necessary context. While no wasted words, it is under-specified for a list operation with pagination.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 optional parameters and an existing output schema, the description fails to convey what the output contains or how pagination works. Sibling tools add variety but no differentiation is provided, making the tool less complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions in the schema. The description does not explain the parameters (limit, offset, fetch_all) or their interactions (e.g., fetch_all overriding limit), leaving the agent to infer from defaults and types alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'List' and resource 'Teams Connector node status', indicating a listing operation. However, it does not differentiate from sibling 'get_teams_node_status' which likely returns a single node's status, missing an opportunity to clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_teams_node_status'. The description does not mention pagination or batch retrieval scenarios, leaving the agent without context on typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List VMRs (Pexip conference objects with service_type=conference).
Args: name: Exact name match. name_contains: Case-insensitive substring match on name. tag: Filter by tag. limit: Max results (default 20). Use 0 to return all (avoid on large platforms). offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | ||
| name | No | ||
| limit | No | ||
| offset | No | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint (true) and idempotentHint (true), so the description doesn't need to reiterate safety. However, it adds no extra behavioral details beyond parameter constraints, which is adequate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences for purpose, then a bullet-like list of parameters. Every line adds value, no waste. Front-loaded with what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with an output schema, the description covers all input parameters well, including pagination details and a warning. It lacks output description but output schema handles that. Minor gap: no mention of default sorting or total count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: exact name match, case-insensitive substring, tag filter, limit with default and warning about 0, and offset for pagination. This significantly aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists VMRs (Pexip conference objects) with a specific condition (service_type=conference), distinguishing it from generic list tools and the singular get_vmr.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_vmr or other list tools. The agent must infer usage from the name and parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize / report on call history — grouped counts and totals over a window.
USE THIS for any "summarize", "report", "breakdown", "how many calls by X", "stats", or "totals" request. Returns aggregated counts + durations grouped by a field — NOT individual records. Prefer this over list_history_conferences / list_history_participants whenever the user wants aggregates rather than a raw list; it walks pagination internally and is far cheaper on context and tool calls than fetching individual records.
Args: start_time: Lower bound (inclusive) on start_time. UTC ISO 8601 required. end_time: Upper bound (exclusive) on start_time. UTC ISO 8601 required. group_by: One of "call_direction", "call_quality", "protocol", "service_tag", "system_location", "conference_name", "disconnect_reason", "vendor". conference_name: Restrict to one conference name. service_tag: Restrict to one tag. call_direction: "in" or "out" — useful when group_by is something else. location: system_location filter (name or id). max_records: Hard cap on participants fetched. Defaults to 10,000 (the platform retention limit).
Returns: { "total_calls": int, "total_duration_seconds": int, "average_duration_seconds": float, "time_range": {"start": ..., "end": ...}, "group_by": str, "groups": {: {"count": int, "duration_seconds": int}, ...}, "truncated": bool # true if max_records was hit before exhausting results }
| Name | Required | Description | Default |
|---|---|---|---|
| end_time | Yes | ||
| group_by | No | call_direction | |
| location | No | ||
| start_time | Yes | ||
| max_records | No | ||
| service_tag | No | ||
| call_direction | No | ||
| conference_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds behavioral details: it returns aggregated counts/durations, walks pagination internally, and provides a truncation flag. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, usage guidelines, parameter list, and return format. It is front-loaded with the core purpose and each sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count (8), output schema presence, and annotation richness, the description covers all essential aspects: what the tool does, when to use it, all parameters, and the return format including truncation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides comprehensive parameter explanations (start_time, end_time, group_by, etc.) including types, defaults, and constraints. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool summarizes/reports on call history with grouped counts and totals. It uses specific verbs and resource, and distinguishes from sibling tools like list_history_conferences by noting it provides aggregates rather than raw lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'USE THIS for any summarize, report, breakdown, how many calls by X, stats, or totals request.' It also explicitly counsels against using sibling tools when aggregates are needed, explaining cost benefits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0get_active_participantget_alarm_historyget_backplaneget_backplane_historyget_backplane_history_media_streamsget_backplane_media_streamsget_cloud_monitored_locationget_cloud_nodeget_cloud_overflow_locationget_conference_shardget_conference_sync_statusget_conferencing_nodeget_deviceget_end_userget_exchange_scheduler_statusget_gateway_ruleget_global_settingsget_history_conferenceget_history_participantget_ivr_themeget_ldap_sourceget_licensing_statusget_locationget_location_statisticsget_location_statusget_management_node_statusget_mjx_endpoint_statusget_mjx_meeting_statusget_node_event_historyget_node_statisticsget_node_statusget_participant_qualityget_registration_aliasget_registration_historyget_resourceget_resource_schemaget_teams_node_call_statusget_teams_node_statusget_vmrlist_active_conferenceslist_active_participantslist_alarm_historylist_alarmslist_aliaseslist_automatic_participantslist_backplane_historylist_backplaneslist_cloud_monitored_locationslist_cloud_nodeslist_cloud_overflow_locationslist_conference_shardslist_conference_sync_statuslist_conferencing_nodeslist_deviceslist_end_userslist_exchange_scheduler_statuslist_gateway_ruleslist_history_conferenceslist_history_participantslist_ivr_themeslist_ldap_sourceslist_location_statuslist_locationslist_management_node_statuslist_mjx_endpoint_statuslist_mjx_meeting_statuslist_node_event_historylist_node_statuslist_registration_aliaseslist_registration_historylist_registrationslist_resourceslist_teams_node_call_statuslist_teams_node_statuslist_vmrssummarize_callsScored across 76 tools
Tools clearly distinguish between active and historical states, and different resource types (participants vs conferences vs nodes). However, the high number of similar get/list pairs (e.g., get_node_statistics vs get_node_status) could confuse agents, though descriptions help.
Almost all tools follow a consistent verb_noun pattern with get_ and list_ prefixes in snake_case. Exceptions like summarize_calls and get_resource_schema are minor and still descriptive. No mixing of conventions.
With 76 tools, the count far exceeds the 25+ threshold considered 'too many.' While the domain is complex, this many tools risks overwhelming agents and increases cognitive load. A more curated set or consolidated tools could improve usability.
The tool set covers a wide range of read and monitoring operations across conferences, participants, nodes, configurations, and history. The catch-all list_resources fills many gaps. Missing write operations (create/update/delete) are acceptable given the read-only intent, but a few minor read gaps exist (e.g., no get_alarm for active alarms).
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP-Native LLM Orchestration Agent
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Josh-E-S/pexip-mgmt-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server