Skip to main content
Glama

Edit intake settings

update_intake

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 Schema

TableJSON Schema
NameRequiredDescriptionDefault
clientNoClient fields to change. Email cannot be changed here — use manage_recipients.
due_dateNoDeadline in YYYY-MM-DD format. null clears it.
folder_idNoMove this intake to a different folder, using an id from list_folders. null removes it from any folder.
intake_idYesIntake ID returned by define_intake.
owner_noteNoPrivate note, never shown to the client. null clears it.
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. Up to 5000 characters. null clears it. 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_nameNoHuman-readable project name shown to the client.
chase_at_timeNoAnchor reminders to this 24-hour local time in the client's timezone (e.g. "07:00"), overriding quiet hours. null clears it.
max_remindersNoCap on reminder attempts (1-1000), or "unlimited". Raising this above the number already sent reactivates a stalled intake.
chase_intervalNoHow often to remind, only meaningful with chase_schedule="custom". Pair with chase_interval_unit.
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.
chase_interval_unitNoUnit for chase_interval.
respect_quiet_hoursNoWhether reminders pause outside 08:00-19:00 in the client's timezone.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, it discloses critical side effects: including certain fields cancels all pending reminders and re-plans the schedule, raising max_reminders reactivates a stalled intake, and folder_id never touches the chase schedule. It also explains the email limitation and document attachment route, giving an agent accurate expectations.

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

Conciseness5/5

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

The description is long but every sentence carries operational value, and the main purpose is front-loaded before the caveats. It efficiently packs usage guidance, exclusions, side effects, and failure conditions without repetition.

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 tool with 13 parameters, nested objects, and significant side effects, the description covers input requirements, when to use alternatives, error conditions, and special cases like archived intakes and stalled reminders. The output schema exists, so not describing the return value is acceptable.

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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter behavior not visible in the schema: the reminder re-planning trigger, max_reminders reactivation semantics, and null-clearing behavior for folder_id and client_brief. This adds genuine meaning beyond the individual parameter descriptions.

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 description uses a specific verb and resource ('Change settings on an intake that has already been sent') and enumerates exactly which fields can be modified. It clearly distinguishes itself from siblings like define_intake and manage_recipients by stating what this tool can and cannot do.

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?

It explicitly says to use this instead of deleting and recreating an intake when deadlines or chase cadence change, and it names manage_recipients as the alternative for changing the client email. It also gives constraints: fails if archived and at least one field must be provided.

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