argus-qa

Server Quality Checklist

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

Latest release: v9.8.0
Disambiguation5/5
Each tool has a clearly distinct purpose: fast audit, deep audit, environment comparison, design fidelity, live context capture, report retrieval, PR validation, visual diff, and snapshot monitoring. Despite some conceptual overlap between argus_audit and argus_audit_full, they are explicitly differentiated by depth and scope, and descriptions clarify when to use each.
Naming Consistency5/5
All tools follow a consistent 'argus_<descriptive_name>' pattern using snake_case, with clear verb-noun or noun phrases (e.g., argus_audit, argus_visual_diff). The convention is uniform and predictable.
Tool Count5/5
With 9 tools, the set is well-scoped for a QA audit server. Each tool addresses a specific aspect of web quality assurance (basic audit, deep audit, visual diff, design audit, PR validation, etc.), and none feel redundant or unnecessary.
Completeness5/5
The tool surface covers the full lifecycle of QA auditing: fast checks, deep analysis, visual and design fidelity, environment comparison, live debugging, PR-specific validation, and report management. There are no obvious gaps; even baseline management and caching are supported.
Average 4.6/5 across 9 of 9 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 151 commits in the last 12 weeks
- Last stable release on June 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It details the audit process, 13 mismatch types, selector fallback strategy, prerequisites (FIGMA_API_TOKEN, Chrome on debug port), and return structure. Minor omission: no mention of side effects or idempotency, but it's a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense paragraph packing all information into a single block. It front-loads the purpose but enumeration of 13 types could be structured (e.g., bullet list) for readability. Every sentence adds value, but structure could be improved.
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 no output schema or annotations, the description covers the input schema, return values (findings, summary with counts), and non-obvious dependencies. It lacks error conditions or examples, but the complexity is high and the description is largely complete.
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 descriptions in the schema. The description adds minimal extra meaning beyond stating that the URL must be reachable and the Figma URL must include node-id. Baseline 3 is appropriate since the schema already describes parameters sufficiently.
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: 'Full design-to-implementation fidelity audit against a Figma frame.' It enumerates 13 specific mismatch types, selector fallback, and dependencies, making it distinct from sibling tools like argus_audit or argus_audit_full.
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 implicitly indicates use cases for detailed audit but does not explicitly differentiate from siblings or provide when-to-use versus when-not-to-use guidance. It mentions required environment setup, which is helpful but not comparative.
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 exist, but the description details behavioral traits: first call saves baseline, subsequent calls compare, returns different signals with thresholds (0.1% warning, 5% critical), baseline storage path, and Chrome prerequisite. It covers the main behaviors.
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?
Well-structured: starts with core action, then first/subsequent usage, then CI context, then parameter guidance, then prerequisite. Slightly long but every sentence adds value and is logically ordered.
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?
No output schema, but description explains return values (visual_baseline_created, visual_regression, visual_diff_summary). Covers prerequisites (Chrome on port 9222) and threshold details. Complete for the tool's complexity.
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 3 params described in schema). The description adds practical context: explains updateBaseline use for intentional UI changes, url reachability requirement, and baselineDir override. Adds value beyond 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's core purpose: screenshot baseline comparison via pixelmatch. It distinguishes from sibling tools like argus_audit or argus_compare by focusing on visual regression detection between screenshots.
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?
Provides explicit context for use: CI or fix loops, and explains first-call vs. subsequent-call behavior. Lacks an explicit 'when not to use' but contrasts with 'full audit' and gives clear lifecycle.
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?
Describes all steps: navigating URLs, capturing screenshots, running analyzer, and returning regressions. Also explains need for env vars and CSS-analysis-only mode when TARGET_STAGING_URL is omitted. No annotations provided, so description carries full burden and does it well.
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?
Description is clear and informative but somewhat lengthy. Could be slightly tightened, but still effective. Front-loaded with main purpose.
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?
Given the complexity (multi-step, env vars, no output schema), description fully covers what the tool does, how to set it up, and what it returns. Leaves no important gaps.
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 in schema; baseline is 4. Description adds no parameter info as none exist.
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?
Clearly states it diffs dev vs staging environments, captures screenshots, runs analyzer, and surfaces regressions. Distinguishes from sibling tools like argus_visual_diff by specifying side-by-side comparison and regression detection.
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?
Explicitly says 'Run before promoting a build to staging' and explains environment variable setup. Missing explicit when-not-to-use, but context is sufficient.
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 description carries full burden. It details the tool's actions (Lighthouse, responsive, memory, hover, accessibility) and output format. However, it does not explicitly state that it is read-only or if there are side effects like resource usage.
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?
Description is a single paragraph, somewhat dense but all sentences are informative. Could be structured with bullet points for clarity, but no wasted words.
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?
Given no output schema, the description adequately explains the report contents (findings by severity, Lighthouse scores, layout overflow). It covers the complexity of the tool's features without gaps.
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 covers 100% of parameters. Description adds context: url must be reachable, critical escalates console.error to critical severity, and suggests when to set critical to true.
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 it extends argus_audit with specific additional capabilities (Lighthouse scoring, responsive checks, memory leak detection, etc.) and distinguishes itself from the sibling tool argus_audit.
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?
Explicitly says 'Use when argus_audit passes clean but visual or performance regressions are suspected' and mentions the prerequisite 'Requires Chrome running with --remote-debugging-port=9222.'
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?
With no annotations, description carries full burden. It fully discloses return format, error condition, and that it reads from a file system directory. No mention of auth or side effects, but for a read-only tool, it is sufficient and not misleading.
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, front-loaded with verb and resource, zero superfluous information. Perfectly concise.
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?
Given no parameters and no output schema, the description fully explains the tool's behavior, return format, and error handling. No gaps remain.
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, so baseline 4. Description adds value by explaining the return value and error case, which is beyond the empty 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?
Description clearly states it returns the most recent report, specifies its contents (findings array, severity summary), and covers the error case. Distinguishes from sibling audit tools by mentioning avoiding re-running scans.
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?
Explicitly tells when to use: to retrieve prior results without re-running a scan or to pipe findings. Implicitly excludes use for new scans, differentiating from argus_audit and argus_audit_full.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description fully discloses behavior: does not navigate, uses Chrome remote debugging on port 9222, requires an open page, returns a structured response. It also explains that passing tabId switches focus. This is transparent and complete.
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 paragraph but front-loads the core action, then lists return fields, usage guidance, and prerequisites. Every sentence adds value; no redundancy or filler.
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?
Given no output schema, the description includes the return structure and key fields. It covers prerequisites (Chrome remote debugging, open page), optional parameters, and contrasts with full audit. It is sufficiently complete for an agent to use 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%, so parameters are already documented. The description adds value by explaining that url does not navigate and tabId is for switching tabs, including how to obtain tabId from argus_get_context. This contextual usage guidance goes 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's purpose: 'Snapshots the currently open Chrome tab' and lists what it captures (console errors, network failures, etc.). It distinguishes itself from a full audit by saying 'without running a full audit', and references sibling tools like argus_get_context and list_pages for tab IDs.
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?
The description explicitly says 'Use during active development to inspect what is happening on the current page without running a full audit.' It also explains when to pass tabId and when not to. However, it does not explicitly state when to use alternative tools (e.g., argus_audit) instead, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the tool's behavior: it performs a one-pass detection sweep, returns findings with severity/type/message/url and a summary, explains cache behavior (per-session, max 20 entries, LRU eviction), details the critical parameter effect, and notes the prerequisite (Chrome with --remote-debugging-port=9222). No behavioral aspects are hidden.
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 the core purpose and list of checks. It is somewhat long due to the enumeration, but each sentence adds value. Minor redundancy could be trimmed (e.g., listing 'returns { findings... }' is helpful but partly repeats schema). Still efficient overall.
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?
Given the tool's complexity (many checks), no output schema, and 3 parameters, the description completely covers what it does, how to use it, what it returns (including structure), prerequisites, and when to avoid it. No gaps remain for an agent to correctly select and invoke the tool.
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 description coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining the cache parameter's practical use ('useful in tight fix loops') and the critical parameter's scenario ('Set true for business-critical routes'), which enhances agent understanding.
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 it performs a fast QA audit on a URL using Chrome DevTools Protocol, enumerates numerous specific checks, and distinguishes itself from the sibling tool argus_audit_full by explicitly stating what argus_audit_full covers (Lighthouse scoring, CSS analysis, etc.). This provides a specific verb-resource pairing and differentiates from siblings.
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 this tool ('Use for CI smoke tests and pre-deploy gates'), provides guidance on the cache parameter for tight fix loops, and explicitly names the alternative tool for other use cases ('For Lighthouse scoring... use argus_audit_full'). This meets the highest standard for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden. It discloses that the tool requires Chrome on port 9222, does not navigate, reads live state, and provides diff capabilities via snapshot_id. It also explains behavior in authenticated sessions and mid-flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that is effective but slightly long. Every sentence earns its place, but breaking it into smaller sections or bullet points could improve scannability. Still, it is well-structured and front-loaded.
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?
Despite having no output schema, the description lists all returned fields and explains the diff workflow. It covers prerequisites, multi-tab handling, and use in a fix loop. This is comprehensive for a moderately complex tool with three optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 100%, the description adds significant context beyond the schema: it explains that 'url' does not navigate, 'snapshot_id' enables diff comparisons, and 'tabId' switches focus. This enriches the agent's understanding drastically.
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 uses a specific verb 'Captures' and clearly identifies the resource: 'everything currently broken on the open Chrome tab' formatted as diagnostic context. It distinguishes from siblings like argus_audit by stating it reads live tab state and does not navigate.
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?
Explicitly states when to use the tool ('read the live tab state') and provides a complete workflow: call → suggest fix → apply fix → verify with snapshot_id. It also specifies when to use tabId for multi-tab scenarios, effectively differentiating from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description thoroughly covers all behavioral aspects: PR diff fetching, route mapping strategies, concurrency, timeouts, baseline-aware blocking, and best-effort commenting, plus prerequisites like Chrome and env vars.
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 dense but well-organized, front-loading the core purpose and then detailing process, outputs, and usage without unnecessary words.
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?
Given the complexity of the tool (4 parameters, no output schema, no annotations), the description covers all necessary information for correct invocation, including output structure, env vars, and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant context for each parameter, such as how prUrl is used, default behavior for blockOn, fallback logic for targetUrl, and token requirements above schema details.
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 runs a targeted Argus audit on routes affected by a GitHub pull request, distinguishing it from sibling tools like full audit or visual diff.
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?
Explicitly recommends using in CI to gate merges and contrasts with a full scan, including fallback logic and when infrastructure changes trigger different behavior.
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:

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

Score Badge

Copy to your README.md:

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

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/ironclawdevs27/Argus'

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