MCPulse

Get one tool

get_tool

Read-onlyIdempotent

One tool in detail: outcome breakdown, latency distribution, retries, first-call success, response size, and which tools get called alongside it.

Always returns this tool's numbers broken out per client as well. Read that first when first-call success looks low: a tool that works for one model and not another is a description problem, not a server problem, and the average of the two says neither.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	End date, inclusive, YYYY-MM-DD (UTC).
`mcp`	Yes	The MCP, by name or id. Names are matched case-insensitively; call list_mcps if unsure.
`from`	No	Start date, YYYY-MM-DD (UTC).
`tool`	Yes	The tool name, exactly as the server registered it.
`clients`	No	Narrow to these client names — `claude-desktop`, `cursor`, `unknown`. Omit for every client. Read the per-client split from get_overview first: one model failing where another succeeds is a tool-description problem, and the server-wide average is what hides it.
`last_days`	No	Window ending today, in days — 7 for the last week, 30 for the last month. Ignored when from/to are given.

Output Schema

TableJSON Schema

Name	Required	Description
`range`	Yes	The window these figures cover, echoed back.
`series`	Yes
`totals`	Yes
`clients`	Yes	This tool read by each client. Read this first when first-call looks low: a tool at 76% for one model and 22% for another is a description problem, and the average of the two says neither. Ignores the client filter — comparing one client with itself is not a comparison.
`filters`	Yes
`follows`	Yes
`latency`	Yes
`outcomes`	Yes
`tool_name`	Yes
`granularity`	Yes	`hour` when the window is a single day, `day` otherwise. Decided here rather than guessed from the number of points.
`never_called`	Yes
`schema_bytes`	Yes
`nightly_as_of`	Yes	The last day the nightly pass has walked. Retries, first-call success and tool pairs only exist up to here; null means it has not run over this window at all.
`available_clients`	Yes
`client_first_call_spread`	Yes	The gap between the best and worst client on this tool. The finding is the gap, not either figure. Null with fewer than two clients.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 8, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds real behavioral context beyond annotations: it always returns results broken out per client, and it provides diagnostic meaning for the first-call success metric. This helps the agent interpret results, not just invoke the tool.

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

Conciseness5/5

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

The description is tight and front-loaded: the first sentence states exactly what the tool returns, and the second paragraph explains how to interpret a key metric. There is no filler, and the diagnostic guidance earns its place rather than padding the text.

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

Completeness5/5

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

Given the presence of a rich output schema, 100% parameter coverage, and read-only/idempotent annotations, the description is complete. It explains the tool's scope, the guaranteed per-client breakdown, and the interpretation guidance an agent needs to use the result effectively. Nothing essential is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already documents all six parameters including format, constraints, and semantics. The description does not add new parameter-level detail, but it also does not need to; it stays at the level of what the tool returns. Baseline 3 is appropriate.

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

Purpose5/5

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

The description opens with 'One tool in detail' and enumerates a concrete set of metrics: outcome breakdown, latency distribution, retries, first-call success, response size, and co-called tools. This clearly identifies the resource and the specific analytical angle, distinguishing it from siblings like list_tools (which lists tools) and get_overview (which is broader).

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

Usage Guidelines4/5

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

The description gives actionable guidance: read the per-client breakdown first when first-call success looks low, and explains that a model-specific failure indicates a description problem rather than a server problem. It also points to get_overview for the per-client split and list_mcps for resolving names. It does not explicitly say 'do not use this tool for X', but 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.

All MCPulse tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?