Agent-Native Calendar
Agent-Native Google Calendar - manage events, sync, and public booking
Description from the maker (original English)
Deployment-readiness checks for document-QA and extraction AI: grounding, extraction, CI gate.
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
You need
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"groundwork": {
"command": "npx",
"args": [
"-y",
"@pharmatools/groundwork",
"mcp"
]
}
}
}Run this in your terminal
claude mcp add groundwork -- npx -y @pharmatools/groundwork mcpPaste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"groundwork": {
"command": "npx",
"args": [
"-y",
"@pharmatools/groundwork",
"mcp"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Paste into .vscode/mcp.json in your project
{
"servers": {
"groundwork": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@pharmatools/groundwork",
"mcp"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
Runs on your computer; the tool list appears in your AI app after you install it.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 6, 2026
The registry name was verified with the GitHub account nickjlamb, which owns the repo
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
This one runs on your computer; there is no internet endpoint
Runs on your computer and uses local settings instead
Runs on your computer; we can only read tool lists from internet endpoints
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
The GitHub repo last changed –, and the latest version (0.4.1) reached the registry 39 days ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Node.js on your computer.
In the same category: Agent-Native Calendar, Excel MCP Server, MCP Server for Excel
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
Agent-Native Google Calendar - manage events, sync, and public booking
Lets AI create and edit Excel files itself, including formulas, charts and PivotTables, without Excel installed.
Excel automation for AI - Sheets, Power Query, DAX, VBA, Tables, Ranges and more. Windows only.
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
Deployment-readiness harnesses for AI deployment patterns.
Redaction · evals from your real failures · a CI gate that fails fabrication
Website · Getting started · Examples · Roadmap · Contributing · Changelog
You have a prototype: your documents, a model, useful output. What you don't have is the apparatus that makes it responsible to ship — a privacy pre-step, an evaluation built from your own failures, and a gate that stops a quiet prompt tweak from deploying a system that fabricates. That apparatus usually requires an ML engineer. Groundwork scaffolds it instead.
Groundwork's units are deployment patterns, not products — think Terraform modules for trustworthy AI deployments. groundwork init scaffolds the whole harness for a pattern:
| Archetype | The pattern | Status |
|---|---|---|
document-qa | documents → retrieval → grounded answers → human review | ✅ shipped |
extraction | documents → structured fields → schema validation → human review | ✅ shipped |
| research synthesis | questions → evidence → synthesis → human review | planned — see the roadmap |
Every check is deterministic: same inputs, same result, every time — no LLM judge, and no API key for the checks themselves.
git clone https://github.com/nickjlamb/groundwork.git && cd groundwork
npm install && npm run build npm run demo # document QA: the whole loop passes, fully offline npm run demo:break # the system starts fabricating — watch the gate go red
✗ GROUNDING demo-savings: ungrounded number "14" — not in the provided context ✗ GROUNDING demo-unanswerable-appeals: unanswerable question — the answer did not abstain
The same loop for structured extraction:
npm run demo:extraction # documents → fields, every check green
npm run demo:extraction:break # a guessed date of birth, a dropped field — red, by name
✗ EXTRACTION demo-referral: SCHEMA: /referral_date must be string ✗ EXTRACTION demo-referral: FABRICATED field "date_of_birth": document does not state it (got "12 April 1988")
That red build is the product: a fabricated figure, a guessed field, or a failed abstention becomes a CI failure, not a user complaint.
Ready for your own system?
npm install -D @pharmatools/groundwork
npx groundwork init # document QA npx groundwork init extraction # structured extraction
| You edit | Groundwork runs | The gate enforces |
|---|---|---|
adapter.mjs — one file: answer() for document QA, extract() for extraction | Redaction pre-step (Redacta) — identifiers become labelled tokens locally, before anything is sent | check --baseline freezes a good run as the floor |
datasets/cases/*.json — gold cases from real questions and real documents, labelled by hand | The archetype's eval (OpenGATE) — document QA: anchored facts · numbers trace to context · abstention. Extraction: schema validity · field accuracy vs gold · no fabricated fields | check --ci in the scaffolded GitHub Action fails any PR below it |
groundwork.config.json — archetype, redaction, eval, and gate settings | Cost profiling — measured token usage, savings in leverage order (caching → batching → trimming → routing) | A human still reviews high-stakes outputs — the gate is a floor, not a certification |
For extraction, one schema choice does most of the safety work: nullability is the abstention contract. A field the system must always find is non-nullable; a field the document may not state is nullable, and the system returns null for it — unknown → null, never guessed. A guessed value in a null-gold field fails by name: FABRICATED field "date_of_birth": document does not state it.
| Example | What it shows | Run |
|---|---|---|
demo/ | Document QA: the full loop on a tiny local system — and the gate catching fabrication by name. Zero network. | npm run demo / npm run demo:break |
demo-extraction/ | Structured extraction: schema validation, field accuracy, and the gate naming a guessed date of birth and a dropped required field. Zero network. | npm run demo:extraction / npm run demo:extraction:break |
examples/claude-doc-qa/ | A real Claude-backed system: answer-from-document-only prompting, prompt caching, key-gated evals, measured usage feeding groundwork cost — plus a mock API so the whole loop runs offline in CI. | npm run example:mock (offline) / npm run example:check (live) |
examples/claude-extraction/ | Claude filling a schema from fictional referral letters: unknown → null in the prompt contract, the schema as the cached prefix, and the gate catching a guessed date of birth — plus a mock API for offline CI. | npm run example:extraction:mock (offline) / npm run example:extraction:check (live) |
groundwork init [archetype] scaffold the harness for a pattern (document-qa, extraction)
groundwork check redaction self-test + the archetype's eval groundwork check --baseline freeze this run as the regression floor groundwork check --ci exit non-zero on failure or regression vs baseline groundwork cost measured token usage + savings, in leverage order
Two ways to learn it: docs/GETTING-STARTED.md is the reference walkthrough (about half an hour), and the course covers the same ground as checkpoint-driven lessons — including the sabotage test, where you deliberately break your own system to prove the gate catches it, and a lesson on the extraction archetype. The scaffolded playbook (GROUNDWORK.md) lives inside your repo, where your team will actually read it.
The same checks ship as an MCP server (groundwork-mcp, stdio) so Claude Code, Cowork, or Claude Desktop can run them conversationally — check_readiness on a repo, check_answer_grounding on a single answer, check_extraction on a single record (no repo needed), scaffold_harness, cost_summary:
{ "mcpServers": { "groundwork": { "command": "npx", "args": ["-y", "@pharmatools/groundwork", "mcp"] } } }
There's also an Agent Skill (skills/groundwork-readiness/) that teaches an agent to run the gate and report results honestly — including refusing to present a green check as a safety certification.
Groundwork is a strong floor, not a guarantee. Deterministic checks catch the failures that can be caught deterministically; they cannot certify an AI system safe. For high-stakes outputs — anything touching health, money, legal standing, or safety — a human must review before the output reaches the person it affects. Extraction raises the stakes quietly: the record feeds decisions, so a wrong field is a wrong decision. The scaffolded playbook says this too, on purpose.
MIT. Everything init scaffolds into your repo is MIT-0 — yours, no attribution needed.