Whisper

agents: policy

whisper_agents_policy

The policy operation on the Whisper control plane, served as CALL whisper.agents({op:'policy', args:{...}}). Requires your Whisper API key. With no arguments it describes what you already have, so the example below runs as published. Example call: {"skill":"agents.policy","input":{}} Needs a linked Whisper account (OAuth) or your API key in the X-API-Key header.

Tool call template

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

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

Input Schema

Name	Required	Description	Default
`input`	No	Arguments for this operation. With none, it describes what you already have.

Output Schema

Name	Required	Description
`rows`	Yes	The answers, one object per row, keyed by the column names above. An empty array means the question was understood and nothing matched, which is an answer and not a failure.
`columns`	Yes	The column names, in order. Every row object has exactly these keys, so this is the row shape and reading it is cheaper than inspecting a row.
`statistics`	No	What the query cost.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

C2.4/5.0

Behavior2/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, and the description adds nothing about what is mutated, whether changes are reversible, or what permissions are needed beyond authentication. Worse, the description frames the no-arg behavior as "describes what you already have" (a read) while annotations set readOnlyHint=false, leaving the agent unsure whether this call can change state. Auth requirements are stated but repeated twice rather than expanded.

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

Conciseness4/5

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

It is short and the key constraint is easy to find, but it is disorganized: the auth requirement is stated twice in different words, and the mid-sentence call-syntax fragment ("served as CALL whisper.agents({op:'policy', args:{...}})") interrupts rather than front-loads the purpose.

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

Completeness2/5

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

An output schema exists, so return values need not be explained, but for a nested-object operation with a false readOnlyHint the description should clarify what the operation does to policy state and when the no-arg introspection form is appropriate. It covers authentication only, leaving the core behavior underspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With one optional parameter and 100% schema description coverage, the schema already carries the semantics; the description's "with no arguments it describes what you already have" merely echoes the schema's own description of the input object. No additional detail is given about the shape of args or what keys the nested input accepts.

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

Purpose2/5

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

"The policy operation on the Whisper control plane" largely restates the title "agents: policy" without saying what the operation actually does or returns. The one substantive hint — "With no arguments it describes what you already have" — suggests an introspection of existing policy, but it is ambiguous whether the tool reads or configures policy, and nothing distinguishes it from the 20+ sibling whisper_agents_* tools.

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

Usage Guidelines2/5

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

The description gives prerequisites (API key, linked Whisper account via OAuth, or X-API-Key header) but no when-to-use guidance. There is no mention of when to pick this over whisper_agents_identity, whisper_agents_firewall, or any other sibling, so the agent has no routing signal. The note that a no-argument call works is the only actionable usage cue.

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

All Whisper tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.