Skip to main content
Glama
visaacceptance

Visa Acceptance

by visaacceptance
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Visa Acceptance Model Context Protocol

The Visa Acceptance Model Context Protocol server allows you to integrate with Visa Acceptance APIs through function calling. This protocol supports various tools to interact with different Visa Acceptance services, including enhanced invoice management, and payment links functionality.

Quick Start

To run the Visa Acceptance MCP server using npx, use the following command:

# To set up all available tools
npx -y @visaacceptance/mcp --tools=all --merchant-id=YOUR_MERCHANT_ID --api-key-id=YOUR_API_KEY_ID --secret-key=YOUR_SECRET_KEY

# To set up specific tools 
npx -y @visaacceptance/mcp --tools=invoices.create,invoices.read,paymentLinks.create,paymentLinks.read --merchant-id=YOUR_MERCHANT_ID --api-key-id=YOUR_API_KEY_ID --secret-key=YOUR_SECRET_KEY

# To configure test environment (default is true)
npx -y @visaacceptance/mcp --tools=all --merchant-id=YOUR_MERCHANT_ID --api-key-id=YOUR_API_KEY_ID --secret-key=YOUR_SECRET_KEY --use-test-env=true

Make sure to replace the credential placeholders with your actual Visa Acceptance credentials. Alternatively, you could set these values in your environment variables.

Related MCP server: stripe

Usage with Claude Desktop

Add the following to your claude_desktop_config.json. See here for more details.

{
  "mcpServers": {
    "visa-acceptance": {
      "command": "npx",
      "args": [
          "-y",
          "@visaacceptance/mcp",
          "--tools=all",
          "--merchant-id=YOUR_MERCHANT_ID",
          "--api-key-id=YOUR_API_KEY_ID",
          "--secret-key=YOUR_SECRET_KEY"
      ]
    }
  }
}

Available Tools

Tool

Description

invoices.create

Create a new invoice with customer info and enhanced invoice parameters

invoices.update

Update an existing invoice including customer and invoice information

invoices.list

List invoices with pagination support

invoices.get

Get detailed invoice transaction

paymentLinks.create

Create a new payment link with optional shipping info

paymentLinks.update

Update an existing payment link

paymentLinks.list

List payment links with pagination

paymentLinks.get

Retrieve details of a specific payment link

Debugging the Server

To debug your server, you can use the MCP Inspector.

First build the server:

npm run build

Run the following command in your terminal:

# Start MCP Inspector and server with all tools
npx @modelcontextprotocol/inspector node dist/index.js --tools=all --merchant-id=YOUR_MERCHANT_ID --api-key-id=YOUR_API_KEY_ID --secret-key=YOUR_SECRET_KEY

Debugging Instructions

  1. Replace the credential placeholders with your actual Visa Acceptance credentials.

  2. Run the command to start the MCP Inspector.

  3. Open the MCP Inspector UI in your browser and click Connect to start the MCP server.

  4. You can see the list of tools you selected and test each tool individually.

Configuration

You can also configure the server using environment variables:

# Visa Acceptance API Credentials
# Both new simplified names and old names are supported
# New simplified names take precedence if both are defined

VISA_ACCEPTANCE_MERCHANT_ID=your_merchant_id
VISA_ACCEPTANCE_API_KEY_ID=your_api_key_id
VISA_ACCEPTANCE_SECRET_KEY=your_secret_key

# Environment Configuration
# When true, points to apitest.visa-acceptance.com (non-production)
# When false, points to api.visa-acceptance.com (production)
VISA_ACCEPTANCE_ENVIRONMENT=SANDBOX
VISA_ACCEPTANCE_TOOLS=all

You can copy the .env.template file to get started:

cp .env.template .env

Local Development

This package is designed to be used as a local npm package during development. Follow these steps to set up the package for local development:

Installation

  1. Clone the repository:

    git clone https://github.com/visaacceptance/agent-toolkit.git
cd agent-toolkit/modelcontextprotocol

  2. Install dependencies:

    npm install

  3. Build the package:

    npm run build

Local Package Linking

To use this package locally in another project:

  1. Link the package globally:

    npm link

  2. In your project directory, link to the package:

    npm link @visaacceptance/mcp

  3. You can now import and use the package in your project:

    import { VisaAcceptanceAgentToolkit } from '@visaacceptance/mcp';
// or
const { VisaAcceptanceAgentToolkit } = require('@visaacceptance/mcp');

