# Reported issues for Nooticr Pod holds 16 of 18 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 [Nooticr](/mcp/nooticr). ## Most discussed ### "Track what @x is doing" picks analyze_creator_profile, never track_competitor ## What's wrong The quest prompt *"Track what @fixture_creator_1 has been doing on TikTok, and keep an eye on them from now on"* selected `analyze_creator_profile` in **3 of 3 runs**. `track_competitor` — the tool whose name is literally the user's own verb — was never called. (The host did go on to `watch_creator` correctly, so the second half of the journey works.) This is a tool-selection collision, not a chaining failure, and it is invisible to every other tier in the repo: both tools… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/46) · 2026-09-07 · closed · outside contributor · 1 comment ### show_* tools are never retrieved — a tool nobody searches for steers nothing ## What's wrong 64 tools is past the point where Claude Code keeps them all in context, so every one of them sits behind a `ToolSearch` and only enters context if a search returns it. Over the 36 quest runs whose expected chain ends in a `show_*` tool: | | called | |---|---| | `ToolSearch` never returned the `show_*` tool | **0 / 18** | | `ToolSearch` did return it | **14 / 18** | | the model's **first** `ToolSearch` query already named it | **9 / 10** | | it was not in the first query | 5 /… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/45) · 2026-09-07 · closed · outside contributor · 1 comment ### A sessionless `tools/call` is rejected 400 because `reInitialize()` gives the transport a session the client never learned Separate from #64 (which is the protocol-version rejection and accounts for every Claude 400): a `tools/call` can arrive with **no `mcp-session-id` header** and be rejected 400 by the SDK's session validation. Observed on `openai-mcp/1.0.0`: ``` 09-07 06:52 ua=openai-mcp/1.0.0 method=tools/call proto=None sid=no → 400 (480ms) 09-07 06:52 ua=openai-mcp/1.0.0 method=None proto=None sid=no → 400 ( 92ms) ``` Rare — 2 in a ~10% Workers Logs sample over 7 days, so on the order of… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/68) · 2026-09-08 · closed · outside contributor · 0 comments ### The OAuth metadata document 404s at the path-inserted URL RFC 9728 tells clients to build, so spec-compliant discovery fails before it finds the working root form RFC 9728 tells a client that knows the resource is `https://mcp.nooticr.com/mcp` to build the metadata URL by inserting the well-known segment **before the resource path**: ``` https://mcp.nooticr.com/.well-known/oauth-protected-resource/mcp ``` We only match the bare root form, so that request 404s. ``` GET /.well-known/oauth-protected-resource/mcp 404 75 reqs ua=undici (MCP TS SDK), node GET /.well-known/oauth-protected-resource 200 65 reqs ua=undici $ curl -o /dev/null -w… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/65) · 2026-09-08 · open · outside contributor · 0 comments ### Claude negotiates MCP protocol 2026-07-28, the pinned SDK stops at 2025-11-25, and every such request is rejected with HTTP 400 Claude's newer client negotiates **`MCP-Protocol-Version: 2026-07-28`**. The bundled SDK's supported list stops at `2025-11-25`, so `validateProtocolVersion()` rejects the request with **HTTP 400** before any method dispatch happens. Those sessions never get as far as `tools/list` — the server is simply unusable for that client. It is **26.1% of Claude's authenticated POSTs to `/mcp`** (130 of 498 over 7 days), present every hour of every day in the window. > **Correction to the first version… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/64) · 2026-09-08 · closed · outside contributor · 0 comments ### The evidence reaches only one of the two channels, and the host decides which — on Claude.ai the model gets "Here are 4 comments" and no comments #44 found that **guidance** was landing in a channel Claude Code drops. #51 fixed that by writing guidance into both channels. This is the same defect pointed the other way, and it is worse: the **evidence** still lives in one channel only, and on the host this connector actually ships to, that is the channel the model never sees. ## From a real session A user called `find_people_with_problem` on Claude.ai. The full tool result the model received, verbatim: ``` 17 posts that might be someone… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/59) · 2026-09-08 · closed · outside contributor · 0 comments ### A failing platform gets retried with reworded queries instead of reported ## What happened From a real session, after Reddit's discovery endpoint started failing (`Nooticr/nooticr-server#50`): ``` discover_social_posts { platform: "reddit", niche: "creator burnout tracking analytics multiple platforms manually" } → error discover_social_posts { platform: "reddit", niche: "tired of manually checking competitor social media posts" } → error discover_social_posts { platform: "reddit", niche: "social media analytics burnout small business" } →… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/49) · 2026-09-07 · closed · outside contributor · 0 comments ### No tool answers "find people who have the problem my product solves" ## What happened From a real session. *"Please search on X and Reddit for people that might see our product (nooticr) as a great use for their daily struggle."* A clear, common, commercially central request: **find prospects by the pain they describe.** The model reached for `discover_social_posts` and fed the pain point in as the `niche`: ``` discover_social_posts { platform: "twitter", limit: 8, niche: "struggling to track social media analytics competitor research"… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/48) · 2026-09-07 · closed · outside contributor · 0 comments ## Most recent ### Guidance never reaches Claude Code — move it inside structuredContent ## What's wrong `evidence.ts`'s premise is stated in its own header: > *"A tool result is the only channel to the calling model — prompts are user-controlled and cannot drive anything. So the guidance below is not documentation; it is the steering, and it lands in the model's context."* It does not land. When a tool result carries `structuredContent`, Claude Code drops **every** `content` text block, keeps the non-text blocks, and appends the serialised `structuredContent` as the only text… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/44) · 2026-09-07 · closed · outside contributor · 0 comments ### "What should I tag?" is answerable on one network out of ten ## The gap The discovery half of the surface is deliberately wide — `discover_social_posts` sweeps nine networks, `get_user_posts` reads ten, `search_mentions` monitors nine. The two tools that answer *what to attach to a post* are not: | tool | reach | source | |---|---|---| | `discover_hashtags` | **TikTok only** | TikTok Creative Center trend board | | `discover_sounds` | TikTok + Instagram | `SOUND_PLATFORMS` | `discover_hashtags` does not even take a `platform` argument — its inputs are… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/32) · 2026-09-06 · closed · outside contributor · 0 comments ### Every creator is measured only against themselves — nothing benchmarks you against a competitor, or two creators against each other ## The gap The surface has a strong, deliberate stance on baselines, and it applies it in one direction only. `track_competitor`: > scores each against the median of that same window, because a raw view count > mostly measures follower count — outperformance against themselves is the > signal `why_did_this_underperform` does the same for one post: > One post measured against the creator's own recent median rather than against > another post ... excludes the post from its own baseline That… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/30) · 2026-09-06 · closed · outside contributor · 0 comments ### The harness has no memory: every tool is a fresh fetch, so "what changed since last month" cannot be asked at any price ## The gap README frames this server as three things — read, understand, make — plus "it monitors a name". Every one of the 64 tools answers about **now**. Nothing answers about *change*, and no amount of credits buys the answer, because the past was never kept. Three tools come close and each stops one step short: | tool | what it remembers | what it cannot tell you | |---|---|---| | `catch_up_watchlist` | a per-creator snapshot marker, moved forward on each run | how often they post,… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/28) · 2026-09-06 · closed · outside contributor · 0 comments ### README says "49 tools" (64 are registered) and "those two ask first" (six do) Two counts in `README.md` have fallen behind the code. Both are load-bearing — `CLAUDE.md` opens by calling the README "the product surface ... and doubles as the contract this server promises hosts". ## 1. "49 tools" `README.md`'s Tools section: > **49 tools**, grouped by what you are trying to do. `tools/list` against the built `dist/index.js` returns **64**, and the README's own tables already have 64 unique tool rows — I diffed them and they match the registered set exactly, in both… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/27) · 2026-09-06 · closed · outside contributor · 0 comments ### 1,286 outputSchema properties emit `"type"` as an array, which strict MCP clients either reject or silently drop ## What's wrong `npm run contract:host` passes, and reports: ``` 0 errors, 1291 warnings across 64 tools. OK: 64 tools, 115 resources, both host contracts intact ``` Broken down, the 1,291 are: | count | warning | |---|---| | 1,286 | ``` `type` is an array (["string","number","boolean"]). The array form is legal JSON Schema, but several MCP clients read `type` as a single string and either reject the tool or drop the constraint. ``` | | 5 | ``` Schema carries no validation keyword at all,… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/26) · 2026-09-06 · closed · outside contributor · 0 comments ### `search_spoken_mentions` names a two-network ceiling for a reason that is false — the real reachable set is Douyin today, and four to five more once whisper is provisioned > **Second rewrite, after adversarial verification.** Revision 1 argued only for > Douyin. Revision 2 over-corrected to "every video-bearing platform". A > 3-lens verification pass refuted the broad version: the reachable set is > specific, smaller than revision 2 claimed, and split by whether an operator > has provisioned a whisper model. Revision 2's repricing section was also > wrong and has been removed. The corrected numbers are below. ## What's wrong (the part that survived verification,… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/23) · 2026-09-06 · closed · outside contributor · 0 comments ### `understand_social_post`'s description drops LinkedIn while its own `url` hint lists it — and `proseOf` merges the two, so the check cannot see the contradiction ## What's wrong `understand_social_post` makes two platform claims that disagree with each other. Its **description** names nine: > Supports TikTok, Instagram, YouTube, X, Reddit, Douyin, Xiaohongshu, Weibo > and Bilibili. Its **`url` input hint** names ten: ``` Full public post URL (TikTok/Instagram/YouTube/X/Reddit/Douyin/Xiaohongshu/Weibo/Bilibili/LinkedIn). ``` `postDetail` in `vendor/platform-capabilities.json` serves ten, LinkedIn included, so the hint is right and the description… [Read the thread](https://github.com/Nooticr/nooticr-mcp/issues/22) · 2026-09-06 · closed · outside contributor · 0 comments The remaining reports are on [the project's issue tracker](https://github.com/Nooticr/nooticr-mcp/issues).