2026-04-06 07:17:48 -05:00
|
|
|
# Paperclip MCP Server
|
|
|
|
|
|
|
|
|
|
Model Context Protocol server for Paperclip.
|
|
|
|
|
|
|
|
|
|
This package is a thin MCP wrapper over the existing Paperclip REST API. It does
|
|
|
|
|
not talk to the database directly and it does not reimplement business logic.
|
|
|
|
|
|
|
|
|
|
## Authentication
|
|
|
|
|
|
|
|
|
|
The server reads its configuration from environment variables:
|
|
|
|
|
|
|
|
|
|
- `PAPERCLIP_API_URL` - Paperclip base URL, for example `http://localhost:3100`
|
|
|
|
|
- `PAPERCLIP_API_KEY` - bearer token used for `/api` requests
|
|
|
|
|
- `PAPERCLIP_COMPANY_ID` - optional default company for company-scoped tools
|
|
|
|
|
- `PAPERCLIP_AGENT_ID` - optional default agent for checkout helpers
|
|
|
|
|
- `PAPERCLIP_RUN_ID` - optional run id forwarded on mutating requests
|
|
|
|
|
|
|
|
|
|
## Usage
|
|
|
|
|
|
|
|
|
|
```sh
|
|
|
|
|
npx -y @paperclipai/mcp-server
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Or locally in this repo:
|
|
|
|
|
|
|
|
|
|
```sh
|
|
|
|
|
pnpm --filter @paperclipai/mcp-server build
|
|
|
|
|
node packages/mcp-server/dist/stdio.js
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## Tool Surface
|
|
|
|
|
|
|
|
|
|
Read tools:
|
|
|
|
|
|
|
|
|
|
- `paperclipMe`
|
|
|
|
|
- `paperclipInboxLite`
|
|
|
|
|
- `paperclipListAgents`
|
|
|
|
|
- `paperclipGetAgent`
|
|
|
|
|
- `paperclipListIssues`
|
|
|
|
|
- `paperclipGetIssue`
|
|
|
|
|
- `paperclipGetHeartbeatContext`
|
|
|
|
|
- `paperclipListComments`
|
|
|
|
|
- `paperclipGetComment`
|
|
|
|
|
- `paperclipListIssueApprovals`
|
|
|
|
|
- `paperclipListDocuments`
|
|
|
|
|
- `paperclipGetDocument`
|
|
|
|
|
- `paperclipListDocumentRevisions`
|
|
|
|
|
- `paperclipListProjects`
|
|
|
|
|
- `paperclipGetProject`
|
[codex] Harden heartbeat scheduling and runtime controls (#4223)
## Thinking Path
> - Paperclip orchestrates AI agents through issue checkout, heartbeat
runs, routines, and auditable control-plane state
> - The runtime path has to recover from lost local processes, transient
adapter failures, blocked dependencies, and routine coalescing without
stranding work
> - The existing branch carried several reliability fixes across
heartbeat scheduling, issue runtime controls, routine dispatch, and
operator-facing run state
> - These changes belong together because they share backend contracts,
migrations, and runtime status semantics
> - This pull request groups the control-plane/runtime slice so it can
merge independently from board UI polish and adapter sandbox work
> - The benefit is safer heartbeat recovery, clearer runtime controls,
and more predictable recurring execution behavior
## What Changed
- Adds bounded heartbeat retry scheduling, scheduled retry state, and
Codex transient failure recovery handling.
- Tightens heartbeat process recovery, blocker wake behavior, issue
comment wake handling, routine dispatch coalescing, and
activity/dashboard bounds.
- Adds runtime-control MCP tools and Paperclip skill docs for issue
workspace runtime management.
- Adds migrations `0061_lively_thor_girl.sql` and
`0062_routine_run_dispatch_fingerprint.sql`.
- Surfaces retry state in run ledger/agent UI and keeps related shared
types synchronized.
## Verification
- `pnpm exec vitest run
server/src/__tests__/heartbeat-retry-scheduling.test.ts
server/src/__tests__/heartbeat-process-recovery.test.ts
server/src/__tests__/routines-service.test.ts`
- `pnpm exec vitest run src/tools.test.ts` from `packages/mcp-server`
## Risks
- Medium risk: this touches heartbeat recovery and routine dispatch,
which are central execution paths.
- Migration order matters if split branches land out of order: merge
this PR before branches that assume the new runtime/routine fields.
- Runtime retry behavior should be watched in CI and in local operator
smoke tests because it changes how transient failures are resumed.
> 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, GPT-5-based coding agent runtime, shell/git tool use
enabled. Exact hosted model build and context window are not exposed in
this Paperclip heartbeat environment.
## 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 run tests locally and they pass
- [x] I have added or updated tests where applicable
- [ ] If this change affects the UI, I have included before/after
screenshots
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] I will address all Greptile and reviewer comments before
requesting merge
2026-04-21 12:24:11 -05:00
|
|
|
- `paperclipGetIssueWorkspaceRuntime`
|
|
|
|
|
- `paperclipWaitForIssueWorkspaceService`
|
2026-04-06 07:17:48 -05:00
|
|
|
- `paperclipListGoals`
|
|
|
|
|
- `paperclipGetGoal`
|
|
|
|
|
- `paperclipListApprovals`
|
|
|
|
|
- `paperclipGetApproval`
|
|
|
|
|
- `paperclipGetApprovalIssues`
|
|
|
|
|
- `paperclipListApprovalComments`
|
|
|
|
|
|
|
|
|
|
Write tools:
|
|
|
|
|
|
|
|
|
|
- `paperclipCreateIssue`
|
|
|
|
|
- `paperclipUpdateIssue`
|
|
|
|
|
- `paperclipCheckoutIssue`
|
|
|
|
|
- `paperclipReleaseIssue`
|
|
|
|
|
- `paperclipAddComment`
|
[codex] Add structured issue-thread interactions (#4244)
## Thinking Path
> - Paperclip orchestrates AI agents for zero-human companies.
> - Operators supervise that work through issues, comments, approvals,
and the board UI.
> - Some agent proposals need structured board/user decisions, not
hidden markdown conventions or heavyweight governed approvals.
> - Issue-thread interactions already provide a natural thread-native
surface for proposed tasks and questions.
> - This pull request extends that surface with request confirmations,
richer interaction cards, and agent/plugin/MCP helpers.
> - The benefit is that plan approvals and yes/no decisions become
explicit, auditable, and resumable without losing the single-issue
workflow.
## What Changed
- Added persisted issue-thread interactions for suggested tasks,
structured questions, and request confirmations.
- Added board UI cards for interaction review, selection, question
answers, and accept/reject confirmation flows.
- Added MCP and plugin SDK helpers for creating interaction cards from
agents/plugins.
- Updated agent wake instructions, onboarding assets, Paperclip skill
docs, and public docs to prefer structured confirmations for
issue-scoped decisions.
- Rebased the branch onto `public-gh/master` and renumbered branch
migrations to `0063` and `0064`; the idempotency migration uses `ADD
COLUMN IF NOT EXISTS` for old branch users.
## Verification
- `git diff --check public-gh/master..HEAD`
- `pnpm exec vitest run packages/adapter-utils/src/server-utils.test.ts
packages/mcp-server/src/tools.test.ts
packages/shared/src/issue-thread-interactions.test.ts
ui/src/lib/issue-thread-interactions.test.ts
ui/src/lib/issue-chat-messages.test.ts
ui/src/components/IssueThreadInteractionCard.test.tsx
ui/src/components/IssueChatThread.test.tsx
server/src/__tests__/issue-thread-interaction-routes.test.ts
server/src/__tests__/issue-thread-interactions-service.test.ts
server/src/services/issue-thread-interactions.test.ts` -> 9 files / 79
tests passed
- `pnpm -r typecheck` -> passed, including `packages/db` migration
numbering check
## Risks
- Medium: this adds a new issue-thread interaction model across
db/shared/server/ui/plugin surfaces.
- Migration risk is reduced by placing this branch after current master
migrations (`0063`, `0064`) and making the idempotency column add
idempotent for users who applied the old branch numbering.
- UI interaction behavior is covered by component tests, but this PR
does not include browser screenshots.
> 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, GPT-5-class coding agent runtime. Exact model ID and
context window are not exposed in this Paperclip run; tool use and local
shell/code execution were 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 run tests locally and they pass
- [x] I have added or updated tests where applicable
- [ ] If this change affects the UI, I have included before/after
screenshots
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] I will address all Greptile and reviewer comments before
requesting merge
---------
Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-04-21 20:15:11 -05:00
|
|
|
- `paperclipSuggestTasks`
|
|
|
|
|
- `paperclipAskUserQuestions`
|
|
|
|
|
- `paperclipRequestConfirmation`
|
2026-04-06 07:17:48 -05:00
|
|
|
- `paperclipUpsertIssueDocument`
|
|
|
|
|
- `paperclipRestoreIssueDocumentRevision`
|
[codex] Harden heartbeat scheduling and runtime controls (#4223)
## Thinking Path
> - Paperclip orchestrates AI agents through issue checkout, heartbeat
runs, routines, and auditable control-plane state
> - The runtime path has to recover from lost local processes, transient
adapter failures, blocked dependencies, and routine coalescing without
stranding work
> - The existing branch carried several reliability fixes across
heartbeat scheduling, issue runtime controls, routine dispatch, and
operator-facing run state
> - These changes belong together because they share backend contracts,
migrations, and runtime status semantics
> - This pull request groups the control-plane/runtime slice so it can
merge independently from board UI polish and adapter sandbox work
> - The benefit is safer heartbeat recovery, clearer runtime controls,
and more predictable recurring execution behavior
## What Changed
- Adds bounded heartbeat retry scheduling, scheduled retry state, and
Codex transient failure recovery handling.
- Tightens heartbeat process recovery, blocker wake behavior, issue
comment wake handling, routine dispatch coalescing, and
activity/dashboard bounds.
- Adds runtime-control MCP tools and Paperclip skill docs for issue
workspace runtime management.
- Adds migrations `0061_lively_thor_girl.sql` and
`0062_routine_run_dispatch_fingerprint.sql`.
- Surfaces retry state in run ledger/agent UI and keeps related shared
types synchronized.
## Verification
- `pnpm exec vitest run
server/src/__tests__/heartbeat-retry-scheduling.test.ts
server/src/__tests__/heartbeat-process-recovery.test.ts
server/src/__tests__/routines-service.test.ts`
- `pnpm exec vitest run src/tools.test.ts` from `packages/mcp-server`
## Risks
- Medium risk: this touches heartbeat recovery and routine dispatch,
which are central execution paths.
- Migration order matters if split branches land out of order: merge
this PR before branches that assume the new runtime/routine fields.
- Runtime retry behavior should be watched in CI and in local operator
smoke tests because it changes how transient failures are resumed.
> 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, GPT-5-based coding agent runtime, shell/git tool use
enabled. Exact hosted model build and context window are not exposed in
this Paperclip heartbeat environment.
## 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 run tests locally and they pass
- [x] I have added or updated tests where applicable
- [ ] If this change affects the UI, I have included before/after
screenshots
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] I will address all Greptile and reviewer comments before
requesting merge
2026-04-21 12:24:11 -05:00
|
|
|
- `paperclipControlIssueWorkspaceServices`
|
2026-04-06 21:56:13 -05:00
|
|
|
- `paperclipCreateApproval`
|
2026-04-06 07:17:48 -05:00
|
|
|
- `paperclipLinkIssueApproval`
|
|
|
|
|
- `paperclipUnlinkIssueApproval`
|
|
|
|
|
- `paperclipApprovalDecision`
|
|
|
|
|
- `paperclipAddApprovalComment`
|
|
|
|
|
|
|
|
|
|
Escape hatch:
|
|
|
|
|
|
|
|
|
|
- `paperclipApiRequest`
|
|
|
|
|
|
|
|
|
|
`paperclipApiRequest` is limited to paths under `/api` and JSON bodies. It is
|
|
|
|
|
meant for endpoints that do not yet have a dedicated MCP tool.
|