09688c1114
Sprint 3.5: close every dead link and replace the single-step wizard with the spec-mandated 3-step flow. Wizard: - Step 1 collects prompt + name + slug, calls /v1/servers/preview. - Step 2 renders parsed tools (name, description, input schema as copyable JSON) + a credential field per requiredSecret Claude actually identified. Self-contained servers see 'No credentials needed' instead of generic Notion placeholders. - Step 3 streams the live build over WebSocket and shows install snippets. New dashboard pages: - /settings — org, plan/usage, members table, API keys + billing stubs (Sprint 4), encryption status. Reads /v1/me/org. - /audit — filterable table over /v1/audit with action pills, resource refs, IP, metadata JSON. Docs site (/docs + 6 sub-pages): - Sticky 240px sidebar, max-w-prose article column, shared DocsTitle/H2/Code primitives. - Quickstart, MCP concepts, OAuth 2.1 flow (full walkthrough with curl), Authoring tools, Self-hosting, API reference, FAQ. Marketing pages: - /changelog with tagged release timeline. - /security with 8 pillars + disclosure. - /privacy with GDPR-aware sections. - /terms (10 clauses). - /pricing full page (nav now points here instead of /#pricing anchor). - /status with live 10s probes against /api/health and /login. Footer 'system status' badge now links to /status. All 20 routes 200 OK in smoke crawl. Typecheck clean across packages.
87 lines
3.1 KiB
XML
87 lines
3.1 KiB
XML
import {
|
|
DocsTitle,
|
|
DocsLead,
|
|
DocsH2,
|
|
DocsP,
|
|
DocsList,
|
|
DocsLi,
|
|
DocsCode,
|
|
Mono,
|
|
} from '@/components/docs-page';
|
|
|
|
export const metadata = { title: 'MCP concepts — BuildMyMCPServer docs' };
|
|
|
|
export default function Concepts() {
|
|
return (
|
|
<>
|
|
<DocsTitle kicker="Get started">MCP concepts</DocsTitle>
|
|
<DocsLead>
|
|
Model Context Protocol is an open standard from Anthropic for connecting AI assistants to
|
|
external tools, data, and APIs. Three primitives, one transport.
|
|
</DocsLead>
|
|
|
|
<DocsH2 id="primitives">The three primitives</DocsH2>
|
|
<DocsList>
|
|
<DocsLi>
|
|
<strong className="text-[--color-fg]">Tools</strong> — functions the AI can invoke.
|
|
Each has a name, a description, an input schema (JSON Schema or Zod), and a server-side
|
|
implementation. The AI decides when to call them based on the description.
|
|
</DocsLi>
|
|
<DocsLi>
|
|
<strong className="text-[--color-fg]">Resources</strong> — read-only data the AI can
|
|
fetch. URI-addressed. Think files, documents, database records.
|
|
</DocsLi>
|
|
<DocsLi>
|
|
<strong className="text-[--color-fg]">Prompts</strong> — parameterized prompt templates
|
|
the server exposes to the client. Used for orchestration patterns the server author
|
|
wants to encourage.
|
|
</DocsLi>
|
|
</DocsList>
|
|
|
|
<DocsH2 id="transport">Transport: Streamable HTTP</DocsH2>
|
|
<DocsP>
|
|
Every generated server speaks <Mono>Streamable HTTP</Mono> (MCP spec 2025-11-25). The
|
|
previous SSE transport was deprecated in June 2025 and is not supported here. One HTTP
|
|
endpoint at <Mono>/mcp</Mono>, optionally negotiating a long-lived stream via
|
|
<Mono>text/event-stream</Mono> when the server wants to push updates.
|
|
</DocsP>
|
|
<DocsCode
|
|
label="single request"
|
|
code={`POST /mcp HTTP/1.1
|
|
Authorization: Bearer <jwt>
|
|
Content-Type: application/json
|
|
Accept: application/json, text/event-stream
|
|
|
|
{
|
|
"jsonrpc": "2.0",
|
|
"id": 1,
|
|
"method": "tools/list"
|
|
}`}
|
|
/>
|
|
|
|
<DocsH2 id="session">Session lifecycle</DocsH2>
|
|
<DocsList>
|
|
<DocsLi>
|
|
<Mono>initialize</Mono> — client sends protocol version + capabilities, server returns
|
|
its info and assigns a session id via the <Mono>mcp-session-id</Mono> header.
|
|
</DocsLi>
|
|
<DocsLi>
|
|
<Mono>notifications/initialized</Mono> — client confirms readiness. Server is now free
|
|
to push notifications.
|
|
</DocsLi>
|
|
<DocsLi>
|
|
<Mono>tools/list</Mono>, <Mono>tools/call</Mono>, <Mono>resources/list</Mono>,
|
|
<Mono>prompts/list</Mono> — the work.
|
|
</DocsLi>
|
|
</DocsList>
|
|
|
|
<DocsH2 id="why-mcp">Why MCP and not just REST</DocsH2>
|
|
<DocsP>
|
|
REST APIs need bespoke OpenAPI integration per client. MCP standardizes the discovery,
|
|
invocation, auth and streaming so any spec-compliant client picks up any spec-compliant
|
|
server with zero glue code. That's the entire point.
|
|
</DocsP>
|
|
</>
|
|
);
|
|
}
|