Skip to main content
Glama

Edit intake settings

update_intake

Update an intake after it's sent: change project name, due date, reminder cadence, client details, folder, or brief without deleting and recreating. Automatically replans pending reminders.

Instructions

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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description discloses the key side-effect: including any of eight listed fields cancels all pending reminders and replans the schedule from now, with already-sent reminders still counting toward max_reminders. It also documents the stalled-intake reactivation behavior, that folder_id 'never touches the chase schedule', and the archived-intake failure condition. No contradiction with annotations.

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?

Eight sentences, each earning its place: purpose, use case, side effects, exclusions, per-field notes, constraints, return value. Despite its length, nothing is redundant with the schema, and the most decision-relevant information (replanning trigger, email exclusion) appears early and prominently.

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 13-parameter tool with nested objects and no output schema, the description covers all invocation requirements: required intake_id, the at-least-one-field rule, failure conditions ('Fails if the intake is archived'), return shape, and side-effect semantics. An agent can invoke it correctly using only this text plus the schema.

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 100%, so the baseline is 3. The description earns a 4 by adding cross-parameter semantics the per-field schema entries don't convey: the exact list of fields that trigger reminder replanning, the interaction between raising max_reminders and reminders already sent, and the guarantee that folder_id is independent of the chase schedule.

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 names a specific verb ('Change') and resource ('an intake that has already been sent') and enumerates the editable fields. It is further differentiated from sibling tools like define_intake (creating), manage_recipients (email), and add_items/update_item (items), so an agent can select it unambiguously.

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 'Use this instead of deleting and recreating the intake when a deadline moves or the chase cadence needs to change' and names manage_recipients as the alternative for email changes. It also tells the agent what not to use it for (brief documents go through REST/dashboard) and states failure preconditions (archived intakes).

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