Skip to main content
Glama

Create client intake

define_intake
Idempotent

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": "file_list", "label": "Photos (5–10 images)", "constraints": { "formats": ["jpg","png","heic"], "min_count": 5, "max_count": 15 } } ] }

Item types: text, longtext, file, file_list, image, color_list, select (one of options[]), multiselect (several of options[]; min_count/max_count in constraints), boolean, url, secret (encrypted; the value is shown only on the first retrieval), structured (requires schema with JSON Schema).

DECISIONS — questions for the account holder, not the client. An item with assignee="owner" and type select/multiselect is a question only the account holder can answer ("does the discounted plan cost 19 or 29?"). It can carry an optional "proposed" answer, e.g. proposed = { value: "19", rationale: "matches the competitor we benchmarked" }, which is stored separately from the account holder's answer and clearly labelled as a proposal.

get_intake_results returns the current answer with meta..decided_by: "owner" when the account holder answered in the dashboard, "agent_proposal" while only the proposal exists. A proposal cannot be confirmed through this API; only the account holder answers it. Item keys must be snake_case (e.g. "logo", "hero_copy", "ga4_id") — they become property names in get_intake_results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sendNoWhether to send the invite email immediately. Default: true. Set to false to create a draft and call /v1/intakes/:id/send later.
itemsYesList of assets to collect. Each item has key, type, label, and optional constraints.
clientYesClient contact details.
brandingNoOverride account-level branding for this intake.
due_dateNoDeadline in YYYY-MM-DD format. Shown in the portal and used to escalate chase cadence.
templateNoTemplate slug to pre-populate items (e.g. "restaurant-website", "consulting-firm").
folder_idNoPut 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 with create_folder.
retentionNoHow 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 photos): the contents are then removed shortly after YOU collect them with get_intake_results, because at that point you already have the files and there is no reason for a copy to sit on our server. An intake you never collect still expires on the day count, so this can only ever delete data earlier, never later. Example: { "mode": "on_delivery" } — or { "mode": "days", "days": 7 } to just shorten the window.
email_copyNoYour 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 rather than rendered literally to the client. Layout, button and footer stay as they are.
client_briefNoFree-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 to 5000 characters. Documents attached to the brief go through the REST endpoint POST /v1/intakes/:id/brief/files (dashboard or REST — not available through this MCP tool set).
project_nameYesHuman-readable project name shown in the invite email and portal heading.
chase_at_timeNoLocal 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 whole days. Naming a time deliberately overrides quiet hours, so "07:00" stays 07:00.
max_remindersNoReminders 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 for a rapid cadence, which would otherwise exhaust three attempts in minutes. A bounce or spam complaint always cancels the remaining reminders, whatever this is set to.
chase_intervalNoHow 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_scheduleNoAutomated 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.
auto_approve_hoursNoHours after submission before an item is auto-approved without agent review. Default: 72. Set to 0 to require explicit approval.
chase_interval_unitNoUnit for chase_interval. Defaults to "days".
respect_quiet_hoursNoHold 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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNo
noticesNoCadence caveats, present only when chase_schedule="custom" makes them relevant.
follow_upNoHow to learn this intake is done — present unless a webhook already covers it. Mirrors FollowUpAdvice in client.ts.
intake_idNo
portal_urlNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • removedOutput schema / additionalProperties
      Removed value: -false
    • removedOutput schema / properties / follow_up / additionalProperties
      Removed value: -false
    • removedOutput schema / properties / follow_up / properties / schedule / additionalProperties
      Removed value: -false
    • removedOutput schema / properties / follow_up / properties / schedule / required
      Removed value: -[
      -  "check_with",
      -  "every_hours",
      -  "until"
      -]
    • removedOutput schema / properties / follow_up / properties / webhook / additionalProperties
      Removed value: -false
    • removedOutput schema / properties / follow_up / properties / webhook / required
      Removed value: -[
      -  "active_endpoints",
      -  "events",
      -  "register_with"
      -]
    • removedOutput schema / properties / follow_up / required
      Removed value: -[
      -  "recommended",
      -  "reason",
      -  "webhook",
      -  "schedule"
      -]
    • removedOutput schema / required
      Removed value: -[
      -  "intake_id",
      -  "portal_url",
      -  "status"
      -]
  2. Changed3 schema fields changed
    • addedInput schema / properties / client_brief
      Added value: +{
      +  "description": "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 to 5000 characters. Documents attached to the brief go through the REST endpoint POST /v1/intakes/:id/brief/files (dashboard or REST — not available through this MCP tool set).",
      +  "maxLength": 5000,
      +  "type": "string"
      +}
    • addedInput schema / properties / folder_id
      Added value: +{
      +  "description": "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 with create_folder.",
      +  "type": "string"
      +}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "follow_up": {
      +      "additionalProperties": false,
      +      "description": "How to learn this intake is done — present unless a webhook already covers it. Mirrors FollowUpAdvice in client.ts.",
      +      "properties": {
      +        "reason": {
      +          "type": "string"
      +        },
      +        "recommended": {
      +          "enum": [
      +            "webhook",
      +            "schedule"
      +          ],
      +          "type": "string"
      +        },
      +        "schedule": {
      +          "additionalProperties": false,
      +          "properties": {
      +            "check_with": {
      +              "type": "string"
      +            },
      +            "every_hours": {
      +              "type": "number"
      +            },
      +            "until": {
      +              "type": "string"
      +            }
      +          },
      +          "required": [
      +            "check_with",
      +            "every_hours",
      +            "until"
      +          ],
      +          "type": "object"
      +        },
      +        "webhook": {
      +          "additionalProperties": false,
      +          "properties": {
      +            "active_endpoints": {
      +              "type": "number"
      +            },
      +            "events": {
      +              "items": {
      +                "type": "string"
      +              },
      +              "type": "array"
      +            },
      +            "register_with": {
      +              "type": "string"
      +            }
      +          },
      +          "required": [
      +            "active_endpoints",
      +            "events",
      +            "register_with"
      +          ],
      +          "type": "object"
      +        }
      +      },
      +      "required": [
      +        "recommended",
      +        "reason",
      +        "webhook",
      +        "schedule"
      +      ],
      +      "type": "object"
      +    },
      +    "intake_id": {
      +      "type": "string"
      +    },
      +    "notices": {
      +      "description": "Cadence caveats, present only when chase_schedule=\"custom\" makes them relevant.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "portal_url": {
      +      "type": "string"
      +    },
      +    "status": {
      +      "enum": [
      +        "draft",
      +        "sent",
      +        "in_progress",
      +        "completed",
      +        "archived"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "intake_id",
      +    "portal_url",
      +    "status"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations, the description reveals important side effects: the invite email is sent, BriefGate chases the client automatically, and nothing pushes back because MCP is request/response. It also warns about the common failure of never checking, explains the follow_up block, and even flags the blank-name pitfall ('Hello,' to someone being asked for their admin password).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but the length is largely justified by 18 parameters, nested objects, and complex lifecycle behavior. It is front-loaded with the core purpose, then uses titled blocks and a concrete example; some content slightly repeats schema details, so it is not perfectly lean.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers creation, the returned contract, follow-up setup, item and assignee semantics, naming constraints, and failure modes. An output schema exists, so the description does not need to enumerate return fields beyond the key { intake_id, portal_url, status, follow_up } shape. Nothing an agent needs to decide whether, when, or how to call it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers 100% of parameters, but the description adds substantial meaning beyond it: a full example intake, snake_case key rule, semantics for each item type, assignee='owner' behavior, proposal/decided_by flow, retention nuances, and chase cadence details. This materially improves an agent's ability to construct correct requests.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States 'Create a new client intake request — a branded portal where the client submits logos, copy, files, credentials, and other assets' with a specific verb, resource, and outcome. The create-vs-manage distinction is clear from 'Call this once at the start of a project' and from the sibling tool names like update_intake and add_items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to call this once at the project start after the needed assets are known, and gives detailed post-create guidance on setting up follow-up via webhook or schedule. It does not explicitly name alternatives like update_intake for modifying an existing intake, so exclusion guidance is implied rather than fully stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources