Agent-Native Calendar
Agent-Native Google Calendar - manage events, sync, and public booking
제작자가 쓴 설명(영어 원문)
MCP protocol enforcing explicit task acceptance and attestation-tagged completion claims.
이 세 가지는 절대 하나의 점수로 합치지 않아요. 의견, 측정, 인기는 서로 다른 것이니까요.
이 서버는 아직 쉬운 말로 된 요약을 쓰지 못했어요. 아래는 레지스트리에서 읽어 온 사실이에요.
쓰고 있는 AI 앱을 고른 다음 설정을 복사하세요.
제작자가 레지스트리에 설치 정보를 올리지 않았어요. 아래 제작자의 README를 확인하세요.
내 컴퓨터에서 실행돼요. 설치하면 AI 앱에 도구 목록이 나타나요.
누구나 볼 수 있는 정보를 점검했고, 코드는 읽지 않았어요. 해당하지 않는 항목은 개수에서 뺐어요. · 2026년 11월 7일 점검
레지스트리 이름이 GitHub 계정 bg4ff8mtdn-dotcom 기준으로 확인되었고, 이 계정이 저장소를 소유하고 있어요
아직 GitHub에서 이 저장소를 읽어 오지 않았어요
아직 GitHub에서 이 저장소를 읽어 오지 않았어요
내 컴퓨터에서 실행되는 서버라 인터넷 엔드포인트가 없어요
내 컴퓨터에서 실행되며, 대신 로컬 설정을 사용해요
내 컴퓨터에서 실행돼요. 도구 목록은 인터넷 엔드포인트가 있는 서버에서만 읽을 수 있어요
레지스트리에서 이 카테고리의 활성 서버 전체와 비교했어요. 스타는 게시자가 저장소를 소유한 경우에만 세요.
해당하는 기본 점검 1개 중 1개를 통과했어요. 코드는 읽지 않았어요. 키나 토큰을 넣기 전에 서버가 어떤 권한을 요구하는지 확인하고, 꼭 필요한 권한만 있는 키를 쓰세요.
레지스트리에 필수 키가 나와 있지 않아요. 다만 처음 쓸 때 로그인을 요구하는 서버도 있어요.
내 컴퓨터에서 실행돼요. AI 앱이 필요할 때 실행하고, 데이터는 제작자의 서버를 거치지 않아요(서버 자체가 온라인 서비스를 호출하는 경우는 제외).
GitHub 저장소는 마지막으로 – 변경됐고, 최신 버전(1.0.1)은 3개월 전 레지스트리에 올라왔어요.
Claude Desktop, Claude Code, Cursor, VS Code처럼 MCP를 지원하는 앱에서 쓸 수 있어요.
같은 카테고리에는: Agent-Native Calendar, Excel MCP Server, MCP Server for Excel
같은 카테고리에서 다른 제작자가 만든 서버예요. 스타 순으로 정렬했어요.
카드 보는 법:★ GitHub 스타i세 기둥: 리뷰 · 점검 · 사용 정도i업데이트 = 최신 버전을 레지스트리에 공개한 날i
Agent-Native Google Calendar - manage events, sync, and public booking
Create and edit Excel files with AI: charts, PivotTables, formulas. No Excel needed.
Excel automation for AI - Sheets, Power Query, DAX, VBA, Tables, Ranges and more. Windows only.
제작자의 저장소에서 쓰인 그대로 가져왔어요. PopNx MCP가 검토하거나 보증한 내용이 아니에요. HTML, 이미지, 스크립트는 제거했어요. 링크를 누르면 이 사이트를 벗어나요.
A small MCP protocol that enforces two rules no mainstream agent framework currently enforces natively:
Observed (I did this myself), Reviewed (I checked evidence of it), or Reported (I'm relaying what I was told). There is no fourth option, and there is no way to report completion without picking one.That's the whole protocol. Everything else in this repo exists in service of those two rules.
Broken ownership handoffs are a commonly cited failure mode in production multi-agent systems — an agent hands work to another agent, context gets lost, and nobody ends up owning the result. Separately, a March 2026 paper on agent identity protocols (Prakash, *AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A*, arXiv:2603.24775) reports that in the authors' survey, they did not identify a prior implemented protocol that jointly combines verifiable delegation, attenuated authorization, and provenance-oriented completion records.
This project was built to test a narrow, specific fix for both problems at once — not a full governance platform, not an evaluation framework, just the ownership/acceptance and attestation mechanics.
Two documented, public incidents shaped this design directly:
Both failures are the same shape: a claim stated with more confidence than it had earned. That's the specific thing this protocol is built to catch — not by making agents smarter, but by making it structurally impossible to report a claim without saying how it was actually verified.
| Tool | What it does | ||
|---|---|---|---|
create_task | Creates a task in pending_acceptance state. Nothing is owned yet. | ||
accept_task | Explicit acceptance. Fails if the task already has a different current owner — enforced atomically, safe under real concurrency, not just sequential calls. | ||
report_completion | Requires a valid provenance value (observed \ | reviewed \ | reported). Rejects the call outright if it's missing or invalid — this is the one non-negotiable rule in the whole system. |
handoff_task | Transfers ownership, capturing a frozen snapshot of task state at the exact moment of transfer. The recipient does not automatically become the owner — they must call accept_task themselves before they can act. | ||
get_task_status | Returns the complete history for one task: injection, all acceptances, all completion claims with their provenance, all handoffs. | ||
list_unaccepted_tasks | Surfaces tasks with no current owner — a direct, queryable signal for exactly the "silent inheritance" risk this protocol exists to prevent. |
These six statements hold in any conformant implementation, at all times:
observed claim that supersedes a reported one on the same task unless the call supplies a sourceReference naming what was verified. Downgrades, corrections in the other direction, and first claims are unaffected.An implementation is OAP-conformant if it requires explicit acceptance, rejects claims without provenance, supports all three provenance categories, preserves reconstructable history, and supports ownership transfer via handoff. Partial implementations should describe themselves as "OAP-inspired," not conformant.
Fair question, and the short answer is that OAP is meant to sit alongside these, not replace them:
Requirements: Node.js 24, PostgreSQL, pnpm.
pnpm install
Set the required environment variables:
DATABASE_URL=<your Postgres connection string>
MCP_ACCESS_TOKEN=
Push the schema and start the API server:
pnpm --filter @workspace/db run push
pnpm --filter @workspace/api-server run dev
Create at least one actor before calling any tool. Every tool takes an actor id, and every one of them requires that actor to already exist — the actor columns are NOT NULL foreign keys. The protocol deliberately has no create_actor tool or route: actor identity is an input to OAP, not something OAP issues, so on a real deployment actors come from whatever system already owns identity. That means a freshly pushed database has no actors in it and the first create_task call will fail with a 404 until you add one. For local development there is a seed script:
pnpm --filter @workspace/scripts run seed-actor alice human "Alice"
It is a plain script, not part of the protocol surface — it is never imported by the server and is not reachable over HTTP.
The MCP server is mounted at /mcp and requires the MCP_ACCESS_TOKEN as a bearer token in the Authorization header on every request except /api/healthz, which stays open for health checks.
Connect a real MCP client (e.g. Claude Code):
claude mcp add --transport http opp http://localhost:5000/mcp --header "Authorization: Bearer <your-token>"
The suite covers the protocol's concurrency guarantees, so it needs a real PostgreSQL instance — it exercises genuinely simultaneous transactions and cannot run against an in-process or single-connection substitute.
pnpm --filter @workspace/api-server run test
Tests connect to postgresql://opp:opptest@127.0.0.1:55432/opp_test by default. Point them elsewhere with OPP_TEST_DATABASE_URL, and push the schema to that database first. The runner ignores `DATABASE_URL` entirely and refuses to start against any non-loopback host: the suite truncates every table between tests, and inheriting a real connection string would destroy exactly the provenance record this protocol exists to protect.
This is an early, personally-tested project, not a polished product. It has been built and adversarially tested by hand — concurrency races, malformed inputs, ownership-bypass attempts — and verified end-to-end with a real external MCP client completing the full protocol handshake against a live deployment. The ownership and attestation guarantees that hand-testing covered are now pinned by an automated suite that runs the races concurrently against a real database. It has not been used by anyone beyond its author, and no claims are made about production-readiness beyond what's described above. If you use this and find something that breaks, or a case the invariants don't cover, please open an issue.
MIT