Claude connector

MCP server changelog

Breaking changes are flagged. Tool additions are non-breaking.

0.26.0 — October 4, 2026

  • + Added: job applications carry tags, the kind of job (Creative Technologist, Forward Deployed, Hardware & Prototyping…). create_resume_application takes up to five; without them the app reads the kind from the title, so jobs filed before this are tagged too. list_resume_applications returns them.

0.25.1 — October 4, 2026

  • ~ Fixed: whoami listed scopes: [] for every token, even while its tools worked. It now reports the scopes the token was granted, the same ones each tool checks.

0.25.0 — October 4, 2026

  • + Added: get_resume_library and save_resume_library. An agent reads the signed-in applicant's whole resume library and writes it back whole, replacing theirs or creating it on the workspace's Resume Library form. Ids tie versions to the jobs, bullets, skills and schools they show; a version that picks an id the library does not have is refused.

0.24.0 — October 3, 2026

  • + Added: create_resume_application: an agent that finds a job creates its application, with where the listing came from (sourceType), whether it was confirmed on the company's own careers page or ATS (verificationStatus), the careers and LinkedIn links, and a matchScore. The same postingUrl twice returns the first application.
  • + Added: a Triage stage before Planning in System: Resume Tracker. Created applications land there; the applicant approves one (it moves to Planning, ready to tailor) or passes (Withdrawn). list_resume_applications filters by it, returns the sourcing fields, and sorts best match first.

0.23.0 — October 3, 2026

  • + Added: the resume kits, as a pair. resumeLibrary (the Resume Library kit) is one per person: every job with every bullet, skill groups, education, and named versions that pick from them. resume (the Job Applications kit) is one per job: the posting, a source version, and the tailored resume. Both described in list_field_types.
  • + Added: list_resume_applications, get_resume_application and save_tailored_resume. Tailoring reads the applicant's whole library and saves a frozen copy on the application; get_resume_application returns the tailoring rules (build from the library, never invent).
  • + Added: an application's stage is its submission status, run by the new System: Resume Tracker workflow (Planning, Applied, Interviewing, Offer, Rejected, Withdrawn); list_resume_applications filters by stage.

0.22.1 — September 30, 2026

  • + Added: endShowReceipt on update_page: the end screen's receipt (submitted time, the assignment answered, and the next workflow step when the form has a review). Default true.

0.22.0 — September 30, 2026

  • + Added: inloadVariants on a scheduleV2grid: a question asked at the grid's top (“Which assignment are you on?”) with two or more options. The answer is stored at <grid>.variant and is required to submit. Each dashboard param may hold one number per option at source.byVariant; source.value stays the fallback. Written by apply_form_tool_call / update_page, described in list_field_types.
  • + Added: evaluate_totals_v2 evaluates a term when sample_data answers it: { "<grid>": { "variant": "<option id>" } }.
  • * Why:colleges with 16- and 17.5-week terms built one page per term, each with a hand-copied grid and dashboard. One grid now serves both, each counselor measured against their own term's numbers.

0.21.0 — September 18, 2026

  • + Added: targetRule.mode on a totals tile: "confirm" (the default, and what every existing rule means) shows the shortfall and asks the respondent to confirm with an optional note; "block" refuses the submit and the POST answers 409, through the same gate as validations[]. Written by apply_form_tool_call / update_page like any metric key, read back by get_form.
  • * Why:the builder's metric editor could only ask for a confirmation, and the block gate could only be reached by writing validations[]by hand. A dean who wants “cannot submit under the cap” now has it on the tile.

0.20.1 — September 16, 2026

  • − Dropped: scheduled reminders. Nothing reads publishSettings.reminders any more: a value sent through update_form_settings is stored like any other passthrough key but nothing acts on it, and the key stays on existing windows untouched. The nightly reminders job is gone with it. Reminders are sent on demand from the submissions roster (POST /api/submissions/remind), which is unchanged.
  • * Why: no tenant had configured a scheduled reminder, and the on-demand remind covers the same outcome with a click.

0.20.0 — September 11, 2026

Breaking: the email-template tools and the template:// resource are removed.

  • − Removed (3 tools): list_email_templates, get_email_template_full, update_email_template; and the template://<id> resource. form://<slug> is the one resource scheme.
  • * Why:they read and wrote rows in a collection nothing sends from. The notification emails (approval, changes requested, signup, reminders) are code — written per recipient in their language since 0.19 — and the rows were seeds of an older version of that code; the templates a campaign could reuse went with campaigns in 0.18. An edit through these tools changed nothing a person received. There is no replacement because there is nothing to edit: a workflow rule picks a template by name, and its wording is the platform's.
  • * No scope changed. forms:read / forms:write keep every other tool they had.

