Part 1: What MCP means for social intelligence


It's 10:40 on a Tuesday and the product team has a reasonable question: why are people so cross about our latest product release? You know where the answers are. The public complaints sit in your listening platform. What customers told the company directly sits in the customer-feedback tool. The returns figures are in a spreadsheet someone emailed you a few weeks ago. Putting them side by side means 3 exports, a lot of copying and pasting, and explaining the brief again to every tool you open. The question takes 20 minutes to answer; the admin takes the morning.
MCP is how you get most of that morning back. At least 150 vendors in this year's SITech directory offer an MCP server, spread across all 9 pillars of social intelligence technology, so there's a fair chance something you already pay for has one sitting there, unused.
(Already running 6 servers and a Notion workspace that half-updates itself? There's a section at the end with your name on it.)
What MCP is
MCP stands for Model Context Protocol. It's an open standard: a shared set of rules that lets an AI assistant connect to other software, ask what that software can do, and then use it. Because it's a standard, a vendor builds one connection and it works with Claude, ChatGPT, Microsoft's Copilot Studio, Perplexity and a growing list of others.
You need 4 terms to get through most vendors' documentation:
- The assistant is where you type the request: Claude, ChatGPT and the rest. Documentation sometimes calls it the client or the host; same thing.
- The MCP server is the piece of software a vendor provides so assistants can reach its platform. It runs on the vendor's systems or on your own computer. (No server cupboard required.)
- Tools are the individual things a server lets the assistant do: search mentions, fetch a project's top themes, save a draft post, add a row to a sheet. A server rarely offers everything the platform does, so its list of tools tells you what you can ask for.
- Connectors are what Claude calls these connections in its settings. ChatGPT calls each connection an app, and you'll find apps in its Plugins directory.
When documentation says a server exposes data, it means the data is available to an assistant you've connected and signed in to.
One question, 4 tools
Back to the product launch. With your listening platform and your feedback tool connected, plus Google Drive for the returns sheet, you can ask Claude something like this:
Compare the main complaints about our latest product release in the listening project and in customer feedback over the past 30 days. Add the returns figures from the Returns Q3 sheet. Show where the 3 sources agree, where they differ, and what the product and service teams should look at first.
The assistant asks the listening server for the month's themes and a sample of posts, it asks the feedback server for the matching comments, it reads the sheet, and lays out the comparison with each finding tied to its source. Say the public conversation is mostly about a feature that doesn't work as advertised, while direct feedback is mostly about how hard it is to get a replacement. That's 2 problems, owned by 2 teams, and the second is probably making the first louder.
You can ask it to finish the job: put the comparison in a new tab of the returns sheet, and build 4 slides in Google Slides for Thursday's product meeting. The deck will be plain, and it'll exist before lunch, with every number traceable to its source.
You could do all of this by hand, and I'm sure you have for many years. What changes now is who does the carrying. The assistant fetches the material, and you spend the morning on the part that needs you: deciding whether the faulty feature and the replacements are one story or two.
Reading, writing and the button you didn't mean to press
Everything up to the slides is read access: the assistant fetches information and changes nothing. Writing the comparison into the sheet and building the deck is write access: the assistant creates or changes something in another tool.
Write access is where MCP gets useful for content teams, and where it deserves a moment's thought. A social media management server might let the assistant turn the launch findings into reply templates and draft posts about the replacement process. Saving a draft, scheduling a post and publishing it are 3 different actions, with 3 different consequences if the wording is wrong. A draft waits for a human. A scheduled post goes out at 9am whether anyone has read it or not.
So start with drafts. Let the assistant prepare the work and save it where your team already reviews things, and keep scheduling and publishing inside the approval process you trust. Claude and ChatGPT both let you decide, connection by connection, whether to approve each action or let it run. Part 3 covers what to check before you loosen any of that.
Where automations and agents come in
A conversation is the simplest way to use MCP: you ask, the assistant fetches, you read. Automation platforms and agent apps change when the work happens, and who asks for it.
Automation platforms run work on a schedule or a trigger while you get on with something else, and the big ones all speak MCP now. Zapier's server gives an assistant access to actions in more than 9,000 apps. IFTTT's can turn a plain-language description into a working automation (IFTTT calls them applets). n8n works in both directions: a workflow you've built can become a tool an assistant calls, and a workflow can call other servers itself. In practice, the launch comparison can run every Monday at 8am and land in the product team's Slack channel before their stand-up.
Agent apps are newer, and they live where you already talk. Meta's Muse, launched in the US in September, works through its own app, the web and WhatsApp, connects to your email, calendar and payment methods, and asks before it sends or spends anything. Instinct is an agent you text or call, which can work across Gmail, Drive, Docs, Sheets and Slides once you link Google Workspace. Town gives each person at a company their own assistant, and those assistants ask each other questions and pass work between them. Wabi builds small personal apps inside chat threads, starting from your inbox. Not all of them say how their connections work underneath, and none of them is a listening tool.
They matter to social intelligence anyway, because they move the assistant out of the chat window and into email, messages and team workflows. Wherever it ends up, the questions stay the same: what can it reach, and what can it change without asking you first?
Where to start
Here's how it shows up in my own consultancy work with clients. After a research workshop, I ask Claude to pull the call notes from Granola, read the client's brief from Google Drive, and draft a findings page in Notion with each observation tagged to the person who raised it. When a research project needs listening data and survey results side by side, the assistant lines them up in a Google Sheet and I spend my time on what the gaps between them mean. It saves me a few hours a week, and those hours go into interpretation, which is the part clients pay for.
If you're new to this, pick one question that keeps coming back. Write down where the material lives and what you want at the end: a sheet, a doc, a deck, a message in Slack. Then check whether those platforms have MCP servers, and whether the servers include the tools your question needs (your vendor's documentation or account manager will know). Connect one, in a test project if you can, and try the question with read access only. If the answer is useful and you can check it against the source, you've found your first workflow.
Part 2 has 9 more, one for each pillar, each in a different sector.
Already running MCPs?
A few things from this year's directory work that might save you an afternoon.
- Remote or local. Of the 152 directory vendors with a server, 79 say how it runs, and 74 of those are remote: hosted by the vendor, signed into with your usual account. Local servers run on your own machine, usually with an API key in a config file, which makes them more flexible and easier to leave lying around.
- Beta is common. 11 of the servers matched in September were still beta, preview or early access. Check the status before you build a weekly report on one.
- Tool overload. Every server you connect adds its tools to the assistant's list, and with dozens loaded, assistants can get worse at choosing between them. Switch off the tools a task doesn't need, per connection or per conversation.
- The busiest shelf. AI Search Optimisation (GEO/AEO) has more servers than any other category: 39 of the 152. If you track how brands appear in AI answers, look there first.
Part 2 gets into chaining several servers in one task, and building your own when a vendor hasn't (coming soon).
