glama-status-mcp

by sandraschi

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Some overlap exists between dedicated report tools (glama_daily_report, glama_scores_summary) and the glama_status tool which has its own 'report' and 'list' operations. Descriptions try to clarify, but an agent might struggle to choose the correct tool for a given task.
Naming Consistency5/5
All tools follow a consistent 'glama_<descriptive_name>' pattern in snake_case, with clear verb_noun or descriptive names. There is no mixing of conventions or confusing styles.
Tool Count5/5
With 7 tools, the set is well-scoped for monitoring and analyzing Glama scores. Each tool has a distinct purpose, and the count feels neither too few nor too many.
Completeness4/5
The set covers analysis, reporting, summary, detailed queries, and rich cards. Missing a direct submission tool is acceptable as it's outside the server's scope. Minor gaps like lacking a bulk update feature are not critical.
Average 3.9/5 across 7 of 7 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on June 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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, the description should disclose behavioral traits. It only lists output fields but does not explain real-time behavior, authentication needs, or error conditions.
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?
Extremely concise: one sentence stating purpose and a line listing outputs. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with an output schema, the description sufficiently explains what is returned. However, lacks context on when to invoke.
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?
No parameters exist, and schema coverage is 100%. The description adds no parameter info, but baseline is 4 since no parameters need explanation.
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 it returns a compact fleet-wide score summary and lists output fields. However, it does not differentiate from sibling tools like glama_agentic_analyze or glama_generate_reports.
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 guidance on when to use this tool versus alternatives. The description only states what it does, not when or why to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool uses LLM sampling via MCP ctx.sample, which implies it may have latency or cost implications. However, it does not clarify if the tool is read-only or creates persistent data, and no safety or permission details are given. Annotations are empty, so the description carries full burden.
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 concise with two sentences. The first sentence captures the core purpose, and the second adds an important implementation detail. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description appropriately omits return value details. It mentions the use of MCP ctx.sample, which is critical context. However, it could briefly note prerequisites (e.g., need for a connected LLM) or how results are presented.
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%, and the tool description adds no new meaning beyond what the schema already provides for the single parameter 'repo_name'. The schema already explains the parameter, so the tool description does not enhance understanding.
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 it analyzes Glama scores using LLM sampling and generates fixable todos. This distinguishes it from sibling reporting tools like glama_daily_report or glama_scores_summary, which likely provide summaries without analysis or task generation.
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 guidance is provided on when to use this tool versus alternatives like glama_daily_report or glama_generate_reports. The description does not mention use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the side effect of creating files in reports/ and the conditional behavior for all repos, but lacks details on overwriting behavior, concurrency, or permissions.
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?
Three sentences with front-loaded purpose, no redundant information, and clear structure: purpose, details, conditional behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and one parameter with 100% schema coverage, the description covers the main behavior and parameter effect. Lacks guidance on choosing between sibling tools, but otherwise complete.
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 schema describes the parameter as optional with a default, and the description adds the crucial context that an empty value triggers generation for all scored repos, enhancing understanding beyond the schema alone.
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 generates markdown analysis reports for repos, specifying output format (markdown) and directory (reports/). However, it does not explicitly distinguish from sibling tools like glama_daily_report or glama_scores_summary.
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 provides guidance on when to use the repo_name parameter (empty generates all scored repos) but doesn't advise on when to use this tool vs alternatives like glama_daily_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It describes a read-only operation ('shows', 'displays') and lists the data categories. No mention of side effects or limitations, but the behavior is clear enough for a display 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?
Two sentences, no wasted words. The first sentence states the main action and output format; the second lists details. Efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers what the tool does and what it returns (TDQS, grades, per-tool scores). It is sufficient for an agent to understand the tool's purpose.
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 coverage is 100% with a clear description for the only parameter. The description adds that it is 'per-repo' and 'for a single repo', reinforcing the parameter meaning but not adding substantial new info beyond the schema.
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 clearly states the tool shows 'per-repo Glama score breakdown as a rich Prefab card' and lists what is displayed. This distinguishes it from siblings like 'glama_scores_summary' which likely covers multiple repos.
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 use when needing a specific repo score breakdown, but does not explicitly state when to use or not use, nor mention alternatives. Given siblings, clearer guidance would help.
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 return format (ToolResult with PrefabApp card and plain-text fallback) but does not disclose behavioral traits such as read-only nature, idempotency, or any side effects. No reference to authentication or data freshness is made.
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?
Description is brief, front-loaded with purpose, followed by content list, return format, and example usage. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description covers purpose, displayed information, and return format. It lacks mention of error cases or prerequisites (e.g., authentication), but is sufficient for a simple status card.
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?
No parameters exist, so schema coverage is 100%. Description adds no parameter info as there are none, but baseline 4 is appropriate since the schema already covers everything.
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?
Explicitly states it shows fleet Glama score overview as a Prefab card, listing specific displayed content (grade distribution, per-repo scores, worst tools, stale repos). Clearly distinguishes from sibling tools like show_glama_repo_card (single repo) and glama_status (text status).
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?
Description implies usage for fleet-wide overview via 'Show fleet Glama score overview' and provides examples. However, no explicit when-not-to-use or alternative guidance is given. In context of siblings, the purpose is clear but not formally stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description carries full burden. It describes generating a report, typical of a read-only operation, but does not explicitly state whether the tool is non-destructive or has side effects. The precondition is useful, but more transparency about behavioral traits (e.g., read-only) is needed.
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 efficient with three sentences plus a list. It is front-loaded with purpose and contents, followed by usage guidelines. Each sentence earns its place, though the structure is slightly fragmented.
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?
For a simple tool with one optional parameter and an output schema, the description covers purpose, contents, usage conditions, and preconditions. It is complete enough for an agent to use correctly without needing additional context.
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% for the single parameter 'format', which already provides a clear description. The tool description does not add any additional parameter semantics beyond what is in the schema, so baseline score of 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 clearly states the tool generates a daily fleet health report and lists its contents (grade distribution, recent changes, worst tools, stale repos). It distinguishes from sibling tools by explicitly stating when not to use (for single repo details use glama_status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('once daily for comprehensive fleet Glama score overview'), when NOT to use ('for single repo details use glama_status'), and lists a precondition ('at least one refresh must have been run'). This provides excellent guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden. It details each operation (list, get, worst_tools, refresh, etc.) and mentions preconditions, but does not explicitly state side effects or mutability. While it covers the purpose of operations like 'refresh' (rescrape) and 'add_repo' (add a repo), it lacks explicit disclosure of whether operations are destructive or require special permissions. However, the level of detail provided is sufficient for basic understanding, warranting a score of 4.
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 front-loaded with a clear summary, followed by structured sections for usage guidance, preconditions, and operations. It is well-organized but slightly lengthy due to the detailed operation list. Every sentence adds value, and the structure aids readability. It could be slightly more concise, but it's effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple operations, 3 parameters, no annotations, and an output schema), the description covers key aspects: when to use, operations, preconditions, and parameter roles. It does not explain return values, but the presence of an output schema mitigates this. The description is sufficiently complete for an agent to understand and invoke the tool correctly.
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?
Schema coverage is 100% (all parameters described in input schema), but the description adds value by listing all operations beyond the schema's description, which omits 'add_repo', 'remove_repo', and 'reload_config'. The description clarifies the meaning of each operation and the context for 'repo_name' (required for get). It compensates for the schema's incompleteness, adding meaningful context for parameter usage.
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 clearly states the tool as a 'Fleet-wide Glama score tracker -- query per-tool TDQS grades.' It lists specific operations and distinguishes from siblings by specifying when to use (fleet scores, docstring fixes, refresh) and when not to use (code diagnostics, submission/review). The verb 'query' and resource 'Glama scores' are explicitly defined, and the tool is differentiated from siblings like 'glama_scores_summary' and 'show_glama_repo_card' through usage guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to use:' and 'When NOT to use:' sections. It provides clear context for appropriate use: checking fleet scores, finding tools needing docstring fixes, triggering a refresh. It also specifies when not to use: for code diagnostics use repo's own tools, for submission/review use glama.ai. Additionally, it mentions preconditions (repo must have been submitted and scored), offering comprehensive guidance for agent decision-making.
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:

[![glama-status-mcp MCP server](https://glama.ai/mcp/servers/sandraschi/glama-status-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sandraschi/glama-status-mcp)

Score Badge

Copy to your README.md:

[![glama-status-mcp MCP server](https://glama.ai/mcp/servers/sandraschi/glama-status-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sandraschi/glama-status-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/sandraschi/glama-status-mcp'

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