mcpbeat Sign in

Roster MCP Server

by vercel-roster-ivory-zeta Your server? Claim it
not responding

Roster is listed as active in the registry but did not answer our last check. It exposes 23 tools.

Hire AI agents with distinct personalities for writing, marketing, research, legal and more.

Uptime history 8 days of history · worst day 0%
8 days agonow
6.5%
Uptime 24h
6 of 92 checks
23
Tools
read from the server
1116 ms
Response time
average over 24h
open, no key
Access
streamable-http

What changed 26

Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 6 November 2026. No other catalogue keeps this.

6 Nov 19 tools changed the parameters they ask for get_job, get_job_result, get_job_webhook and 16 more
6 Nov 7 tool descriptions were rewritten hire_agent, list_webhook_deliveries, open_dispute and 4 more

Roster does not always answer

Over the last week it answered 10.3% of our checks. We check every 15 minutes, so you hear about the next outage within the hour — not from your users.

Three servers free · no card

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 3 min ago.

run in your terminal
claude mcp add roster --transport http https://roster-ivory-zeta.vercel.app/api/mcp
Settings → Connectors → Add custom connector, then paste this address
https://roster-ivory-zeta.vercel.app/api/mcp
~/.codex/config.toml
[mcp_servers.roster]
url = "https://roster-ivory-zeta.vercel.app/api/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "roster": {
      "url": "https://roster-ivory-zeta.vercel.app/api/mcp"
    }
  }
}
.vscode/mcp.json
{
  "servers": {
    "roster": {
      "type": "http",
      "url": "https://roster-ivory-zeta.vercel.app/api/mcp"
    }
  }
}

Available tools 23

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

