Skip to main content
Glama

metrics_get_resource_usage_metrics_by_user

Read-onlyIdempotent

Retrieve aggregated resource usage metrics for a specified user to monitor deployment consumption and analyze per-user usage.

Instructions

Returns aggregated metrics values of the given user GET /aggregator/api/metrics/deployment/aggregate/users/{userId}

Input Schema

NameRequiredDescriptionDefault
userIdYes(path)
apiVersionNoThe version of the API in yyyy-MM-dd format (UTC). For versioning information refer to /approval/api/about

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.5/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only a raw endpoint path and the word "aggregated"; it says nothing about time-range defaults, aggregation semantics, or permissions, which is where value beyond the annotations would lie.

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

Conciseness3/5

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

Very short and front-loaded, but the second line is a raw REST path that duplicates the title/annotation title rather than earning its place. It is under-specified rather than wasteful.

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?

A metrics-aggregation read tool with no output schema needs the description to explain what dimension the values are aggregated on and over what period. Neither is present, so an agent cannot predict the shape or scope of the response.

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 both userId and apiVersion are documented in the schema; a baseline of 3 applies. The description only restates that the result is scoped to "the given user" and adds no format, constraint, or semantics beyond the schema.

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

Purpose3/5

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

States the verb and resource ("Returns aggregated metrics values of the given user"), but the phrasing is generic: it does not say which metrics, over what window, or with what aggregation. It also does not distinguish itself from siblings metrics_get_resource_usage_metrics and metrics_get_resource_usage_metrics_by_project.

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

Usage Guidelines2/5

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

No when-to-use guidance and no naming of alternatives. With four metrics_* siblings in the list, the description gives no basis for picking this one over the project-scoped or unscoped variants beyond the implied user parameter.

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

Deploy Server

Other Tools