Claude Telemetry MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
The tools have overlapping purposes that could cause confusion, particularly around usage retrieval. For example, get_today_usage, get_week_usage, get_current_session_usage, and get_usage_summary all provide usage metrics with unclear boundaries between them. However, descriptions help differentiate some tools like compare_usage_periods and get_usage_trends.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., get_usage_summary, check_usage_limits, estimate_remaining_capacity), which is predictable and readable. There are minor deviations like compare_usage_periods (verb_noun_noun) and get_telemetry_health, but overall the naming is coherent.
Tool Count4/5
With 12 tools, the count is reasonable for a telemetry server focused on usage monitoring and analytics. It's slightly on the higher side but still well-scoped, as each tool appears to serve a distinct analytical function without obvious redundancy.
Completeness5/5
The tool set provides comprehensive coverage for telemetry and usage analytics, including current metrics, historical trends, comparisons, capacity estimation, and health checks. There are no obvious gaps; agents can monitor, analyze, and manage usage effectively without dead ends.
Average 3.1/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('compare') without disclosing behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, or what the output format might be. It lacks details on how the comparison is performed or any side effects.
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 a single, efficient sentence with zero waste, front-loading the core purpose. It's appropriately sized for a simple tool, making it easy for an agent to parse quickly.
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?
Given the complexity of comparing usage data, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'usage' entails, how results are formatted, or any limitations, leaving significant gaps for the agent to infer behavior.
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?
The input schema has 100% description coverage, clearly documenting both parameters with defaults. The description adds no additional meaning beyond the schema, as it doesn't explain parameter interactions or usage context. Baseline 3 is appropriate since the schema does the heavy lifting.
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?
The description 'Compare usage between different time periods' states a clear verb ('compare') and resource ('usage'), but it's vague about what specific usage metrics are compared and doesn't distinguish from sibling tools like 'get_usage_trends' or 'get_usage_summary' which might offer similar functionality. It provides a basic purpose but lacks specificity.
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 offers no guidance on when to use this tool versus alternatives like 'get_usage_trends' or 'get_usage_summary' from the sibling list. It implies usage comparison but doesn't specify contexts, exclusions, or prerequisites, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'estimate' which implies a calculation, but doesn't disclose behavioral traits like whether it requires authentication, how it handles missing parameters, if it's read-only or has side effects, or what the output format might be. For a tool with zero annotation coverage, this is inadequate.
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 a single, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy or fluff. It's appropriately sized for a simple tool with two parameters.
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?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the estimation returns (e.g., percentage, absolute values, timeframes), how it calculates capacity, or error conditions. For a tool in a crowded sibling set with complex usage tracking context, more completeness is needed.
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 schema fully documents both parameters. The description adds no additional meaning beyond what's in the schema (e.g., no explanation of how daily vs weekly limits interact, default behaviors, or unit details). Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('estimate') and resource ('remaining usage capacity') with scope ('for specified daily/weekly limits'). It distinguishes from siblings like 'get_current_session_usage' or 'get_usage_summary' by focusing on capacity estimation rather than raw usage data retrieval. However, it doesn't explicitly differentiate from all siblings like 'check_usage_limits' which might overlap conceptually.
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 provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'get_today_usage', 'get_week_usage', 'check_usage_limits'), there's no indication of when this estimation tool is preferred over direct usage retrieval tools. It lacks context about prerequisites, timing, or comparative advantages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'over time' and 'identify patterns', which hints at temporal analysis, but doesn't specify what data is returned (e.g., time series, aggregated metrics), whether it's read-only (implied by 'Get'), or any constraints like rate limits or authentication needs. For a tool with no annotations, this leaves significant behavioral gaps.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Get usage trends over time') and adds the goal ('to identify patterns') concisely. Every part of the sentence contributes meaning.
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?
Given no annotations and no output schema, the description is incomplete for effective tool use. It doesn't explain what 'usage trends' entail (e.g., metrics returned, format), how patterns are identified, or any behavioral aspects like error conditions. For a tool with 1 parameter but rich sibling context, more detail is needed to guide the agent properly.
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?
The input schema has 100% description coverage, with the single parameter 'days_back' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3. Since there's only one parameter, the description doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'usage trends over time' with the purpose 'to identify patterns'. It distinguishes from siblings like 'get_usage_summary' or 'get_today_usage' by focusing on trends over time rather than current or summary data. However, it doesn't explicitly differentiate from 'compare_usage_periods' which might also involve temporal analysis.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'get_usage_summary', 'get_today_usage', and 'compare_usage_periods', there's no indication of when this trend analysis tool is preferred over other usage-related tools. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Get breakdown' but doesn't specify what the breakdown includes (e.g., metrics, timeframes), whether it's read-only or has side effects, or any constraints like rate limits or authentication needs. This leaves significant gaps in understanding the tool's behavior.
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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and clear, though it could be slightly more structured by specifying scope (e.g., 'for the current session' or 'across all tools').
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?
Given the complexity of usage analytics and lack of annotations or output schema, the description is incomplete. It doesn't explain what the breakdown entails (e.g., data format, included metrics), making it hard for an agent to use effectively without additional context or trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could slightly enhance value by hinting at implicit parameters (e.g., default timeframes), though not required. Baseline is high due to no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('breakdown of tool usage and edit decisions'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_usage_summary' or 'get_session_analytics', which might provide similar breakdowns, so it falls short of a perfect score.
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 provides no guidance on when to use this tool versus alternatives. With multiple sibling tools related to usage (e.g., 'get_usage_summary', 'get_usage_trends'), it lacks explicit context or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'check' implies a read operation, the description doesn't specify whether this requires authentication, has rate limits, returns real-time or cached data, or what format the warnings take. For a tool with 6 parameters and no annotation coverage, this is inadequate behavioral transparency.
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 extremely concise at just 9 words, front-loading the core purpose without any wasted language. Every word earns its place - 'check' (verb), 'current usage' (resource), 'against specified limits' (action), 'and get warnings' (outcome). This is a model of efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with full schema coverage but no annotations and no output schema, the description is minimally adequate. It states what the tool does but lacks context about when to use it versus siblings, what the warnings contain, or behavioral constraints. For a tool with this complexity and no output schema, more completeness would be expected regarding the return value.
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%, with all 6 parameters clearly documented in the schema. The description mentions 'specified limits' which aligns with the parameters, but adds no additional semantic context beyond what's already in the schema descriptions. With complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as checking current usage against specified limits and getting warnings, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_usage_warnings' or 'get_current_session_usage', which appear related. The purpose is clear but lacks sibling differentiation.
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 provides no guidance on when to use this tool versus alternatives. With multiple sibling tools dealing with usage data (compare_usage_periods, get_usage_warnings, get_current_session_usage, etc.), there's no indication of when this specific limit-checking tool is appropriate versus other usage-related tools. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Get usage metrics' but does not specify whether this is a read-only operation, if it requires authentication, any rate limits, or the format of returned data. This leaves significant gaps in understanding the tool's behavior and constraints.
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 a single, efficient sentence that front-loads the core purpose ('Get usage metrics') and specifies the scope ('current Claude Code session') and key metrics ('tokens, cost, activity'). There is no wasted language, making it highly concise and well-structured.
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?
Given the complexity of usage metrics tools and the lack of annotations and output schema, the description is insufficient. It does not explain what the metrics entail, how they are formatted, or any behavioral aspects like data freshness or access requirements. This leaves the agent with incomplete context for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate here. A baseline of 4 is applied as it adequately handles the lack of parameters without introducing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get usage metrics') and resources ('current Claude Code session'), specifying the metrics include tokens, cost, and activity. However, it does not explicitly distinguish it from sibling tools like 'get_today_usage' or 'get_week_usage', which might target similar metrics but different timeframes, leaving some ambiguity in differentiation.
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 provides no guidance on when to use this tool versus alternatives. With multiple sibling tools related to usage (e.g., 'get_today_usage', 'get_week_usage', 'get_usage_summary'), there is no indication of context, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool checks if the telemetry system is 'running and accessible,' which implies a read-only, diagnostic operation, but lacks details on what 'accessible' means, potential error conditions, response format, or any side effects. This is a significant gap for a tool with zero 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core purpose without any wasted words. It is appropriately sized for a simple, no-parameter tool, making it highly efficient and easy to parse.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal but incomplete. It lacks context on what 'running and accessible' entails, expected outputs, or error handling, which are crucial for an agent to use it effectively. The absence of annotations and output schema means the description should compensate more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, which is appropriate, earning a baseline score of 4 for adequately handling the lack of parameters without unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('telemetry system'), and specifies what is being checked ('running and accessible'). It distinguishes itself from sibling tools that focus on usage metrics rather than system health. However, it doesn't explicitly contrast with siblings like 'check_usage_limits' which might also involve system checks.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or context for checking telemetry health, nor does it reference sibling tools for related tasks like monitoring usage or capacity. Usage is implied only by the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves—e.g., whether it's read-only, requires authentication, has rate limits, or what the return format looks like. This is a significant gap for a tool with zero 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get total usage metrics') and adds necessary context ('for the current week (Monday-Sunday)'). There is zero waste, and every word earns its place.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'total usage metrics' includes, the return format, or behavioral traits like error handling. For a tool with no structured data beyond the input schema, more context is needed to be fully helpful to an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter documentation in the description. The description appropriately doesn't mention parameters, earning a high baseline score for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('total usage metrics'), and specifies the time scope ('current week (Monday-Sunday)'). However, it doesn't explicitly differentiate from sibling tools like 'get_today_usage' or 'get_usage_summary', which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives like 'get_today_usage' or 'get_usage_summary'. It implies usage for current week metrics but doesn't specify exclusions or prerequisites, leaving the agent to infer context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves analytics but doesn't disclose behavioral traits such as whether it requires authentication, has rate limits, returns real-time or historical data, or what format the output takes. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
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 a single, efficient sentence that front-loads the core purpose ('Get analytics about session patterns') and adds clarifying examples ('averages, totals, productivity metrics'). There is no wasted verbiage, and every word earns its place in defining the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description is minimally adequate. It explains what the tool does but lacks details on behavioral context, output format, or differentiation from siblings. For a simple read operation, it meets basic needs but doesn't provide full guidance for an agent in a crowded toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and the baseline for 0 parameters is 4, as it avoids unnecessary detail while matching the schema's simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'analytics about session patterns', with specific examples of metrics (averages, totals, productivity metrics). It distinguishes itself from siblings by focusing on session patterns rather than usage, limits, or telemetry. However, it doesn't explicitly differentiate from all siblings (e.g., 'get_usage_summary' might overlap).
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 provides no guidance on when to use this tool versus its many siblings. With 11 sibling tools focused on usage, analytics, and telemetry, there is no indication of context, prerequisites, or alternatives. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what metrics are retrieved but doesn't describe the return format, whether data is real-time or cached, permission requirements, or rate limits. For a read operation with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that front-loads the core purpose ('Get total usage metrics for today') and lists specific metrics without unnecessary elaboration. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers what metrics are retrieved but lacks details on return format, data freshness, or error handling. For a read-only tool with no structured output, this is minimally viable but leaves gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter details, so it meets the baseline of 4 for tools with no parameters, as it focuses on the tool's purpose without redundant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('total usage metrics for today') with specific metrics listed (tokens, cost, sessions, activity). It distinguishes from siblings like 'get_week_usage' by specifying 'today', but doesn't explicitly differentiate from 'get_usage_summary' or 'get_current_session_usage', keeping it at 4 rather than 5.
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 provides no guidance on when to use this tool versus alternatives like 'get_week_usage' or 'get_usage_summary'. It implies usage for today's metrics but doesn't specify prerequisites, exclusions, or named alternatives, leaving the agent to infer context from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'default thresholds' but doesn't explain what constitutes a warning, how warnings are formatted, whether this is a read-only operation, or if it requires specific permissions. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that front-loads the core purpose ('Get usage warnings') and adds necessary detail ('with default thresholds'). There is no wasted verbiage, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no output schema, and no annotations, the description is minimally adequate. It explains what the tool does but lacks details on behavior, output format, or integration with siblings. For a simple tool, this might suffice, but it doesn't fully address potential agent needs like understanding warning criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by specifying that thresholds are defaulted to 80% and 90%, which provides context beyond the empty schema. This justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('usage warnings'), and specifies the scope ('with default thresholds'). It doesn't explicitly differentiate from siblings like 'check_usage_limits' or 'get_usage_summary', but the focus on warnings with thresholds provides some implicit distinction.
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 explicit guidance on when to use this tool versus alternatives is provided. The description mentions default thresholds (80% and 90%), which implies usage for monitoring near-limit scenarios, but it doesn't specify when to choose this over siblings like 'check_usage_limits' or 'get_usage_summary'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a summary but doesn't describe what 'comprehensive' entails, potential rate limits, authentication needs, or the format of the returned data. This leaves significant gaps for a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information: 'Get comprehensive usage summary for session, today, and this week in one call.' It has zero waste and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description provides basic purpose but lacks details on behavioral aspects like data format or limitations. With no annotations to supplement, it's minimally adequate but leaves gaps in understanding how the tool behaves or what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and the baseline for 0 parameters is 4, as it avoids unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get comprehensive usage summary for session, today, and this week in one call.' It specifies the verb ('Get'), resource ('usage summary'), and scope ('session, today, and this week in one call'). However, it doesn't explicitly differentiate from siblings like 'get_today_usage' or 'get_week_usage' beyond implying comprehensiveness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'comprehensive usage summary... in one call,' suggesting efficiency for aggregated data. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_today_usage' or 'get_week_usage,' nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![claude-telemetry-mcp MCP server](https://glama.ai/mcp/servers/cordlesssteve/claude-telemetry-mcp/badges/card.svg)](https://glama.ai/mcp/servers/cordlesssteve/claude-telemetry-mcp)

Score Badge

Copy to your README.md:

[![claude-telemetry-mcp MCP server](https://glama.ai/mcp/servers/cordlesssteve/claude-telemetry-mcp/badges/score.svg)](https://glama.ai/mcp/servers/cordlesssteve/claude-telemetry-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cordlesssteve/claude-telemetry-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server