0.19.1 — September 11, 2026

  • + Workflow status labels are translatable through the same overlay: get_form_translations lists them as statuses.<label> and set_form_translations takes statuses: { <label>: translated }. Keyed by the label itself, because the label is a status's identity — what a submission stores and what the workflow's role pointers name — so it is never changed; only what a member's chip shows. Lives on the form, not the workflow template, because the portal reads each form's embedded copy.

0.19.0 — September 11, 2026

  • + get_form_translations and set_form_translations: translate a form's own text — title, page titles, field labels, placeholders, option labels, signup notes — into a language, as an overlay readers of that language see in place of the source. The source text is never changed. Fields are keyed by id and options by value, so a rename in the builder cannot orphan a translation, and a field with no id is reported as untranslatable rather than keyed by a name that drifts.
  • + The read returns a coverage report: what is translated, what is not (with the source text to translate), and what has gone stale — each translation records a hash of the source it was written for, and one whose source the admin has since reworded falls back to the source when rendered and is listed for retranslation.
  • + set_form_translations with propose: true queues the overlay for review in list_pending_changes, the same gate as any other form edit.
  • + Prompt translate-form: the end-to-end workflow — read the tenant's glossary, read coverage, translate, write, verify.
  • * Readers choose a language with ?lang=on a public form, the header toggle, or (members) Settings → Language. The renderer's own chrome was translated in the preceding releases; this is the first release in which the tenant's words can be.

0.18.1 — September 6, 2026

  • + update_form_settings documents renderSettings.family, the form's group on members' My submissions: a string names the group, null inherits it from the starter kit or the form's fields, false keeps the form on its own. The key was already merged through; the tool description now says so, and the third state is new.

0.18.0 — August 21, 2026

Breaking: the campaign, contact and audience tools are removed, and the campaigns:read / campaigns:write scopes no longer exist.

  • * Why: email campaigns were removed from ezInputs. The feature competed in a market the product has no advantage in, while consuming maintenance budget that the approval, accrual and attendance engines earn. This is a product decision, not a deprecation cycle — the tools have no replacement because the capability behind them is gone.
  • − Removed (28 tools): list_campaigns, get_campaign, create_campaign, set_campaign_blocks, apply_tool_call, schedule_campaign, cancel_campaign, duplicate_campaign, list_campaign_snapshots, restore_campaign_snapshot, save_as_template, apply_template_to_campaign, list_templates, get_template, render_email, lint_email, screenshot_email, list_block_types, list_contacts, get_contact, add_contact, update_contact, tag_contact, list_audiences, get_audience, create_audience, add_to_audience, remove_from_audience.
  • − Removed resources: campaign://<id>, campaign://<id>/preview.html and campaign://<id>/lint.
  • − Removed prompts: /new-newsletter, /audit-deliverability, /refresh-template and /promote-form. /build-form and /triage-submissions are unaffected.
  • * Rescoped, not removed: list_email_templates, get_email_template_full and update_email_template moved from campaigns:* to forms:read / forms:write. They manage the workflow notification templates, which are transactional and still part of the product. The template://<id> resource moved to forms:read for the same reason.
  • − set_campaign_mode is gone from apply_form_tool_call, and get_form no longer returns campaignMode. It configured list auto-enrolment and campaign-link prefill, both of which no longer happen. Forms that still carry the key keep it — nothing strips it on save.
  • * What breaks: a connector holding campaigns:read or campaigns:write keeps working for every other tool; the grant is simply ignored. Calls to any removed tool return unknown_tool. Re-consenting drops the dead scopes from the token.
  • * Correction to earlier docs:the connector page advertised "destructive writes auto-snapshot with a 30-day TTL" and a restore_snapshot tool. That snapshotting only ever covered campaigns, and went with them. Form edits are guarded by the propose/accept queue instead — pass propose: true, then list_pending_changes and accept_pending_change / reject_pending_change.

0.17.0 — August 12, 2026

Booking fields gained a shared weekly assignment grid.

  • + booking field bookingConfig.weeklyGrid: set enabled: true (plus startHour, endHour, slotMinutes, days) to render a shared per-room schedule sheet — the same grid as scheduleV2— instead of the single date picker. Respondents DRAG to claim stretches of time and may hold several; other people's bookings render as locked blocks showing who has the room. See list_field_types → booking.
  • * Stored value depends on the mode: the date picker still stores { roomId, date }; the grid stores { claims: [{ roomId, day, start, end }] }, where day is an ABSOLUTE weekday index (Mon=0..Sun=6) and start/end are minutes from midnight. Adding or removing a column never moves an existing claim.
  • * Conflicts are interval overlap, not cell equality:a claim overlapping held time at all is rejected whole, never silently trimmed. Intervals are half-open, so 9–12 and 12–2 don't conflict.
  • * Occupancy stays derived: both shapes are read from submissions at request time (cancelled/rejected submissions release their cells automatically), and the submissions route rejects conflicting claims with a 409 on both first submit and resubmission.

