You run research operations at a mid-sized company, and this week someone senior asks a simple question: can we let AI agents handle our market research through MCP? You don't want to give a hand-wavy answer. You want to know what is actually possible, what is risky, and what any vendor will really stand behind.
So you read a post from PulseLake, titled "MCP for market research: five example agent workflows." You might expect a sales pitch for a server. It isn't one. The post opens with a limit: "What MCP doesn't do is make the research valid, or give anyone permission to launch fieldwork."
The five workflows are the useful part. They cover finding prior studies, turning a brief into a reviewable study plan, rehearsing a questionnaire before fieldwork, building an analysis packet, and answering stakeholder questions. You can picture each one in your own team's week.
The idea holding them together is the line between reading and acting. In the post's words: "Searching a repository is one kind of operation. Sending invitations is quite another." That gives you a way to sort your own answer. Letting an agent look things up is one decision. Letting it contact real people is a different one, and it needs its own permission.
The post is also unusually plain about what it is not claiming. The five workflows "aren't a list of documented PulseLake MCP endpoints or tool names," and the article "isn't a promise of an undocumented public MCP server." PulseLake has internal Copilot analytics tools, but "external agent access still needs a verified interface and permissions." There are no vendor figures here for you to discount, because the post doesn't offer any.
What survives is practical advice you could hand to your team today. Keep draft and approved as separate states. Label synthetic respondents as simulated. Compute figures on the dataset rather than letting a model estimate them. And treat anything an agent retrieves "as evidence, never as instructions."
Now the turn. You wonder whether a company this candid is telling the truth about itself, so you check the APIs.io record. The PulseLake provider page agrees with the post. Two API pages are on file: the PulseLake API and the pulselake-co API. The catalog description covers study design, AI-led interviews, research agents, and reporting, the same arc the five workflows follow. The record has one blemish of the catalog's own making: the display name is still the slug. The catalog calls that a cleanup for itself, not a finding about PulseLake.
The scores are modest. The Kin Score is 18.4, in the emerging band. Discoverability is the strong part at 64.3, while access clarity and operational transparency sit at 10.5 and developer ergonomics at 9.5. Agent Readiness is 34.5, labelled agent-ready.
The list of what is lit is the odd part. Spec presence, auth clarity, the well-known catalog, delegated identity, protected resource metadata, and dynamic client registration are lit. The MCP server, agentic access, error semantics, and dry-run mode are dark. In other words, PulseLake has the authorization plumbing an agent would need to connect, and no server for the agent to connect to.
That matches the post exactly. The company said it has no public server, and its record shows no public server. A company that says out loud which half it has not built is easier to trust on the half it has.
So here is what you take back to the senior person who asked. Yes, agents can help with research, but start with the reading tasks and keep anything that reaches real respondents behind a human approval. Ask any vendor, PulseLake included, for a verified interface and defined permissions before you promise outside agents access. Keep draft and approved apart, mark simulated respondents, and calculate numbers on the data. And when a vendor tells you what it hasn't built, check that against the public record. Here the two agreed, and that is worth noting.
Read the original: https://apis.io/2026/11/10/pulselake-writes-five-mcp-research-workflows-and-says-it-has-no-public-server/