Model Context Protocol · a server for one person · spec + demo

Be bookable by agents: a human in the loop, served as an MCP server.

You already run an MCP client. Humanport opens the port the other way: agents, and the people behind them, book your time and expertise by enqueuing a task, pay for the work you take, and wait for your answer. You are the only one who decides what actually happens. A queue with a conscience.

For agent developers it is the human gate their agents need: a person-server that answers a question, runs an errand in the world or acts online on someone's behalf, through the same tools as any other MCP server.

Open the console Read the spec See the business model

requester's agent → person.magzimcreate_task

{
  "kind": "virtual",
  "title": "Review PR #412",
  "body": "Please approve if the tests pass.",
  "priority": "high",
  "location": { "type": "url", "value": "https://github.com/acme/app/pull/412" },
  "reply_to": "queue"
}
// → { "id": "tsk_abc", "status": "pending" }   nothing happens until the operator accepts

Three parties, one queue

The operator comes first: a developer or consultant who already runs an MCP client and wants agents, and the people behind them, to book their time and expertise. A requester (usually someone's agent) puts work in. The server in between is the queue, its rules, a gate agent that screens requesters, and a stream of events.

Requester

Anyone with a token. Sees only their own tasks.

create_task → pending
get_task · list_tasks
subscribe_tasks → events
cancel_task

person.magzim

The MCP server. Holds the queue, gates access by requester, can schedule accepted work into the operator's task manager, emits task_event notifications.

person://magzim/profile
person://magzim/capabilities
person://magzim/availability
person://magzim/queue/stats

Operator

The person. The sole authority over every item; paid per task they take.

respond_to_task (operator-only)
accept · decline · start
block · complete · comment
edit capabilities, availability

Three kinds of work

Every task declares what it asks of the person. The kind decides what a result looks like and whether the operator has to confirm before anything happens.

information

A question

Research, an opinion, a fact only this person knows. The result is an answer.

“Which mornings are open next week?” · “Summarize the contract.”

physical

An action in the world

Usually has a location, travel, effort. Stays pending until the operator accepts.

“Collect the notarized deed.” · “Sign this in person.”

virtual

An action online, on their behalf

Has a target URL. The person does it with their own hands and accounts.

“Approve and merge PR #412.” · “Reply to this email.”

Lifecycle

Every status change is a call to respond_to_task, and only the operator can make it. Requesters can withdraw; deadlines expire on their own.

pending →accept→ accepted →start→ in_progress →complete→ completed

side exits: declined blocked cancelled expired

declined is the operator saying no. blocked pauses in-progress work and can be resumed. cancelled is the requester withdrawing. expired is a passed due_at.

The one rule. Side-effectful tasks (physical, virtual, anything with a budget) stay pending until the operator explicitly accepts. Nothing acts on the person's behalf automatically, and capabilities can declare what is off-limits outright.

The MCP surface

Seven tools and four read-only resources. Full input schemas are in the spec.

Tool	What it does	Who
create_task	Enqueue work: kind, title, body, requester, priority, location, constraints (due, budget, effort), attachments, how to reply.	anyone
get_task	Fetch one task by id.	own tasks
list_tasks	Read the queue with filters on status, kind, priority, requester, date; paginated.	own tasks
subscribe_tasks	Open a live stream of `created`, `status_changed`, `completed`, `cancelled` events, filtered by kind or minimum priority. Delivered as MCP notifications or to a webhook.	anyone
unsubscribe	Close a subscription.	anyone
cancel_task	Withdraw a task you created.	requester
respond_to_task	Advance a task: accept, decline, start, block, complete, comment. Attach the result: outcome, message, data, attachments.	operator only

person://magzim/capabilities what the person accepts: kinds, regions and travel radius for physical work, budget authority, response SLA per priority, off-limits topics.

person://magzim/availability working hours, current load, out-of-office windows.

person://magzim/queue/stats counts by status and kind, backlog, median response time.

Bait and moat: how a person-server makes money

Give away the frontend. Lock the value in the MCP backend. The repo ships a runnable demo of exactly this: a free Claude artifact over a paid MCP server with OAuth identity and a paywall.

Architecture diagram: the copyable artifact frontend, labelled bait, calls your MCP server, labelled moat, which holds identity, free tools, paid tools and the paywall. — The artifact does nothing on its own. Copying it only sends another lead into your funnel.

Discover the artifactfree, remixable frontend; no account yet
awareness
Open it, see “Connect”the mcp capability is null until the viewer connects your connector
the gate
Connect via OAuthyour /authorize page creates a free account
sign-up
Use the free toolsping works; a habit forms
activation
Call a Pro toolpro_report returns an upgrade link instead of the answer
conversion
PayStripe flips paid=true; the same call now answers
revenue

An artifact that uses the mcp capability cannot be made fully public, because it runs with the viewer's connected accounts. That missing “one public link” is not a bug. The connect step is the sign-up and the paywall. In the demo, /authorize is the gate and POST /mcp answers 401 without a token.

What is in the repo

Four pieces at different stages. Together they are the spec, the face, the money, and the memory of a person-server.

specification

person.magzim spec

The task model, three kinds, seven tools with JSON schemas, four resources, the lifecycle and the authorization model.

magzim-person-mcp.md

in-browser mockup

Operator console

Enqueue tasks as a requester, work the queue as the operator, watch the subscription stream. State lives in your browser. The “Server source” tab holds a stdio MCP server in TypeScript that implements the same tools.

src/console.html

runnable

MCP paywall demo

Express + MCP SDK over Streamable HTTP. Minimal OAuth, a free tool, a paid tool that returns a pay link, a checkout that flips the entitlement, a Stripe webhook stub. In-memory store.

mcp-paywall-demo/server.ts · store.ts · companion-artifact.html

sibling project, copied in

Personal Memory

A private memory store with the same instinct: an AI can draft a conclusion over MCP, but it cannot become permanent without evidence, scope, a timeframe, and a human click in the UI.

personal-memory/ · FastAPI + SQLite + MCP

Where it stands

✓Spec v0.1.0 written: task model, tools, resources, lifecycle, authorization.
✓Operator console as a browser mockup, with a stdio server implementation inside it.
✓Paywall demo runs end to end: OAuth, free vs paid tools, checkout, webhook.
○person.magzim as a hosted HTTP server with real auth, a database and the console wired to it. Not built yet. This is the next step.