0.17.0 — August 19, 2026

Breaking: advance_submission_status now requires the new submissions:write scope.

  • * Why: it was gated on submissions:recommend, a scope whose whole purpose is to let a connector SUGGEST an approval without being able to perform one. The consent screen told users the connector "cannot actually approve — a human still clicks the button" while that same grant permitted a real workflow status change. Suggesting an approval and performing one are different decisions, so they are now different scopes.
  • * What breaks: an existing connector holding only submissions:recommend now gets an insufficient_scope error from advance_submission_status. Reconnect it and approve the new scope to restore that tool. Every other tool is unaffected — including recommend_submission, bulk_recommend_submissionsand clear_recommendation, which stay on submissions:recommend.
  • * Not a silent widening: nothing gains a capability here. A connector that was never re-consented can do strictly less than before, which is the point.

0.16.1 — July 27, 2026

Fix: the write-path context hint no longer goes silent on unlinked forms.

  • * apply_form_tool_call / apply_form_tool_calls: when the target form has no linked AI Context documents but the tenant has some (often build guides sitting on the sibling form a new build is modeled on), the response note now says so and points at list_context_documents — previously the hint only fired for docs linked to the form being edited, so an agent rebuilding a documented form type elsewhere proceeded unguided.

0.16.0 — July 27, 2026

Batch edits, compact responses, and a loud no-op guard.

  • + apply_form_tool_calls: apply a sequence of granular ops in ONE request — ops validate against the running result in order, everything writes atomically with a single revision bump, and the response is a compact summary with per-op notes. All-or-nothing: the first failing op aborts the batch with nothing written. A 15-op build is one round-trip instead of 15 full-document echoes.
  • + apply_form_tool_call compact option: return a small { revision, pageCount, fieldCount, … } summary instead of the full form document — fetch the doc once at the end with get_form.
  • * update_field no longer silently no-ops: a call whose patch is not under data (e.g. sent as patch:) previously returned success while changing nothing; it now errors with the expected shape and the keys it received, and nothing is written.

0.15.1 — July 27, 2026

Fix: repeater fields now repeat by default.

  • * add_field: field_type: "repeater" now mints the container with repeatable: true (plus repeatMin: 1, repeatMax: 5) — previously the type alone produced a plain non-repeating container unless the call also passed data.repeatable explicitly. Explicit data values still override the defaults.

0.15.0 — July 27, 2026

Staleness signal on AI Context enrichment.

  • * get_form / get_submission: form-scoped documents in buildContext / reviewContext now carry stale: truewhen the form was updated after the document's last edit, and the response note says how many are stale — verify against the current form (or refresh the doc) before relying on flagged guidance. The admin AI Context tab shows a matching "Form updated since" chip.

0.14.0 — July 26, 2026

