# Yellowhead Digital agent door (remote · api.yellowhead.digital)

Read your Yellowhead Diagnostics, scans and action items in an AI assistant, and start Diagnostics.

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

## Components

- remote · `api.yellowhead.digital`: 78/100 (this document), [markdown](https://verifymcp.io/servers/digital-yellowhead-agent-door/api.md), [page](https://verifymcp.io/servers/digital-yellowhead-agent-door/api)

## Channel facts

- Endpoint: `https://api.yellowhead.digital/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `0.1.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-07.

- **Endpoint Security**: 100/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
  - The authorisation server supports Client ID Metadata Documents, the current MCP client-registration mechanism.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 57/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 6806 tokens (~272/item across 25 items; 25 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 3/100
  - Stability observed for 1 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 89/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 66% 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.
  - We read all 25 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 26 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Yellowhead Digital agent door MCP server?

Yellowhead Digital agent door is a hosted endpoint at https://api.yellowhead.digital/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 digital-yellowhead-agent-door 'https://api.yellowhead.digital/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "digital-yellowhead-agent-door": {
      "url": "https://api.yellowhead.digital/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "digital-yellowhead-agent-door": {
      "type": "http",
      "url": "https://api.yellowhead.digital/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.digital-yellowhead-agent-door]
url = "https://api.yellowhead.digital/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "digital-yellowhead-agent-door": {
      "type": "remote",
      "url": "https://api.yellowhead.digital/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add digital-yellowhead-agent-door --url 'https://api.yellowhead.digital/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  digital-yellowhead-agent-door:
    url: "https://api.yellowhead.digital/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "digital-yellowhead-agent-door": {
      "Transport": "http",
      "Url": "https://api.yellowhead.digital/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add digital-yellowhead-agent-door -t streamable-http -u 'https://api.yellowhead.digital/mcp'
```

### Other

```json
{
  "mcpServers": {
    "digital-yellowhead-agent-door": {
      "type": "http",
      "url": "https://api.yellowhead.digital/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-07 (score 78, +1)

- [security] Tool “get_action_item” rewrote its description, which is the text the model reads
- [security] Tool “get_report” rewrote its description, which is the text the model reads
- [security] Tool “list_action_items” rewrote its description, which is the text the model reads
- [security] Tool “list_portfolio” rewrote its description, which is the text the model reads
- [security] Tool “run_diagnostic” rewrote its description, which is the text the model reads
- [functional improvement] Stability: unverified → 0.03
- [cosmetic] “list_portfolio” reworded the description of “pillar”
- [cosmetic] “start_diagnostic” reworded the description of “side_a_scores”

### 2026-11-06 (score 77)

First indexed and scored.

## MCP tools (25)

### `list_diagnostics` (~208 tokens)

List Diagnostics

Lists the Diagnostics in the connected Yellowhead account, newest first. Each item has its id, business name, website, status (queued, processing, completed or failed; a run with no result after 15 minutes is reported as failed), client_id, MIDAS score once complete, and created date. Diagnostics are visible across the whole account, not only to the person who ran them. Filters: client_id (one client workspace) and since (created on or after a date and time). An empty page means none were returned for these filters, not that none exist. Fits questions like "what Diagnostics do we have" and "is my Diagnostic ready", and finding two runs to compare.

Input parameters:

- `client_id` (string)
- `cursor` (string): Opaque pagination cursor from a previous list response.
- `limit` (integer): Page size (default 25, max 100).
- `since` (string): Only diagnostics created at/after this RFC 3339 timestamp.

### `get_diagnostic` (~65 tokens)

Get a Diagnostic

Returns one Diagnostic by id: its status, business name, website, client_id, MIDAS score and created date, plus report_id once it has completed. Fits checking whether a particular run has finished; the findings themselves come from get_report.

Input parameters:

- `id` (string, required)

### `get_report` (~283 tokens)

Get a Diagnostic report

Returns the report of a completed Diagnostic by id: the ten pillar scores as the person rated them (side_a_scores) and as detected (side_b_scores), the MIDAS score, executive summary, blind spots, budget and investment reads, business profile, detected tech stack, brand visibility and sentiment, published apps, and a counts-only summary of the AI connectors found. Internal signals are not included. Some detail depends on the account's plan, as the app shows it: on the Free plan the report carries one blind spot (with that pillar's sub-scores only), the brand visibility and sentiment scores without their findings, the stated and estimated tool spend (on older reports, the estimated total) without the per-pillar breakdown, and no market context; the advertising sub-scores also need Starter or above; the investment roadmap (recommended_investment) and published-app identifiers and links need Pro or above (below Pro, published_apps lists only the platforms). A Diagnostic that has not finished returns report_not_ready. Scores for an unchanged site can move a little between runs, so a small change is not on its own evidence that something changed. The findings are what can be observed from outside; when they need business context, priorities or trade-offs, a Strategic Assessment (a human walkthrough of the findings) is the usual next step.

Input parameters:

- `id` (string, required)

### `list_action_items` (~239 tokens)

List action items

Lists the action items in the connected account, newest first. Each has its id, title, description, rationale, status, priority, pillar, phase, estimated cost range, suggested tools, remediation guidance, the source it came from (source_type and source_id: a Diagnostic, which get_report reads, or a Citation, Crawlability or Accessibility Scan, which get_citation_scan, get_crawlability_scan or get_accessibility_scan reads), client_id, assignee and due date. Statuses: suggested, queued, in_progress, completed (the person doing it says it is done), confirmed (a second person signed off), verified (a later Diagnostic saw the fix from outside) and dismissed. Filters: client_id, source_id and status. An empty page means none were returned for these filters. Fits "what should we fix first" and progress reviews.

Input parameters:

- `client_id` (string)
- `cursor` (string): Opaque pagination cursor from a previous list response.
- `limit` (integer): Page size (default 25, max 100).
- `source_id` (string)
- `status` (string)

### `get_action_item` (~128 tokens)

Get an action item

Returns one action item by id with its full detail: why it matters (rationale), what to do (description and remediation guidance), the tools involved, its status and dates, and the source it came from (source_type and source_id: a Diagnostic, or a Citation, Crawlability or Accessibility Scan). Fits explaining or planning one fix. Fixes happen on the business's own systems with its own access; an item becomes verified only when a later Diagnostic sees the fix from outside. Yellowhead's Assist service takes on fixes a team cannot do itself.

Input parameters:

- `id` (string, required)

### `get_usage` (~118 tokens)

Get Diagnostic usage

Returns this month's Diagnostic allowance for the connected account: how many included Diagnostics are used (used), the monthly allowance (limit), how many remain (remaining), the plan, whose allowance a run draws on (pool), and the date the allowance resets (resets_on). On the Free plan it carries a note on the first-month allowance. With client_id, it also gives that client workspace's own monthly limit (per_client). Fits questions about how many Diagnostics are left this month and when the allowance resets.

Input parameters:

- `client_id` (string)

### `list_strategic_assessments` (~160 tokens)

List Strategic Assessments

Lists the published Strategic Assessments in the connected account, newest first, with their ids, the Diagnostic each was based on, client_id and dates. Only published assessments appear: one that is booked or still being written appears once it is published, so an empty page does not mean none was ordered. Filters: client_id and diagnostic_report_id. A Strategic Assessment is a human walkthrough of a Diagnostic's findings: which matter, what to fix first, and whether any need more help.

Input parameters:

- `client_id` (string)
- `cursor` (string): Opaque pagination cursor from a previous list response.
- `diagnostic_report_id` (string)
- `limit` (integer): Page size (default 25, max 100).

### `get_strategic_assessment` (~47 tokens)

Get a Strategic Assessment

Returns one published Strategic Assessment by id: the deliverable written for the business after its live session. Fits working from its priorities and recommendations.

Input parameters:

- `id` (string, required)

### `list_infrastructure_audits` (~115 tokens)

List Infrastructure Audits

Lists the published Infrastructure Audits in the connected account, newest first, with their ids, the Diagnostic each followed, client_id and dates. Only published audits appear: one that is in progress appears once it is published. Filters: client_id and diagnostic_report_id.

Input parameters:

- `client_id` (string)
- `cursor` (string): Opaque pagination cursor from a previous list response.
- `diagnostic_report_id` (string)
- `limit` (integer): Page size (default 25, max 100).

### `get_infrastructure_audit` (~40 tokens)

Get an Infrastructure Audit

Returns one published Infrastructure Audit by id, as published to the account. Fits working from its findings and recommendations.

Input parameters:

- `id` (string, required)

### `list_citation_scans` (~219 tokens)

List Citation Scans

Lists the Citation Scans in the connected account, newest first. A Citation Scan asks a fixed set of buyer questions in one category and country across several AI answer engines and records which websites the answers cite. Each item has its id, the website scanned (target_domain), category, country, status (pending_payment, paid, running, completed, failed or cancelled), client_id, the Diagnostic it started from (diagnostic_report_id), created and completed dates, and once completed the share of answered cells that cited the website (target_share, 0 to 1) and how many answer cells were filled (populated_cells). Filters: client_id and status. An empty page means none were returned for these filters, not that the account has none or that Yellowhead does not offer the scan.

Input parameters:

- `client_id` (string)
- `cursor` (string): Opaque pagination cursor from a previous list response.
- `limit` (integer): Page size (default 25, max 100).
- `status` (string)

### `get_citation_scan` (~188 tokens)

Get a Citation Scan

Returns one Citation Scan by id: its website, category, country, status and dates, the named competitors (competitor_domains), and once completed its results: the ranking of every domain the answers cited with each one's share of answered cells, the coverage (how many answer cells were filled), each answer cell's question, engine, whether the scanned website was cited and which domains were, and where the scan asked them, the head-to-head questions against named competitors. results is null until the scan completes; on a completed scan whose stored results could not be read, results_unavailable is true and the results are in the Yellowhead app. The citations are what the engines answered when asked; they can differ between runs and are not on their own evidence of why a site was or was not cited. The cited page addresses are in the Yellowhead app.

Input parameters:

- `id` (string, required)

### `list_crawlability_scans` (~240 tokens)

List Crawlability Scans

Lists the Crawlability Scans in the connected account, newest first. A Crawlability Scan checks, URL by URL from the website's sitemap, whether AI crawlers are allowed in by robots.txt and whether pages answer AI crawler identities the way they answer a browser. Each item has its id, the website (target_domain), status (draft, importing, awaiting_review, pending_payment, paid, running, completed, failed or cancelled; the first three are the free sitemap import and page review), whether it is a re-scan of an earlier scan's pages (sample_mode same_as_prior) or a first scan (fresh), the approved and measured page counts, client_id, diagnostic_report_id, and created and completed dates. Filters: client_id and status. An empty page means none were returned for these filters, not that the account has none or that Yellowhead does not offer the scan.

Input parameters:

- `client_id` (string)
- `cursor` (string): Opaque pagination cursor from a previous list response.
- `limit` (integer): Page size (default 25, max 100).
- `status` (string)

### `get_crawlability_scan` (~207 tokens)

Get a Crawlability Scan

Returns one Crawlability Scan by id: its website, sitemap, status, dates and page counts (imported, approved, measured, not measured, dead, stale or missing last-modified dates, duplicates, linked but not in the sitemap), and once completed its run summary (results): whether robots.txt and llms.txt were read, the per-crawler roll-up of what robots.txt allows, how pages answered AI crawler identities compared with a browser, pages linked from the site that the sitemap does not list (up to 25 of each list, with the totals), and why a run stopped early if it did. results is null until the scan completes; on a completed scan whose stored results could not be read, results_unavailable is true and the results are in the Yellowhead app. A robots.txt that could not be read is reported as unknown, not as absent. The per-URL results are in the Yellowhead app.

Input parameters:

- `id` (string, required)

### `list_accessibility_scans` (~233 tokens)

List Accessibility Scans

Lists the Accessibility Scans in the connected account, newest first. An Accessibility Scan measures a sample of the website's pages against automated WCAG 2.x A and AA checks, grouped by page template. Each item has its id, the website (target_domain), status (draft, importing, awaiting_review, pending_payment, paid, running, completed, failed or cancelled; the first three are the free sitemap import and page review), whether it is a re-scan of an earlier scan's pages (sample_mode same_as_prior) or a first scan (fresh), the approved and measured page counts, the number of page templates, client_id, diagnostic_report_id, and created and completed dates. Filters: client_id and status. An empty page means none were returned for these filters, not that the account has none or that Yellowhead does not offer the scan.

Input parameters:

- `client_id` (string)
- `cursor` (string): Opaque pagination cursor from a previous list response.
- `limit` (integer): Page size (default 25, max 100).
- `status` (string)

### `get_accessibility_scan` (~193 tokens)

Get an Accessibility Scan

Returns one Accessibility Scan by id: its website, sitemap, status, dates and page counts, and once completed its results: the run summary (pages measured on both viewports, templates sampled, and the note on what automated checks can and cannot show), the per-template roll-up of failing checks (the 20 largest templates and up to 25 of the most widespread failing checks each, with the totals), and on a re-scan the fix verification against the earlier scan as counts (fixed, still failing or not confirmed). results is null until the scan completes; on a completed scan whose stored results could not be read, results_unavailable is true and the results are in the Yellowhead app. Automated checks cover only part of WCAG, so a page with no failing check is not thereby shown to meet it. The per-page results are in the Yellowhead app.

Input parameters:

- `id` (string, required)

### `get_approval_status` (~89 tokens)

Get approval status

Returns the state of a held request by its approval_id (from update_action_item, add_action_item_comment or run_diagnostic): pending_approval (waiting for an account admin in the Yellowhead app), applying, applied, denied, expired or failed, with the request and decision times and any reason given. Only requests made through this connection are visible.

Input parameters:

- `approval_id` (string, required)

### `update_action_item` (~321 tokens)

Update an action item

Requests a change to one action item: its status (queued, in_progress, completed or dismissed), assignee, due date or resolution notes. Available only on a connection an account admin set up in the Yellowhead app and allowed to make this request; a connection made through an assistant's sign-in cannot make it, on any plan. By default the change is held: the result is {status: 'pending_approval', approval_id}, nothing changes until an account admin approves it in the Yellowhead app, and get_approval_status reports the outcome. Only a connection the account has allowed to apply changes directly, and that proves its signing key on each request, applies it at once. Status changes follow the same rules as the app: suggested and verified are set by Yellowhead (verified only when a later Diagnostic sees the fix from outside), and confirmed is a second person's sign-off in the app, so none of the three can be set here. Marking an item completed records that the work was done; it does not verify it.

Input parameters:

- `assigned_to` (string|null): Who the item is assigned to: a name or email kept as a label, the user id of someone who can work on the item (a member of its organization or a client member of its workspace), or null to clear.
- `due_date` (string|null): Calendar date (YYYY-MM-DD) or null to clear.
- `id` (string, required): The action item to update.
- `resolution_notes` (string|null)
- `status` (string)

### `add_action_item_comment` (~203 tokens)

Comment on an action item

Requests a comment on one action item's timeline: what was done, what was found, or what is needed from a person. Available only on a connection an account admin set up in the Yellowhead app and allowed to make this request; a connection made through an assistant's sign-in cannot make it, on any plan. By default the comment is held: the result is {status: 'pending_approval', approval_id}, nothing is posted until an account admin approves it in the Yellowhead app, and get_approval_status reports the outcome. Only a connection the account has allowed to apply changes directly, and that proves its signing key on each request, posts it at once. Comments only add: this cannot edit or delete anything or change the item's status. The same comment sent twice is posted twice.

Input parameters:

- `body` (string, required): The comment text. Plain text; stored and displayed as written.
- `id` (string, required): The action item to comment on.

### `run_diagnostic` (~573 tokens)

Re-run a Diagnostic

Requests a new Diagnostic of the same website and business as an earlier one (prior_diagnostic_id), reusing that run's answers. Available only on a connection an account admin set up in the Yellowhead app and allowed to make this request; a connection made through an assistant's sign-in cannot make it, on any plan. The website, business and account cannot be changed here. The person's own 1-to-10 pillar ratings (side_a_scores) and the spend figures can optionally be updated: anything not sent keeps the earlier run's value, and the approver sees each change beside the earlier value. A run is always held for an account admin to approve in the Yellowhead app, whatever the connection's settings; the result is {status: 'pending_approval', approval_id}. It uses one of the account's included monthly Diagnostics while any remain (get_usage shows how many). Once those are used, a plan that offers additional Diagnostics pays the published per-run rate from the account's prepaid balance, and any other plan is refused. Which of the two applies is decided when the run is requested and checked again at approval; if it changed in between, the run is refused rather than charged differently. After approval a run takes 5 to 10 minutes: get_approval_status gives the new Diagnostic's id and get_diagnostic its progress. Only accounts enabled for runs requested from an assistant can use this tool.

Input parameters:

- `advertising_budget` (integer): Optional. Total monthly media spend, whole US dollars.
- `advertising_budget_digital` (integer): Optional. Monthly DIGITAL ad spend, whole US dollars.
- `advertising_platform_fees` (integer): Optional. Monthly ad platform / management fees, whole US dollars.
- `budget` (integer): Optional. Stated monthly marketing tools/software spend, whole US dollars. Without an override the prior run's stated figure is replayed, or 0 if it never stated one.
- `digital_share_pct` (integer): Optional. Digital share of total media spend: 100 = all digital, 1–99 = partial. This SCALES UP rather than parting out: advertising_budget_digital must carry the DIGITAL amount, never the total, bec…
- `prior_diagnostic_id` (string, required): The diagnostic whose intake this run replays. Must belong to your organization.
- `side_a_scores` (object): Optional. Per-pillar self-assessment overrides, merged over the prior run's scores — omitted pillars keep their prior value. Whole numbers 1–10; unknown pillar names are refused, not ignored. (`web_s…

### `describe_yellowhead` (~194 tokens)

About Yellowhead and the free Diagnostic

Describes Yellowhead Digital, with no sign-in needed: what it is; the free Diagnostic (the ten pillars it checks, how long it takes, what the Free plan includes, and that an account is needed to run one); every plan with its price and monthly Diagnostics; the paid scans and human services with their prices and public pages; and a link that opens the Diagnostic form with a website and business name filled in. Fits questions about what Yellowhead does or costs, whether it checks something, or how to get started, including before any account exists. The optional url and business_name only fill in that link: nothing is scanned, stored or looked up.

Input parameters:

- `business_name` (string): Optional. The business name to prefill in the start link, as the person gave it.
- `url` (string): Optional. The website to prefill in the start link, as the person gave it.

### `list_portfolio` (~547 tokens)

List the Portfolio

Lists the client workspaces of the connected team account (brand workspaces on Business Enterprise), one page at a time, with the total so an answer can say how many are shown out of how many. Each row has the client_id, client name and website, the latest Diagnostic (report_id and date; it may still be running or may have failed) and the days since it, the MIDAS score with its tier, its change from the previous scored Diagnostic and whether that change is larger than the usual run-to-run variation, open_action_items (the Portfolio page's own count: items not done and not dismissed, so suggested, queued and in progress), open_high_priority_items (the open items that are critical or high), and the next scheduled Diagnostic. Both item counts cover only work the account owes: items from Diagnostics classified as a competitor, research or a prospect are not counted (list_action_items still lists them). Sorts: name, largest_decline, largest_improvement, lowest_midas, most_open_high_priority, most_open_items, longest_since_last_diagnostic, most_recent_diagnostic and next_scheduled; in the score and date sorts, a client with no Diagnostic or no score comes last. Filters: search (name or website), status, MIDAS tier, client_id, pillar (counts only that pillar's critical and high items) and min_open_high_priority_items. An empty page means no workspace matched these filters, not that the account has none. Included with team accounts on the Agency plans, Business Enterprise and custom plans. Fits "which clients need attention", ranking clients, and finding a client's client_id by name for list_action_items or list_diagnostics.

Input parameters:

- `client_id` (string): One client workspace's row.
- `cursor` (string): Opaque pagination cursor (next_cursor) from a previous response.
- `limit` (integer): Page size (default 10, max 25).
- `min_open_high_priority_items` (integer): Only workspaces with at least this many open items of critical or high priority, counting only work the account owes.
- `pillar` (string): A pillar (compliance is shown to people as Trust & Security). The critical and high item count, and min_open_high_priority_items, then cover that pillar only.
- `search` (string): Part of a client name or website, matched without regard to case.
- `sort` (string): Row order (default name).
- `status` (string): Active workspaces (default), archived ones, or all.
- `tier` (string): Only workspaces whose latest MIDAS score is in this tier, or that have no score yet.

### `get_portfolio_changes` (~391 tokens)

Get Portfolio changes

Lists the client workspaces whose MIDAS score moved since a date (default: the last 30 days), largest move first. A client appears when its most recent scored Diagnostic is on or after that date and its MIDAS changed, against the scored Diagnostic before it, by more than the usual run-to-run variation; smaller moves are left out, because scores for an unchanged site can move a little between runs. Each item has the client_id and client name, the previous and current MIDAS and the change, both report_ids with their dates for citing (report_id, previous_report_id and previous_report_date are null when that pair cannot be confirmed in this account), and the open items of critical or high priority (only work the account owes: items from Diagnostics classified as a competitor, research or a prospect are not counted). direction narrows the list to declines or improvements; client_id narrows it to one client. An empty list means no client moved by more than that in the window, not that nothing changed. truncated is true when more clients moved by more than that in the window than one call examines (the most recent are examined), so the list may be incomplete. Archived workspaces are not included. Included with team accounts on the Agency plans, Business Enterprise and custom plans. Fits "which of my clients got worse this month" and "who improved since our last review".

Input parameters:

- `client_id` (string): One client workspace only.
- `cursor` (string): Opaque pagination cursor (next_cursor) from a previous response.
- `direction` (string): declined, improved, or any (default).
- `limit` (integer): Page size (default 10, max 25).
- `since` (string): Start of the window: a date (YYYY-MM-DD, read as midnight UTC) or an RFC 3339 date-time. Default: 30 days ago.

### `start_diagnostic` (~943 tokens)

Start a free Diagnostic

Starts a Diagnostic of a website for the signed-in person, in two calls. The first call returns a preview and starts nothing: the website, the business name, the ten 1-to-10 self-ratings (which were answered, carried over or entered as 5 for "not sure"), the monthly tools budget, where the run is filed, which of the account's included monthly Diagnostics it uses, and a confirmation_token. A second call with that token starts it; any change needs a new preview. It uses only the account's included Diagnostics: when none are left the result is quota_exhausted with the reset date and the plans page, and nothing is charged. A run takes 5 to 10 minutes and a completion email also arrives; get_run_status reports progress. earlier_report_id fills in the website, name, ratings and budget from an earlier report, for a re-check; if that run did not complete and the same person started it, starting it again once for the same website and name does not use another Diagnostic (the preview says whether it applies). On an account with workspaces (clients, prospects or brands), client_id or file_as says where the run is filed, and needs_client lists the candidates when that is not clear. For an owner or admin of an Agency-plan team account, file_as prospect on a website not yet in Prospects creates a new prospect workspace for it (named by prospect_name, else the business name); the preview says so and nothing is created before the confirmation. The same person may ask for a new client workspace for a website no workspace holds: file_as client with client_name (the new workspace's name); without client_name a miss lists the client workspaces instead. Available on connections made through an AI assistant's sign-in.

Input parameters:

- `budget` (integer|null): Roughly what the business spends a month on marketing tools and software, in whole US dollars. Null when unknown: it is then entered as 0, the intake form's own default. Left out, it is also entered…
- `business_name` (string): The name of the business that operates the website, as the person gave it. Optional with earlier_report_id.
- `client_id` (string): The client, prospect or brand workspace to file the run in. It must be a workspace of this account.
- `client_name` (string): Asks for a new client workspace with this name, for a website no workspace of the account holds. Sent only with file_as client and without client_id, and only when the person asked for a new client w…
- `confirmation_token` (string): The token from this tool's preview. Present only on the second call, which starts the run.
- `earlier_report_id` (string): An earlier Diagnostic of this account whose website, business name, ratings and budget fill in anything not sent.
- `file_as` (string): What the person asked for when no client_id is sent: prospect (filed in Prospects; for an owner or admin of an Agency-plan team account, a website not yet in Prospects gets a new prospect workspace),…
- `prospect_name` (string): The name of a new prospect workspace, sent only with file_as prospect and without client_id. Left out, the business name is used. Invisible and control characters are removed; it needs a letter or di…
- `side_a_scores` (object): The person's own 1-to-10 rating of each pillar, keyed attribution, tech_stack, conversion, compliance (shown to people as Trust & Security), brand, marketing, advertising, competitors, product and di…
- `url` (string): The website to check, as the person gave it (a domain or an http/https address). Tracking parameters are removed, and the address that remains must be at most 2048 characters. Optional with earlier_r…

### `get_run_status` (~137 tokens)

Get a Diagnostic run's status

Reports whether a Diagnostic is queued, running, completed or failed, by its id (diagnostic_id, as start_diagnostic and list_diagnostics give it), with when it started and how many minutes have passed. A Diagnostic usually takes 5 to 10 minutes; one taking longer is reported as running with slow set, because it may still finish, and as failed only once it has recorded a failure or 30 minutes have passed. A failed result says whether starting it again from this connection uses another of the month's Diagnostics. Fits "is it ready yet?" at any point in the conversation.

Input parameters:

- `diagnostic_id` (string, required)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/digital-yellowhead-agent-door/api#diagnostics

## Score history

- 2026-11-07: 78
- 2026-11-06: 77

## Common questions

### What is the Yellowhead Digital agent door MCP server?

Yellowhead Digital agent door is an MCP server listed in the public MCP registry as digital.yellowhead/agent-door. Read your Yellowhead Diagnostics, scans and action items in an AI assistant, and start Diagnostics. This page covers its hosted endpoint (https://api.yellowhead.digital/mcp).

### Is the Yellowhead Digital agent door MCP server safe to use?

Yellowhead Digital agent door scores 78 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 Yellowhead Digital agent door MCP server expose?

Yellowhead Digital agent door exposes 25 tools: list_diagnostics, get_diagnostic, get_report, list_action_items, get_action_item, and 20 more. Their descriptions and schemas cost roughly 6,081 tokens of context every time the server is loaded.

### Does the Yellowhead Digital agent door MCP server require authentication?

Yes. Yellowhead Digital agent door asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

### Is the Yellowhead Digital agent door MCP server still maintained?

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

### What did VerifyMCP test on the Yellowhead Digital agent door MCP server?

VerifyMCP ran 13 checks on Yellowhead Digital agent door, covering TLS certificate, Authorization, HTTPS, HSTS header and 9 more. Supply Chain Security and Provenance & Transparency do not apply to a hosted endpoint, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.

## Links

- Remote endpoint: https://api.yellowhead.digital/mcp
- Website: https://yellowhead.digital/docs/agent-door
- Changelog RSS feed: https://verifymcp.io/servers/digital-yellowhead-agent-door/api.xml
- Changelog JSON feed: https://verifymcp.io/servers/digital-yellowhead-agent-door/api/changelog.json
- Trust report (JSON): https://verifymcp.io/servers/digital-yellowhead-agent-door/api.json
- HTML version of this page: https://verifymcp.io/servers/digital-yellowhead-agent-door/api