# Reported issues for Unified AI System MCP Gateway Pod holds 13 of 13 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects. Back to [Unified AI System MCP Gateway](/mcp/unified-ai-system-mcp-gateway). ## Most discussed ### stdio server takes 6.4-8.9s to answer initialize (23 cold boots, one machine), which clients can read as a failed start ### The symptom, measured `node packages/mcp-server/src/index.js` answers JSON-RPC `initialize` after **7.5-8.5 seconds** on this machine, and the number is stable rather than jittery: | run | `initialize` latency | `tools/list` names | | --- | --- | --- | | 1 | 8505 ms | 15 | | 2 | 7569 ms | 15 | | 3 | 7737 ms | 15 | | 4 | 7544 ms | 15 | Measured 2026-09-26 at `fd33ac3f`, Node v25.8.1, Windows 10.0.19045, warm file cache, no other load on the port. Every run returned the same fifteen names… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/168) · 2026-09-26 · open · 7 comments ### Both published linux/arm64 images ship x86-64 native modules (regression since 0.4.9) ## What is wrong `ghcr.io/happy520ai/unified-ai-system/mcp-server` is published as a multi-platform image, and the `linux/arm64` tag contains **four x86-64 native modules and no AArch64 ones**: ``` app/node_modules/.pnpm/@napi-rs+canvas-linux-x64-gnu@0.1.80/.../skia.linux-x64-gnu.node 64-bit LSB x86-64 app/node_modules/.pnpm/@rolldown+binding-linux-x64-gnu@1.0.3/.../rolldown-binding...node 64-bit LSB x86-64… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/190) · 2026-09-29 · open · 3 comments ### A paging upstream MCP server contributes only its first tools/list page, and the aggregation calls that complete ## Symptom The gateway's MCP upstream clients request `tools/list` once, with no `cursor`, and read only `result.tools`. `result.nextCursor` is never looked at, so an upstream that paginates contributes its first page and nothing more - and the aggregation reports that as the complete tool surface. Three call sites, all the same shape: - `apps/ai-gateway-service/src/mcpGateway/mcpUpstreamClient.ts:160-165` - Streamable HTTP: `post(createRequest("tools/list", {}))`, then `(response.result as… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/177) · 2026-09-27 · closed · 3 comments ### A well-formed OpenAPI spec that converts to zero tools looks healthy in the roster and /mcp/health ## Symptom A governed upstream whose OpenAPI 3 document is well-formed but yields no operations is reported as a healthy server. Nothing in the aggregated roster or in `/mcp/health` distinguishes "this REST source contributes zero tools" from "this source is working and you have not called it yet". Found while answering https://github.com/higress-group/higress/issues/4735 (their `hgctl` panics on `Tools[0]` for the same input). Their converter and ours share the silent-zero shape; the… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/174) · 2026-09-27 · closed · 3 comments ### The gateway tells every upstream it is version 0.5.0, and the A2A agent card repeats it `clientInfo.version` is what an MCP server learns about the client that connected to it. Ours says `0.5.0`. The newest release is `0.8.0`, and the image people actually run is tagged `ai-gateway-service:0.8.0`. ## Where it is said | where | what it says | who can see it | | --- | --- | --- | | `apps/ai-gateway-service/src/mcpGateway/mcpUpstreamClient.ts:199` | `clientInfo: { name: "unified-ai-gateway", version: "0.5.0" }` (HTTP transport) | every HTTP MCP upstream we connect to, in its logs |… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/179) · 2026-09-27 · open · 2 comments ### MCP protocol revision: two client paths declare versions seven months apart, and neither acts on the server's answer ## Symptom One gateway, two MCP client paths, declaring protocol revisions seven months apart, and neither path acts on the revision the server actually agreed to. | Call site | Declares | Reads the server's answer | | --- | --- | --- | | `apps/ai-gateway-service/src/mcpGateway/mcpUpstreamClient.ts:45` → sent at `:189` (HTTP) and `:348` (stdio) | `const PROTOCOL_VERSION = "2025-06-18"` | no — `grep -c protocolVersion` on this file returns 2, both are sends | |… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/178) · 2026-09-27 · open · 2 comments ### MCP Registry search matches the name field only, so our entry is unreachable by category terms ## The finding The official MCP Registry is the discovery surface where an MCP client looks for a server like ours. Measured tonight: **its search matches the `name` field only.** A description - however well written - cannot make us findable there. Two independent readings, both this session: | probe | result | | --- | --- | | `tools/measure-mcp-registry-search.mjs` (3,000-server sample, 30 pages, 10 words) | `description_only_mentions: 230`, `of_those_returned_by_search: 0`,… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/207) · 2026-09-29 · open · 1 comment ### The gateway caches every upstream's tool list for 60s and shares it across tenants, ignoring the ttlMs and cacheScope the upstream declares ## What was measured `tools/survey-mcp-list-cache-hints.mjs 40` (2026-09-27, anonymous, read-only, structure only - no tool descriptions or other server prose is copied out): of the 16 servers that returned a tool list, **15 declared no cache hint at all**, and one declared, at the result level: ``` ttlMs: 300000 cacheScope: "private" ``` Our gateway reads neither field. `mcpGatewayService.ts:29` held `TOOL_LIST_CACHE_TTL_MS = 60_000`, compared at `:235`, and the list-walking client… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/184) · 2026-09-27 · closed · 1 comment ## Most recent ### 0 of our 15 MCP tools declare an outputSchema - the one systematic gap the TDQS self-audit found ## Measured today, not inferred `node tools/audit-tool-definition-quality.mjs /tmp/tdqs.json --expect-count 15` boots the real server in-process on the credential-free local runtime and reads exactly what a client gets from `tools/list`. On 2026-09-28 it printed: ``` served 15 tools over 1 page(s); titles 15/15; all-4-annotations 15; none 0; params documented 20/20; output schema 0 (bare 0); when-to-use 5; boundary 0; ordering smell 0 ``` The published reading, including the per-tool table,… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/189) · 2026-09-28 · open · 0 comments ### A crawler that builds our Dockerfile gets the gateway, not the MCP server; Glama's record shows it never inspected us ## What was found A crawler that clones this repository, builds the root `Dockerfile` with no `--target`, runs the resulting image, and performs the standard MCP `initialize` → `tools/list` exchange over stdio **cannot succeed**, because the default build target is the HTTP gateway, which never reads stdin. This is not a hypothesis about someone else's pipeline. It is a property of our own file, read today: | where | what it says | | --- | --- | | `Dockerfile:62-68` | `FROM runtime AS mcp` …… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/188) · 2026-09-28 · open · 0 comments ### The gateway replays an upstream's session id but never its negotiated revision, so a pinned header can name a revision the upstream declined ## What the measurement says `tools/survey-mcp-protocol-version-header.mjs 40` (run 2026-09-27, anonymous, read-only): of 40 `streamable-http` endpoints in the official MCP registry, 22 required auth, 2 failed the handshake, and **16 completed `initialize`**. Each was then asked for `tools/list` twice, the two requests differing by exactly one header - once naming the revision the server had answered with, once with the header absent: - served **with** the header: 16/16 - served **without**… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/183) · 2026-09-27 · closed · 1 comment ### One unresolvable construct discards every operation in the document, with no pointer to which rule fired ## Symptom `parseOpenApiOperations()` rejects an entire OpenAPI document with one coarse error when a single operation contains a construct it will not resolve. The operator gets no indication of which operation, which node, or which rule fired - and every other operation in the document is lost with it. ## Reproduction (public spec, no credentials) ```console $ node probe.mjs # fetches https://developers.notion.com/openapi.json, calls parseOpenApiOperations() spec bytes: 1324776 | HTTP… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/175) · 2026-09-27 · open · 0 comments ### Publish an npm package so MCP clients can npx-install the server ## Context Every MCP client config people actually share looks like `{"command": "npx", "args": ["-y", ""]}`. We only advertise a Docker path, so a visitor who liked the README still has to install Docker to try it. An `npx` line is the cheapest thing that turns a reader into a user. The pieces are almost in place already. `packages/mcp-server/package.json` **already declares `bin`** (`unified-ai-system-mcp` -> `./src/index.js`) and `engines.node >= 20`, which is most of what an… [Read the thread](https://github.com/happy520ai/unified-ai-system/issues/170) · 2026-09-26 · open · 1 comment The remaining reports are on [the project's issue tracker](https://github.com/happy520ai/unified-ai-system/issues).