AI Context guidance now reaches the write path.

  • * apply_form_tool_call: when the target form has AI Context documents, the response note now carries a heads-up with the doc count and where to fetch them (get_form's buildContext / get_context_document) — so an agent that edits without reading first is pointed at the tenant's guidance instead of mutating blind.
  • * create_context_document: same-kind, same-scope near-duplicates are now refused by default — the call returns the existing documents with created: false and asks you to fold additions in via update_context_document. Pass the new optional allow_duplicate: true to create anyway. Prevents repeated write-backs from crowding real guidance out of the enrichment cap.

0.13.0 — July 11, 2026

New field type: estimateWorksheet — construction estimate worksheet.

  • + estimateWorksheet field type:a self-contained cost sheet with line items grouped by division (CSI-style sections), live qty × unit-cost math per row, division subtotals, a sequential markup cascade (e.g. Overhead then Profit), and a bid total + margin readout. Configure via estimateConfig (divisions, units, rowTypes, markups, marginFloor); omit it for sensible defaults. Value shape: { version: 1, rows: [{ division, description, rowType, qty, unit, unitCost }], markups }.
  • + totalsV2 estimate source: { kind: "estimate", field, measure: "directCost"|"bidTotal"|"margin"|"division"|"rowType", key? } — reads computed worksheet measures, so compliance rules can hard-block a submission (e.g. margin below a floor) using the same engine as every other source.
  • * list_field_types now returns the estimateWorksheet schema.

0.12.0 — June 12, 2026

Removed: add_submission_comment (submission comments deprecated).

  • - add_submission_comment is removed. Submission comments have been deprecated and taken out of the product; the tool no longer exists. Use recommend_submission (advisory review) or advance_submission_status for review actions.

0.11.0 — June 12, 2026

Withdrew the experimental preview_form MCP Apps widget.

  • * A short-lived experimental preview_form tool + MCP Apps UI resource (io.modelcontextprotocol/ui) was trialed and removed the same day — inline MCP Apps rendering is still unreliable in current hosts. Form previews remain available via the existing tools and the form’s /share/<slug> link. No stable tools were affected.

0.10.0 — June 12, 2026

AI Context documents — shared guidance for humans and agents.

  • + AI Context tools: list_context_documents, get_context_document, create_context_document, update_context_document, delete_context_document — tenant-scoped markdown guidance documents (kinds: review_guide, form_purpose, field_glossary, general), each optionally linked to a form. Shown to human reviewers in the admin AI Contexttab and the submission-review panel, and read by agents as build guides and review rubrics — write a “how to build X” doc once and the next agent can repeat the build.
  • * get_submission attaches reviewContext andget_form attaches buildContext— the form’s context documents plus tenant-wide ones, delivered with the data so agents don’t need a separate lookup. Bounded (12 docs, 6,000 chars per body) with truncation reported, never silent: oversized docs carry truncated/fullLength and the response note says to fetch the full body via get_context_document.
  • * Server instructions on initialize — connected agents are steered to consult context documents before building or reviewing a form, and to prefer duplicate_formfor same-form-new-term requests (e.g. “make a new inload form for spring”).

0.9.1 — June 11, 2026

Fix: update_form_settings no longer wipes grouped settings.

  • * update_form_settings now deep-merges the groupedrenderSettings keys (signup, booking,auditTrail, reviewSettings). Previously a patch touching one nested key replaced the whole group — e.g.{ reviewSettings: { labelBadges: true } } silently erasedrequireReviewNoteOnReturn and showActivityTimeline. Top-level scalars still replace; unknown keys still pass through.

0.9.0 — June 11, 2026

Safe field renames: rename_field cascades references.

  • + New op rename_field on apply_form_tool_call({ field_name, new_name }) — renames a field and updates every reference to the old name in the same write: totalsV2 metric sources (field / schedule / repeater + sub-field, incl. hoursPair__base/__derived), page logicRules conditions,visibleWhen visibility rules, and submission-tabledisplayFields. The result note lists exactly which references were updated. Previously names were immutable via MCP because a rename silently orphaned these references (totals read 0).
  • * delete_field now warns about orphaned references — deleting a field that totals, logic, visibility, or submission columns still point at returns a warning naming each dangling reference. References are flagged, never auto-removed.
  • * Builder warning banner — opening a form whose config references missing fields (e.g. after an external edit) now shows a non-blocking warning listing each dangling reference, instead of letting totals silently render 0.

0.8.0 — June 9, 2026

Totals v2: cross-referential validation + a dry-run evaluator.

  • * Cross-ref validation on add_field/update_field: a totalsV2 source that points at a field, schedule, or repeater/sub-field that doesn’t exist on the form is now rejected with the list of valid names — instead of being written and silently rendering 0(the most common formula mistake). Builds on the structural validation from 0.7.x.
  • + New tool evaluate_totals_v2 — dry-run a dashboard config (inline, or an existing field via form_slug + field_name) against sample_dataand get each metric’s computed value + target. Runs the exact engine the renderer uses (rounding, repeater sums, schedule exclusions), so you can verify formulas without rendering the form.

0.7.0 — June 8, 2026

Totals v2 formulas + per-event-type schedule policy — documented in list_field_types.

  • * totalsV2 metrics now document the full surface: the{ kind: "repeater", repeater, subField } source (sum a sub-field across repeater rows, incl. hoursPair __base/__derivedhalves), per-metric rounding (half/quarter/whole/ceil/floor), a target goal source, named parameters(param: true constants) and aliases(alias: true named computed values). Formulas now note+ − × ÷ support and the key rule: evaluatedleft-to-right with no operator precedence.
  • * scheduleV2 event types (titleOptions) gain excludeFromTotals(block type doesn’t count toward hours) and respondentHidden(template-only boundary — submitters can’t pick it, e.g. “Non Service”).

0.6.0 — June 7, 2026

Totals Dashboard v2 field type.

  • + New field type totalsV2 — a self-contained metric-tile dashboard configured on the canvas (no separate workspace). Available via create_form/add_field. Config istotalsV2Config = { version: 2, columns, metrics }; each metric sources from a form field, a scheduleV2 total (overall/per-title/per-day), a static value, or a simple +/− formula.

0.5.0 — June 7, 2026

Schedule Grid v2 field type.

  • + New field type scheduleV2 — a self-contained, timezone-safe weekly availability grid that needs no CalendarTemplate. Available via create_form/add_field and listed inlist_field_types. Submitted value is{ version: 2, events: [{ day, start, end, title, color }] }where day is 0=Mon…6=Sun and start/endare minutes-from-midnight. Configure days,startHour/endHour, slotMinutes,titleOptions, and a pre-filled locked template.
  • + Reusable templates: list_schedule_v2_templates,get_schedule_v2_template, create_schedule_v2_template,update_schedule_v2_template, delete_schedule_v2_template— save and reuse a grid’s config + locked blocks across forms.

0.4.0 — May 28, 2026

Form-linked CTA buttons.

  • * Button blocks can now link to one of your forms instead of a URL: set { linkType: "form", formId, formSlug }(get both from list_forms) and omit href. The send path rewrites it into a tracked, name/email-prefilled form link. Reflected in list_block_types schemas.
  • * lint_email now flags form-linked buttons whose target is missing/deleted (form-link-missing), archived (form-link-archived), or unpublished (form-link-unpublished), and no longer false-positives a form button as having “no link.” The form catalog is resolved from your tenant automatically.

0.3.0 — May 26, 2026

Major batch — full tool surface.

  • + Diagnostics: whoami.
  • + Forms admin: archive_form, publish_form, duplicate_form, add_page, update_page, delete_page, reorder_pages, update_form_settings, assign_workflow_to_form.
  • + Reads: list_calendar_templates, get_calendar_template, list_contacts, get_contact, list_audiences, get_audience, list_workflow_templates, get_workflow_template, get_form_stats.
  • + Submissions: bulk_recommend_submissions(HMAC confirm when matching > 25), add_submission_comment, advance_submission_status (HMAC confirm).
  • + Campaigns: create_campaign, schedule_campaign, cancel_campaign, duplicate_campaign, save_as_template.
  • + Contacts & audiences: add_contact, update_contact, tag_contact, create_audience, add_to_audience, remove_from_audience.
  • + Workflow & calendar template writes: create_workflow_template, update_workflow_template, create_calendar_template, update_calendar_template.
  • + Variables: list_variables, get_variable, set_variable_value.
  • + Email templates: list_email_templates, get_email_template_full, update_email_template.
  • + Tenant, media, audit: get_tenant, update_tenant_branding, list_media, delete_media, get_audit_log.
  • * All write tools now carry MCP destructiveHint annotations. All reads carry readOnlyHint.
  • * recommend_submission gains structured signals (concerns[], highlights[],fieldsReferenced[], suggestedAction) for richer review-panel rendering.
  • * Forms now carry a revision counter for optimistic-concurrency protection across multi-tab + MCP + UI edits.
  • * Every write response includes clickable deep links to the affected form / campaign / submission for in-chat hand-off.

0.2.0 — May 2026

  • + Form builder tools (V2 schema): list_forms, get_form, create_form(single- and multi-page with logicRules), apply_form_tool_call, list_field_types.
  • + Submissions soft-approval tools: list_submissions, get_submission, recommend_submission, clear_recommendation. recommend_submission is advisory only — never changes workflow status.
  • + JSON Schemas for every form field type incl. totals(dashboard widgets + formula DSL) and rich select options.

0.1.0 — Initial release

  • + MCP OAuth provider: PKCE S256 + Dynamic Client Registration + Authorization Server Metadata.
  • + Campaigns tools: list_campaigns, get_campaign, set_campaign_blocks, apply_tool_call, render_email, screenshot_email, lint_email.
  • + Email block templates: list_templates, get_template, apply_template_to_campaign.
  • + Auto-snapshots before destructive campaign writes (list_campaign_snapshots, restore_campaign_snapshot, 30-day TTL).
  • + upload_image for the media library.
  • + Slash-command prompts via prompts/list.

Versioning policy

The server's MAJOR.MINOR.PATCH version is exposed at GET /api/mcp in the version field.

  • Patch (0.x.Y): bug fixes, doc updates, internal refactors. No client-visible changes.
  • Minor (0.X.0): new tools, new optional fields on existing tool inputs/outputs, new prompts. Backwards-compatible.
  • Major (X.0.0): breaking schema changes, tool removals, scope renames. Announced ≥ 30 days in advance via this changelog and an email to active OAuth clients' registered contacts where available.