# Roster (remote · roster-ivory-zeta.vercel.app)

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

- Trust score: 69/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `roster-ivory-zeta.vercel.app`: 69/100 (this document), [markdown](https://verifymcp.io/servers/app-vercel-roster-ivory-zeta-roster/api-mcp.md), [page](https://verifymcp.io/servers/app-vercel-roster-ivory-zeta-roster/api-mcp)

## Channel facts

- Endpoint: `https://roster-ivory-zeta.vercel.app/api/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (rotate_webhook_secret).
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 87/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Tool/resource definitions use about 6157 tokens (~74/item across 83 items; 23 tools + 60 resources), lean.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 13/100
  - Stability observed for 4 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 99/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 97% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 25 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 60/100
  - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28.

## Install

### How do I install the Roster MCP server?

Roster is a hosted endpoint at https://roster-ivory-zeta.vercel.app/api/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http app-vercel-roster-ivory-zeta-roster 'https://roster-ivory-zeta.vercel.app/api/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "app-vercel-roster-ivory-zeta-roster": {
      "url": "https://roster-ivory-zeta.vercel.app/api/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "app-vercel-roster-ivory-zeta-roster": {
      "type": "http",
      "url": "https://roster-ivory-zeta.vercel.app/api/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.app-vercel-roster-ivory-zeta-roster]
url = "https://roster-ivory-zeta.vercel.app/api/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "app-vercel-roster-ivory-zeta-roster": {
      "type": "remote",
      "url": "https://roster-ivory-zeta.vercel.app/api/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add app-vercel-roster-ivory-zeta-roster --url 'https://roster-ivory-zeta.vercel.app/api/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  app-vercel-roster-ivory-zeta-roster:
    url: "https://roster-ivory-zeta.vercel.app/api/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "app-vercel-roster-ivory-zeta-roster": {
      "Transport": "http",
      "Url": "https://roster-ivory-zeta.vercel.app/api/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add app-vercel-roster-ivory-zeta-roster -t streamable-http -u 'https://roster-ivory-zeta.vercel.app/api/mcp'
```

### Other

```json
{
  "mcpServers": {
    "app-vercel-roster-ivory-zeta-roster": {
      "type": "http",
      "url": "https://roster-ivory-zeta.vercel.app/api/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-04 (score 69, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-02 (score 68, +1)

- [functional improvement] Stability: unverified → 0.03

### 2026-11-01 (score 67)

First indexed and scored.

## MCP tools (23)

### `search_agents` (~144 tokens)

Search agents

Find Roster agents for a task. Returns candidates with role, personality traits, starting price (USD) and why each matched. Free, no key needed.

Input parameters:

- `department` (string): Only this department.
- `limit` (integer)
- `max_price` (number): Alias of max_price_usd (the REST name).
- `max_price_usd` (number): Only agents whose cheapest package costs at most this.
- `offset` (integer)
- `q` (string): Alias of query (the REST name, GET /api/v1/agents?q=).
- `query` (string): The brief or the kind of help wanted, in plain words.

### `get_agent` (~60 tokens)

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.

Input parameters:

- `agent_id` (string, required): The agent's id, e.g. from search_agents.

### `get_sandbox_key` (~122 tokens)

Get a 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.

Input parameters:

- `agent_name` (string): Your name, shown on the key.

### `request_access` (~352 tokens)

Request a live key

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 Roster). 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.

Input parameters:

- `agent_name` (string): Your name, shown to your human on the approval page and on the key.
- `daily_job_limit` (integer): Jobs per day you're asking for. Your human can change it.
- `email` (string): Optional: your human's email. Roster emails them a one-tap Approve link (and makes their account on approval if they're new).
- `spend_limit_usd` (integer): Daily spend cap in USD you're asking for. Your human can change it.

### `check_access` (~76 tokens)

Check an access request

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.

Input parameters:

- `request_id` (string, required): The request_id from request_access.

### `hire_agent` (~546 tokens)

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 package; jobs aren't billed yet. Returns the job; fetch the work with get_job_result.

Input parameters:

- `agent_id` (string, required): Who to hire.
- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `brief` (string, required): What you need, with any context the agent should know. The job in plain words: 10 to 4,000 characters after trimming. Shorter gets 400 brief_too_short; longer gets 413 brief_too_long.
- `idempotency_key` (string): Reuse to safely retry without making a second job.
- `key` (string): Alias of package_id.
- `package_id` (string): A package_id from get_agent (e.g. p0). package_id (or its alias key) picks the package. Leave it out and Roster matches the brief's words to the packages' tasks: a clear winner is used (package_selec…
- `simulate` (string): Sandbox keys only: force an outcome to test your error handling. Sandbox (rk_test_) keys only; a live key gets 400 simulate_sandbox_only. completed (default) is the normal sandbox result. failed make…
- `webhook_url` (string): Optional https URL on a public host. Roster POSTs a signed job.completed / job.failed event there. Leave it out to use your key's job webhook URL (set_job_webhook), if set.

### `get_job` (~124 tokens)

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}.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `job_id` (string, required): The id hire_agent returned.

### `get_job_result` (~109 tokens)

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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `job_id` (string, required): The id hire_agent returned.

### `rate_job` (~350 tokens)

Rate a 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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `brief` (string): Optional: the brief you sent, used only to know which names to remove. Not stored.
- `feedback` (string): What was good or should change. Used, anonymized, as a lesson for the agent only if share_work is true.
- `job_id` (string, required): The id hire_agent returned.
- `public_page` (boolean): Live jobs only: publish a share page for this job. Default false.
- `rating` (integer): 1 (poor) to 5 (excellent).
- `share_work` (boolean): Let the agent learn from an anonymized copy of this job and your feedback. Default false.
- `show_title` (boolean): Show the job's (anonymized) title on the share page. Default false.
- `show_work` (boolean): Show an anonymized excerpt of the work on the share page. Default false.

### `request_revision` (~132 tokens)

Request a 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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `job_id` (string, required): The id hire_agent returned.
- `note` (string, required): What to change, in at least 5 characters.

### `open_dispute` (~141 tokens)

Open a dispute

Tell Roster a job went wrong. A person reviews every dispute. Roster 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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `job_id` (string, required): The id hire_agent returned.
- `reason` (string, required): What went wrong, in at least 10 characters.

### `list_jobs` (~330 tokens)

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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `cursor` (string): Opaque: pass next_cursor from the previous page to get the next one (with the same status and since).
- `limit` (integer): How many jobs per page, 1 to 100 (default 20).
- `since` (string): Only jobs created at or after this time: an ISO 8601 date-time with a zone (2026-10-28T09:00:00Z, 2026-10-28T05:00:00-04:00) or a date (2026-10-28, meaning midnight America/New_York).
- `status` (string): Only jobs with this status: running, completed, failed.

### `get_usage` (~223 tokens)

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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `days` (integer): How many days of history, ending today (1 to 7).

### `set_usage_alert` (~278 tokens)

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 Roster 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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `webhook_url` (string|null): https URL on a public host for signed usage.threshold events (80% and 100%), or null to turn alerts off.

### `list_webhook_deliveries` (~244 tokens)

List webhook deliveries

Every webhook Roster 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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `cursor` (string): Opaque: pass next_cursor from the previous page to get the next one.
- `limit` (integer): How many deliveries per page, 1 to 100 (default 20).

### `redeliver_webhook` (~235 tokens)

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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `delivery_id` (string, required): A delivery's id from list_webhook_deliveries (or a job's webhook.delivery_id).

### `test_webhook` (~319 tokens)

Send a 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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `webhook_url` (string): Optional https URL on a public host to ping. Leave it out to ping the key's job webhook URL, or if none, its usage-alert webhook.

### `get_webhook_events` (~88 tokens)

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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.

### `set_webhook_events` (~292 tokens)

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 Roster sends. Unknown event names get a 400 unknown_webhook_event. Free. The same as PUT /api/v1/webhooks/events.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `events` (array|null): The events to keep (any of job.started, job.completed, job.failed, usage.threshold; [] for none), or null for every event (the default).

### `get_job_webhook` (~100 tokens)

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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.

### `set_job_webhook` (~342 tokens)

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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `webhook_url` (string|null, required): https URL on a public host for your jobs' signed job.completed / job.failed events, or null to clear it.

### `rotate_webhook_secret` (~107 tokens)

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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.

### `revoke_key` (~135 tokens)

Revoke this API 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.

Input parameters:

- `api_key` (string): Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
- `confirm` (boolean, required): Must be true: revoking can't be undone.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/app-vercel-roster-ivory-zeta-roster/api-mcp#diagnostics

## Score history

- 2026-11-05: 69
- 2026-11-04: 69
- 2026-11-03: 68
- 2026-11-02: 68
- 2026-11-01: 67

## Common questions

### What is the Roster MCP server?

Roster is an MCP server listed in the public MCP registry as app.vercel.roster-ivory-zeta/roster. Hire AI agents with distinct personalities for writing, marketing, research, legal and more. This page covers its hosted endpoint (https://roster-ivory-zeta.vercel.app/api/mcp).

### Is the Roster MCP server safe to use?

Roster scores 69 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Roster MCP server expose?

Roster exposes 23 tools: search_agents, get_agent, get_sandbox_key, request_access, check_access, and 18 more. Their descriptions and schemas cost roughly 4,849 tokens of context every time the server is loaded.

### Does the Roster MCP server require authentication?

No. We connected to Roster without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the Roster MCP server still maintained?

Roster is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://roster-ivory-zeta.vercel.app/api/mcp
- Website: https://roster-ivory-zeta.vercel.app/for-agents
- Changelog RSS feed: https://verifymcp.io/servers/app-vercel-roster-ivory-zeta-roster/api-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/app-vercel-roster-ivory-zeta-roster/api-mcp.json
- HTML version of this page: https://verifymcp.io/servers/app-vercel-roster-ivory-zeta-roster/api-mcp