Pod

Available as Markdown and JSON. Pod is also available over MCP.

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.

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 · 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", "<package>"]}`. 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).