Skip to main content
Glama

Create client intake

define_intake
Idempotent

Create a branded client intake portal to collect logos, files, and credentials, with automated invite emails and reminder chases until all items are submitted.

Instructions

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; revealed exactly once — store the value on the first read), structured (requires schema with JSON Schema).

DECISIONS — questions for the developer, not the client. An item with assignee="owner" and type select/multiselect is a question only the account holder can settle ("does the discounted plan cost 19 or 29?"). Never stop and wait for one: give it a "proposed" answer and carry on building. proposed = { value: "19", rationale: "matches the competitor we benchmarked" } records what you went with and why; it is stored separately from the real answer, so it can never be mistaken for one the developer gave.

Read the answer back from get_intake_results. meta..decided_by tells you which it is: "owner" means a person settled it, "agent_proposal" means the build is still standing on your own pick and may yet be overruled. You cannot confirm your own proposal — answering is the developer's, through the dashboard. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.9.0
    • addedInput schema / properties / client / properties / also_notify
      Added value: +{
      +  "description": "Other people who should receive the same invitation and the same reminders, through the same portal link — two directors of one company, say, where it does not matter which of them supplies the material. Each address gets its own message (nobody sees the others) and its own bounce state, so one dead address does not stop the rest being chased. At most 4, on top of the primary client.",
      +  "items": {
      +    "properties": {
      +      "email": {
      +        "description": "Their email address.",
      +        "type": "string"
      +      },
      +      "name": {
      +        "description": "Their name, used to address their copy.",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "email"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / client / properties / name / description
      Previous value: -"Client name for personalised emails."New value: +"Client name (required). Every email opens by addressing them by name, so a blank one sends \"Hello,\" to someone being asked for their admin password."
    • changedInput schema / properties / client / required
      Previous value: -[
      -  "email"
      -]New value: +[
      +  "email",
      +  "name"
      +]
    • 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"
      +}
    • addedInput schema / properties / items / items / properties / assignee
      Added value: +{
      +  "description": "Who owes this. \"client\" (the default) is something the client fills in through the portal. \"owner\" is a private to-do for the account holder, e.g. \"call the client\": it never appears in the client portal, is never mentioned in a reminder, and never holds up completion of the intake. Use type \"boolean\" for a plain tick-off task. Owner items cannot use type file, file_list, image or secret.",
      +  "enum": [
      +    "client",
      +    "owner"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / items / items / properties / type / enum
      Previous value: -[
      -  "text",
      -  "longtext",
      -  "file",
      -  "file_list",
      -  "image",
      -  "color_list",
      -  "select",
      -  "boolean",
      -  "url",
      -  "secret",
      -  "structured"
      -]New value: +[
      +  "text",
      +  "longtext",
      +  "file",
      +  "file_list",
      +  "image",
      +  "color_list",
      +  "select",
      +  "multiselect",
      +  "boolean",
      +  "url",
      +  "secret",
      +  "structured"
      +]
  2. First observedv0.2.1

TDQS

A4.9/5.0
Behavior5/5

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

It discloses several non-obvious behaviors: BriefGate automatically sends the invite and chases the client, nothing pushes to the agent, follow_up.recommended selects the completion mechanism, secrets are revealed exactly once, and owner items never block completion. These go well beyond the annotations, which only cover read-only/destructive/idempotency hints.

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 tool is complex and the length is mostly purposeful, with clear sections for the example, item types, and decisions. It is front-loaded with the core action and the most critical follow-up warning, though some content could be trimmed without losing value.

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?

Given 18 parameters, nested objects, and no output schema, the description supplies what the schema cannot: the return shape, follow-up workflow, failure mode, and parameter interaction rules. An agent has enough context to call this tool and wire up the resulting intake correctly.

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?

Schema coverage is 100%, and the description adds substantial meaning on top: item type semantics, owner vs client assignee behavior, the proposed-answer concept for developer decisions, and a full worked example. It clarifies how 'secret' items behave and when 'structured' requires a JSON Schema.

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?

The opening sentence states a specific action ('Create a new client intake request') and describes the resource (a branded portal where the client submits assets). It also distinguishes this creation tool from follow-up siblings by noting the returned intake_id is needed for all follow-up calls.

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

Usage Guidelines5/5

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

The description explicitly says to call it once at the start of a project after knowing the assets needed. It then tells the agent how to learn completion, naming get_intake_status and manage_webhook as the relevant alternatives, and warns against creating an intake and never checking again.

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