Skip to main content
Glama
Sign In
ictinnovations

ictfax-mcp

Official
by ictinnovations
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ictfax-mcp

A Model Context Protocol server for ICTFax, the open-source fax server built on the ICTCore framework by ICT Innovations.

It lets an AI assistant list fax transmissions and check their status, and — only when you turn writes on — upload a document and send a fax.

Install

npx -y ictfax-mcp      # no install
npm install -g ictfax-mcp

Requires Node.js 18 or newer.

Related MCP server: GotFreeFax MCP Server

Configure

Variable

Required

Default

ICTFAX_BASE_URL

yes

ICTCore REST base, normally ending in /api, e.g. https://your-ictfax/api

ICTFAX_USERNAME

yes

API account email (ICTCore logs in by email)

ICTFAX_PASSWORD

yes

Password for that account

ICTFAX_ACCOUNT_ID

no

1

Account id to send faxes from

ICTFAX_MCP_ALLOW_WRITE

no

false

Unlock upload/send (see Safety)

ICTFAX_TIMEOUT_MS

no

30000

Per-request timeout

ICTFAX_TLS_INSECURE

no

false

Skip TLS verification — self-signed test servers only

Claude Desktop example

{
  "mcpServers": {
    "ictfax": {
      "command": "npx",
      "args": ["-y", "ictfax-mcp"],
      "env": {
        "ICTFAX_BASE_URL": "https://your-ictfax/api",
        "ICTFAX_USERNAME": "admin@example.com",
        "ICTFAX_PASSWORD": "your-password"
      }
    }
  }
}

Tools

Read tools are always available:

Tool

What it does

ictfax_list_faxes

List fax transmissions (id, contact, status, direction)

ictfax_get_fax_status

Status of one transmission by id

Write tools appear only when ICTFAX_MCP_ALLOW_WRITE=true:

Tool

What it does

ictfax_upload_document

Upload a local PDF as a fax document; returns a document_id

ictfax_send_fax

Send a local document as a fax to a number — dials a real number

Safety

The server is read-only by default. Sending a fax dials a real number and can cost money, so ictfax_upload_document and ictfax_send_fax are not registered at all unless you set ICTFAX_MCP_ALLOW_WRITE=true.

How it connects

ICTFax runs on ICTCore, which authenticates with a JWT from POST /authenticate (login by email) and reads it back from the Authorization: Bearer header. Sending a fax is a short chain the server handles for you: upload the document (metadata then raw bytes, which ICTFax converts to fax format), create the recipient and a sendfax program, create the transmission and send it.

About

Built by Tahir Almas at ICT Innovations — the team behind ICTFax, ICTPBX, ICTContact, ICTDialer and the ICTCore framework these share. ICTFax is free and open source; learn more at ictfax.org.

MIT licensed. Issues and PRs welcome at github.com/ictinnovations/ictfax-mcp.

Available Tools

2 tools
ictfax_get_fax_statusGet fax statusA
Read-only

Get one fax transmission by id: its status (processing, completed, failed), contact and pages. Poll this after sending a fax.

NameRequiredDescriptionDefault
transmission_idYesThe transmission id.

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real context beyond that: the tool is intended for repeated polling and the observable state machine is processing/completed/failed, which tells the agent when to stop polling. It does not mention rate limits or eventual-consistency behavior, so not a 5.

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?

Two short sentences, zero filler. The resource and returned fields come first and the polling instruction closes it, so the agent gets the actionable cue immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 the returned fields (status, contact, pages) and the status values. It could say more about what happens for an unknown id (error vs empty), 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is documented as 'The transmission id.' The description's 'by id' restates the same idea without adding format, sourcing (where to obtain the id), or constraints. Baseline 3 applies when the schema carries the meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get one fax transmission by id') and enumerates what is returned (status, contact, pages), which implicitly separates it from the sibling list tool. It stops short of naming ictfax_list_faxes as the alternative, so differentiation requires a small inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Poll this after sending a fax' gives a concrete trigger condition, which is the main thing an agent needs to know. There is no explicit when-not guidance or reference to the list tool as a fallback for browsing, keeping it just below a 5.

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

