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.

If the response carries invitation_sent: false, the client was NOT emailed: an invitation limit was hit (30 per hour on every plan; 10 per UTC day on the Free plan) and the intake was kept as a draft. Say so instead of reporting the client as contacted — note explains how to send it later.

The server cannot notify this conversation when the client finishes (MCP is request/response), so the returned follow_up block describes how completion will be learned:

  • follow_up.recommended = "webhook" — the account has an active webhook endpoint; completion events are delivered there.

  • follow_up.recommended = "schedule" — no endpoint is registered. follow_up.schedule gives the cadence for checking with get_intake_status (every_hours) and the date to stop (until). An account that runs a public HTTPS service can register an endpoint with manage_webhook instead.

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. logo_url, accent_color and sender_name are custom branding (Solo plan and up): on the Free plan they are accepted and stored but not used, and the email and portal show a built-in sender name with the account owner's address instead.
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. No links, web addresses or email addresses in any line — those are rejected; the portal button is the only link in the email. Part of custom branding (Solo plan and up): on the Free plan the lines are stored but the built-in wording is sent. 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
noteNoComes with invitation_sent: false — which limit was hit and how to send the draft later.
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
invitation_sentNoPresent, and false, only when an invitation limit was hit: the intake exists as a draft and the client was NOT emailed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / branding / description
      Previous value: -"Override account-level branding for this intake."New value: +"Override account-level branding for this intake. logo_url, accent_color and sender_name are custom branding (Solo plan and up): on the Free plan they are accepted and stored but not used, and the email and portal show a built-in sender name with the account owner's address instead."
    • changedInput schema / properties / branding / properties / sender_name / description
      Previous value: -"Name shown as email sender, e.g. \"Radim\"."New value: +"Name shown as email sender, e.g. \"Radim\". No links, web addresses or email addresses — those are rejected. Solo plan and up."
    • changedInput schema / properties / email_copy / description
      Previous value: -"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 rather than rendered literally to the client. Layout, button and footer stay as they are."New value: +"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 rather than rendered literally to the client. No links, web addresses or email addresses in any line — those are rejected; the portal button is the only link in the email. Part of custom branding (Solo plan and up): on the Free plan the lines are stored but the built-in wording is sent. Layout, button and footer stay as they are."
    • addedOutput schema / properties / invitation_sent
      Added value: +{
      +  "description": "Present, and false, only when an invitation limit was hit: the intake exists as a draft and the client was NOT emailed.",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / note
      Added value: +{
      +  "description": "Comes with invitation_sent: false — which limit was hit and how to send the draft later.",
      +  "type": "string"
      +}
  2. 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"
      -]
  3. 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"
      +}
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover only the generic safety profile (readOnly=false, openWorld=true, idempotent=true, destructive=false); the description adds substantial non-obvious behavior: invitation rate limits (30/hr, 10/day Free), the draft fallback on invitation_sent:false, the webhook-vs-schedule completion model, and the rule that a secret's value is shown only on first retrieval.

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?

Long but front-loaded and organized: purpose, invocation timing, return handling, quota caveat, follow-up model, example, then item types and decisions. The example and decisions section are justified by the 18-parameter surface, though a few passages could be tightened.

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?

For a complex create tool with nested objects, enums and an output schema, the description covers everything an agent needs to invoke correctly: when to call, what a draft means, how completion is learned, and the item-type/decision model. Return-value shape is also sketched despite the output schema existing.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains item key conventions as result property names, enumerates item types, and documents the 'proposed' sub-field for owner decisions, which does not appear in the input schema at all.

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?

Opens with a specific verb+resource ('Create a new client intake request') and immediately defines what an intake is ('a branded portal where the client submits logos, copy, files, credentials'). This clearly separates it from siblings 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?

States explicit timing ('Call this once at the start of a project, after you know what assets you need') and routes follow-up behavior to alternatives (manage_webhook, get_intake_status). No explicit when-not-to-use clause, but 'call once' implicitly rules out repeats.

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