mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-26 18:31:34 +01:00
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Governed MCP access spans contracts, runtime enforcement, adapters, UI surfaces, and operator verification > - The parity reference PR #9534 is too large for effective automated or human review > - The feature therefore needs a linear stack whose individual diffs stay below the 100-file review limit > - This pull request is split 3/8 and focuses on tool-access policy and authorization core > - The benefit is a standalone, testable review boundary while preserving byte-for-byte parity at the top of the stack ## Linked Issues or Issue Description - Related parity reference: #9534 - Problem: Authorization, OAuth binding, secret projection, content guards, and policy evaluation need a security-reviewable server boundary. - Proposed solution: Adds tool-access services/routes/tests plus the runtime service dependencies directly imported by the core, without registering the routes in the application. - Alternatives considered: keeping #9534 as one 403-file review, or rewriting the feature to manufacture seams; both were rejected in favor of path extraction plus compile-driven boundary moves. - Roadmap alignment: this advances the existing governed MCP/tool-access work already represented by #9534; it does not introduce a separate roadmap initiative. - Stack position: base branch is `pap10341-split/02-schema-shared`. - Merge policy: merge bottom-up, in order, only after the complete eight-PR stack has been reviewed and the top-of-stack parity gate remains empty. - Requested review: SecurityEngineer for authz, OAuth, secrets, and content guards; Greptile on every PR. ## What Changed - Adds tool-access services/routes/tests plus the runtime service dependencies directly imported by the core, without registering the routes in the application. - Keeps this PR below 100 changed files and independently typecheckable. - Preserves the final tree from #9534 when combined with the other seven stack levels. ## Verification - `pnpm typecheck` - Focused server Vitest run — 4 files, 143 tests passed ## Risks - Authorization bugs could permit cross-company or over-broad tool access; the PR remains inert until PR 4 wiring and requires dedicated security review. - Stack risk: merging out of order can expose incomplete layers; mitigate by following the documented bottom-up merge policy. - Parity risk: later edits to an intermediate branch can drift from #9534; mitigate by re-running the empty top-of-stack diff before merge. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex, exact model ID `gpt-5.4`; runtime-managed context window; medium reasoning with repository, shell, Git, GitHub CLI, and code-execution tools enabled. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] Internal references are omitted except the execution-plan link explicitly required for this coordinated split stack - [x] My branch name describes the change and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge ## Stack Coordination - Internal execution plan: [PAP-13874](/PAP/issues/PAP-13874#document-plan) - Parity reference: #9534 - Stack: #9556 → #9557 → #9558 → #9559 → #9560 → #9561 → #9562 → #9563 - Merge bottom-up only after full-stack review and an empty parity diff at #9563. --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
85 lines
3.2 KiB
TypeScript
85 lines
3.2 KiB
TypeScript
// Helpers for talking to remote MCP servers over the Streamable HTTP transport.
|
|
//
|
|
// The MCP Streamable HTTP spec requires the client to advertise that it accepts
|
|
// BOTH a single JSON response and an SSE stream on every POST:
|
|
//
|
|
// Accept: application/json, text/event-stream
|
|
//
|
|
// Spec-compliant servers reject requests missing this header with 406 Not
|
|
// Acceptable, and when the header is present they are free to answer with an
|
|
// SSE stream (`event: message\ndata: {…}`) instead of a bare JSON body. So any
|
|
// code path that POSTs JSON-RPC to a remote `/mcp` endpoint must (a) send the
|
|
// Accept header and (b) be able to read an SSE-framed response.
|
|
|
|
/** The Accept header value required by the MCP Streamable HTTP transport. */
|
|
export const MCP_HTTP_ACCEPT = "application/json, text/event-stream";
|
|
|
|
/**
|
|
* Default headers for an MCP Streamable HTTP JSON-RPC POST. Caller-supplied
|
|
* headers (e.g. resolved credentials) are preserved, while the required
|
|
* Streamable HTTP Accept value is kept authoritative.
|
|
*/
|
|
export function mcpHttpRequestHeaders(extra?: Record<string, string>): Record<string, string> {
|
|
return {
|
|
"content-type": "application/json",
|
|
...extra,
|
|
accept: MCP_HTTP_ACCEPT,
|
|
};
|
|
}
|
|
|
|
function looksLikeJsonRpcMessage(value: unknown): boolean {
|
|
if (typeof value !== "object" || value === null) return false;
|
|
const record = value as Record<string, unknown>;
|
|
return "result" in record || "error" in record || "method" in record || "id" in record;
|
|
}
|
|
|
|
/**
|
|
* Parse the body of an MCP Streamable HTTP response into its JSON-RPC payload.
|
|
*
|
|
* Handles both response shapes the transport allows:
|
|
* - `application/json`: the body is the JSON-RPC message directly.
|
|
* - `text/event-stream`: one or more SSE events; we return the JSON payload of
|
|
* the first `data:` event that parses as a JSON-RPC message.
|
|
*
|
|
* Falls back to a plain JSON parse when the content type is unknown so we stay
|
|
* compatible with non-compliant servers that ignore the Accept header.
|
|
*/
|
|
export function parseMcpHttpResponseBody(bodyText: string, contentType: string | null): unknown {
|
|
const isEventStream = (contentType ?? "").toLowerCase().includes("text/event-stream");
|
|
if (!isEventStream) {
|
|
return JSON.parse(bodyText) as unknown;
|
|
}
|
|
|
|
// Split the SSE stream into events on blank lines, then collect each event's
|
|
// `data:` lines (which may span multiple lines per the SSE spec).
|
|
const events = bodyText.replace(/\r\n/g, "\n").split(/\n\n+/);
|
|
let lastError: unknown = null;
|
|
let firstParsed: unknown;
|
|
let sawData = false;
|
|
for (const event of events) {
|
|
const dataLines = event
|
|
.split("\n")
|
|
.filter((line) => line.startsWith("data:"))
|
|
.map((line) => line.slice("data:".length).replace(/^ /, ""));
|
|
if (dataLines.length === 0) continue;
|
|
const data = dataLines.join("\n");
|
|
let parsed: unknown;
|
|
try {
|
|
parsed = JSON.parse(data) as unknown;
|
|
} catch (error) {
|
|
lastError = error;
|
|
continue;
|
|
}
|
|
if (!sawData) {
|
|
firstParsed = parsed;
|
|
sawData = true;
|
|
}
|
|
if (looksLikeJsonRpcMessage(parsed)) {
|
|
return parsed;
|
|
}
|
|
}
|
|
if (sawData) return firstParsed;
|
|
if (lastError) throw lastError;
|
|
throw new SyntaxError("MCP SSE response contained no data events");
|
|
}
|