Same underlying dataset. One route is publicly queryable. The route my agent takes goes through an authenticated Context MCP endpoint, which needs an organization API token — not a project token, which Sanity explicitly does not accept there. I had not provisioned Pouya any access to my organization, so cloning the repo gave him no way to authenticate the path the agent actually uses.
I am being careful about "same" here: an MCP endpoint can be configured with its own sources and a groqFilter, so it is not guaranteed to expose the same 120 documents the public route does. Same source, different access path, different interface contract. That distinction turns out to be the bug.
That gap is the whole story, and I did not know it was there until the contributor who fell into it told me.
A developer named Pouya read a post of mine, decided my diagnosis was wrong, cloned the repo and opened a pull request. First outside contribution the project has ever had.
It is merged, so it will not appear in the default pull request list, which shows open ones only. A reviewer told me the repo had no PRs at all for exactly that reason, which is a small instance of the same mistake this whole post is about.
His diagnosis was reasonable. My agent queries a Sanity dataset with GROQ, and he thought the failures came from the model guessing at document types and inventing query syntax. His fix: put the real schema and worked examples into the tool description, so the model is told the shape instead of guessing it.
Both from the pull request description. Here is the one for a claim, against the live dataset:
Null for two separate reasons. There is no findingRef field on my patch documents — it is findings, and it is an array. And the ids are case sensitive: finding-B1, not finding-b1.
The patch did not just carry two broken examples. It wrote a schema into the tool description, and the schema did not match my data:
| the patch told the model | what the database actually has | |---|---| | claim.subject | nothing | | claim.statement | text | | finding.finders | foundBy | | finding.verifiedReceipts | commentId or commentIds, depending on the record | | patch.findingRef | findings[] | | patch.commitHash | sha |
That is the record his example referenced. An earlier draft of this post ran the same command against finding-B8 instead, because B8 carries commentIds and B1 carries the singular commentId, which made my table read cleaner. That is picking the sample that proves the point, in a post about not doing that, and a reviewer caught it before it shipped.
So a patch written to stop a model from inventing schema would have installed a mismatched schema into the exact place the model reads it from. Worse than the bug it fixed, because a guess made at runtime is a guess, while a guess sitting in the tool description arrives with the authority of documentation.
I wrote a draft of this post that said I did not know how the patch was produced and was not going to guess. That was the right call, because when I asked, the answer was nothing I would have guessed. In his words, published with his permission:
The dataset itself is public of course, but I wasn't able to replicate the full MCP setup on my end at the time I tested it so I was hitting that 401 on the Context MCP endpoint. So I just tested the query generation logic against an offline mock schema on LM Studio instead, which is where those field names came from.
He could read every one of my 120 documents in a browser. He could not run my agent, because the agent does not take the public route — it goes through an org-scoped MCP endpoint needing an organization credential I had not provided and was not going to publish with the repository.
So he did the careful thing. He built an offline mock of the schema and tested the query generation logic against that. And when he built the mock he chose better names than mine:
When creating that schema, I used clean, self-describing semantic names (commitHash instead of sha, verifiedReceipts instead of commentIds, finders instead of foundBy) because explicit naming makes it way easier for the SLMs to understand what fields represent and prevents confusion.
He is right about that, by the way. commitHash is a better name than sha. foundBy is worse than finders. Every wrong name in that table is the name a competent person would pick if they were designing the schema rather than reading it.