Development Workflow

  1. Make changes to the source code

  2. Rebuild the package:

    npm run build

  3. The linked projects will automatically use the updated version

Available Tools

10 tools
cancel_invoiceB

This tool will cancel an invoice in Visa Acceptance.

ParametersJSON Schema
NameRequiredDescriptionDefault
invoice_idYesInvoice ID (required)

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are present, so the description should disclose behavioral traits like irreversibility, authorization needs, or side effects. It only says 'will cancel,' omitting critical details such as whether cancellation can be undone or what happens to associated data.

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 a single sentence with no fluff. It directly states the action and context, making it highly concise and easy to parse.

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

Completeness3/5

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

While the tool is simple with one parameter and no output schema, the description lacks behavioral context (e.g., consequences of cancellation). A more complete description would mention effects like 'marks invoice as cancelled' or 'action is irreversible.' Given low complexity, the gap is moderate.

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% with one parameter 'invoice_id' described as 'Invoice ID (required).' The tool description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.

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 clearly states 'cancel an invoice in Visa Acceptance.' The verb 'cancel' and resource 'invoice' are specific. Since no sibling tool cancels invoices (others create, get, list, update, send), it distinguishes well from alternatives.

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

Usage Guidelines2/5

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, such as prerequisites (e.g., invoice must be unpaid) or conditions. The description simply states it cancels, without any contextual use advice.

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

create_invoiceC

This tool will create an invoice in Visa Acceptance.

ParametersJSON Schema
NameRequiredDescriptionDefault
invoice_numberYesUnique invoice number (letters & numbers only, <20 chars)
totalAmountYesInvoice total amount e.g. "100.00"
currencyYesInvoice currency code e.g. "USD"
customerNameNoCustomer name for invoice
customerEmailNoCustomer email for invoice
invoiceInformationYesInvoice information object

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are present, so the description must convey behavioral traits. It only says 'create an invoice' without mentioning side effects like sending, persistence, or output expectations. Critical details like automatic sending or delivery are absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single focused sentence, highly concise and front-loaded. There is no extraneous information, though it lacks depth.

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

Completeness2/5

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

Given the tool has 6 parameters including a nested object and no output schema, the description is too minimal. It does not explain return values, error conditions, or the effect of parameters like 'sendImmediately', leaving the agent underinformed.

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 description coverage is 100%, so the schema already documents parameter purposes. The description adds no additional meaning beyond what the schema provides, meeting the baseline for high coverage.

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?

The description clearly states the tool creates an invoice in 'Visa Acceptance', distinguishing it from sibling creation tools like 'create_payment_link'. The verb 'create' is specific and the resource 'invoice' is unambiguous.

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

Usage Guidelines1/5

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

The description provides no guidance on when to use this tool versus alternatives such as 'create_payment_link', nor does it specify prerequisites or scenarios where creation is inappropriate.

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

get_invoiceB

This tool will get a specific invoice from Visa Acceptance.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesInvoice ID (required)

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It only states 'get' implying read-only, but no details on side effects, rate limits, or other behaviors. Minimal transparency.

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?

Single sentence, 10 words, front-loaded. No unnecessary words or repetition. Efficient.

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

Completeness3/5

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

For a simple single-invoice retrieval tool without output schema, the description is minimally complete. Could mention output format or usage context but acceptable.

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 already covers the only parameter 'id' with description. Description adds no extra meaning. Baseline 3 as per guidelines for 100% coverage.

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?

Description clearly states the tool retrieves one invoice, with source 'Visa Acceptance'. It distinguishes from sibling list_invoices (multiple) and create_invoice (write). Could specify what invoice details are returned.

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?

Usage is implied—use when you have an invoice ID. No explicit guidance on when to use this vs alternatives like list_invoices or get_payment_link. No prerequisites mentioned.

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

list_invoicesC

This tool will list invoices from Visa Acceptance.

ParametersJSON Schema
NameRequiredDescriptionDefault
offsetYesPagination offset (required)
limitYesPagination limit (required)
statusNoFilter by status (optional)

TDQS

C2.8/5.0
Behavior2/5

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

No annotations provided. The description only mentions listing invoices without disclosing behavioral traits such as pagination behavior, ordering, or whether it is read-only. For a list tool, basic read-only hint would help.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence but lacks front-loading of key information. It is not overly verbose, but it could be more informative without increasing length.

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

Completeness2/5

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

The tool is simple but has no output schema. The description does not indicate what the return format is (e.g., list of invoice objects). Given the absence of annotations and output schema, more context would be beneficial.

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 description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.

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?

