Search and read questions, answers, comments, users, tags and badges across Stack Overflow and the 170+ other Stack Exchange sites.
Stack Exchange ships in the w6w first-party pack. It declares 39 actions, 3 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.stackexchangeStack Exchange is the network behind Stack Overflow and more than a hundred and seventy other question-and-answer communities. This app reads it through the public Stack Exchange API (v2.3): search questions by title, tag or full text, fetch a question with its answers and comments, look up users, their reputation history and badges, walk a tag’s wiki, synonyms, related tags and top answerers, and enumerate the sites on the network.
Every call takes the site to read from (stackoverflow by default), so one connection covers the whole network. Results carry the API’s own paging flag and daily quota counters, so a workflow can page with has_more and stop before it spends its quota.
The app authenticates with an application key from stackapps.com, which lifts the daily limit from 300 to 10,000 requests. It is read-only: writing to Stack Exchange needs a per-user OAuth access token, which is not modelled here. Health checks track the live quota and API reachability.
Three routes to the same 39 actions. The Workflow tab is generated from Stack Exchange's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
answer-get Fetch answers by ID (up to 100 at once). Pass Filter `withbody` for the body text.
info-get Network-statistics snapshot of a site: total questions, answers, users, unanswered, activity rates.
post-get Fetch posts (questions or answers) by ID when you do not know which kind an ID is.
question-comment-list Get the comments on one or more questions (not their answers' comments).
question-get Fetch questions by ID (up to 100 at once). Pass Filter `withbody` for the body text.
question-list List the questions on a site. Filter with tags, date range and score bounds.
question-related-list Questions the site considers related to the given questions (undocumented algorithm, heavily cached).
search Search a site's questions. At least one of Tags or Title contains is required; Tags match any (OR).
search-advanced Search questions with the full criteria set: text, body/title/URL, tags, author, answered/closed state, minimum views and answers.
search-excerpt Search questions and answers and return highlighted snippets (`<span class="highlight">`). Takes the same criteria as Search Questions (Advanced).
similar-question-list Questions similar to a hypothetical one given a title (and optional tags), like the site's ask-page suggestions.
site-list Every site on the Stack Exchange network, with its `api_site_parameter`. Changes rarely; cache it for a day.
user-associated-list A network user's accounts on every site, by network account ID. Network-level: takes no site.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Stack Exchange's real ids.
{
"manifestVersion": "2",
"name": "stackexchange-example",
"steps": [
{
"id": "answer-comment-list",
"uses": {
"app": "io.w6w.stackexchange",
"action": "answer-comment-list",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"answerIds": "<answerIds>"
}
}
]
}answer-comment-list answer-get answer-list badge-list comment-list +34 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Stack Exchange, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Stack Exchange. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "answer-comment-list",
payload: {
// site: "<value>",
answerIds: "<value>",
// page: "<value>",
// pageSize: "<value>",
// sort: "<value>",
// order: "<value>",
// min: "<value>",
// max: "<value>",
// fromDate: "<value>",
// toDate: "<value>",
// filter: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action answer-comment-list --payload '{"answerIds":"<value>"}' Give an AI agent Stack Exchange — without giving it Stack Exchange's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.stackexchange#answer-comment-list",
"input": {
"answerIds": "<answerIds>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Stack Exchange connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Stack Exchange's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Stack Exchange itself is MIT, and the runtime that executes it is source-available (FSL).
Stack Exchange declares its own checks, so its health is a property of the app rather than something the host guesses at.
Unauthenticated GET of /info?site=stackoverflow. A wrapper object with network statistics is the healthy answer; key validity is the `auth:api-key` check's job.
quota_remaining / quota_max from the wrapper object of a signed GET /info.