F
licenseNot graded
qualityB
maintenanceEnables commerce operations teams to investigate missing-delivery complaints and resolve them through natural language, with policy-enforced refunds and escalations.
VISA Dispute Advisor
Click on "Install 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., "@VISA Dispute AdvisorSearch VISA guidelines for 'item not received' claim with tracking proof"
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.
VISA Dispute Advisor
A merchant dispute advisory system powered by the VISA Dispute Management Guidelines.
Given a dispute case, the system retrieves the applicable VISA conditions, reasons over the merchant's response options and past dispute history, and returns a structured recommendation.
Deployed as a Model Context Protocol (MCP) server — any MCP-compatible client (GitHub Copilot, Claude Desktop, etc.) connects and drives the reasoning loop using the two provided tools.
Architecture
MCP Client (GitHub Copilot / Claude Desktop / …)
│ calls tools over MCP stdio transport
▼
FastMCP Server
├─► ChromaDB (sentence-transformers embeddings — local, no API key)
│ semantic search over VISA Dispute Management Guidelines PDF chunks
└─► SQLite (SQLAlchemy)
merchant dispute history warehouseNo LLM runs server-side. The server is a pure retrieval layer.
Related MCP server: Payment Reconciliation Copilot
Tools
Tool | Purpose |
| Semantic search over VISA Guidelines — start here |
| Merchant dispute history lookup by merchant ID |
Prerequisites
uv ≥ 0.5
Python ≥ 3.11
data/merchants-dispute-management-guidelines.pdf— your copy of the VISA Dispute Management Guidelines PDF
Setup
# 1. Clone
git clone https://github.com/alejamorenovallejo/visa-dispute-advisor.git
cd visa-dispute-advisor
# 2. Install dependencies
uv sync
# 3. Configure paths (defaults work out-of-the-box)
cp .env.example .env
# 4. Place VISA PDF in the data/ folder
# Download from: https://myanmar.visa.com/content/dam/VCOM/global/support-legal/documents/merchants-dispute-management-guidelines.pdf
# Save it as: data/merchants-dispute-management-guidelines.pdf
# 5. Ingest VISA rules into vector store
uv run python -m visa_dispute_advisor.ingest
# 6. Seed demo merchant dispute history
uv run python scripts/seed_merchants.pyRunning the server
# stdio transport — for MCP clients
uv run visa-advisor
# HTTP transport with browser inspector — for development
uv run fastmcp dev src/visa_dispute_advisor/server.pyConnecting a client
GitHub Copilot (VS Code)
Create .vscode/mcp.json:
{
"servers": {
"visa-dispute-advisor": {
"type": "stdio",
"command": "uv",
"args": ["run", "visa-advisor"],
"cwd": "${workspaceFolder}"
}
}
}Claude Desktop
Add to claude_desktop_config.json:
{
"mcpServers": {
"visa-dispute-advisor": {
"command": "uv",
"args": ["run", "visa-advisor"],
"cwd": "/absolute/path/to/visa-dispute-advisor"
}
}
}Typical advisory session
Dispute case:
Merchant ID: MER-001 (Tech Store Guatemala)
Cardholder claim: Item not received. Ordered a laptop online on
2026-03-01, expected delivery 2026-03-10. Tracking shows "delivered"
but customer denies receiving it. Amount: $450.00.
Merchant response: Has carrier tracking proof showing delivery to
the billing address.
Agent calls:
1. search_visa_rules("customer claims item not received, merchant has tracking proof")
2. query_warehouse("MER-001")
Recommendation: REJECT DISPUTE (favor merchant)
Applicable rule: Condition 13.1 — Merchandise/Services Not Received.
Merchant can provide tracking documentation proving delivery to the
agreed address. Under Condition 13.1, this constitutes valid compelling
evidence to dispute the chargeback.
Merchant risk profile: LOW RISK — 2 of 3 prior disputes resolved in
merchant's favor. No pattern of fraudulent behavior detected.
Next steps:
1. Request signed proof of delivery from carrier.
2. Submit tracking number and delivery confirmation to acquirer.
3. If cardholder insists, escalate to Visa arbitration.Development
uv run ruff check --fix src/
uv run ruff format src/
uv run pytestSee AGENTS.md for full contributor and agent guidance.
License
MIT
Available Tools
2 toolsquery_warehouseA
Retrieve the dispute history for a merchant from the data warehouse.
Args: merchant_id: The merchant identifier (e.g. "MER-001").
Returns: A dict containing: merchant_id – the queried ID merchant_name – registered name (or None) total_cases – total number of dispute cases on record resolutions – breakdown: {merchant_won, merchant_lost, settled, pending} cases – list of individual case records (date, amount, type, res)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| merchant_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation by using 'retrieve', but does not explicitly state that it is safe, idempotent, or any potential side effects. The return structure is described, which adds some context.
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 concise and well-structured with clear Args and Returns sections. Every sentence adds value, and the most important info (purpose) is front-loaded.
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 tool with one required parameter and an explicit return structure described, the description is fairly complete. However, it lacks details on error handling, pagination limits, or authorization requirements, which would be beneficial for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the input schema provides only type string with no description. The description compensates fully by naming the parameter, providing an example value ('MER-001'), and explaining its purpose (merchant identifier).
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 it retrieves dispute history for a merchant from a data warehouse, with specific verb 'retrieve' and resource 'dispute history'. It distinguishes from sibling tool 'search_visa_rules' which addresses a different domain.
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 description explains the parameter merchant_id with an example but does not explicitly state when to use this tool versus alternatives, nor provide any exclusion criteria. Sibling tool name implies different use case, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_visa_rulesA
Search VISA Dispute Management Guidelines for rules relevant to a dispute.
Args: scenario: Free-text description of the dispute (cardholder claim, merchant response, transaction type, etc.).
Returns: A ranked list of matching VISA rule candidates, each containing: condition_id – e.g. "13.1" title – section heading snippet – relevant text excerpt score – cosine similarity score (0–1, higher = more relevant)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| scenario | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; description carries full burden. Describes return format but does not disclose behavioral traits such as read-only nature, side effects, authentication needs, or rate limits. For a search tool, this is a notable gap.
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?
Well-structured with Args and Returns sections. Every sentence is informative and earns its place. Front-loaded with the main purpose. No wasted words.
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?
Given simple schema (1 param) and no annotations, the description is fairly complete: explains input and output format. Lacks details on behavior (e.g., read-only) but covers essential usage info. Output schema exists, so return values are partially covered.
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?
Schema coverage is 0%, so description compensates well with detailed explanation of 'scenario' parameter: 'Free-text description of the dispute (cardholder claim, merchant response, transaction type, etc.).' Adds meaning beyond the schema but lacks details on length or format.
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?
Description clearly states the tool searches VISA Dispute Management Guidelines for rules relevant to a dispute. Uses specific verb 'search' and resource 'VISA rules'. Distinguishes from sibling query_warehouse by being specialized for visa disputes.
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?
Provides explicit context: use when searching for VISA rules for a dispute. Args section explains input scenario. Does not explicitly state when not to use or name alternatives, but the specialization is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A3.9/5.0
Disambiguation5/5
The two tools serve completely distinct purposes: one searches Visa dispute rules, the other retrieves merchant dispute history. There is no overlap or ambiguity.
Naming Consistency5/5
Both tools follow a consistent verb_noun pattern in snake_case: 'search_visa_rules' and 'query_warehouse'. The naming is predictable and uniform.
Tool Count2/5
With only 2 tools, the server feels under-scoped for a 'VISA Dispute Advisor'. One would expect additional tools for creating, updating, or resolving disputes to make it useful.
Completeness2/5
The tool set lacks core dispute management capabilities like creating a dispute, updating status, or listing disputes. Only rule search and merchant history are provided, leaving significant gaps.
Maintenance
ActivityInactive
ResponsivenessSyncing
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
Company-specific regulatory assessments for concrete business questions, as structured data or PDF.
Which of your credit cards to use at any store, from verified bank data. No bank login.
Bank and lender monitoring with historical-evidence limits and eligibility flags beside every claim.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceEnables read-only investigation of payment transactions by building normalized timelines, detecting anomalies like duplicate charges and stuck refunds, and creating diagnostic escalations for human review. Never executes or modifies payment actions.
- FlicenseNot gradedqualityCmaintenanceProvides read-only MCP tools to diagnose customer billing disputes by analyzing billing records, identifying contradictions, citing evidence, and scoring confidence to auto-resolve or escalate.
- AlicenseNot gradedqualityBmaintenanceEnables agents to interrogate payment routing decisions through six tools: route transactions, explain decisions, simulate scenarios, inspect segment evidence, normalize decline codes, and review backtest summaries. It provides read-only access to the routing engine, allowing natural-language queries without modifying any decisions.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/alejamorenovallejo/visa-dispute-advisor'
If you have feedback or need assistance with the MCP directory API, please join our Discord server