The description clearly states 'list invoices from Visa Acceptance', specifying the action (list) and resource (invoices) and a source. It distinguishes from sibling tools like cancel_invoice or create_invoice.

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

Usage Guidelines2/5

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 such as get_invoice for a single invoice or list_payment_links for payment links. The description lacks context for selection.

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

send_invoiceC

This tool will send an invoice to the customer from Visa Acceptance.

ParametersJSON Schema
NameRequiredDescriptionDefault
invoice_idYesInvoice ID (required)

TDQS

C2.9/5.0
Behavior2/5

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

No annotations exist; description only says 'will send', implying mutation but no detail on idempotency, state requirements, failure modes, or side effects. The agent lacks crucial behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words. However, it is overly concise and omits important details; conciseness is not a substitute for completeness.

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

Completeness3/5

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

Tool is simple (1 param, no output schema). Description covers the basic action but misses outcomes, error conditions, and whether sending requires a pre-existing invoice. Barely adequate.

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% (1 param described). Description does not add meaning beyond the schema; it clarifies nothing about invoice_id format or retrieval. Adequate but no added value.

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?

The description clearly states the action (send) and resource (invoice) with context (Visa Acceptance). It distinguishes from sibling tools like create_invoice or cancel_invoice, but does not specify the delivery mechanism (e.g., email).

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., must invoice be created first? Not mentioned). No prerequisites, exclusions, or conditional logic provided.

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

update_invoiceD

This tool will update an invoice in Visa Acceptance.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesInvoice ID (required)
customerInformationYesCustomer information object (required even if properties are optional)
invoiceInformationYesInvoice information object (required even if properties are optional)
orderInformationYesOrder information object (required)

TDQS

D1.9/5.0
Behavior1/5

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

With no annotations, the description carries full burden. It only says 'update' but fails to disclose if updates are partial or full, required permissions, or side effects like overwriting existing data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is too minimal and under-specified. It does not earn its place as it adds no value beyond the tool name.

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

Completeness1/5

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

The tool has a complex nested schema with 4 required parameters and no output schema. The one-line description is completely inadequate for an agent to understand the tool's full capabilities and proper usage.

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 description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides for parameters.

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

Purpose2/5

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

The description merely states 'update an invoice' which is a tautology of the tool's name. It does not specify which fields can be updated or distinguish the tool from siblings like cancel_invoice or send_invoice.

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

Usage Guidelines2/5

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. There is no mention of prerequisites, context, or 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 10 tool updatesv1.0.0
    • Changedcancel_invoice2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedcreate_invoice2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedcreate_payment_link2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedget_invoice2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedget_payment_link2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedlist_invoices2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedlist_payment_links2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedsend_invoice2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedupdate_invoice2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedupdate_payment_link2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
  2. 10 tool updates
    • First observedcancel_invoice
    • First observedcreate_invoice
    • First observedcreate_payment_link
    • First observedget_invoice
    • First observedget_payment_link
    • First observedlist_invoices
    • First observedlist_payment_links
    • First observedsend_invoice
    • First observedupdate_invoice
    • First observedupdate_payment_link
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
Disambiguation5/5

Each tool targets a distinct resource (invoice vs payment_link) with clear actions (create, get, list, update, cancel, send). No overlap in purpose.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., create_invoice, list_payment_links), making them predictable and easy to understand.

Tool Count5/5

10 tools cover two main resources with essential CRUD and lifecycle operations. The count is well-scoped without being excessive or insufficient.

Completeness4/5

Invoices have full lifecycle coverage (create, get, list, update, cancel, send). Payment links cover create, get, list, update, but missing delete or refund functionality, a minor gap.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • stripe by stripe

    stripeofficial

    stripe
    A
    license
    Not graded
    quality
    C
    maintenance
    The Stripe Model Context Protocol server allows you to integrate with Stripe APIs through function calling. This protocol supports various tools to interact with different Stripe services.
    17,353
    1,790
    -

  • Valyu MCP Server

    valyuAI
    A
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that provides LLMs with access to Valyu's knowledge retrieval and feedback APIs for searching proprietary/web sources and submitting transaction feedback.
    2
    MIT

  • VoIPBin MCP Server

    nrjchnd
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI models to interact with VoIPBin's VoIP services, supporting features like call management, agent management, campaigns, conferences, and chat functionality.
    4
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/visaacceptance/agent-toolkit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server