bc-rig

Server Quality Checklist

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

Latest release: v3.0.0
Disambiguation5/5
Each tool has a clear, distinct purpose within its category (browser vs mobile vs utility). Browser tools cover session management, observation, action, and screenshot; mobile tools cover observation, action, and screenshot; doctor and run are unique utilities. No two tools appear to do the same thing.
Naming Consistency4/5
Most tools follow a consistent [category]_[action] pattern (browser_*, mobile_*), which is clear and predictable. The doctor and run tools deviate slightly as they lack a category prefix, but they are still verb-named and not ambiguous. Overall, naming is mostly consistent with minor deviations.
Tool Count5/5
With 9 tools, the server is well-scoped for its purpose: browser automation, mobile automation, and basic utilities. Each tool earns its place, and the number is neither too few nor too many for the apparent breadth of functionality.
Completeness3/5
The tool surface covers core browser and mobile interactions (observe, act, screenshot) and includes a readiness check (doctor) and manifest management (run). However, mobile session management is absent (no mobile_session tool), while browser has browser_session. This is a notable gap that could hinder mobile workflows.
Average 3.5/5 across 9 of 9 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on July 21, 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.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, suggesting mutation but no destruction. The description does not add behavioral context such as required permissions, side effects, or rate limits. With sparse annotations, more transparency is needed. Score 2 for insufficient disclosure.
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 single sentence, which is concise, but it packs multiple actions without structure. It could be more effective with clearer separation and front-loaded key content. Score 3 for adequate but not optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no explanation of the workflow or expected outcomes, the description is critically incomplete. It does not cover what happens upon 'start' vs 'status' vs 'finish', nor does it explain the evidence manifest concept. Score 1 for severe incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify the meaning or usage of any of the 7 parameters, including 'action', 'label', 'status', etc. The tool's behavior depends on these parameters, but no semantic help is provided. Score 1 for failing to compensate.
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?
Description lists possible actions (start, inspect, annotate, finish) on an 'evidence manifest for an exploratory run,' but the term 'evidence manifest' is unclear. The purpose is somewhat vague and does not distinguish this tool from sibling tools that handle specific browser/mobile actions. Score 3 for vague purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings, which include browser and mobile observation/action tools. The description does not specify context, prerequisites, or exclusions. Score 2 for no usage guidance.
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?
Annotations already set readOnlyHint=true and idempotentHint=true, so the description adds no behavioral context beyond listing what is checked. It doesn't confirm the read-only nature or mention lack of side effects.
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 concise (one sentence) and lists the components checked. It is appropriately sized but could benefit from a bit more structure (e.g., bullet points) for clarity.
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?
With no parameters and no output schema, the description tells what it checks but not what the result looks like (e.g., boolean, summary). This leaves the agent guessing about the return format, which is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline for 0 parameters is 4. Description adds no parameter info as none are needed.
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 checks readiness of host, Android, Playwright, and project browser-session. It distinguishes itself from action-oriented sibling tools but could be more specific about what 'readiness' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. As a diagnostic tool, it likely should be used before other actions, but the description does not indicate this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool modifies state but is not destructive. The description adds 'returns changed state,' which aligns with mutation. No further behavioral details are provided, but the annotations cover the safety profile adequately.
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 very short (one sentence), which is concise, but it lacks important details for an agent to fully understand usage. It is front-loaded with 'Act,' but the brevity reduces utility.
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 tool has 6 parameters, 1 required, no output schema, and no nested objects, the description is insufficient. It does not explain the action enum, the observe options, or the url parameter. The tool's complexity demands more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% for 6 parameters, but the description adds zero parameter-level details. The schema itself describes some parameters (e.g., key, value, target, observe), but the description does not compensate for the missing 50% coverage or provide additional meaning.
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 states the tool acts in the selected project browser and returns changed state, distinguishing it from browser_observe and browser_screenshot. However, 'act' alone is vague; the action enum is only in the schema. It clearly specifies the use of @b refs, which adds clarity.
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 to use an @b ref from browser_observe, providing a clear step to obtain the ref before acting. This guides the agent on workflow but does not explicitly state when to avoid the tool or list alternatives.
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?
The description adds behavioral specifics beyond the annotations (e.g., stable @m refs in compact mode, classes and bounds in full mode). Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which the description does not contradict.
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?
A single sentence that front-loads the purpose and key mode differentiation. Every word is meaningful, and there is no redundancy.
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?
Despite good annotations, the description is too brief given the tool has 5 parameters and no output schema. It does not explain return structure, how parameters affect output, or how the two modes differ in results beyond a hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only indirectly references the 'mode' parameter via 'compact' and 'full'. No mention of limit, query, since, or offset, leaving agents without parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads MobileNAV state (verb+resource) and distinguishes two modes: compact with stable @m refs, and full which adds classes and bounds. This differentiates it from sibling tools like browser_observe or mobile_act.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only use case, aligning with its annotations, but provides no explicit guidance on when to use compact vs full, or when to choose this tool over browser_observe or other siblings. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description does not need to restate safety. It adds that start requires a specific path, but does not elaborate on effects like session isolation, what happens on stop, or output format, providing only minimal addition over annotations.
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 sentence that front-loads the actions and includes a critical constraint. It is efficient with no wasted words, though it could benefit from a clearer separation of operations and outcomes without losing conciseness.
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 tool has multiple operations and no output schema, the description is too brief. It does not explain what each operation returns (e.g., list yields session IDs, status gives session state), nor does it cover edge cases like what happens when no session is active. An agent would need additional inference for full understanding.
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?
With 75% schema description coverage, the schema already documents most parameters. The description adds one behavioural note about launchJson being required for start, which is useful but not extensive. It does not clarify session or configuration semantics 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 lists the core operations (start, select, inspect, list, stop) on 'isolated project browsers', clearly indicating the tool manages browser session lifecycles. It distinguishes well from siblings like browser_observe and browser_act, which handle interaction within sessions.
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 mentions that 'Start requires an AL launch.json path', providing a specific prerequisite. However, it offers no guidance on when to use this tool versus alternatives (e.g., browser_observe for observing elements) or which operation to choose in different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (all false), and the description adds that value text is never echoed or stored, and returns compact state. However, it does not disclose potential destructive actions (e.g., reset) or side effects beyond the return.
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 concise sentences front-load the purpose and key usage, with no wasted words. Every line adds value.
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 7 parameters, no output schema, and minimal annotations, the description covers core behavior but omits error handling, action details, and return format beyond 'compact state'. Additional completeness would help for such a complex tool.
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?
With only 43% schema coverage, the description adds meaning to target (@m refs) and observe (compact state), but fails to document snapshot or timeoutMs parameters. The schema enums for action and observe are clear, but no additional context is provided.
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 operates MobileNAV with actions like tap/type/wait, and distinguishes from mobile_observe by returning compact state. However, it doesn't explicitly list all actions or define 'MobileNAV', leaving some ambiguity.
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 advises using @m refs for target parameters and implies using this tool instead of mobile_observe for state, but lacks explicit when-to-use or when-not-to-use guidance compared to siblings like browser_act.
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?
Annotations are all false, so the description bears full burden for behavioral transparency. It states the tool saves a screenshot (implying a write operation) and returns a path, but it does not disclose potential side effects (e.g., file overwrite, permissions, storage location) or any constraints on usage. This lack of detail limits transparency.
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, consisting of two sentences that are front-loaded with essential information. Every word serves a purpose, with no redundancy or filler. This is a model of efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides adequate context: it describes the action and the return value. However, it does not explain what 'BC' stands for or the format of the returned path, which could be useful for an agent. For a low-complexity tool, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description need not add parameter information. With 100% schema coverage, the baseline score is 3, but the description implicitly acknowledges the absence of parameters by not mentioning any, earning a 4 as no additional value is required.
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 action: 'Save a BC screenshot and return its path.' It specifies the verb (save) and the resource (screenshot), and adds a usage condition ('Use only when visual evidence matters') that further clarifies purpose. This distinguishes it from sibling tools like browser_observe and browser_act.
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 includes explicit guidance: 'Use only when visual evidence matters.' This tells the agent when the tool is appropriate. However, it does not name alternatives or provide explicit when-not-to-use scenarios, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly=true and idempotent=true. Description adds that compact returns stable @b refs and full is costly, plus the prerequisite of browser_session. Could mention error behavior if prerequisite not met.
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 concise sentences with no superfluous text. Starts with purpose, then usage guidance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with good annotations and no output schema, the description is nearly complete. Tells prerequisite, mode differences. Lacks explanation of 'selected project browser' and potential errors.
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 only 40% (only query and since have descriptions). Description links compact mode to stable refs, but does not explain limit, offset, or query beyond schema. Some added value but insufficient to compensate for low coverage.
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 reads the selected project browser, distinguishing from action tools like browser_act and browser_screenshot. Mentions compact and full modes, with specific behavior for compact (stable @b refs).
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 states 'Call browser_session first' as a prerequisite. Contrasts compact vs full ('Compact returns stable @b refs; full is costly'), guiding mode selection. Does not exclude alternatives like mobile_observe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description must convey behavior. It mentions saving a screenshot and returning a path, which is clear. However, it does not detail file format, naming conventions, or side effects beyond saving.
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 two concise sentences with no wasted words. Purpose and usage are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description is largely complete. It could be slightly improved by clarifying what 'MobileNAV' is or the expected path format, but it is sufficient for basic selection.
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 tool has no parameters and schema coverage is 100% trivial. The description adds no parameter details but this is acceptable; baseline for 0 parameters is 4.
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 verb ('Save') and resource ('MobileNAV screenshot'), and specifies the return value ('path'). It distinguishes from sibling tools like browser_screenshot and mobile_observe by targeting MobileNAV.
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 phrase 'Use only for visual evidence' implies a specific use case, but it does not explicitly state when not to use the tool or suggest alternatives from the sibling list.
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:

[![bc-rig MCP server](https://glama.ai/mcp/servers/Brad-Fullwood/bc-rig/badges/card.svg)](https://glama.ai/mcp/servers/Brad-Fullwood/bc-rig)

Score Badge

Copy to your README.md:

[![bc-rig MCP server](https://glama.ai/mcp/servers/Brad-Fullwood/bc-rig/badges/score.svg)](https://glama.ai/mcp/servers/Brad-Fullwood/bc-rig)

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/Brad-Fullwood/bc-rig'

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