Agent-Native Calendar
Agent-Native Google Calendar - manage events, sync, and public booking
Beschreibung vom Entwickler (englisches Original)
MCP protocol enforcing explicit task acceptance and attestation-tagged completion claims.
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Der Entwickler hat in der Registry keine Installationsangaben gemacht. Sieh dir unten die README des Entwicklers an.
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 7. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto bg4ff8mtdn-dotcom bestätigt, dem das Repo gehört
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (1.0.1) kam vor 3 Monaten in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code.
In derselben Kategorie: Agent-Native Calendar, Excel MCP Server, MCP Server for Excel
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
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.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
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