Repro Capsule MCP enables you to create, analyze, and execute safe, reproducible bug reproduction cases with mandatory review, secret redaction, and export capabilities.
Create and manage cases: Start a new case with an automatically redacted bug report; list all persisted cases and retrieve full details (profile, artifacts, analyses, runs).
Inspect the project: Dynamically discover project manifests, available commands, environment variable names, and Git state within the case's project root.
Analyze evidence: Generate evidence-cited hypotheses to answer specific questions about the bug.
Add artifacts: Attach reviewed project files as redacted text or hash-only binary records (no unreviewed binary content).
Plan and execute commands: Prepare exact non-shell command plans with one-time approval tokens, declaring network and workspace‑write intents; execute with bounded output, timeouts, process‑group cleanup, and output redaction before persisting.
Compare runs: Diff two recorded execution transcripts by exit status, expectation match, and output hashes.
Export capsule: Package all case metadata and reviewed artifacts into a portable ZIP with a versioned manifest and reproduction guide; no secrets or tokens included.
Security: Automatic redaction of secrets, strict denial of unlisted commands, separate approvals for network and workspace write, allowed‑roots enforcement, and force‑cleanup of process groups on timeout.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Repro Capsule MCP start a case from this bug report"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English | 한국어
Turn a bug report into a portable, reviewable reproduction capsule without silently copying a repository or executing model-generated shell text. Every report, command plan, transcript, artifact, and export stays evidence-linked and redacted.
flowchart LR
A[Bug report] --> B[Dynamic project profile]
B --> C[Evidence-based hypotheses]
B --> D[Reviewed command plan]
D --> E[One-time approval]
E --> F[Bounded execution]
C --> G[Portable capsule]
F --> GDynamic command discovery from current project manifests
Secret-redacted reports, text artifacts, stdout, and stderr
Binary artifacts represented by metadata and hashes instead of unreviewed content
Direct argv execution without a shell
One-time plan tokens with separate workspace-write and network approvals
Process-group timeout cleanup and bounded output capture
Run-to-run transcript comparison without guessing whether a fix is correct
ZIP export containing a versioned manifest and reproduction guide
Stdio and Streamable HTTP transports
Related MCP server: DumpAnalysisMCP
uv tool install "git+https://github.com/efficjump/repro-capsule-mcp.git"
repro-capsule-mcp --transport stdioFor source development:
git clone https://github.com/efficjump/repro-capsule-mcp.git
cd repro-capsule-mcp
uv sync --all-extras --locked
uv run repro-capsule-mcp --transport stdio{
"mcpServers": {
"repro-capsule": {
"command": "repro-capsule-mcp",
"args": ["--transport", "stdio"]
}
}
}The installed command avoids embedding any local checkout path in client configuration.
Tool | Purpose |
| Create a bounded case with a redacted bug report |
| Browse persisted case state and evidence |
| Discover manifests, environment names, Git state, and commands |
| Produce host-model hypotheses from current evidence |
| Add reviewed text or hash-only binary evidence |
| Prepare an exact non-shell command and one-time token |
| Run one approved plan with bounds and redaction |
| Compare two execution transcripts |
| Create a portable ZIP and manifest |
Project roots must remain inside REPRO_CAPSULE_ALLOWED_ROOTS.
Sensitive filenames, symlinks, oversized files, and unreviewed binary content are excluded.
Commands not discovered from current project files are denied by default.
Network intent and workspace-write intent require separate approval.
Environment values and approval tokens are not written into capsule exports.
Every process uses a timeout, bounded output, and redaction before persistence.
This server is not an operating-system sandbox. Inspect and execute untrusted projects only in an isolated container or virtual machine.
repro-capsule-mcp --transport streamable-http --host 127.0.0.1 --port 8766The default endpoint is http://127.0.0.1:8766/mcp.
uv sync --all-extras --locked
uv run ruff format --check .
uv run ruff check .
uv run mypy src
uv run pytest --cov --cov-report=term-missing
uv buildSee architecture, security policy, and contribution guide.
Add one reviewed project file as redacted text or a binary hash-only record.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional provenance or reason for including this artifact. | |
| case_id | Yes | Identifier returned by start_case. | |
| relative_path | Yes | Project-relative regular file path; symlinks and sensitive names are denied. | |
| include_binary_content | No | Request binary contents; server-level binary opt-in is also required. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it clarifies that content is either redacted text or a binary hash-only record. Annotations already indicate non-destructive mutation. However, it does not disclose behaviors like overwrite policy, size limits, or whether concurrent adds are allowed.
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 a single concise sentence that front-loads the key purpose. It efficiently conveys the tool's function without unnecessary words, though it could be slightly more specific about the case context.
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?
With a complete schema and output schema, the description covers the high-level function but lacks guidance on when not to use the tool or how it integrates with sibling tools. Prerequisites are implied by the parameter description for case_id.
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%, and each parameter has a clear description (e.g., 'relative_path' denies symlinks). The description adds no specific parameter details beyond the schema, so 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 clearly states the verb 'add' and the resource 'artifact' (as a project file), specifying two modes: redacted text or binary hash-only. While it doesn't explicitly mention 'case', the required parameter case_id implies the context. It distinguishes from sibling tools like 'analyze_case' or 'execute_plan' by focusing on adding content.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., a case must exist) or when to choose redacted text vs. binary mode, leaving the agent to infer from parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Form evidence-cited hypotheses with host sampling, or return an explicit fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes | Identifier returned by start_case. | |
| objective | Yes | Question the analysis should answer from current evidence. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, implying modification and external calls. The description adds the behavior of returning an explicit fallback, which is useful, but does not detail state changes or other 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the purpose, making it very concise.
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?
With an output schema present, the return values are covered. However, the description lacks details about the fallback behavior and the sampling process. It is minimally adequate but could be more informative for a complex analysis tool.
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 already provides clear descriptions for both parameters (case_id from start_case, objective as question). The description adds no additional parameter information, so it meets the baseline for high schema coverage.
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 a specific action: forming evidence-cited hypotheses with host sampling, or returning a fallback. This clearly distinguishes it from sibling tools like start_case or execute_plan, though the term 'host sampling' is somewhat ambiguous.
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 no guidance on when to use this tool, what prerequisites exist (e.g., case must be started), or when alternatives are preferred. It merely states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare exit status, expectation match, and redacted output hashes for two runs.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes | Identifier returned by start_case. | |
| baseline_run_id | Yes | Recorded execution identifier. | |
| candidate_run_id | Yes | Recorded execution identifier. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, which the description supports. The description adds detail about what is compared, enhancing transparency beyond 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?
Single, front-loaded sentence with no wasted words. Every word adds meaning.
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?
The description covers the core functionality without redundancy. Given the presence of an output schema and the tool's simple nature, it is adequately complete, though it could mention that runs must exist beforehand.
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?
All three parameters are described in the schema with coverage 100%. The description does not add additional meaning beyond the schema, so baseline score 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 uses a specific verb 'Compare' and resource 'runs', listing exact aspects (exit status, expectation match, redacted output hashes). This clearly distinguishes it from sibling tools which handle case creation, analysis, plan execution, etc.
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?
No guidance on when to use this tool versus alternatives like analyze_case. The description only states what it does, not when it should be preferred or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consume one approval token and record bounded, redacted command output.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes | Identifier returned by start_case. | |
| plan_id | Yes | Identifier returned by plan_command. | |
| allow_network | No | Explicit approval for a network-intent plan; server opt-in is also required. | |
| approval_token | Yes | One-time token returned with the reviewed command plan. | |
| allow_workspace_write | No | Explicit approval for a plan marked as workspace-writing. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag as destructive and not read-only; description adds that the token is consumed once and output is bounded and redacted, providing useful behavioral context beyond 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?
Single sentence with front-loaded verb, no unnecessary words, efficient and clear.
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?
Description is concise but lacks details on error handling, idempotency, or what happens on token reuse; however, output schema likely covers return structure, so it is minimally adequate.
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 covers 100% of parameters with descriptions; the tool description does not add further parameter-level detail, so 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 clearly states it consumes an approval token and records bounded, redacted command output, specifying a unique action distinct from sibling tools like plan_command or start_case.
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 implies use after plan_command (requires plan_id), but provides no explicit guidance on when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a ZIP containing only persisted case metadata and reviewed artifact contents.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes | Identifier returned by start_case. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that it creates a ZIP with specific contents, which is consistent with annotations (readOnlyHint=false, destructiveHint=false). However, it does not explain the output format, storage location, or any side effects. Minimal added value beyond 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?
Single well-structured sentence of 13 words, front-loaded with the key action and constraints. No wasted words.
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?
For a simple tool with one parameter and an output schema, the description covers the main behavior. However, it omits edge cases like missing artifacts or empty metadata, and lacks usage guidance.
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% and the parameter 'case_id' has a clear description in the schema. The tool description adds no additional meaning 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 has a specific verb 'Create' and resource 'ZIP', with clear constraints on contents ('persisted case metadata and reviewed artifact contents'). It distinguishes from siblings like 'start_case' and 'list_cases' by focusing on export.
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?
No explicit guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., case must be started, artifacts must exist). Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List persisted reproduction cases without reading project files or running commands.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds context about not reading files or running commands, which reinforces the read-only nature but does not contradict 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?
Single sentence, completely front-loaded with no extraneous words. Every word earns its place.
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 zero parameters and an existing output schema (not shown), the description is fully adequate. It tells the agent exactly what the tool does without ambiguity.
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?
No parameters exist, and schema coverage is 100%. Description adds value by explaining the scope ('persisted reproduction cases') without needing to detail parameters. Baseline for 0 params is 4.
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 uses a specific verb 'List' and clearly identifies the resource as 'persisted reproduction cases'. It also distinguishes from siblings by clarifying that it does not read project files or run commands, implying those are done by other tools.
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 implies that this tool is for listing persisted cases without side effects, but does not explicitly state when to use it over alternatives like analyze_case or plan_command. No direct mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a non-shell execution plan and one-time approval token from project evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| argv | No | Explicit non-shell argv; unlisted commands require server-level opt-in. | |
| case_id | Yes | Identifier returned by start_case. | |
| purpose | Yes | Reason this command contributes to reproducing the failure. | |
| env_names | No | Discovered environment names to inherit; values are never persisted. | |
| candidate_id | No | Candidate command identifier returned by inspect_project. | |
| network_intent | No | Whether execution is expected to access the network. | |
| timeout_seconds | No | Wall-clock execution timeout in seconds. | |
| workspace_write | No | Whether execution is expected to write inside the project workspace. | |
| expected_exit_codes | No | Exit codes that count as the planned observation; defaults to zero. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate readOnlyHint=false and destructiveHint=false. The description adds that the tool creates a non-shell plan and token, implying a write operation but not destructive. It does not disclose other behavioral traits like side effects, required permissions, or the lifecycle of the token. However, there is 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 a single, well-structured sentence that front-loads the core action. No unnecessary words; every part contributes meaning. It is appropriately sized.
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 and 9 parameters, the description is very brief. It does not explain the role of the approval token, how the plan relates to execution, or the expected workflow. Given the tool's complexity, the description lacks completeness to guide an agent effectively.
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%, so all parameters have descriptions in the input schema. The tool description itself does not add any parameter-specific information beyond what the schema provides. Baseline 3 is appropriate since the schema carries the full burden.
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 creates a non-shell execution plan and one-time approval token from project evidence. The verb 'Create' and the resource 'non-shell execution plan and one-time approval token' are specific. This distinguishes it from siblings like execute_plan (which likely executes plans) and start_case (which starts a case).
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 does not provide any guidance on when to use this tool versus alternatives. It lacks explicit context for usage, such as prerequisites (e.g., case must exist) or when not to use it. No comparison with sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a versioned case after constraining the project root and redacting the report.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Short human-readable name for the reproduction case. | |
| bug_report | Yes | Observed failure report; credential-like text is redacted. | |
| project_root | Yes | Existing project directory inside REPRO_CAPSULE_ALLOWED_ROOTS. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) are minimal, so the description carries the burden. It discloses two key behaviors: redaction of credential-like text and constraint of project root to allowed directories. This added context is valuable, though it does not cover all potential side effects or authorization 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 a single, well-constructed sentence that immediately states the action ('Create a versioned case') and then adds essential qualifiers. No superfluous information; every word earns its place.
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 three parameters, full schema coverage, and existence of an output schema, the description is sufficiently complete. It conveys the core purpose and key behavioral traits (redaction, constraint, versioning), providing enough context for an agent to decide when to invoke this tool.
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 each parameter already has clear documentation. The tool description adds only a high-level summary of behavior (constraining, redacting) rather than parameter-specific details. With full schema coverage, a baseline 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 'Create a versioned case', which is a specific verb+resource combination. It distinguishes from sibling tools like list_cases and analyze_case by focusing on creation. The additional context 'after constraining the project root and redacting the report' clarifies the 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 does not provide any guidance on when to use this tool versus alternatives like add_artifact or plan_command. It implies prerequisites (constraining project root) but does not explicitly state conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: starting cases, listing, analyzing, adding artifacts, planning/executing commands, comparing runs, and exporting. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern (e.g., start_case, list_cases, analyze_case). Verbs and nouns are clear and predictable.
With 8 tools, the server is well-scoped for reproduction capsule management. Each tool serves a necessary step in the workflow without excess or deficiency.
The tool set covers the core lifecycle of a reproduction case: creation, artifact addition, command planning/execution, analysis, comparison, and export. Minor gaps like case deletion or modification exist but are not critical for typical use.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Hunt zero-days by talking to binaries. 40+ tools. Hosted, OAuth + SSO, invite: hi@byteray.ai
Browser-backed QA with evidence and fix-ready reports for coding agents.
Voice-powered bug reporting with 13 MCP tools. Record bugs by talking; let AI find and fix them.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/efficjump/repro-capsule-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
