Agent-Native Calendar
Agent-Native Google Calendar - manage events, sync, and public booking
作者による説明(英語の原文)
MCP protocol enforcing explicit task acceptance and attestation-tagged completion claims.
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
使っている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スターi3つの柱:レビュー · チェック · 利用状況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