Engaging Networks MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ENGAGINGNETWORKS_REGION | No | The datacentre your account is on, from the spec's server list: `ca` (Canada / Europe, `https://ca.engagingnetworks.app/ens/service`, the default), `us` (`https://us.engagingnetworks.app/ens/service`) or `us2` (`https://us2.engagingnetworks.app/ens/service`). | ca |
| ENGAGINGNETWORKS_BASE_URL | No | Overrides the region's base URL. Used by the tests. | |
| ENGAGINGNETWORKS_API_TOKEN | Yes | The API User token. Required. An administrator of your Engaging Networks account creates the API user in the dashboard, gives it permissions (for example view permission on supporter data), and whitelists the IP address of the machine this server runs on. | |
| ENGAGINGNETWORKS_ALLOW_WRITES | No | `true` to register `update_supporter_opt_ins`. Off by default. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_pagesA | List the account's campaign pages of one type (donation, petition, event, data capture and so on), optionally only those with one status, with name, title, subtype, status, locale and dates. Names and titles have contact details redacted. |
| get_pageB | Details of one campaign page: type, subtype, status, locale, base URL, template, tracking parameters and attributes. |
| find_supporterA | Look up one supporter by email address or by supporter ID. Returns the supporter ID, whether they are suppressed (excluded from email), their name, and optionally their question and opt-in answers and memberships. The email, phone, postal address, date of birth and every other supporter field are only returned with include_contact_details; card and bank fields are never returned. Emails, phone numbers and postcodes typed into names and answers are redacted by pattern unless include_contact_details is set. |
| query_supportersA | List supporters matching one of the API's queries: latestCreated or latestModified (optionally within days_back, 1-32), suppressed, profile (needs profile_id, a supporter profile built in the dashboard) or search (needs filter, e.g. 'firstName:Bob |
| get_supporter_transactionsA | A supporter's transaction history: donations, event tickets, petition signatures, emails to targets, data captures and peer-to-peer activity, with page names, dates and statuses, plus their recurring donation schedules (amount, currency, frequency, status, next payment date). The history list carries no amounts; recurring schedules do. max_results caps each of the two lists. Card details and payment-gateway references are never returned. |
| list_supporter_fieldsB | The supporter fields defined in the account's data structure: each field's name (as used in supporter records), tag and standard property name. |
| list_supporter_questionsB | The questions and opt-ins defined in the account: id, questionId, name and type (OPT = opt-in, CONF = opt-in needing confirmation, GEN = general question). |
| get_supporter_questionA | How one question is presented, per locale: label, HTML field type, the answer options (value and label) or range settings. Returns at most 50 locales and max_options answer options per locale, with the totals. |
| list_marketing_automationsA | Marketing automations (email journeys) in the account with status (ACTIVE, INACTIVE, PAUSED), folder and dates. Filter by dashboard folder and/or part of the name. Without folder_id the API lists the Home folder (0) only. |
| get_marketing_automationA | One marketing automation with its statistics: journey starts, average open and click rates, actions and donations completed from it, objective reached, unsubscribes, SMS delivery rate and jumps. Optionally limit the stats to a range of months. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a distinct resource and action: list vs get for automations, pages and questions, separate supporter lookup vs query, and dedicated transaction/field/question list tools. The only potential overlap is find_supporter vs query_supporters, but the descriptions clearly delineate single-record lookup from filtered listing.
All names use snake_case verb_noun constructions with predictable plural/singular forms (list_marketing_automations, get_marketing_automation; list_pages, get_page). Verbs vary (list, get, find, query) but remain semantically appropriate and consistent throughout.
10 tools for a multi-entity CRM/advocacy platform is well-scoped; each tool covers a needed read operation without redundant or filler entries.
The surface is entirely read-only and omits create/update/delete for all entities, which is a notable gap for a platform management server. There are also dead ends for required IDs: no tool lists marketing automation folders or supporter profiles referenced by list_marketing_automations and query_supporters, and transaction-level detail retrieval is absent.