Calls, errors and duration percentiles for this tenant over a window.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | ||
| tenant_key | No | The key `signup` returned. Required only when this connection carries no Authorization: Bearer header -- when both are present, the header wins. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It does disclose the nature of the result—calls, errors, and duration percentiles—and scopes it to a tenant, which is helpful. It does not mention whether the operation is read-only, how tenant authentication is resolved, how windows are interpreted, or whether results are aggregated or raw.
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, compact sentence with no filler words. It front-loads the main output metrics and scoping context, making it easy to parse; it is perhaps too sparse, but that is a completeness issue rather than a conciseness or structure issue.
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 tool with no output schema and no annotations, the description leaves important operational details unresolved: window value format, default behavior for optional parameters, and whether the metrics are counts, rates, or per-request breakdowns. The tenant_key/auth nuance is covered by the schema, but the most ambiguous parameter, window, is not explained sufficiently for a confident call.
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 only 50%: tenant_key is documented in the schema, but window has no description. The description's phrase 'over a window' only loosely echoes the parameter and does not explain accepted formats, defaults, or examples, so it fails to compensate for the undocumented window 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 names the specific resource (host usage) and the key metrics returned: calls, errors, and duration percentiles, scoped to a tenant over a window. It is clearer than the tool name alone, though it lacks an explicit verb such as 'retrieve' or 'get' and does not explicitly distinguish itself from siblings like host.tool_logs.
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 a usage/observability purpose: an agent would use it to inspect call volumes, failures, and latency percentiles for a tenant over a time window. However, it gives no explicit guidance about when to prefer it over related tools such as host.tool_logs, host.tool_call, or host.tool_run, and it does not mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target a clearly distinct resource or lifecycle stage, with billing, secret, and tool-publishing groups nicely separated. The main ambiguity is among host.tool_call, host.tool_test, and host.tool_run, which all invoke a published tool in slightly different modes; the descriptions clarify this, but the names alone could mislead an agent.
The namespace prefixes billing.* and host.* provide a consistent organizational pattern, and host.tool_* tools use a predictable resource-action style. Deviations like signup, host.quickstart, host.usage, and host.whoami break the pattern, but they are few and still readable.
At 17 tools, the server is slightly over the typical well-scoped 3-15 range, but the breadth is justified by the multi-tenant hosting domain: signup, billing, tool lifecycle, secrets, debugging, and usage observability each need dedicated tools. Every tool has a plausible role, so the count feels reasonable rather than bloated.
The tool lifecycle is well covered with publish, list, test, run, call, logs, and remove, and billing/usage/signup are present. Notable gaps remain, though: secret_set has no corresponding secret_delete, there is no tenant update/delete operation, and host.registry_publish references admin.tenant_verify_namespace, which is not exposed in this tool set.