J
Jonathan Carter
The MCP server exposes RECORDS well and CONFIGURATION poorly.
Contacts, opportunities, conversations and transactions are all readable. The objects that define how a sub-account actually behaves mostly are not. There is no way to list a workflow, a form, a calendar, a product, a tag, or a user.
That blocks anything needing to know how an account is set up rather than what is in it: auditing, documentation, migration, agency-side QA, or handing a sub-account to a new operator.
Below is the full set of reads that are missing, grouped by area. Some may already exist in the public REST API; where they do, exposing them through MCP should be a wrapper change rather than new engineering.
  1. AUTOMATION AND MESSAGING
Nothing in this area is reachable today. This is the largest gap.
  • workflows_get-workflows — list: id, name, status, folder, created, updated
  • workflows_get-workflow — full definition, see the note below
  • triggers_get-triggers — legacy Triggers, the pre-Workflows system
  • campaigns_get-campaigns — legacy Campaigns, with status
  • emails_get-templates — template list; emails_fetch-template already exists but requires an id nothing returns
  • sms_get-templates — template list with message body
  • trigger-links_get-trigger-links — name, destination URL, id
  • ai_get-agents — Conversation AI and Voice AI agents: instruction set, channels, escalation rules, status
  • reputation_get-review-requests — review request automations: trigger, template, platform pushed to
Note on workflows_get-workflow: please return action parameters, not just action types.
A response listing only "SendEmail, AddTag, UpdateField" is not enough to understand a workflow. To be useful it needs, per action, the thing that action is configured to act on: the tag it adds or removes, the email or SMS template it sends, the custom field or custom value it writes and the value written, the pipeline and stage it moves an opportunity to, the webhook URL it calls, the other workflow it starts or stops, and the media asset it attaches.
Branch conditions need their operands for the same reason. Which tag or field a branch tests on is how you learn what a workflow READS, as opposed to what it writes.
With that included, "which workflows use this tag, field or template?" becomes answerable client-side. Without it, that stays unanswerable even with everything else on this list implemented.
Legacy Triggers and Campaigns matter more than they may appear. Both are enabled by default on every sub-account we looked at, and either can hold live automation that is completely invisible from the Workflows list.
  1. FORMS, SURVEYS AND CALENDARS
  • forms_get-forms — list: id, name, folder
  • forms_get-form — field schema, field types, custom-field mapping, conditional logic, submission behavior
  • surveys_get-surveys — as above, for surveys
  • surveys_get-survey
  • calendars_get-calendars — list: id, name, type, group, assigned users, status
  • calendars_get-calendar — duration, buffers, availability rules, attached form, confirmation behavior, booking URL, notification settings
  • calendars_get-calendar-groups — group id and name
calendars_get-calendar-events already exists, but it requires a calendarId, userId or groupId, and nothing in the MCP surface returns any of those. It cannot be called without obtaining an id from outside MCP first.
The event payload also never contains the calendar's name, so even working backwards from events does not identify which calendar you are looking at.
  1. COMMERCE
  • products_get-products — name, type, price, billing interval, trial, connected processor, where sold from, status
  • products_get-prices — price points per product
  • coupons_get-coupons — code, discount, validity window, applicable products, status
  • memberships_get-offerings — courses, memberships and communities: structure, modules, lesson titles, drip schedule
  • memberships_get-access-rules — what grants access and what revokes it
  • invoices_get-templates — invoice templates and tax collection settings
  • affiliates_get-campaigns — Affiliate Manager: campaigns, commission structure, payout settings
  • documents_get-documents — document and contract templates, signature settings
payments_list-transactions exists, so a partial catalog can be reconstructed from what has sold. That cannot show a product configured but never sold, cannot show list price where a discount was applied, and cannot show a coupon at all.
  1. SUB-ACCOUNT SETTINGS
  • locations_get-custom-values — custom values (global variables): name, value, id
  • locations_get-tags — tag list WITH contact counts; today the only way to enumerate tags is sampling contact records, which cannot find a tag applied to zero contacts, exactly the tag worth finding
  • locations_get-smart-lists — saved segments with their filter logic
  • locations_get-custom-field-folders — folder id and name; locations_get-custom-fields returns parentId but nothing resolves it to a name
  • locations_get-plan — plan tier and business hours, both absent from locations_get-location
  • users_get-users — name, email, role, permissions, which locations each can reach, status
  • reports_get-dashboards — custom dashboards and reports
  1. INTEGRATIONS
  • integrations_get-connections — connected services per location: payment processor, email provider, phone provider, per-user calendar syncs, marketplace apps
  • integrations_get-private-tokens — private integration tokens with scopes and creation date
  • webhooks_get-webhooks — outbound webhook destinations and triggers
  • phone_get-numbers — numbers attached, provider, A2P registration status
  • phone_get-call-routing — IVR menu options, routing targets, business-hours and after-hours behavior, voicemail
  • email_get-sending-config — sending domain, provider, authentication status
The token inventory matters more than its position suggests. An unattributed live API token is a security finding, and there is currently no programmatic way for an account owner to enumerate their own tokens.
  1. PUBLIC SURFACES
  • funnels_get-funnels — funnel and website list: name, type, serving domain, status
  • funnels_get-pages — page list with URLs, and the forms and calendars embedded on each
  • funnels_get-tracking-code — injected scripts, with site-level versus page-level scope
  • portal_get-config — client portal: enabled, domain, what it exposes, authentication, how access is granted or revoked
  • media_get-files — media library listing
  1. CUSTOM OBJECTS
  • custom-objects_get-objects — the object itself: name, description, what it links to
Today only a custom object's FIELDS are readable, via locations_get-custom-fields, with no way to learn what the object is or what it relates to.
  1. GAPS INSIDE EXISTING TOOLS
These are missing data rather than missing tools.
  • locations_get-custom-fields returns picklistOptions for contact and opportunity fields, but omits the property entirely for custom_objects.* fields, including single-select fields that clearly have options in the UI. Those option lists are unreachable.
  • locations_get-location returns no plan tier and no business hours.
  • emails_fetch-template requires an id, and no tool returns one.
  • calendars_get-calendar-events requires an id, and no tool returns one.
  1. ADD A fields PARAMETER
Every read returns the whole object; there is no projection.
Reading TAG NAMES means pulling full contact records. Reading WHICH PAYMENT PROCESSOR IS CONNECTED means pulling full transaction records, which also return contact name, email address, IP address, card brand, last four digits and billing postal code.
A fields= parameter on list endpoints, taking a comma-separated projection, would cut response sizes by an order of magnitude and stop configuration queries returning cardholder data as a side effect. That second point makes the MCP server considerably easier to adopt in any regulated context.