# BriefGate (npm · @briefgate/mcp)

Client intake for AI agents: get files, copy and logins from clients, chased automatically.

- Trust score: 87/100 (high trust)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-21

## Components

- npm · `@briefgate/mcp`: 87/100 (this document), [markdown](https://verifymcp.io/servers/sekera-radim-briefgate/briefgate-mcp.md), [page](https://verifymcp.io/servers/sekera-radim-briefgate/briefgate-mcp)

## Channel facts

- Registry: `npm`
- Package: `@briefgate/mcp`
- Version: `0.10.5`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, 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-09-21.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 31 of 96 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 97/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to sekera-radim/briefgate-mcp).
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 2 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 62/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 5348 tokens (~356/item across 15 items; 15 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 67/100
  - Stability observed for 20 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 98/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 94% of tool parameters carry a description.
  - Structured output schemas are declared (87% of tools); any adoption earns full credit.
- **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 16 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 BriefGate MCP server?

BriefGate runs locally as an npm package, launched with npx -y @briefgate/mcp. 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 sekera-radim-briefgate -- npx -y @briefgate/mcp
```

### Cursor

```json
{
  "mcpServers": {
    "sekera-radim-briefgate": {
      "command": "npx",
      "args": [
        "-y",
        "@briefgate/mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "sekera-radim-briefgate": {
      "command": "npx",
      "args": [
        "-y",
        "@briefgate/mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add sekera-radim-briefgate -- npx -y @briefgate/mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "sekera-radim-briefgate": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@briefgate/mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add sekera-radim-briefgate --command npx --arg -y --arg @briefgate/mcp
```

### Hermes

```yaml
mcp_servers:
  sekera-radim-briefgate:
    command: "npx"
    args: ["-y", "@briefgate/mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "sekera-radim-briefgate": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@briefgate/mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add sekera-radim-briefgate -t stdio -c npx -a -y @briefgate/mcp
```

### Other

```json
{
  "mcpServers": {
    "sekera-radim-briefgate": {
      "command": "npx",
      "args": [
        "-y",
        "@briefgate/mcp"
      ]
    }
  }
}
```

## 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-09-20 (score 87, +1)

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

### 2026-09-18 (score 86, +1)

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

### 2026-09-17 (score 85, +11)

- [security improvement] Known CVEs: unverified → pass
- [functional improvement] Dependency health: unverified → 0.85

### 2026-09-16 (score 74, −10)

- [security regression] Malware scan: pass → unverified
- [security regression] Known CVEs: pass → unverified
- [security regression] Tool safety: pass → unverified
- [security regression] Stability: 0.47 → unverified
- [functional regression] Capabilities: pass → unverified
- [functional regression] Dependency health: 0.84 → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional] First check of Tool coverage: 87
- [functional] First check of Schema quality: unverified
- [functional] Package version: 0.9.0 → 0.10.5
- [functional] Package version: 0.9.0 → 0.10.4
- [functional] Package version: 0.9.0 → 0.10.1
- [functional] Package version: 0.9.0 → 0.10.0

### 2026-09-14 (score 84, +1)

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

### 2026-09-12 (score 83, +1)

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

### 2026-09-09 (score 82, +1)

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

### 2026-09-07 (score 81, +16)

- [security improvement] Malware scan: unverified → pass

## MCP tools (15)

### `define_intake` (~1710 tokens)

Create client intake

Create a new client intake request — a branded portal where the client submits logos, copy, files, credentials, and other assets. BriefGate sends the invite email and chases the client automatically until all items are collected.

Call this once at the start of a project, after you know what assets you need. Returns { intake_id, portal_url, status, follow_up }. Save intake_id — you need it for all follow-up calls.

AFTER CREATING AN INTAKE, SET UP HOW YOU WILL LEARN IT IS DONE. Nothing pushes to you on its own: MCP is request/response, so the server cannot wake you when the client finishes. Creating the intake and never checking again is the common failure — the completed work then sits in the portal until a human happens to look. The returned follow_up block tells you which of the two mechanisms applies:

\- follow_up.recommended = "webhook" — the account already has an endpoint; deliveries will arrive there and you need do nothing further.
\- follow_up.recommended = "schedule" — no endpoint is registered. If you control a service that can receive public HTTPS, register one with manage_webhook. Otherwise tell the user to set up a recurring check (cron, a systemd timer, a scheduled task in their agent host) that calls get_intake_status every follow_up.schedule.every_hours hours until follow_up.schedule.until, and offer to configure it for them.

Example:
{
  "project_name": "Website for John Finance",
  "client": { "email": "john@example.com", "name": "John", "language": "cs" },
  "due_date": "2026-08-15",
  "branding": { "accent_color": "#1B2A4A", "sender_name": "Radim" },
  "items": [
    { "key": "logo", "type": "image", "label": "Company logo",
      "constraints": { "formats": ["svg","png"], "min_width": 512 } },
    { "key": "hero_copy", "type": "longtext", "label": "Homepage headline (2–3 sentences)",
      "constraints": { "max_chars": 400 } },
    { "key": "wp_admin", "type": "secret", "label": "WordPress admin credentials" },
    { "key": "photos", "type":…

Input parameters:

- `auto_approve_hours` (number): Hours after submission before an item is auto-approved without agent review. Default: 72. Set to 0 to require explicit approval.
- `branding` (object): Override account-level branding for this intake.
- `chase_at_time` (string): Local time of day to send reminders at, "HH:MM" in the client's timezone (e.g. "07:00"). Anchors the cadence to a clock time instead of counting from the invite, and needs an interval measured in who…
- `chase_interval` (integer): How often to remind, only with chase_schedule="custom". Pair with chase_interval_unit. Defaults to every 3 days when omitted. The interval must work out to at least 5 minutes and at most 90 days.
- `chase_interval_unit` (string): Unit for chase_interval. Defaults to "days".
- `chase_schedule` (string): Automated reminder cadence. default=T+2d,T+5d,T+9d,weekly. gentle=T+3d,T+8d,biweekly. aggressive=T+1d,T+3d,T+5d,every-other-day. custom=every chase_interval chase_interval_unit. off=no auto reminders.
- `client` (object, required): Client contact details.
- `client_brief` (string): Free-text brief shown to the client at the top of the portal, above the requested items — information from you to them: an offer, instructions, or context for why you are asking for these items. Up t…
- `due_date` (string): Deadline in YYYY-MM-DD format. Shown in the portal and used to escalate chase cadence.
- `email_copy` (object): Your own subject and intro lines, overriding the built-in translation for this intake. Placeholders: {sender}, {project}, {client}, {count}, {minutes}, {due}. An unknown placeholder is rejected rathe…
- `folder_id` (string): Put this intake in an existing folder from list_folders instead of leaving it unfiled. Folders group intakes by client or project — reuse one for a returning client rather than creating a duplicate w…
- `items` (array, required): List of assets to collect. Each item has key, type, label, and optional constraints.
- `max_reminders`: Reminders to send before the intake is marked stalled and handed back to you (default 3). An integer from 1 to 1000, or the string "unlimited" to keep reminding until the client finishes. Raise it fo…
- `project_name` (string, required): Human-readable project name shown in the invite email and portal heading.
- `respect_quiet_hours` (boolean): Hold reminders to the client's 08:00-19:00 local window (default true). A cadence of minutes or hours pauses overnight and resumes in the morning; set false to send around the clock.
- `retention` (object): How long BriefGate keeps this intake after it is finished. Default: purged 90 days after the client completes. Use mode "on_delivery" when the intake holds anything sensitive (credentials, personal p…
- `send` (boolean): Whether to send the invite email immediately. Default: true. Set to false to create a draft and call /v1/intakes/:id/send later.
- `template` (string): Template slug to pre-populate items (e.g. "restaurant-website", "consulting-firm").

Output parameters:

- `follow_up` (object): How to learn this intake is done — present unless a webhook already covers it. Mirrors FollowUpAdvice in client.ts.
- `intake_id` (string)
- `notices` (array): Cadence caveats, present only when chase_schedule="custom" makes them relevant.
- `portal_url` (string)
- `status` (string)

### `get_intake_status` (~167 tokens)

Check intake progress

Check the completion status of a client intake — which items are submitted, pending, or need revision; the history of automated chase emails sent; and when the client last opened the portal.

Use this to decide whether to send a manual reminder (send_chase), request a revision (request_revision), or fetch results (get_intake_results). Returns per-item status and chase history.

This is also the call a scheduled check should make when no webhook is registered — see follow_up in the define_intake response for the cadence. When status becomes "completed", fetch the results with get_intake_results and carry on with the work that was waiting on them.

Input parameters:

- `intake_id` (string, required): Intake ID returned by define_intake (e.g. "in_8f3k").

Output parameters:

- `chases` (array)
- `client_brief` (string): The brief shown to the client above the requested items, if one is set.
- `client_last_seen` (string|null)
- `due_date` (string|null)
- `intake_id` (string)
- `items` (array)
- `progress` (object)
- `status` (string)

### `get_intake_results` (~313 tokens)

Collect intake results

Retrieve the typed submitted values from a client intake.

Files are returned as signed download URLs that expire after 24 hours.

Secrets (type=secret, e.g. passwords, API keys) are decrypted and included only in the first retrieval. Later calls return first_reveal: false in meta and omit the value, so the user should be ready to receive a secret before this tool is called on an intake that contains one.

Use only_new=true to get only items submitted since the last call (useful in webhook-driven workflows). Use include_pending=true to also return partially filled items.

Returns { results: { <key>: <typed value> }, meta: { <key>: { type, status, submitted_at, first_reveal? } } }.

For a DECISION item (assignee=owner, type select/multiselect), results holds the current answer and meta.<key>.decided_by is "owner" (answered by the account holder) or "agent_proposal" (only a proposal exists). Proposals are returned even without include_pending. A proposal does not bump revision, so only_new returns decisions the account holder has answered or changed since the last call.

Input parameters:

- `include_pending` (boolean): Include items not yet submitted (useful for partial progress checks). Default: false.
- `intake_id` (string, required): Intake ID returned by define_intake.
- `only_new` (boolean): Return only items submitted or updated since the previous get_intake_results call. Default: false.

Output parameters:

- `intake_id` (string)
- `meta` (object): Keyed the same as results.
- `results` (object): Keyed by this intake's own item keys. A value's shape depends on that item's type.
- `status` (string)

### `request_revision` (~165 tokens)

Request a revision

Ask the client to resubmit a specific item with a note explaining what is wrong.

Use this after reviewing get_intake_results and finding an item that does not meet requirements — for example a blurry logo, copy that is too long, or a broken URL. The client is notified automatically and the item status moves to needs_revision.

Returns { status: "revision_requested", item_key }.

Input parameters:

- `intake_id` (string, required): Intake ID returned by define_intake.
- `item_key` (string, required): The key of the item to revise (e.g. "logo", "hero_copy").
- `note` (string, required): Plain-language explanation shown to the client (e.g. "Logo is blurry — we need at least 512 px wide in SVG or PNG with a transparent background").

Output parameters:

- `item_key` (string)
- `status` (string)

### `send_chase` (~109 tokens)

Send a reminder

Send a manual reminder to the client outside the automatic schedule.

Use when a deadline is approaching and the client has not responded to automatic reminders, or when you want to send an SMS after email attempts have failed. The automatic chase schedule continues after this call — this is an extra nudge, not a replacement.

Returns { sent: true }.

Input parameters:

- `channel` (string): Delivery channel. Email is the only one offered.
- `intake_id` (string, required): Intake ID returned by define_intake.

Output parameters:

- `sent` (boolean)

### `list_intakes` (~239 tokens)

List intakes

List all intakes in your account, optionally filtered by status, client email, folder, or a text search.

Use this to get an overview of active projects, find a specific intake by the client's email when you have lost the intake_id, check how many intakes are currently in progress, or see what's in a folder from list_folders.

Returns { intakes: [...], total } where each intake includes intake_id, project_name, status, created_at, due_date, folder_id, and portal_url.

Input parameters:

- `client_email` (string): Filter by client email address.
- `folder_id` (string): Filter by folder, using an id from list_folders. Pass the literal string "none" to see only intakes that are not in any folder.
- `limit` (number): Maximum number of results (1–100). Default: 20.
- `offset` (number): Pagination offset. Default: 0.
- `q` (string): Free-text search: matches a substring of project name, client name, or client email.
- `status` (string): Filter by intake status. Omit to return all.

Output parameters:

- `intakes` (array)
- `total` (number)

### `add_items` (~123 tokens)

Add items to an intake

Add new items to an already-sent intake — for example, when you realise mid-project that you also need a favicon, social media assets, or additional credentials.

The client is notified about the new items. Existing items and their submitted values are not affected. Returns the updated intake object.

Items must follow the same key/type/label rules as define_intake (snake_case keys, type-specific constraints).

Input parameters:

- `intake_id` (string, required): Intake ID returned by define_intake.
- `items` (array, required): New items to add. Same schema as define_intake items.

Output parameters:

- `folder_id` (string|null)
- `follow_up` (object): How to learn this intake is done — present unless a webhook already covers it. Mirrors FollowUpAdvice in client.ts.
- `intake_id` (string)
- `items` (array)
- `portal_url` (string)
- `status` (string)

### `update_item` (~357 tokens)

Edit an item

Change one item on an intake that is already with the client — its type, label, hint, whether it is required, and which file formats it accepts.

Reach for this when the field turns out to be the wrong shape: you asked for an image and the client only has their logo as a PDF, or what you asked for as a line of text is really a file. Widening the accepted formats or switching the type unblocks them without adding a duplicate item and waiving the original.

The item key cannot be changed — results come back under it, so renaming would break whatever reads them. Add a new item instead.

If the client has already answered and the change would make their answer invalid, the call fails and nothing is touched. Repeat it with discard_submitted_value: true to clear the answer and ask them again. A change that leaves their answer valid (a new label, a wider limit) never discards anything.

Input parameters:

- `constraints` (object|null): Same shape as define_intake, e.g. { "formats": ["svg","png","pdf"] }. null clears all constraints.
- `discard_submitted_value` (boolean): Go ahead even though it throws away what the client already sent. Only set this after the call has failed once for that reason.
- `help` (string|null): Hint under the label. null clears it.
- `intake_id` (string, required): Intake ID returned by define_intake.
- `item_key` (string, required): Key of the item to change.
- `label` (string): Human-readable label shown to the client.
- `options` (array|null)
- `pattern` (string|null)
- `required` (boolean)
- `type` (string)

Output parameters:

- `discarded_submitted_value` (boolean)
- `item` (object)

### `update_intake` (~743 tokens)

Edit intake settings

Change settings on an intake that has already been sent — project name, due date, reminder cadence, quiet hours, which folder it's in, the client brief, or the client's name, phone, language, and timezone.

Use this instead of deleting and recreating the intake when a deadline moves or the chase cadence needs to change. If any of chase_schedule, chase_interval, chase_interval_unit, chase_at_time, max_reminders, respect_quiet_hours, due_date, or client.timezone is included, every pending reminder is cancelled and the schedule is re-planned from now — reminders already sent still count toward max_reminders. Raising max_reminders (or setting it to "unlimited") past the number already sent on a stalled intake reactivates it and resumes chasing.

The client's e-mail address cannot be changed here — the portal link and login are bound to it. Use manage_recipients to add, remove, or reinstate an address.

folder_id moves the intake to a different folder (an id from list_folders); set it to null to remove the intake from any folder. It never touches the chase schedule.

client_brief replaces the free-text brief shown to the client above the requested items; set it to null to clear it. Documents attached to the brief are managed via the dashboard or the REST endpoint POST /v1/intakes/:id/brief/files, not through this tool.

Fails if the intake is archived. At least one field must be given. Returns the full, updated intake object.

Input parameters:

- `chase_at_time` (string|null): Anchor reminders to this 24-hour local time in the client's timezone (e.g. "07:00"), overriding quiet hours. null clears it.
- `chase_interval` (number): How often to remind, only meaningful with chase_schedule="custom". Pair with chase_interval_unit.
- `chase_interval_unit` (string): Unit for chase_interval.
- `chase_schedule` (string): Automated reminder cadence. default=T+2d,T+5d,T+9d,weekly. gentle=T+3d,T+8d,biweekly. aggressive=T+1d,T+3d,T+5d,every-other-day. custom=every chase_interval chase_interval_unit. off=no auto reminders.
- `client` (object): Client fields to change. Email cannot be changed here — use manage_recipients.
- `client_brief` (string|null): Free-text brief shown to the client at the top of the portal, above the requested items — information from you to them: an offer, instructions, or context. Up to 5000 characters. null clears it. Docu…
- `due_date` (string|null): Deadline in YYYY-MM-DD format. null clears it.
- `folder_id` (string|null): Move this intake to a different folder, using an id from list_folders. null removes it from any folder.
- `intake_id` (string, required): Intake ID returned by define_intake.
- `max_reminders` (number|string): Cap on reminder attempts (1-1000), or "unlimited". Raising this above the number already sent reactivates a stalled intake.
- `owner_note` (string|null): Private note, never shown to the client. null clears it.
- `project_name` (string): Human-readable project name shown to the client.
- `respect_quiet_hours` (boolean): Whether reminders pause outside 08:00-19:00 in the client's timezone.

### `manage_recipients` (~221 tokens)

Manage intake recipients

Add, remove, or reinstate a person who receives an intake's invite and reminders, alongside or instead of the primary client.

action="add" invites another address the same way also_notify does at define_intake time — its own message, its own bounce state; pass name to address it by name. action="remove" stops future reminders to that address. action="reinstate" is for a bounce that was wrong — the person did get the e-mail — and clears the bounce flag so reminders resume; if that address was the only one still being chased, the schedule is re-planned from now.

Fails if the address is not on the intake, or — for reinstate — if it never bounced in the first place.

Input parameters:

- `action` (string, required): What to do with the address.
- `email` (string, required): The recipient's e-mail address.
- `intake_id` (string, required): Intake ID returned by define_intake.
- `name` (string): Their name, used to address their copy. Only used with action="add".

### `manage_webhook` (~383 tokens)

Manage webhook endpoints

Register, list, or remove a webhook endpoint so BriefGate pushes intake events to your service instead of you polling for them.

Use this ONLY if you control a service that can receive public HTTPS requests. An agent running in a terminal cannot — for that case do not register anything and check on a schedule with get_intake_status instead. A registered endpoint that cannot receive produces failing deliveries and a false impression that the work is being watched.

action="create" returns a signing "secret" exactly once. The receiving service needs it to verify the signature on every delivery (verifyWebhookSignature from @briefgate/mcp/webhook), and it cannot be shown again. If it is ever exposed, there is no rotation in place — delete the endpoint and create a new one, which issues a fresh secret.

Events: intake.completed (all required items in — the one to act on), item.submitted (a single item arrived), client.viewed (the client opened the portal), chase.bounced (a reminder failed to deliver), intake.overdue (the due date passed with required items outstanding — the one to act on when work is blocked), intake.stalled (fires only when the intake sets max_reminders; without it this event never arrives).

Input parameters:

- `action` (string, required): What to do. "list" needs no other argument.
- `events` (array): Events to receive. Required for action="create". For "tell me when the client is done", this is ["intake.completed"].
- `format` (string): Payload shape. "raw" (default) is the signed BriefGate envelope; "slack" and "discord" post a message those services render directly.
- `url` (string): HTTPS endpoint to deliver to. Required for action="create".
- `webhook_id` (string): Endpoint to remove. Required for action="delete".

### `list_folders` (~84 tokens)

List folders

List the folders in your account, used to group intakes by client or project.

Call this before create_folder or before setting folder_id on define_intake, update_intake, or list_intakes — reuse an existing folder for a returning client instead of creating a duplicate.

Returns { folders: [{ id, name, sort_order, intake_count, created_at }] }.

Output parameters:

- `folders` (array)

### `create_folder` (~113 tokens)

Create a folder

Create a new folder to group intakes, e.g. one per client.

Call list_folders first and reuse a matching folder — only create one when none of the existing folders fits. Fails with folder_exists if a folder with this name already exists; use list_folders to find it instead.

Returns the created folder { id, name, sort_order, intake_count, created_at }.

Input parameters:

- `name` (string, required): Folder name, e.g. the client's or project's name. Must be unique in your account.

Output parameters:

- `created_at` (string|null)
- `id` (string)
- `intake_count` (number)
- `name` (string)
- `sort_order` (number)

### `login` (~308 tokens)

Sign in to BriefGate

Sign in without pasting an API key, the same way `snyk_auth` works: this opens a browser page where a human approves this device, then stores the issued key locally.

Call this whenever a tool reports "Not signed in" or that the stored key was revoked or expired.

This is a TWO-PHASE tool because approval can take minutes — longer than a single tool call should block for:
1\. The first call starts the sign-in and returns immediately with a URL and a short code (e.g. "WDJB-MJHT"). Tell the user to open the URL and confirm the code; a browser is also opened automatically when possible.
2\. Call `login` again (no arguments change) to check progress. While the human hasn't approved yet, it replies that it's still waiting. Once approved, the same call reports success and the key is saved — no further action needed, other tools start working immediately.

Do not wait silently for minutes on one call — call this tool again after telling the user to approve, and again if they say they've clicked Allow.

Has no effect if a key is already supplied via the `--api-key` flag or the `BRIEFGATE_API_KEY` environment variable — those always take priority over a locally stored one, so this tool says so instead of running the flow. Not available when this server is running as the shared hosted endpoint (mcp.briefgate.dev): there, connecting a client already triggers OAuth automatically.

### `logout` (~100 tokens)

Sign out of BriefGate

Remove the API key `login` stored locally for this BriefGate server, and best-effort revoke it on the server too (a `DELETE /v1/keys/current` call using that same key). If the revoke call fails — no network, the API is unreachable — the local copy is still removed; the response says so and points at the BriefGate dashboard to revoke it there instead. Not available when this server is running as the shared hosted endpoint.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/sekera-radim-briefgate/briefgate-mcp#diagnostics

## Score history

- 2026-09-21: 87
- 2026-09-20: 87
- 2026-09-19: 86
- 2026-09-18: 86
- 2026-09-17: 85
- 2026-09-16: 74
- 2026-09-15: 84
- 2026-09-14: 84
- 2026-09-13: 83
- 2026-09-12: 83
- 2026-09-11: 82
- 2026-09-10: 82
- 2026-09-09: 82
- 2026-09-08: 81
- 2026-09-07: 81
- 2026-09-06: 65
- 2026-09-05: 80
- 2026-09-04: 64
- 2026-09-03: 79
- 2026-09-02: 63
- 2026-09-01: 78

## Common questions

### What is the BriefGate MCP server?

BriefGate is an MCP server listed in the public MCP registry as io.github.sekera-radim/briefgate. Client intake for AI agents: get files, copy and logins from clients, chased automatically. This page covers its npm package (@briefgate/mcp).

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

BriefGate scores 87 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 21 September 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. 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 BriefGate MCP server expose?

BriefGate exposes 15 tools: define_intake, get_intake_status, get_intake_results, request_revision, send_chase, and 10 more. Their descriptions and schemas cost roughly 5,135 tokens of context every time the server is loaded.

### Is the BriefGate MCP server still maintained?

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

### What licence is the BriefGate MCP server under?

BriefGate declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/@briefgate/mcp
- Socket report: https://socket.dev/npm/package/@briefgate/mcp
- Repository: https://github.com/sekera-radim/briefgate-mcp
- Website: https://briefgate.dev/
- Changelog RSS feed: https://verifymcp.io/servers/sekera-radim-briefgate/briefgate-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/sekera-radim-briefgate/briefgate-mcp.json
- HTML version of this page: https://verifymcp.io/servers/sekera-radim-briefgate/briefgate-mcp