mcp-server
Server Details
Pre-flight check for AI coding agents: hallucinated packages + hardcoded secrets. Free, no account.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 4 of 4 tools scored.
Each tool targets a distinct stage of the security workflow: pre-commit check (pre_flight_check), PR scanning (scan_repository), result retrieval (get_findings), and automated fixing (auto_remediate). No overlapping responsibilities.
All tool names use snake_case and follow a consistent verb_noun pattern: auto_remediate, get_findings, pre_flight_check, scan_repository. No mixed styles or irregularities.
Four tools cover the essential security lifecycle—scan, retrieve, fix, and pre-commit check—without unnecessary additions. The count feels well-scoped for the domain.
The set covers scanning, finding retrieval, remediation, and local pre-commit checks. A minor gap is lack of a tool to list or manage past scans, but the core workflow is complete.
Available Tools
4 toolsauto_remediateAInspect
Generate an automated security fix for a specific finding. Creates a GitHub PR with the patched code. Verifies the fix with Level 1 SAST before opening the PR. Requires authentication, 3 credits, and ANTHROPIC_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Git ref (branch/SHA) | main |
| file | Yes | File path containing the vulnerability (relative, no traversal) | |
| line | Yes | Line number of the finding | |
| repo | Yes | GitHub repository name | |
| owner | Yes | GitHub repository owner | |
| title | Yes | Finding title from scan results | |
| token | Yes | GitHub token with repo write access | |
| severity | Yes | Finding severity | |
| description | Yes | Finding description | |
| finding_type | Yes | Finding type e.g. 'command_injection', 'sql_injection' | |
| recommendation | Yes | Recommended fix from scan results |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: creates PR, runs Level 1 SAST, requires specific credentials and credits. This provides sufficient transparency for an agent to understand side effects and prerequisites.
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?
Description is three sentences, front-loaded with the primary action. Efficient and to the point, with no 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 no output schema, the description covers the tool's main behavior and side effects. Could mention return value (e.g., PR URL), but overall sufficient for understanding the tool's purpose.
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?
Input schema covers 100% of parameters with descriptions. The description does not add extra meaning beyond 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool generates an automated fix, creates a GitHub PR, and verifies with SAST. It distinguishes from sibling tools (get_findings, pre_flight_check, scan_repository) which focus on different stages.
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?
Description mentions prerequisites (authentication, credits, API key) but does not explicitly state when to use this tool versus alternatives or when not to use it. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_findingsAInspect
Retrieve security findings filtered by file or severity. Run scan_repository first to populate results.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | Filter findings to a specific file path | |
| repo | Yes | GitHub repository name | |
| owner | Yes | GitHub repository owner | |
| severity | No | Filter by severity level |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only operation ('retrieve') and discloses the dependency on scan_repository. No side effects, auth needs, or rate limits are mentioned, but the tool's simplicity (reading findings) limits behavioral complexity.
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?
Two succinct sentences: first states purpose, second provides key dependency. No extraneous words, front-loaded for quick understanding.
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 no output schema, the description could mention the response format or behavior when scan_repository hasn't been run. However, it covers the essential purpose and prerequisite, leaving minor gaps for a simple read operation.
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?
Input schema has 100% parameter description coverage, so baseline is 3. The description rephrases the filtering capability but adds no new semantics or examples beyond what the schema already provides.
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?
Description clearly states 'Retrieve security findings filtered by file or severity', specifying the verb (retrieve) and resource (security findings). This distinguishes it from sibling tools like scan_repository (populating) and auto_remediate (fixing).
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 instruction 'Run scan_repository first to populate results' provides a clear prerequisite, guiding the agent to use the correct sequence. However, it does not explicitly state when not to use this tool or mention alternatives beyond the dependency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pre_flight_checkAInspect
Security pre-flight check for local file changes BEFORE committing. Run this whenever you are about to suggest git commit, git push, or open a pull request — especially when changes touch auth, secrets, SQL queries, package.json / requirements.txt, or environment variables. Returns CLEAR or BLOCKED with specific findings and remediation steps.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | Files staged for commit (path + content) | |
| context | No | What these changes do (helps with triage) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the tool returns CLEAR or BLOCKED with findings and remediation steps. This clearly indicates it is a read-only check (no destructive actions). It does not discuss permissions or rate limits, but for a local file check these are not critical. The behavioral traits are well disclosed.
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 two sentences, front-loaded with purpose followed by usage guidance and return value. Every sentence adds value, with no redundancy or fluff. It is highly 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?
Given the tool has 2 parameters with full schema coverage, no output schema, and no annotations, the description is fairly complete. It explains what the tool does, when to use it, and what it returns. It could be improved by stating that the operation is safe and read-only, but overall it provides sufficient context for an AI agent.
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 100% description coverage for both parameters (files and context). The tool description adds little beyond the schema: it mentions file changes before committing and the return type, but does not elaborate on parameter usage or formats. Baseline of 3 is appropriate since the schema already documents parameters well.
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 it is a security pre-flight check for local file changes before committing. It specifies the verb 'run', the resource 'local file changes', and the context (before commit/push/PR). The sibling tools (auto_remediate, get_findings, scan_repository) are distinguished by this specific pre-commit focus.
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 tells when to use the tool: 'Run this whenever you are about to suggest git commit, git push, or open a pull request — especially when changes touch auth, secrets, SQL queries, package.json / requirements.txt, or environment variables.' It provides clear context but does not explicitly mention when not to use it or alternative sibling tools. However, the guidance is sufficiently specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_repositoryAInspect
Trigger a Level 1 + Level 2 security scan on a GitHub pull request. Returns SAST findings, taint flows, entropy-detected secrets, and (for PRO users) LLM-triaged results. Requires Graneth authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | GitHub repository name | |
| owner | Yes | GitHub repository owner | |
| token | Yes | GitHub access token with repo read permissions | |
| pull_number | Yes | Pull request number to scan |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully convey behavior. It lists the return types (SAST findings, taint flows, secrets, LLM results for PRO users) and authentication needs. However, it lacks details on side effects, duration, idempotency, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences, 30 words) and front-loaded with the core action. Every sentence adds value 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 absence of an output schema and annotations, the description adequately covers the tool's purpose, inputs, and outputs. It explains the types of findings returned and authentication requirements. Minor gaps include no explanation of 'Level 1 + Level 2' or 'PRO users'.
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 100% description coverage, so each parameter's meaning is already documented. The description does not add further semantic context for the parameters. 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 the action ('trigger'), the resource ('security scan on a GitHub pull request'), and the scope ('Level 1 + Level 2'). It distinguishes from sibling tools (auto_remediate, get_findings, pre_flight_check) by focusing on initiation of a scan.
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 mentions a prerequisite ('Requires Graneth authentication') and implicitly indicates when to use (trigger a scan on a PR). However, it does not explicitly state when not to use or provide comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!