Reviewer MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as generate_spec for document creation, review_code for code feedback, and run_tests for testing. However, review_code and run_linter could be confused as both involve code quality checks, though their descriptions clarify that review_code provides feedback while run_linter runs a standardized tool. Overall, the overlap is minimal and manageable.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern, such as generate_spec, review_code, run_tests, and notify. There are no deviations in naming conventions, making the set predictable and easy to understand. This consistency enhances usability and reduces cognitive load for agents.
Tool Count5/5
With 8 tools, the count is well-scoped for a server focused on code review and development tasks. Each tool serves a specific function, such as specification handling, code review, testing, and utilities like notifications and music. This number is neither too sparse nor overwhelming, fitting the server's purpose effectively.
Completeness3/5
The tool set covers key aspects of code review and development, including specification generation, code review, linting, and testing. However, there are notable gaps, such as the lack of tools for updating or deleting specifications, managing review history, or integrating with version control systems. These omissions could limit workflow coverage and cause agent inefficiencies.
Average 3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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 provided, the description carries full burden for behavioral disclosure. It mentions 'Run' but doesn't specify whether this is a read-only analysis or if it modifies files (though the 'fix' parameter hints at potential changes). It lacks details on permissions needed, side effects (e.g., file modifications), output format, or error handling, which are critical for a tool that might alter code.
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. It's front-loaded with the core action and target, making it easy to parse quickly. No unnecessary words or redundancy are present.
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 a linter tool (which can analyze and potentially fix code), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., linting results, success/failure), behavioral traits like side effects, or how it differs from siblings. This leaves significant gaps for an agent to use it effectively.
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 already documents both parameters ('fix' and 'files') clearly. The description adds no additional meaning about parameters beyond what's in the schema, such as how 'files' are resolved or what 'fix' entails. This meets the baseline for high schema coverage but doesn't enhance understanding.
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 states the action ('Run') and target ('standardized linter for the project'), which gives a basic understanding of purpose. However, it's vague about what 'standardized linter' means (e.g., which language, what rules), and doesn't distinguish this from sibling tools like 'review_code' or 'run_tests' that might also analyze code quality. It avoids tautology 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 provides no guidance on when to use this tool versus alternatives. There's no mention of context (e.g., after code changes, as part of CI/CD), prerequisites, or comparisons to siblings like 'review_code' or 'run_tests'. This leaves the agent guessing about appropriate usage scenarios.
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 mentions the OpenAI O3 model but doesn't describe what this tool actually does behaviorally - whether it makes API calls, has rate limits, requires authentication, returns structured data, or has any side effects. 'Generate' implies creation but lacks operational details.
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 wasted words. It's appropriately sized for a tool with 3 parameters and gets straight to the point without unnecessary elaboration.
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?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what kind of specification document is generated, what the output looks like, whether this involves external API calls, or any operational constraints. The description leaves too many open questions for effective tool selection.
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 already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain how parameters interact or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 action ('Generate') and resource ('specification document'), and mentions the specific model ('OpenAI O3 model'), which provides good specificity. However, it doesn't differentiate from sibling tools like 'review_spec' or explain what type of specification document is generated.
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 'review_spec' or other sibling tools. There's no mention of prerequisites, appropriate contexts, or when not to use this tool.
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 mentions platform limitation (macOS only) and implies interaction with Spotify, but doesn't describe what happens when actions are invoked (e.g., does 'play' start playback, does 'info' return track details?), error conditions, or authentication requirements. For a tool with multiple actions and parameters, 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 extremely concise (7 words) and front-loaded with all essential information: tool purpose and key constraint. Every word earns its place with zero wasted text, 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?
For a tool with 4 parameters, multiple actions, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (especially for 'info' action), how parameters interact (e.g., can 'uri' and 'mood' be used together?), or error handling. The high parameter count and action complexity require more contextual guidance than provided.
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 parameters well-documented in the schema itself (e.g., 'action' enum values, 'volume' range, 'mood' options). The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without compensating value.
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: 'Control Spotify for background music (macOS only)'. It specifies the action (control), target resource (Spotify for background music), and platform constraint (macOS only). However, it doesn't distinguish this tool from sibling tools like 'notify' or 'review_code', which serve completely different domains, so sibling differentiation isn't relevant here.
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 minimal usage guidance with the 'macOS only' constraint, but offers no guidance on when to use specific actions (e.g., 'play' vs 'playpause') or parameters (e.g., 'uri' vs 'mood'). It doesn't mention alternatives or exclusions, leaving the agent to infer usage from the schema 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 'audio notifications' and 'macOS only', but fails to disclose key behavioral traits such as whether it's read-only or destructive, authentication needs, rate limits, or error handling. The description is too vague to inform the agent adequately about how the tool behaves beyond basic functionality.
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 with a single sentence, front-loaded with the core purpose and key constraint ('macOS only'). Every word earns its place, with no redundancy or unnecessary details, making it 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 no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits, return values, error cases, and usage context. For a tool with 4 parameters and platform-specific constraints, more detail is needed to ensure the agent can use it correctly without relying on external knowledge.
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 all parameters. The description adds no additional meaning beyond what the schema provides, such as examples or context for parameter use. Baseline score of 3 is appropriate as the schema handles parameter documentation, but the description doesn't compensate or 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 the verb ('Provide audio notifications') and resource ('to users'), specifying the action and target. It distinguishes from siblings by mentioning 'audio notifications' and 'macOS only', though it doesn't explicitly differentiate from similar notification tools that might exist elsewhere. The purpose is specific but could be more distinct regarding sibling tools.
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 minimal guidance with 'macOS only', indicating a platform restriction. However, it lacks explicit when-to-use instructions, alternatives, or context for choosing this tool over others. No mention of prerequisites, timing, or comparison with sibling tools like 'music' or 'review_code' is made, leaving usage unclear.
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 the tool reviews code and provides feedback, but doesn't describe what the feedback looks like (e.g., format, detail level), whether it's automated or human-like, if it has limitations (e.g., language support), or any side effects. This is inadequate for a tool with 3 parameters and no output schema.
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 (6 words) and front-loaded with the core purpose. Every word earns its place with no redundancy or unnecessary elaboration.
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 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (feedback format), behavioral traits, or usage context. For a code review tool that likely produces complex output, this leaves significant gaps for the agent.
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 already documents all parameters thoroughly. The description adds no additional meaning about parameters beyond what's in the schema (e.g., it doesn't explain what 'all' means for reviewType or how diff and context interact). Baseline 3 is appropriate when schema does the heavy lifting.
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 action ('review code changes') and outcome ('provide feedback'), which is specific and actionable. However, it doesn't distinguish this tool from potential siblings like 'run_linter' or 'review_spec', which might also involve code review aspects.
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 'run_linter' or 'review_spec'. It doesn't mention prerequisites, context, or exclusions, 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 the full burden of behavioral disclosure. It mentions reviewing for 'completeness' and providing 'critical feedback', but lacks details on what the feedback entails (e.g., format, depth), whether it's a read-only operation, or any constraints like rate limits or permissions needed.
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 is front-loaded with the core action and outcome. It wastes no words and clearly communicates the tool's function without unnecessary elaboration.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose but lacks details on behavioral traits, usage context, and output expectations, leaving gaps for the agent to navigate.
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 already documents both parameters ('spec' and 'focusAreas') adequately. The description adds minimal value beyond the schema by implying the 'spec' is reviewed for completeness and feedback, but doesn't provide additional syntax or format details for 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 ('review') and resource ('specification'), and it indicates the outcome ('provide critical feedback'). However, it doesn't explicitly differentiate from sibling tools like 'review_code' or 'run_linter', which might also involve reviewing documents or code for quality.
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 sibling tools like 'review_code' (for code reviews) or 'generate_spec' (for creating specifications), leaving the agent to infer usage context without explicit direction.
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 that coverage runs when no pattern is specified, which adds some context about default behavior. However, it doesn't describe critical aspects like whether this is a read-only or destructive operation, what permissions are required, how long tests might take, error handling, or output format. For a tool that executes tests (potentially with side effects), this is a significant gap.
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 and front-loaded: a single sentence that directly states the purpose and key usage detail. Every word earns its place, with no redundancy or fluff. It efficiently communicates the core functionality and the pattern-coverage relationship.
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 complexity (executing tests, potentially with coverage), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and parameter implication but misses details like what 'coverage' entails, how results are returned, error conditions, or side effects. For a test-running tool, users need more context about execution behavior and outputs.
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 description adds meaningful semantics beyond the input schema. The schema has 100% coverage with one parameter ('pattern'), but the description explains the behavioral implication of omitting it: 'runs coverage mode if omitted'. This clarifies that the parameter is optional and affects the tool's mode, which isn't evident from the schema alone. With only one parameter and high schema coverage, the description compensates well.
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: 'Run standardized tests for the project' with the specific verb 'Run' and resource 'standardized tests'. It distinguishes itself from sibling tools like 'run_linter' (code quality) and 'review_code' (code review). However, it doesn't explicitly differentiate from 'generate_spec' or 'review_spec' which might be related to testing workflows.
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 implied usage guidance: it mentions coverage runs when no pattern is specified, suggesting this tool is for executing tests with optional filtering. However, it doesn't explicitly state when to use this versus alternatives like 'run_linter' for code quality checks or 'review_code' for manual inspection, nor does it mention 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 provided, the description carries the full burden of behavioral disclosure. It does reveal the critical behavioral trait that 'data is lost on MCP server restart' which is essential for understanding the tool's limitations. However, it doesn't cover other important behaviors like performance characteristics, concurrency considerations, or error handling.
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 - a single sentence that efficiently communicates both the core functionality and a critical limitation. Every word earns its place, and the most important information (data persistence characteristic) is included upfront.
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 moderate complexity (5 parameters, multiple actions) and no annotations or output schema, the description provides the minimum viable information. It covers the basic purpose and a key limitation but lacks details about return values, error conditions, or operational constraints that would be helpful for an AI agent.
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 schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
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's purpose with specific verbs ('store and retrieve') and resource ('temporary key-value pairs in memory'), plus it distinguishes this tool from siblings by specifying the data persistence characteristic ('data is lost on MCP server restart'). This goes beyond just restating the name 'memory'.
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 any sibling tools or other memory/storage options, nor does it specify prerequisites, constraints, or typical use cases beyond the basic functionality.
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:

[![mcp_reviewer MCP server](https://glama.ai/mcp/servers/jaggederest/mcp_reviewer/badges/card.svg)](https://glama.ai/mcp/servers/jaggederest/mcp_reviewer)

Score Badge

Copy to your README.md:

[![mcp_reviewer MCP server](https://glama.ai/mcp/servers/jaggederest/mcp_reviewer/badges/score.svg)](https://glama.ai/mcp/servers/jaggederest/mcp_reviewer)

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/jaggederest/mcp_reviewer'

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