DFOS has a first-party MCP server

DFOS has a first-party MCP server. You log in with OAuth, it acts as you, and your agent gets structured access to everything you can already do on the platform — read posts, search conversations, send messages, browse docs, check notifications. This post is about what that means, why the security model is simpler than it sounds, and what it looks like when a platform is natively accessible to agents.

the security non-event

The MCP server authenticates via OAuth 2.1 with PKCE — the same protocol your browser uses when you log in with Google, GitHub, or anything else that does modern auth. You authorize the connection once through the DFOS app, and the agent gets a token scoped to your identity. Same permissions. Same membership. Same content boundaries.

There's no elevated access. No API key with god-mode. The token is signed by your own identity key — the same cryptographic key that signs everything else you do on the platform. If you're a member of three spaces, your agent sees three spaces. If you don't have admin access, neither does your agent.

The thing worth naming explicitly: MCP is actually more restrictive than using the API directly. A raw HTTP client can hit any endpoint with any payload. MCP tools are shaped — they have names, descriptions, typed inputs, bounded outputs. An agent working through MCP is operating through a curated interface that's been designed for specific operations. It's less powerful than curl. That's the point.

the opt-in question we walked away from

We built the gating. There's a feature flag (feat-mcp) that controls whether your tools light up beyond a basic identity check. We considered making MCP access opt-in — requiring users to explicitly enable it before agents could connect.

But the more we sat with it, the less the gate made sense. The MCP endpoint doesn't create a new permission surface. It's the same surface you're already on, accessed through a standards-compliant OAuth flow, mediated by tools that are narrower than what the raw API exposes. Requiring opt-in for something that grants no new capabilities is just friction without security benefit.

The flag still exists as an operational dial — we can turn it if we need to. Right now it's enabled for the internal team and for anyone who joins clear.txt. But the direction is toward removing it, not tightening it. If you can log in, you can connect an agent. The agent is you.

what you can actually do

20+ tools across read, write, and search. The full surface:

Read your spaces — list spaces you belong to, browse posts by topic, read comments and replies, scroll through chat channels and threads, check who's in a space and when they were last active.

Search across everything — full-text search across posts, comments, chat messages, and members. Works across all your spaces simultaneously.

Write and participate — create posts (short or long-form, with topics), comment on posts, reply to comments, send chat messages, reply in threads, react to content. Everything your agent writes is authored as you — your identity, your name, your DID.

Manage your attention — list notifications filtered by space or read state, mark them read. Triage without opening the app.

Browse the docs (coming soon) — the full DFOS developer documentation and API reference will be available as a structured tool. An agent will be able to look up how any endpoint works without leaving the conversation. This opens up alongside the public API surface.

example prompts that hit

These are real things you can ask an agent connected to DFOS via MCP. Not hypothetical — I've been running these:

• "What's been happening in clear.txt this week?" — the agent crawls recent posts, scans chat channels, and gives you a synthesis of activity across topics. Catches you up in 30 seconds on what would take 10 minutes of scrolling.

• "Search all my spaces for anyone talking about gaussian splatting" — cross-space full-text search, returns the post, the author, the context. Found Vinny's clear.txt project update in a second.

• "Summarize the AI channel discussion from the last few days" — reads the last N messages in the AI topic, synthesizes the threads and links people shared, surfaces what's worth reading.

• "How many people are in clear.txt and who joined most recently?" — member list with join dates, activity status, roles. 40+ members, newest joined last week.

• "Draft a long post for dfos-dev about the MCP server — cover the OAuth flow, why we walked away from opt-in gating, and ground it in real examples" — the agent reads your previous posts for voice, crawls the space for context, tries its own MCP tools to generate live examples, writes a 1400-word draft, and posts it as you. This post was that prompt.

• "What are my unread notifications?" — notification triage without context-switching. Read state management included.

• "Look up the DFOS docs for how post permissions work" — (coming soon) agent browses the structured docs tree and reads the relevant page. Answers your question about the API without you leaving the terminal.

how we actually use it

This isn't a feature we built and shipped to users while we use something different internally. The MCP server is how we operate the platform day-to-day.

Content operations — weekly summaries, changelogs, community digests are all sourced through MCP. The agent reads production content, synthesizes across spaces and channels, and drafts posts that get reviewed and published through the same tools.

Platform awareness — checking what's active, who's posting, what threads have energy. The agent can answer "what happened in the last 24 hours across all spaces" faster than any dashboard.

Development feedback loops — after shipping a feature, the agent can verify it's working from a user's perspective by reading the content it produces, checking that notifications fired, confirming the chat messages look right. The MCP endpoint closes the loop from "I deployed code" to "I can see what the code does in production."

Operational tooling — notification triage happens through the agent. Content moderation review starts with MCP search.

The shape of this is worth naming: the agent has the same view of the platform that you do. Not an admin backdoor, not a service account, not a monitoring dashboard. Your view. Your spaces. Your conversations. Extended into an interface that's designed for how agents work — structured data, typed tools, bounded operations.

what this is

MCP on DFOS isn't a developer integration or a bot framework. It's the platform itself, made accessible to agents through the same identity and permission model that governs everything else. OAuth for auth. Your key for signing. Your membership for access. Shaped tools that are narrower than the raw API.

The bet is that platforms should be natively legible to agents — not through special APIs or elevated permissions, but through the same trust model that already governs human access. The agent is you. The tools are constrained. The security model is a non-event.

And it's been the most useful thing we've built for ourselves in months.