GotFreeFax
Server Details
Send free or paid faxes to US/Canada from Claude, ChatGPT, and other AI agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- vannet/gotfreefax-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 7 of 7 tools scored. Lowest: 2.9/5.
Each tool has a clearly distinct purpose: checking fax status, account balance, sent history, supported formats, purchasing credits, sending paid faxes, and sending free faxes. No overlap in functionality.
All tools use consistent snake_case naming with clear verb+noun patterns (check_, get_, list_, purchase_, send_). The naming is predictable and easy to understand.
With 7 tools covering sending, status, history, balance, formats, and purchasing, the set is well-scoped for a fax service. No tool seems unnecessary, and the number is appropriate for the domain.
The tool set covers core fax workflows: sending (paid and free), status checking, history, account management, and format listing. Minor gaps exist (e.g., no tool to delete sent faxes or manage recipients), but the essential operations are present.
Available Tools
7 toolscheck_fax_statusAInspect
Check the delivery status of a previously sent fax using its job_id. No authentication required — the job_id is the unforgeable token.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job ID returned by send_fax |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It mentions no authentication is required, which is good, but lacks details on read-only behavior, error handling, or rate limits. Annotations are absent, so the description should do more.
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 sentences, no wasted words, front-loaded with purpose.
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?
Adequate for a simple tool but could mention output type or behavior on missing job_id. Given no output schema, this is 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?
Schema coverage is 100%, and the description adds context about job_id being from send_fax, but the schema already describes it adequately.
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 clearly states the tool checks the delivery status of a previously sent fax using its job_id, distinguishing it from siblings that send faxes or list faxes.
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?
It indicates the tool is for checking status after sending, but does not explicitly contrast with alternatives like list_sent_faxes for status checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_balanceAInspect
Get the current page balance and dollar amount balance for the authenticated account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral traits. It does not disclose whether the operation is read-only, rate limits, authentication requirements beyond mentioning 'authenticated account', or error scenarios. For a simple get operation, more context would be helpful.
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?
The description is a single, direct sentence that conveys the purpose without any fluff. It is appropriately front-loaded and concise.
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?
Given the simplicity of the tool (no parameters, no output schema), the description covers the essential information: what it retrieves and for whom. It could benefit from mentioning the format of the returned values, but overall it is 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?
The tool has no parameters, and schema coverage is 100%. According to guidelines, 0 parameters yields a baseline of 4. The description does not need to add parameter information.
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 clearly specifies the verb ('Get'), the resource ('current page balance and dollar amount balance'), and the context ('for the authenticated account'). It distinguishes this tool from siblings like 'send_fax' or 'purchase_credits' by focusing on balance retrieval.
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?
No guidance is provided on when to use this tool versus alternatives. The description merely states what it does without mentioning conditions, prerequisites, or exclusions. An agent would have to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sent_faxesAInspect
List faxes previously sent by the authenticated account (most recent first). Includes faxes sent via MCP, REST API, and the prepaid web form. Free anonymous sends are not included.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max records to return (1-100, default 20) | |
| offset | No | Skip first N records for pagination (default 0) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses ordering, inclusion/exclusion of fax sources, and that results are based on the authenticated account. However, it does not mention pagination behavior beyond the parameters, rate limits, or response structure.
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 concise sentences. First sentence front-loads the primary purpose and ordering. Second sentence clarifies scope and exclusions. Every word earns its place with no redundancy.
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 list tool with two optional parameters and no output schema, the description adequately covers what the tool does, ordering, and scope exclusions. However, missing guidance on when to use over sibling tools slightly reduces completeness.
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%, meaning both limit and offset are fully described in the input schema. The description adds no additional semantics beyond what the schema already provides (max records, default, pagination). Baseline of 3 is appropriate.
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 clearly states the verb 'List' and the resource 'faxes previously sent by the authenticated account', with explicit ordering (most recent first) and scope (includes MCP, REST API, prepaid web form; excludes free anonymous sends). It fully differentiates the tool from siblings by specifying what is and isn't included.
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 implicitly guides usage by stating what it lists and excludes, but it does not explicitly state when to use this tool versus alternatives like check_fax_status or send_fax. Sibling tools exist but no direct comparison or usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_supported_formatsAInspect
List all supported file formats that can be faxed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description implies a read-only operation. It adequately discloses the behavior by indicating it lists formats, but lacks details on output format or potential side effects, though none are expected.
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?
The description is a single sentence that is front-loaded and contains no unnecessary words. Every word earns its place.
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?
The description completely covers the tool's purpose for a simple, parameterless list operation. No additional context is required.
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?
With zero parameters, the description doesn't need to add parameter meaning. Baseline score of 4 is appropriate as the schema covers everything.
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 clearly states the verb 'List' and the resource 'supported file formats', specifying the context 'that can be faxed'. It distinguishes itself from siblings like 'send_fax' and 'check_fax_status' by focusing on format discovery.
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?
While the description doesn't explicitly state when to use this tool over alternatives, the purpose is self-evident: it is the only tool that lists formats. No guidance on exclusions is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
purchase_creditsAInspect
Start a prepaid credit purchase. If the request is authenticated, credits will be loaded into the authenticated account after PayPal payment. If the request is not authenticated, provide email and name to create a new prepaid account (or load credits into an existing one with the same email). Returns a PayPal payment URL the user must visit to complete the purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Required when the request is not authenticated. Account holder name. | |
| No | Required when the request is not authenticated. Used to create or load an existing prepaid account. | ||
| service_type | Yes | Purchase option. One of: prepaid10 (100 pages, $9.95), prepaid20 (250 pages, $19.95), prepaid50 (800 pages, $49.95), intprepaid50 ($49.95 international balance), intprepaid100 ($99.95 international balance), intprepaid200 ($199.95 international balance). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the behavioral difference between authenticated and unauthenticated requests, and that the result is a PayPal URL requiring user action. However, it does not disclose potential failure modes, rate limits, or whether the tool modifies any state before payment. Given no annotations, the description does a good job covering the core behavior.
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?
The description is concise (two sentences) and front-loaded with the core purpose. Every sentence provides essential information without redundancy.
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 purchase initiation tool with no output schema, the description adequately covers the authentication behavior and the return value (PayPal URL). It lacks detail on error handling or post-payment steps, but given the tool's straightforward nature, it is sufficiently complete.
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 already provides comprehensive descriptions for all three parameters, with 100% coverage. The tool description reiterates the conditional requirement for name/email based on authentication, but does not add new semantic details beyond the schema. Therefore, the parameter semantics dimension scores a baseline of 3.
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 clearly states the tool's purpose: initiating a prepaid credit purchase. It differentiates from sibling tools like send_fax or get_account_balance by focusing on credit purchasing. The verb 'purchase' and resource 'credits' are explicit, and the authentication flow is described.
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 implicitly tells when to use this tool (to purchase credits), but does not explicitly compare with sibling tools. It provides clear guidance on when to include name/email based on authentication state. No when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_faxCInspect
Send a fax to a US or Canada phone number. Accepts PDF, DOC, DOCX, JPG, JPEG, TXT files (max 10) as base64-encoded content.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | Array of files to fax | |
| fax_number | Yes | Destination fax number (10 digits, US or Canada) | |
| notify_url | No | Optional URL to receive fax completion notification |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It only covers accepted file types and encoding, omitting critical details such as cost implications, success/failure indicators, authentication requirements, or any side effects (e.g., consuming credits).
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 sentences with no superfluous content. Every part adds value: action, region, file constraints. Efficiently front-loaded.
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?
Despite low complexity (3 params, no output schema), the description lacks essential context: return value, error handling, cost, prerequisites (credits), and differentiation from free alternative. Incomplete for an agent to use reliably.
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%, so baseline is 3. The description adds extra context for file parameters (allowed types, max count, base64 encoding) and for fax_number (US/Canada region), enhancing meaning beyond schema descriptions. No extra info for notify_url.
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?
Clearly states the action (send fax) and target (US/Canada phone numbers), and specifies acceptable file types and count. However, it does not differentiate from the sibling 'send_free_fax', which could cause confusion about which tool to use for paid vs free faxing.
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?
No guidance on when to use this tool versus alternatives (e.g., send_free_fax, check_fax_status). No prerequisites, required credits, or context for appropriate use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_free_faxAInspect
Send a free fax to a US or Canada number (no account required). Limited to 3 pages total and 2 sends per email/IP per day. Returns a job_id immediately, but the fax does NOT send until the sender clicks a confirmation link emailed to sender_email. The daily-limit check happens at click time, not at submission — a submitted fax may still be rejected if the limit is hit by then; the agent can detect this by calling check_fax_status after the user reports clicking the link. If the document exceeds the free page limit, the response will suggest using purchase_credits to buy a prepaid account.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Fax body text. Either text or files must be provided. | |
| files | No | Up to 3 files. Each must be base64-encoded. Free faxes are limited to 3 pages total across text + files. | |
| subject | No | Subject line (optional). | |
| fax_number | Yes | Destination fax number (10 digits, US or Canada). | |
| sender_fax | No | Sender's fax number (optional). | |
| cover_sheet | No | Include cover sheet (default true). | |
| sender_name | Yes | Sender's name (required). | |
| sender_email | Yes | Sender's email address. A confirmation link will be sent here; the fax does NOT actually send until the user clicks that link. | |
| receiver_name | Yes | Receiver's name (required). | |
| sender_company | No | Sender's company (optional). | |
| receiver_company | No | Receiver's company (optional). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully explains key behaviors: immediate job_id return, confirmation link requirement, daily-limit check at click time, potential rejection, and how to verify via check_fax_status. It also discloses the page limit and alternative action, leaving no ambiguity.
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?
The description is front-loaded with core purpose and limits, then explains async behavior and alternatives. While lengthy, every sentence adds critical information, so it earns a 4 rather than 5.
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?
Given no output schema or annotations, the description covers purpose, constraints, async flow, error handling (suggest purchase_credits), and dependency on check_fax_status. It lacks detail on return format but is sufficient for an agent to use the tool correctly.
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?
With 100% schema coverage, baseline is 3. The description adds value beyond schema for sender_email (confirm link), files (page limit per file), and text (mutual exclusivity with files). This extra context justifies a 4.
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 clearly states the tool sends a free fax to US/Canada numbers with no account required, and specifies the page and daily limits. It also distinguishes from siblings like send_fax by implying a paid alternative and referencing purchase_credits for exceeding limits.
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 provides clear usage context: free fax to US/Canada, no account, up to 3 pages, 2 per day, and the need for user confirmation. It suggests an alternative (purchase_credits) when limits are exceeded. However, it does not explicitly contrast with the sibling send_fax or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!