A skeptical senior-engineer code reviewer over MCP: risk-scans unified diffs, flags AI-generated-code tells, reports complexity hotspots, scans for leaked secrets, and runs an OWASP security pass — real analyzers, no external APIs. Free tier, no signup.
Flag the tells of unreviewed AI-generated code in a source file. FREE.
Detects comments that restate the next line, leaked assistant preambles, placeholder TODOs, shipped 'Example usage' blocks, over-broad try/except that swallows errors, and auto-named identifiers. Typical input {"code": ""} returns {"reviewed_confidence": 0-100, "hits": [{"smell": "...", "evidence": ""}], "reading": "...", "note": "..."}.
Use on a full source file suspected of unreviewed machine authorship. Not on a diff (review_diff), and the result is a signal to check, not proof of authorship. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Full source text to scan, any language; paste the file contents as a single string. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds critical behavioral details: error handling ('never raises a protocol error — it returns an error object with fix instructions') and idempotency guarantee ('after correcting the input it is always safe to retry'). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: purpose first, then examples, usage guidelines, error behavior, and idempotency note. Every sentence adds value. Minor extraneous text ('FREE') but overall excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers almost all aspects: what smells are detected, input/output format, error handling, usage context, and intentional limitations (signal vs. proof). The presence of an output schema further reduces the burden on the description. Very comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear parameter description. The description adds only a typical input example, which is helpful but does not significantly extend the schema's meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Flag the tells of unreviewed AI-generated code in a source file.' It clearly identifies the tool's unique role among siblings (vs. review_diff) by focusing on full source files and AI smeels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('on a full source file suspected of unreviewed machine authorship'), when not to use ('Not on a diff'), and names the alternative tool ('review_diff'). It also clarifies the result is a 'signal to check, not proof of authorship,' setting proper expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report structural complexity of a source file, function by function. FREE.
Measures per-function length, max nesting depth, and a cyclomatic-style branch count (if/for/while/case/&&/||/except), flagging functions too long or too deeply nested to review confidently. Typical input {"code": ""} returns {"functions": N, "detail": [{"name": ..., "start": N, "lines": N, "branches": N, "max_depth": N}], "flags": ["..."], "note": "..."}.
Use when structure rather than correctness is the question. Not for vulnerabilities (security_deep_dive). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Full source text to analyze, pasted as a single string. | |
| language | No | Optional language hint, e.g. "python" or "javascript"; "auto" (default) detects from syntax. | auto |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=true and idempotentHint=true, the description further enhances transparency by explaining the error behavior: 'this tool never raises a protocol error — it returns {"error": ...}'. It also explicitly states that retrying is safe: 'after correcting the input it is always safe to retry'. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very efficient. It starts with a clear single-purpose statement, then lists metrics. Uses whitespace effectively 'FREE' to highlight key aspect. The multi-line structure is readable. Every sentence is necessary, and the example input/output clarifies the tool's behavior without extra fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters (1 required), 100% schema coverage, and an output schema, the description fully covers the usage. The description explains the output structure ('functions, detail array with name/start/lines/branches/max_depth, flags, note'). It also explains the error case behavior. Nothing is missing for this tool's complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about the `code` parameter format ('Full source text to analyze, pasted as a single string.') but does not add significant meaning beyond the schema. The language parameter is also described adequately. No deduction needed as schema fully covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Report structural complexity of a source file, function by function.' It uses specific verbs like 'Report' and identifies the resource as a source file's complexity. It also distinguishes itself from siblings like 'security_deep_dive' by noting it's for structure, not vulnerabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use when structure rather than correctness is the question.' It also clearly states when not to use it: 'Not for vulnerabilities (security_deep_dive).' This directly addresses when-to-use and when-not-to-use, making it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load the Senior Reviewer persona for consistent, high-signal reviews. PREMIUM (license).
The persona is a reviewing voice that is skeptical, specific, and kind — demands evidence over vibes and blocks only on real risk. Takes no arguments. Returns {"persona": ..., "identity": ..., "rules": ["...", ...], "opening_move": "..."} ready to adopt as a system prompt.
Use to keep repeated reviews consistent in voice and rigor. Not for running a review - the scan tools do that. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description goes beyond by detailing error handling behavior ('never raises a protocol error — it returns an error object'), output structure, and the license requirement. This adds significant behavioral context that the agent needs to invoke the tool correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, front-loading the main purpose, then providing usage guidelines, error handling, and behavioral notes. Every sentence adds value without redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, has an output schema, and annotations cover safety traits, the description is complete. It covers purpose, usage, error handling, output structure, and behavioral traits. No gaps are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. The description states 'Takes no arguments,' which only confirms what the schema already shows. It adds no new parameter-level meaning, so 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool loads a Senior Reviewer persona for consistent, high-signal reviews. It explicitly distinguishes itself from sibling scan tools by stating 'Not for running a review - the scan tools do that.' The verb 'load' and resource 'Senior Reviewer persona' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use to keep repeated reviews consistent in voice and rigor' and 'Not for running a review - the scan tools do that.' It also advises on safe retry behavior and mentions the license requirement, giving clear context for when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce a focused pull-request review checklist for a language or stack. FREE.
Covers the things that actually break in production, with extra items per language. Typical input {"language": "python"} returns {"language": "python", "checklist": ["...", ...], "note": "..."}.
Use before a review, to decide what to look for. Not for reviewing actual code - pass code to review_diff or security_deep_dive. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language or stack to tailor for: "python", "javascript", "typescript", "go", "sql", or "general" (default). Unknown values fall back to the general checklist. | general |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's job is partly done. However, the description adds unique value by explaining the error behavior ('never raises a protocol error — it returns {"error": ...}) and clarifying that it is 'FREE', which is not in annotations. It also states 'Every call is read-only and idempotent', consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with key information front-loaded (purpose, cost, scope), example usage, usage guidelines, and error handling. Each sentence adds value. Slightly redundant with annotations on idempotency/read-only, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description clarifies return values with a concrete example. It covers error behavior, fallback handling, cost, and usage context. No gaps remain for a tool with one parameter and clear sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description goes beyond by providing a comprehensive example of typical input/output, listing supported language values explicitly, and explaining fallback behavior for unknown values. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Produce a focused pull-request review checklist for a language or stack', using a specific verb ('produce') and resource ('checklist'), and explicitly distinguishes itself from siblings by stating 'Not for reviewing actual code - pass code to review_diff or security_deep_dive'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use before a review, to decide what to look for' and 'Not for reviewing actual code - pass code to review_diff or security_deep_dive', clearly stating when to use it and which sibling tools to use instead. It also mentions error handling and retry behavior, providing complete usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Risk-scan a unified diff the way a senior reviewer triages a PR. FREE.
Flags added lines matching known risk patterns — injection sinks, disabled TLS, bare excepts, debug prints, TODOs, N+1 hints, leaked secrets — with the new-file line number and a severity (1 low - 4 high). Typical input {"diff": ""} returns {"added_lines": N, "risk_score": 0-100, "verdict": "...", "secrets": [...], "findings": [{"line": N, "severity": 1-4, "issue": "...", "code": "..."}], "note": "..."}.
Use on a unified diff, when only the change matters. Not for whole-file analysis (complexity_report, ai_code_smell_scan). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| diff | Yes | A unified diff exactly as produced by `git diff` — text with @@ hunk headers and +/- line prefixes. Only added (+) lines are scanned. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which align with the tool's description of being read-only and idempotent. The description adds value by specifying that the tool never raises protocol errors on invalid input, instead returning a structured error message with guidance. This goes beyond the annotation coverage to clarify error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with 6 sentences. The first two sentences define purpose and output format, front-loading key info. The use of a free statement and example JSON are efficient. Minor redundancy: 'FREE' standalone could be integrated. Overall, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and is detailed in the description, return values are well-covered. The description addresses edge cases (invalid input), maps to sibling tools, and includes error handling. A slight gap: no mention of rate limits or size limits for the diff, but not critical for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds meaning by clarifying the expected format ('exactly as produced by `git diff` — text with @@ hunk headers'), the scanning scope ('only added (+) lines are scanned'), and by providing an example input/output structure. This compensates for the schema's brief description of 'diff'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Risk-scan a unified diff' and distinguishes it from siblings like 'complexity_report' and 'ai_code_smell_scan' by noting it works only on changes, not whole files. The verb 'risk-scan' combined with 'unified diff' clearly delimits the resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use ('on a unified diff, when only the change matters') and when not to ('not for whole-file analysis'), naming alternatives (complexity_report, ai_code_smell_scan). It also includes error recovery instructions by noting the tool returns an error message and is safe to retry after input correction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan text for accidentally-committed machine credentials and private-key material. FREE.
Reports each match's location and category so it can be rotated before it leaks. Detection is pattern-based over the common leaked-credential formats; it never echoes the matched value back. Typical input {"text": "<file, diff, or config contents>"} returns {"leaked": bool, "count": N, "findings": [{"line": N, "type": ""}], "note": "..."}.
Pattern matching only - a clean result is not proof, and every hit needs human confirmation before anyone acts on it. Not a general security review (security_deep_dive). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The file, diff, or config contents to scan, pasted as a single string. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, destructiveHint, idempotentHint), the description adds important behavioral details: it never echoes matched values, errors return an error object instead of protocol errors, and every call is idempotent and safe to retry. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose statement, then output and behavioral details, followed by limitations and error handling. Every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, clear annotations, and an output schema), the description covers all necessary context: input format, output structure, error handling, idempotency, and limitations. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter and 100% schema coverage, the description adds significant value by showing the exact input format and expected response structure. It also clarifies error behavior on invalid input, which goes well beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Scan text for accidentally-committed machine credentials and private-key material,' using a specific verb and resource. It explicitly distinguishes itself from the sibling tool security_deep_dive by noting it is 'Not a general security review.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (scanning for leaked credentials) and when not (not for general security reviews, names the alternative security_deep_dive). Also advises that clean results are not proof and require human confirmation before action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an OWASP-oriented security pass over a source file. PREMIUM (license).
Checks injection sinks, auth/session handling, crypto misuse, SSRF/deserialization, and unsafe file/path handling — each finding cites the line, the OWASP risk class, and a concrete fix direction. Typical input {"code": ""} returns {"issues": N, "findings": [{"line": N, "class": "A03 Injection", "fix": "...", "code": "..."}], "owasp_note": "..."}.
Use on one source file when vulnerabilities are the question. Not for style or structure (complexity_report), and never a substitute for a security professional on high-risk code. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Full source text to audit, pasted as a single string; any common language. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true. The description reinforces these by stating 'Every call is read-only and idempotent.' It adds valuable context beyond annotations: error handling (returns error objects instead of protocol errors), licensing (PREMIUM), and retry safety. No contradictions. Minor gap: does not describe rate limits or specific authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: first sentence states purpose, then lists checks, provides input/output example, usage guidance, error handling, and idempotency statement. Every sentence adds value with no repetition or fluff. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, full schema coverage, annotations covering idempotency and read-only, and an output schema exists (though not provided in full), the description compensates by showing the output shape. It also covers licensing, error handling, and usage boundaries. No obvious gaps for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'code' described as 'Full source text to audit...'. The description adds significant meaning beyond the schema by providing an example input/output format ({'code': '<file contents>'}) and showing the expected return structure with fields like issues, findings, owasp_note. This helps the agent understand how to construct the input and interpret results, which is not in the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs an OWASP-oriented security pass on a source file, lists specific checks (injection, auth, crypto, etc.), and differentiates from sibling 'complexity_report' by specifying it is not for style or structure. This provides a specific verb+resource with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use on one source file when vulnerabilities are the question' and warns 'Not for style or structure (complexity_report)' and 'never a substitute for a security professional on high-risk code.' It also explains error behavior and retry safety. However, it does not mention alternative siblings like secret_scan or ai_code_smell_scan, leaving some gaps in tool comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
ai_code_smell_scancomplexity_reportget_reviewer_personareview_checklistreview_diffsecret_scansecurity_deep_diveClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: AI smell detection, structural complexity, persona loading, checklist generation, diff risk scanning, secret scanning, and security deep dive. No two tools overlap in function, and descriptions explicitly state what each should not be used for.
All tool names use snake_case and are readable. However, the pattern varies: some are verb_noun (get_reviewer_persona, secret_scan) while others are noun phrases (complexity_report, review_diff). This minor inconsistency prevents a perfect score.
Seven tools cover the code review domain well without being excessive. Each tool addresses a specific aspect of code quality, security, and AI authorship detection. The scope is focused and no tool seems superfluous.
The tool set covers most analysis needs for code review: full-file scans, diff analysis, secret detection, security audit, and context like persona and checklist. A minor gap is the lack of an aggregation tool to combine results into a unified review report, but the core analysis workflows are complete.