Reported issues for mcp
Pod holds 13 of 13 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to mcp.
Most discussed
setMetaData fails with standard metadata objects, requires undocumented array of JSX elements
Current Documentation
Returning an object from setMetaData like { title: '...', meta: [...] } causes rendering/parsing errors or fails silently in the HTML template output. It actually requires returning an array of React JSX elements: [ <title key="title">...</title>, ... ].
Suggested Documentation
We expect setMetaData to support standard metadata configuration objects, or for the documentation/types to explicitly clarify that it expects an array of JSX elements to avoid devel
Read the thread · 2026-07-09 · closed · 2 comments
Android build fails on SDK Platform 34 installation with FileAlreadyExistsException and missing global Java Runtime
Preflight Checklist
- I have searched existing issues and this has not already been reported.
- This is a single issue, not a bundle of unrelated issues.
- I have included reproduction steps, environment details, and logs where available.
Steps to Reproduce
- Ensure there is a corrupted temp download or platform directory for Android-34 under ~/Library/Android/sdk/.temp/ or ~/Library/Android/sdk/platforms/android-34
- Ensure no global Java Runtime is configured on the syst
Read the thread · 2026-07-09 · open · 1 comment
catalyst-mcp crashes with ERR_DLOPEN_FAILED (better-sqlite3 NODE_MODULE_VERSION mismatch)
Preflight Checklist
- I have searched existing issues and this has not already been reported.
- This is a single issue, not a bundle of unrelated issues.
- I have included reproduction steps, environment details, and logs where available.
Steps to Reproduce
- Install better-sqlite3 or catalyst-core using Node 22.
- Configure catalyst-mcp server to run under Node 20.4.0.
- Start/initialize catalyst-mcp server.
Expected Behavior
The catalyst-mcp server should initializ
Read the thread · 2026-07-07 · open · 1 comment
Clarify which IPs to change in config.json; default 127.0.0.1 is correct for the simulator
Summary
config.json has three IP-shaped settings — NODE_SERVER_HOSTNAME, WEBPACK_DEV_SERVER_HOSTNAME, and WEBVIEW_CONFIG.LOCAL_IP — and the relationship between them isn't documented anywhere I could find. The default for all three is 127.0.0.1 and that's correct for the iOS simulator (which shares the Mac's loopback). The only one that needs to change to a LAN IP is WEBVIEW_CONFIG.LOCAL_IP, and only when targeting a physical iOS/Android device on the same Wi-Fi.
Failure mo
Read the thread · 2026-05-03 · open · 1 comment
useFilePicker accessor surface is unclear in docs; consumers reach for raw data
Summary
useFilePicker returns multiple ways to read picked files — data, selectedFile, selectedFiles, getFileObject(index), getAllFileObjects() — with unclear / missing docs on which is canonical or when to use which. AI agents (and humans reading the docs) end up reverse-engineering the raw data shape instead.
What an agent wrote (consumer-side snippet)
const files =
filePickerData.files ??
(filePickerData.fileSrc ? [filePickerData] : [])
for (const f of fil
[Read the thread](https://github.com/tata1mg/catalyst-core/issues/232) · 2026-05-03 · open · 1 comment
### Introduce a runtime-adapter seam (render / static-manifest / transport / logger / config / telemetry)
## Summary
While building a Cloudflare Workers adapter, nearly every shim I wrote patched a place where Catalyst core reaches **directly** for a Node/Express/`fs`/`winston`/`process.env`/`module-alias` primitive or the Node react-dom streaming API. The root cause isn't "missing Workers support" — there's **no seam between framework logic and runtime specifics**.
Proposal: make core runtime-agnostic and delegate environment concerns to a small **Runtime Adapter interface**, with **Node as the d
[Read the thread](https://github.com/tata1mg/catalyst-core/issues/315) · 2026-07-12 · open · 0 comments
### Support TypeScript (.ts / .tsx) extensions for core template entry points
## Motivation
The `catalyst-core` framework (inside files like `expressServer.js`, `handler.js`, `registerAliases.js`, and `validator.js`) hardcodes the `.js` extension when resolving and requiring key entry points (e.g., `server/index.js`, `server/server.js`, `server/document.js`, `src/js/store/index.js`, `src/js/routes/utils.js`, `src/js/containers/App/index.js`, and `client/index.js`). Renaming these files to `.ts`/`.tsx` causes the validator to fail and the build/runtime server to crash wit
[Read the thread](https://github.com/tata1mg/catalyst-core/issues/312) · 2026-07-10 · open · 0 comments
### Enhancing catalyst-mcp: Dynamic AST indexing, active diagnostics, and robust classification
## Motivation
The catalyst-mcp server currently relies on a static knowledge-base.json that is subject to doc-drift/staleness, lacks runtime diagnostics (e.g. detecting port collisions or Babel config conflicts), references transpiled ES5 production code, and uses a strict scope classifier that occasionally blocks valid queries.
## Proposed Behaviour
1. **Dynamic Code Indexing:** Supplement static KB queries with dynamic AST indexing over node_modules/catalyst-core.
2. **Active Diagnostics ('
[Read the thread](https://github.com/tata1mg/catalyst-core/issues/311) · 2026-07-10 · open · 0 comments
## Most recent
### Automatic eager-loading and scoping of catalyst-mcp tools in Catalyst projects
## Motivation
When working in a Catalyst project, the developer and assistant must still manually search schemas and explicitly scope 'catalyst-mcp' for any query, rather than having Catalyst-specific tools pre-registered eagerly by default.
## Proposed Behaviour
All 'catalyst-mcp' tools should be eagerly loaded and registered by default for any Catalyst workspace (e.g. available as direct 'mcp_catalyst_mcp_*' tools). This allows the assistant to call Catalyst checks and operations instantly.
[Read the thread](https://github.com/tata1mg/catalyst-core/issues/310) · 2026-07-10 · open · 0 comments
### Friction in catalyst-mcp configuration: absolute Node path requirements, manual file edits, and tool scoping
## Motivation
Setting up the Catalyst MCP server requires manual global file modification (finding ~/.gemini/antigravity-ide/mcp_config.json vs ~/.gemini/config/mcp_config.json), absolute path node binary resolution (/usr/local/bin/node instead of just node), manual IDE restarts to apply settings, and explicit catalyst-mcp scoping for tool execution.
## Proposed Behaviour
1. **Workspace Auto-Discovery:** Catalyst should support workspace-local MCP server detection (e.g. via .agents/mcp_config
[Read the thread](https://github.com/tata1mg/catalyst-core/issues/309) · 2026-07-10 · open · 0 comments
### Clarification on PUBLIC_STATIC_ASSET_URL for cloud deployments (e.g. Railway)
## Context
PUBLIC_STATIC_ASSET_URL is hardcoded in config.json as 'http://localhost:3005', leading to broken assets in production deployment.
## Expected Guidance
There should be a documented best practice or dynamic fallback for PUBLIC_STATIC_ASSET_URL. For example, if deployed to cloud platforms (like Railway), the build/runtime should automatically default to relative pathing (/assets/) or respect process.env.PUBLIC_STATIC_ASSET_URL dynamically.
## Suggested Labels
`question`, `documenta
[Read the thread](https://github.com/tata1mg/catalyst-core/issues/299) · 2026-07-09 · open · 0 comments
### Missing native .env loader support for environment secrets
## Motivation
Developers must commit secrets to config/config.json or manually parse .env inside preServerInit.
## Proposed Behaviour
Catalyst should support loading .env configurations natively (using dotenv or Node's --env-file) so that local secrets are gitignored out of the box.
## Proposed Fix
Integrate a standard environment variable loader (like dotenv) or support Node.js's native --env-file option in catalyst-core's startup scripts, loading .env variables into process.env before val
[Read the thread](https://github.com/tata1mg/catalyst-core/issues/297) · 2026-07-09 · open · 0 comments
### bug: classifyIntent feedback pattern matches standalone word 'issue' — misroutes debug queries as GitHub issue creation
## Summary
The `feedback` intent regex in `mcp_v2/mcp.js` includes the standalone word `issue` as an alternative match. This causes any query naturally using the word "issue" (e.g. `"I have an issue with routing"`) to be classified as `feedback` intent — triggering the GitHub issue creation workflow instead of the debug flow.
## Current Behaviour
Any query containing the word `"issue"` without strong debug co-signals (error/fail/why) can get classified as `feedback` — causing the LLM to launc
[Read the thread](https://github.com/tata1mg/catalyst-core/issues/275) · 2026-06-18 · open · outside contributor · 0 comments
The remaining reports are on [the project's issue tracker](https://github.com/tata1mg/catalyst-core/issues).