ictfax_list_faxesList fax transmissionsA
Read-only

List fax transmissions on the server (inbound and outbound) with their id, contact, status and direction. Start here to find a transmission id.

NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds useful behavioral scope (inbound and outbound, included fields), but does not disclose any additional constraints such as pagination, sorting, or result limits. This is adequate but not rich.

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?

The description is two sentences with no fluff. The core action and scope are front-loaded, and the user-guidance sentence adds value without padding. Every word contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless list operation, the description covers the main purpose and even states the output fields (id, contact, status, direction). There is no output schema, so this field enumeration is valuable. The only minor gap is not explaining any possible pagination or size limits, but this is not critical given the tool's simplicity.

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?

The tool has zero parameters and 100% schema description coverage, so there are no parameter semantics to explain. The baseline for no parameters is 4, and the description does not need to compensate for any schema gaps.

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 description uses a specific verb and resource: "List fax transmissions on the server (inbound and outbound)" and details the returned fields (id, contact, status, direction). It also differentiates from the sibling tool by saying "Start here to find a transmission id," which positions this tool as the list/entry-point against ictfax_get_fax_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase "Start here to find a transmission id" gives clear situational context for using this tool to obtain an ID, but it does not explicitly mention when to prefer the sibling tool ictfax_get_fax_status or provide exclusion criteria. Usage guidance is implied rather than fully detailed.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.1
    • Changedictfax_get_fax_status3 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / transmission_id / maximum
        Added value: +9007199254740991
      • addedInput schema / properties / transmission_id / minimum
        Added value: +-9007199254740991
  2. 2 tool updatesv0.1.0
    • First observedictfax_get_fax_status
    • First observedictfax_list_faxes
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 2 tools

Disambiguation5/5

The two tools target clearly different operations: listing transmissions versus fetching a single transmission by id. Their descriptions even specify the intended workflow order (list to find an id, then get status), leaving no room for misselection.

Naming Consistency4/5

Both names follow a predictable ictfax_ prefix plus verb_noun structure (get_fax_status, list_faxes). The only minor wrinkle is the singular/plural split between 'fax' and 'faxes', which is natural but slightly uneven.

Tool Count2/5

Two tools is very thin for a fax transmission server, and one of them exists only to support the other. There is no operation to actually send or manage a fax, making the surface feel incomplete rather than deliberately minimal.

Completeness1/5

The domain clearly includes sending faxes ('poll this after sending a fax'), yet no send, cancel, delete, or content-retrieval tool exists. Only read operations are exposed, so core fax lifecycle workflows will dead-end.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • faxdrop-mcp

    klodr
    A
    license
    A
    quality
    A
    maintenance
    Enables AI assistants to send real faxes through the FaxDrop API. Provides safeguards including rate limiting, dry-run mode, and audit logging for secure fax operations.
    3
    255 npm
    5
    MIT

  • GotFreeFax MCP Server

    vannet
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to send free and paid faxes to US and Canada numbers, check fax status, and purchase prepaid credits, all without leaving the chat.
    MIT

  • FaxSeal MCP Server

    grichardomi
    A
    license
    Not graded
    quality
    D
    maintenance
    Send, receive, and verify faxes from AI assistants and agents via the Model Context Protocol.
    122 npm
    MIT
  • ictcontact-mcp by ictinnovations

    ictcontact-mcpofficial

    ictinnovations
    A
    license
    B
    quality
    A
    maintenance
    Enables AI assistants to monitor outbound campaigns in ICTContact/ICTDialer, including listing campaigns, checking status, reading summaries and per-call results, and optionally starting and stopping campaigns when write access is enabled.
    4
    144 npm
    16
    MIT