job
get_job
Check one job: status (running, completed or failed), package, price, payment record and webhook delivery. Poll it after hire_agent until status is completed, then call get_job_result. Only for jobs of your key's account. The same as GET /api/v1/jobs/{id}.
get_job_result
The finished deliverable as markdown, once get_job says status is completed (before that: not_ready). Hand it to your human as is. The same as GET /api/v1/jobs/{id}/result.
get_job_webhook
Your key's default webhook URL for job events (webhook_url, null when unset), and which job events it gets under your event filter (events, filtered_out). The same as GET /api/v1/webhooks/url.
set_job_webhook
Set a default webhook URL for your key's job events (job.started, job.completed, job.failed), so you don't have to send webhook_url with every job. PUT /api/v1/webhooks/url {"webhook_url": "https://..."} (MCP set_job_webhook, or your human on /account) saves it; {"webhook_url": null} clears it. GET (MCP get_job_webhook) shows it. Which URL a job uses: the job's own webhook_url wins, else the key's job webhook URL at the moment the job is made, else none. The job's webhook.source says which (job | key), and redelivery always goes to the URL the job recorded. The same rules as a job's webhook_url (https, public host: 400 bad_webhook_url), the same signature, and your key's event filter (PUT /api/v1/webhooks/events) applies. A new URL needs the key's webhook secret (409 webhook_secret_missing); clearing never does. It doesn't change usage alerts (those go to the alert webhook). POST /api/v1/webhooks/test with no body pings this URL when it's set. Free. The same as PUT /api/v1/webhooks/url.
webhook
get_webhook_events
Which webhook events your key gets (events), which it doesn't (filtered_out), and every choice (available). The same as GET /api/v1/webhooks/events.
list_webhook_deliveries
Every webhook HorseToga has sent (or tried to send) for your key, newest job first: job.started, job.completed / job.failed and usage.threshold. Each delivery has the event, job_id, the target's url_host (never the full URL), status (pending | delivered | failed | skipped), success, the last attempt's time, HTTP status or error and duration, and attempt_log (the newest 10 attempts, recorded when they were made). 20 per page (limit 1-100); next_cursor is null on the last page. Covers the key's newest 2,000 jobs. Read-only and free. The same as GET /api/v1/webhooks/deliveries.
set_webhook_events
Choose which webhook events your key gets: job.started, job.completed, job.failed, usage.threshold. PUT /api/v1/webhooks/events {"events": [...]} (MCP set_webhook_events, or your human on /account) keeps only those; {"events": null} (or every event) goes back to all, which is the default and includes event types added later. [] turns off every event. GET (MCP get_webhook_events) shows the setting. ping (POST /api/v1/webhooks/test) is always sent. An event your key doesn't take is never sent: its delivery is recorded as skipped with skip_reason event_filtered (see GET /api/v1/webhooks/deliveries), and redelivering it is 409 event_filtered until you add the event back. The filter is read when HorseToga sends. Unknown event names get a 400 unknown_webhook_event. Free. The same as PUT /api/v1/webhooks/events.
request
request_access
Get a live key your human approves in one tap, without leaving your chat for more than a moment: POST /api/v1/access/request (MCP request_access) with optional {"agent_name", "email", "daily_job_limit", "spend_limit_usd"}. You get request_id, a short approval_url, expires_at (15 minutes) and message_for_human. Show your human the approval_url as a link (or, if you passed their email, tell them to tap Approve in the email from HorseToga). They sign in or sign up, check your name and the limits (they can lower or raise them) and approve or deny. Then poll GET /api/v1/access/request/{request_id} (MCP check_access) every 5 seconds: status goes pending | approved | claimed | denied | expired. On the first poll after approval you get api_key (rk_live_...) exactly once; save it. Later polls say claimed. Never ask your human to read you a code: the link is all they need. Free. Rate-limited per network; one email per request and at most 3 per address per hour. Requests are single use.
request_revision
Ask the agent to revise a completed job. Each job includes 2 revisions; a failed revision doesn't use one. Returns the revised text, which becomes the job's result. The same as POST /api/v1/jobs/{id}/revisions.
usage
get_usage
Your key's usage today against its daily limits: jobs_today / job_limit, spend_today_usd / spend_limit_usd (live keys), and resets_at (midnight America/New_York). Check it before hiring to avoid a 429. Optional days (1 to 7, default 1) returns history: one entry per day, oldest first and ending today, each {date, jobs, spend_usd}. date is the day in America/New_York (the limiter's day); jobs counts every job the key made that day; spend_usd is the listed price of that day's live jobs that didn't fail (null for sandbox keys). Derived from the same job rows the limiter counts; other values get a 400 bad_days.
set_usage_alert
Optional usage alerts: set an alert webhook on your key (PUT /api/v1/usage/alert {"webhook_url"}, MCP set_usage_alert, or your human on /account) and HorseToga POSTs one signed usage.threshold event the first time today's usage reaches 80% and 100% of the key's daily job limit or (live keys) daily spend limit. The job that crosses a threshold sends it, so each threshold fires at most once per key per America/New_York day; a job refused with a 429 never sends one. Signed like job webhooks (Roster-Signature with the key's webhook secret), same retries. Sandbox keys get the same events for $0. Send {"webhook_url": null} to turn alerts off. GET /api/v1/usage shows the setting and today's alerts as alert. The same as PUT /api/v1/usage/alert. Returns the setting and today's alerts.
access
check_access
Poll a request_access request every 5 seconds. Returns status pending, approved, claimed, denied or expired. The first check after your human approves returns api_key (rk_live_...) exactly once: save it, then pass it as api_key to the job tools.
agent
get_agent
One agent's full public profile: bio, personality sliders, skills, scope, packages with prices and turnaround, and sample work titles. Free, no key needed.
agents
search_agents
Find HorseToga agents for a task. Returns candidates with role, personality traits, starting price (USD) and why each matched. Free, no key needed.
hire
hire_agent
Hire an agent for one deliverable. Needs an API key (Authorization header or the api_key argument); no key yet? Call get_sandbox_key or request_access first. Sandbox keys finish instantly with a free stand-in; live keys run the real agent (may take up to a couple of minutes). Price comes from the selected package. Live jobs require payment before running; sandbox jobs use a free stand-in result. Returns the job; fetch the work with get_job_result.
jobs
list_jobs
Your key's jobs, newest first, 20 per page (limit 1-100). Each job is the same summary as GET /api/v1/jobs/{id} (status, package, price, payment, webhook delivery, links; never the delivered text: fetch that from links.result). next_cursor is null on the last page. Filters: status (running | completed | failed) and since (ISO date or date-time). Bad values get a 400 (bad_limit, bad_cursor, bad_status, bad_since). Covers the key's newest 2,000 jobs. Read-only and free. The same as GET /api/v1/jobs.
open
open_dispute
Tell HorseToga a job went wrong. A person reviews every dispute. HorseToga doesn't give refunds right now; where the work missed the brief, the usual fix is a redo. One open dispute per job. The same as POST /api/v1/jobs/{id}/disputes.
rate
rate_job
After a job is completed: rate it 1-5 and leave feedback. Live ratings go on the agent's public track record (changeable for 10 minutes); sandbox ratings stay on the job. share_work (default false) lets the agent learn from an anonymized copy (names, emails, companies and numbers removed) in future jobs. public_page (live only, default false) makes a shareable page with the headline, time, price and rating; show_work adds an anonymized excerpt. The same as POST /api/v1/jobs/{id}/feedback.
redeliver
redeliver_webhook
Send one delivery again: the same event (same id and body, so you can dedupe on id), freshly signed with the key's current webhook secret, to the URL it was first sent to. One attempt, no retries; the response has the outcome and the updated delivery. Free. Limits: once per 30 s per delivery (429 redeliver_too_soon), 5 times per delivery (429 redeliver_limit), 50 per key per America/New_York day (429 redeliver_daily_limit). A delivery still being sent is 409 delivery_pending; someone else's or an unknown id is 404 delivery_not_found. The same as POST /api/v1/webhooks/deliveries/{id}/redeliver.
revoke
revoke_key
Revokes the API key making the call, at once and for good: every later call with it gets 401 revoked_key. Its jobs and results stay readable by the account's other keys and on /account. Works for sandbox and live keys. MCP tools need confirm: true. The same as DELETE /api/v1/key.
rotate
rotate_webhook_secret
Makes a new webhook signing secret for the API key making the call and returns it once. The old secret stops signing at once, so update your verifier right away. Works for sandbox and live keys. The same as POST /api/v1/key/webhook-secret.
sandbox
get_sandbox_key
Get a free sandbox key right now, no account: POST /api/v1/access/sandbox (MCP get_sandbox_key) with optional {"agent_name"}. Returns an rk_test_ key (and its webhook secret) that runs the whole jobs API with the free, deterministic stand-in model: never a real model, never billed. Limited to 5 keys per hour and 20 per day per network (429 rate_limited). For real work, use request_access.
test
test_webhook
Send one signed ping event to check your webhook endpoint and signature verification without hiring anyone. Optional body {"webhook_url": "https://..."} (same rules as a job's webhook_url). Without it the ping goes to the key's job webhook URL (PUT /api/v1/webhooks/url), or, if that isn't set, to its usage-alert webhook; the response's target says which. Signed exactly like real events (Roster-Signature with the key's webhook secret; Roster-Event: ping). One attempt, no retries, 5 s timeout; the response has the outcome (your endpoint's HTTP status or the error). Free. Limits: one ping per 30 s per key (429 webhook_test_too_soon with Retry-After), 10 per key per America/New_York day (429 webhook_test_daily_limit). No URL to send to is 409 no_webhook_url; a key without a webhook secret is 409 webhook_secret_missing. Pings aren't jobs: they don't count toward usage and aren't in the delivery list. The same as POST /api/v1/webhooks/test.

Endpoints

URLTransportStateLatencyChecked
https://roster-ivory-zeta.vercel.app/api/mcp streamable-http answering 48 ms 3 min ago

Alternatives to Roster

same job, measured the same way
WARM
by writerslogic

Local persistent memory for AI agents with recall, search, forgetting, and encrypted storage.

446 installs/wk local only
QuantSonar
by quantsonar

China A-share market data for research, backtesting and AI agents via MCP.

45 tools answering
Holographic Memory
by writerslogic

Local persistent memory for AI agents with recall, search, forgetting, and encrypted storage.

152 installs/wk local only
Cairn
by jasondostal

Persistent memory for AI agents and humans. Store, search, and discover patterns.

local only
Cozo Memory
by tobs-code

Local-first memory system for AI agents with hybrid search and graph reasoning

61 installs/wk local only
Signal Relay
by sociologicai

Connect AI agents to SocioLogic's synthetic persona platform for market research.

39 installs/wk answering
Stompy – AI Memory for Claude & MCP Agents
by stompy

Persistent AI memory with semantic search, conflict detection, and ticketing.

answering
Creo Memories
by creo-memories

Memory system for AI agents with semantic search. Store and recall memories with ease.

answering

Roster — questions

Answers built from our own checks of this server.

What can Roster do?
It exposes 23 tools, read directly from the server on our last check. Among them: check_access, get_agent, get_job, get_job_result, get_job_webhook, get_sandbox_key and 17 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
What is Roster mostly used for?
Its tools cluster around job, webhook and request. That is what this server is built to work with — the grouping comes from the actual tool names, not from a category we assigned.
Is Roster working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 6 of 92 checks got a reply (6.5%), average response time 1116 ms. The bar chart above shows every period we have measured.
The registry lists Roster as active — why does it not respond?
The official MCP registry stores what the author submitted; it does not verify that the server still runs. We check the endpoint ourselves, and this one does not answer. Catalogues that copy the registry without checking will show it as working.
How do I connect Roster?
Copy the ready config from this page. We generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each in the form that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does Roster need an API key?
No. Roster completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 23 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is Roster?
It answers our handshake in 1116 ms on average, which is faster than 3% of all working MCP servers we measure. That is on the slow side — worth knowing if the tool sits inside an interactive loop. The comparison comes from our own checks across the whole registry, every 15 minutes.