Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ictcontact-mcp List my campaigns and show their current status."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server for ICTContact and its hosted edition ICTDialer.com — the same contact-center engine from ICT Innovations.
It lets an AI assistant monitor outbound campaigns — list them, check status, read summaries and per-call results — and, only when you turn writes on, start and stop them.
npx -y ictcontact-mcp # no install
npm install -g ictcontact-mcpRequires Node.js 18 or newer.
Related MCP server: ictbroadcast-mcp
Variable | Required | Default | |
| yes | Server base URL, without the | |
| yes | API account username | |
| yes | Password for that account | |
| no |
| Unlock start/stop campaign (see Safety) |
| no |
| Per-request timeout |
| no |
| Skip TLS verification — self-signed test servers only |
{
"mcpServers": {
"ictcontact": {
"command": "npx",
"args": ["-y", "ictcontact-mcp"],
"env": {
"ICTCONTACT_BASE_URL": "https://your-ictcontact",
"ICTCONTACT_USERNAME": "admin",
"ICTCONTACT_PASSWORD": "your-password"
}
}
}
}Read tools are always available:
Tool | What it does |
| List campaigns (id and name) |
| Live status of a campaign (running, stopped) |
| Totals: answered, failed, human vs machine |
| Per-call results (contact, response, AMD, DNC) |
Write tools appear only when ICTCONTACT_MCP_ALLOW_WRITE=true:
Tool | What it does |
| Launch a campaign — begins live outbound calling |
| Stop a running campaign |
The server is read-only by default. Starting a campaign begins live outbound
calling and can cost real money, so ictcontact_start_campaign and
ictcontact_stop_campaign are not registered at all unless you set
ICTCONTACT_MCP_ALLOW_WRITE=true.
ICTContact and ICTDialer expose a form-encoded RPC API at {base}/rest/<Method>.
Each call carries the account username and password; the server sends those for
you. There is no separate token to provision.
Built by Tahir Almas at ICT Innovations — the team behind ICTContact, ICTDialer, ICTBroadcast, ICTFax and ICTPBX. Learn more at ictcontact.com and ictdialer.com.
MIT licensed. Issues and PRs welcome at github.com/ictinnovations/ictcontact-mcp.
Per-call results for a campaign (contact, response, answering-machine detection, DNC), optionally filtered by call status.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Optional call-status filter. | |
| campaign_id | Yes | The campaign id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful content about what each record contains, but for a per-call result set it omits volume/pagination expectations (a campaign can have thousands of rows) and whether results are capped or truncated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the resource and uses a compact parenthetical to list returned data. No filler and nothing that could be cut without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly enumerates the return fields, which is the main gap it needed to fill. It is still incomplete for a potentially high-volume listing tool: no pagination, ordering, or empty-result behavior is mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema; the description only restates the optional status filter and adds no value about allowed status values (no enum present) or behavior when status is omitted. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (per-call results for a campaign) and enumerates the returned fields (contact, response, answering-machine detection, DNC), which is far more informative than the title. It does not explicitly distinguish itself from the campaign_status or campaign_summary siblings, leaving the agent to infer that this is the row-level vs. aggregate view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Optionally filtered by call status" implies a usage context, but the description never says when to choose this over ictcontact_campaign_summary or ictcontact_campaign_status, nor any prerequisites (campaign must exist, must have run). Usage is inferable only from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live status of a campaign by id (for example running or stopped). Poll this while a campaign runs.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | The campaign id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds that the value is 'live' and suitable for polling, which is genuine behavioral context, but says nothing about freshness, cost of repeated calls, or what happens with an invalid or finished campaign id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the resource and scope, with the polling instruction second. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description partially compensates by naming example status values a caller might receive. It does not describe the shape of the response beyond that, but for a one-parameter read tool this is close to sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single campaign_id parameter is already documented in the schema. The description only echoes 'by id', adding no format or source-of-id guidance, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and lookup key: live status of a campaign by id, with concrete example values (running/stopped). It is distinguishable from siblings like campaign_summary and campaign_result by the word 'status', though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sentence 'Poll this while a campaign runs' gives a clear usage context: call it repeatedly during an active campaign. It stops short of saying when NOT to use it or pointing to campaign_summary/campaign_result for other needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Totals for a campaign: answered, failed, human vs machine and so on. Optionally scope to one agent/user id.
| Name | Required | Description | Default |
|---|---|---|---|
| usr_id | No | Optional agent/user id to scope the summary. | |
| campaign_id | Yes | The campaign id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds that the output is aggregate counts across several dimensions, which is genuinely useful context beyond the annotations, but says nothing about date windows, freshness of the totals, or what happens for a campaign with no calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses, front-loaded with what the tool returns, then the optional scoping. No wasted words, though 'and so on' is a vague filler that could have been replaced by naming the remaining metrics or omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read with full schema coverage and a safety-covering annotation set, the description is largely sufficient, but with three closely related sibling tools a single sentence about how the totals differ from per-call results would materially improve correct selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both usr_id and campaign_id are documented in the schema, including that usr_id is optional. The description's restatement of the optional scoping adds no syntax or format detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (a campaign) and the kind of data returned (totals: answered, failed, human vs machine), which is more informative than the title 'Campaign summary'. It is distinguishable from siblings like campaign_status or campaign_result by framing itself as aggregate totals, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage hint is the optional agent/user scoping clause; there is no statement of when to choose this over ictcontact_campaign_result or ictcontact_campaign_status, and no prerequisites or exclusions. The agent must infer the routing decision from the tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the outbound campaigns on the ICTContact / ICTDialer server (id and name of each). Start here to find a campaign id.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description's 'List' wording is consistent. It adds useful context beyond the annotations by specifying the scope ('outbound campaigns') and the field content ('id and name'), though it does not describe ordering, pagination, or response envelope details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the action and result front-loaded, and the instruction to 'Start here' earns its place as workflow guidance. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with readOnly/openWorld annotations, the description adequately covers purpose, scope, returned fields, and how it fits into the workflow. It does not document the exact output schema, but the named fields ('id and name') and the simple nature of the tool make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there is nothing for the description to clarify. The description implies a parameterless call by saying 'List the outbound campaigns', and no ambiguity exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies both the resource ('outbound campaigns on the ICTContact / ICTDialer server') and the returned fields ('id and name'). The phrase 'Start here to find a campaign id' clearly separates this from the sibling tools, which operate on individual campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames this tool as the entry point for discovering campaign IDs, which implies it should be used before campaign_summary, campaign_status, or campaign_result. It does not explicitly name those alternatives or state when not to use it, but the 'Start here' guidance provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1ictcontact_campaign_result3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / campaign_id / maximumAdded value: +9007199254740991Input schema / properties / campaign_id / minimumAdded value: +-9007199254740991ictcontact_campaign_status3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / campaign_id / maximumAdded value: +9007199254740991Input schema / properties / campaign_id / minimumAdded value: +-9007199254740991ictcontact_campaign_summary5 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / campaign_id / maximumAdded value: +9007199254740991Input schema / properties / campaign_id / minimumAdded value: +-9007199254740991Input schema / properties / usr_id / maximumAdded value: +9007199254740991Input schema / properties / usr_id / minimumAdded value: +-9007199254740991v0.1.0ictcontact_campaign_resultictcontact_campaign_statusictcontact_campaign_summaryictcontact_list_campaignsScored across 4 tools
Each tool targets a distinct facet: list_campaigns (enumeration), campaign_status (live run state), campaign_summary (aggregate totals), campaign_result (per-call rows). campaign_summary and campaign_result overlap somewhat in reporting on outcomes, but the aggregate-vs-row distinction is clear enough from the descriptions.
All tools share the ictcontact_ prefix and campaign-related names, with a predictable noun_component pattern for three of them. list_campaigns breaks the noun-first pattern by using a verb prefix, a minor deviation that remains readable.
Four tools is on the thin side for a dialer/campaign integration; the surface covers only read/monitoring operations. It is not extreme, but the set feels like a narrow slice of the domain rather than a well-rounded toolkit.
The surface is entirely read-only: you can list, monitor status, and pull summaries/results, but there is no way to start, stop, create, or control a campaign — despite status tooling explicitly advising polling while a campaign runs. This dead end limits agents to observation only.
Manage AI assistants, history, calls, campaigns, contacts, knowledge, messaging, and automations.
AI dialer: add and find leads, list campaigns, and have the AI agent call a lead now.
Place calls, send WhatsApp messages, and read call records, contacts, leads and campaigns
Manage your Telvana AI voice, SMS and chat agents, conversations, campaigns and outbound calls.
