Provides tools to fetch payments, orders, customers, subscriptions, refunds, and analytics from a Razorpay account, enabling natural language queries for revenue trends, failure analysis, and dashboard summaries.
An MCP (Model Context Protocol) server that connects AI assistants like Claude directly to your Razorpay account. Once configured, you can ask your AI to fetch payments, analyze revenue trends, inspect failed transactions, monitor subscriptions, and get a real-time business dashboard — all in natural language, with no code required.
# Clone
git clone https://github.com/indiamcp/razorpay-mcp
# Install
cd razorpay-mcp
npm install
# Configure
cp .env.example .env
# Add your Razorpay API keys to .env
# Build
npm run build
# Run
npm startRelated MCP server: Safaricom Daraja MCP Server
Add this to your claude_desktop_config.json (usually at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"razorpay": {
"command": "node",
"args": ["/path/to/razorpay-mcp/dist/index.js"],
"env": {
"RAZORPAY_KEY_ID": "rzp_test_xxxxxxxxxxxx",
"RAZORPAY_KEY_SECRET": "your_secret_here"
}
}
}
}Or use npx (once published):
{
"mcpServers": {
"razorpay": {
"command": "npx",
"args": ["-y", "@indiamcp/razorpay-mcp"],
"env": {
"RAZORPAY_KEY_ID": "rzp_test_xxxxxxxxxxxx",
"RAZORPAY_KEY_SECRET": "your_secret_here"
}
}
}
}Tool | Description | Key Parameters |
| Fetch a specific payment by ID |
|
| List payments with filters |
|
| Revenue, success rate, method breakdown |
|
| Fetch a specific order by ID |
|
| List orders with filters |
|
| Fetch a specific customer by ID |
|
| List customers |
|
| Fetch a specific subscription by ID |
|
| List subscriptions with filters |
|
| Active count, churn rate, upcoming renewals |
|
| Fetch a specific refund |
|
| List refunds for a payment |
|
| Business health check — revenue today/week/month | (none) |
| Failure reasons, by method and bank |
|
Once connected, try asking Claude:
"Show me all failed payments in the last 7 days and why they failed"
"What's my total revenue this month?"
"List all active subscriptions"
"Which payment method do my customers prefer?"
"Show me customers who signed up this week"
"What's my subscription churn rate this month?"
"Find payment pay_xxxxx"
"How many refunds are pending?"
"Give me a dashboard summary of my business today"
"Analyze payment failures for the last 30 days"
Environment variables only — API keys are read from env vars and never hardcoded or logged
Read-only in v1 — this server only fetches data; it cannot create payments, issue refunds, or modify any records
No data storage — payment data is never persisted or cached by this server
Use test keys during development — Razorpay test keys (rzp_test_*) are safe and make no real charges
# Run in dev mode (no build needed)
npm run dev
# Type check
npm run lint
# Run tests
npm testThis server is part of IndiaMCP — a suite of open-source MCP servers for the Indian API stack.
Fetch details of a specific customer by ID
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes | Customer ID, e.g. cust_xxxxx |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. 'Fetch' implies a read-only operation, but it does not explicitly state that the tool is idempotent, has no side effects, or any authorization requirements. Given the simplicity, the lack of detail is acceptable but not exemplary.
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 concise sentence with no extraneous information. It is appropriately front-loaded and efficient.
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 tool is simple with one required parameter and no output schema. The description adequately covers the purpose and parameter. It could optionally mention that the tool returns the full customer object, but the current level is sufficient for an agent to use it 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?
The input schema covers 100% of the parameter with a clear description ('Customer ID, e.g. cust_xxxxx'). The tool description does not add any additional semantics beyond what the schema provides. Baseline score 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 'Fetch' and the resource 'details of a specific customer by ID'. It distinguishes from sibling tools like 'list_customers' (which returns multiple customers) and other entity-specific tools like 'get_order' or 'get_payment'.
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 implies usage when needing details for one customer by ID, but does not explicitly state when not to use (e.g., use list_customers for multiple customers). It is sufficiently clear for the simple use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a high-level business summary — revenue today, this week, this month, success rate, top payment methods. Perfect for a quick business health check.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavioral traits. It mentions it's a summary but does not note read-only nature, data freshness, or authentication requirements.
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?
Single sentence that is clear and front-loaded. Could be slightly more concise, but effectively conveys 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?
No output schema, so description should detail return structure. Lists included metrics but not the format (e.g., object with fields). Adequate for a simple summary tool but incomplete.
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?
No parameters exist, so schema coverage is complete. Description adds value by listing what the summary includes, aiding interpretation.
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 it retrieves a high-level business summary with specific metrics (revenue, success rate, payment methods). However, it does not explicitly differentiate from sibling tools, though the scope is distinct.
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?
Suggests use for 'quick business health check', implying when to use, but lacks guidance on when not to use or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze why payments are failing — breakdown by error code, bank, payment method
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Unix timestamp — start date | |
| to | Yes | Unix timestamp — end date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states the tool analyzes failures, but does not disclose whether it is read-only, any rate limits, aggregation behavior, or how results are structured. This is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the main purpose. However, it lacks structure and could benefit from bullet points or explicit sections.
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 and no annotations, the description is incomplete. It does not explain the return format, pagination, or how to interpret the breakdowns. More detail is needed for an AI agent to fully understand the tool's behavior.
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?
Input schema has 100% coverage (from and to as timestamps). The description does not add any additional meaning or format details beyond what the schema provides, so the baseline score 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 tool's purpose: analyzing why payments fail with breakdowns by error code, bank, and payment method. It distinguishes from siblings like get_payment_analytics (general analytics) and get_dashboard_summary (summary), though it could be more specific.
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 implies use when payments are failing but provides no explicit guidance on when to use this tool versus alternatives like get_payment_analytics. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch details of a specific order by ID
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | Order ID, e.g. order_xxxxx |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Fetch details,' which implies a read operation, but does not mention error handling (e.g., missing order ID), side effects, permissions, or rate limits. This is minimally transparent.
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 concise sentence that captures the essential purpose without extraneous words. It is front-loaded and efficient for a simple tool.
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 get-by-ID tool, the description is adequate but not fully complete. It does not hint at the return fields or structure, and no output schema exists to compensate. Sibling tools have similar brevity, so it matches the server's convention.
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% and the parameter 'order_id' is well-described with example format. The description adds no additional meaning beyond the schema, so baseline 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 'Fetch details of a specific order by ID' clearly states the action (fetch details), resource (order), and retrieval method (by ID). It distinguishes from siblings like list_orders (which lists multiple) and other get_* tools for different entities.
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 explicit guidance on when to use vs alternatives. The context of sibling tools (list_orders for multiple orders, get_payment for payments) implies usage, but no direct instructions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch details of a specific payment by ID
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | Payment ID, e.g. pay_xxxxx |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'fetch details', indicating a read operation, but fails to mention potential errors, rate limits, required permissions, or the structure of returned details. This is minimal transparency for a simple tool.
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?
Single sentence, no wasted words, front-loaded with the core action. Perfectly concise for the tool's simplicity.
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 one required parameter, no output schema, and no nested objects, the description is adequate but could be more complete. It doesn't clarify what 'details' includes (e.g., status, amount, date) or how it differs from 'get_payment_analytics'. Lacks precautionary context like error handling.
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%, with the parameter 'payment_id' described as 'Payment ID, e.g. pay_xxxxx', adding a format example beyond the schema type. The description itself does not repeat parameter info, but the example adds value. Baseline 3 raised to 4 for the example.
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 'Fetch details of a specific payment by ID' clearly states the action (fetch), resource (payment), and scope (by ID). It distinguishes from siblings like 'list_payments' (list vs single) and 'get_payment_analytics' (analytics vs details).
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., list_payments for multiple payments, get_payment_analytics for aggregated data). Usage is implied by the description but not explicitly stated with when/when-not criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze payments for a date range — total revenue, success rate, failure breakdown, payment method distribution
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Unix timestamp — start date | |
| to | Yes | Unix timestamp — end date |
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 describes the tool as 'Analyze', indicating a non-destructive read operation, but fails to disclose any behavioral traits such as rate limits, required permissions, or what happens with missing data.
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 with dash-separated items, making it concise and front-loaded. Every part is useful, though a slight restructuring could improve clarity.
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 low complexity (2 params, no nested objects, no output schema), the description adequately covers the return values (total revenue, success rate, etc.) and provides sufficient context for a statistical analytics tool.
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% for 2 parameters (from, to). The description mentions 'date range', which maps to the parameters, but adds little beyond the schema's descriptions ('Unix timestamp — start date'). Baseline 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 explicitly states 'Analyze payments for a date range' and lists specific outputs (total revenue, success rate, failure breakdown, payment method distribution), clearly distinguishing it from siblings like get_dashboard_summary (broader) and get_failed_payment_analysis (narrower).
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 implies usage for date-range analysis but does not explicitly state when to use this tool versus alternatives like get_dashboard_summary or get_failed_payment_analysis. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch details of a specific refund
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | Payment ID, e.g. pay_xxxxx | |
| refund_id | Yes | Refund ID, e.g. rfnd_xxxxx |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. The description only states 'fetch details', implying a read-only operation, but does not mention authentication needs, rate limits, or any side effects. This is insufficient for a tool with no annotation support.
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 clear and to the point, with no wasted words. However, it is so minimal that it sacrifices completeness for brevity.
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 two parameters, no output schema, and no annotations, the description is far from complete. It fails to explain return values, error conditions, or any additional context about the refund details. The tool is under-documented for its complexity.
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 both parameters have descriptions with examples (e.g., 'pay_xxxxx', 'rfnd_xxxxx'). The description adds no additional meaning beyond the schema, so a baseline score 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 'Fetch' and the resource 'details of a specific refund', distinguishing it from siblings like 'list_refunds' (which lists multiple) and 'get_payment' (which fetches a different resource). However, it is very brief and could be more specific about what 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.
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 'list_refunds' or 'get_payment'. The agent is left to infer the appropriate context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch details of a specific subscription
| Name | Required | Description | Default |
|---|---|---|---|
| subscription_id | Yes | Subscription ID, e.g. sub_xxxxx |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Fetch details'—a read operation—but does not mention any side effects, permissions, return structure, or rate limits. Minimal transparency beyond the basic action.
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, efficient sentence (6 words) with no filler. It earns its place without excess.
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 tool has only one parameter, no output schema, and no annotations, the description is adequate for a simple retrieval but lacks details on return format or potential errors. Could be more informative.
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 100% coverage for the single parameter (description includes 'Subscription ID, e.g. sub_xxxxx'). The tool description adds no additional parameter meaning, so baseline score 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 'Fetch details of a specific subscription' uses a specific verb ('Fetch') and resource ('a specific subscription'), clearly distinguishing it from sibling tools like list_subscriptions (batch) and get_subscription_analytics (aggregate). No tautology or ambiguity.
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 implies usage when a subscription ID is available, it does not explicitly state when to use this tool versus alternatives like list_subscriptions. The context is clear but lacks exclusions or direct comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze subscriptions — active count, churn rate, MRR, upcoming renewals
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Unix timestamp — start date | |
| to | Yes | Unix timestamp — end date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description should cover behavioral traits. It only lists output metrics without clarifying read-only nature, side effects, or performance, leaving 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?
Single sentence, no wasted words, clearly lists key metrics, and is 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?
For a simple 2-parameter tool with no output schema, the description sufficiently explains what metrics are returned, though could hint at return format.
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 both parameters are described adequately. The description adds no extra parameter context beyond the schema, meeting baseline.
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 'analyze' and resource 'subscriptions', and lists specific metrics (active count, churn rate, MRR, upcoming renewals), distinguishing it from siblings like get_subscription or list_subscriptions.
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 implies usage for aggregate analytics but does not explicitly state when to use this tool over alternatives like get_payment_analytics, nor provide prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List customers with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of records (max 100) | |
| skip | No | Number of records to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'list customers' and 'with optional filters', but does not mention read-only nature, authentication, rate limits, ordering, or any side effects. This is insufficient for a tool with no annotation support.
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 very concise with a single sentence, but it is under-specified and lacks important details. Conciseness should not come at the cost of informativeness.
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 tool is simple with two pagination parameters and no output schema, but the description fails to mention returning format, ordering, or pagination behavior. Given the minimal annotations, the description should cover more behavioral aspects.
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 schema has 100% description coverage for parameters, so the baseline is 3. The description adds 'optional filters' which is not reflected in the schema, potentially causing confusion. It does not add meaningful semantic details beyond what the schema already provides.
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 states 'List customers with optional filters', which clearly indicates the action of listing customers. However, the mention of 'optional filters' is misleading because the schema only provides pagination parameters (count, skip) and no actual filtering capabilities. This reduces clarity.
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 given on when to use this tool versus siblings like get_customer (single customer) or other list_* tools. The description lacks context on when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List orders with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Unix timestamp — start date | |
| to | Yes | Unix timestamp — end date | |
| count | No | Number of records (max 100) | |
| skip | No | Number of records to skip | |
| status | Yes | Filter by order status | |
| authorized | Yes | Filter by authorized state | |
| receipt | Yes | Filter by receipt number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, auth requirements, rate limits, or response behavior. For a list tool, it should at least imply it is safe to call.
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 short sentence, efficient and front-loaded. However, it is almost too brief, lacking important details that could be added without becoming verbose.
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 7 parameters (5 required), no output schema, and no annotations, the description is inadequate. It does not explain the return format, pagination, or filtering behavior beyond what the schema provides.
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?
Input schema has 100% coverage with good descriptions for each parameter. The description adds no additional meaning beyond the schema, so it meets the baseline expectation but does not enhance understanding.
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 'List orders with optional filters' clearly indicates the action (list) and resource (orders). It distinguishes from sibling 'get_order' which retrieves a single order, but does not explicitly differentiate from other list tools like list_payments.
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 no guidance on when to use this tool versus alternatives. There is no context about prerequisites, scenarios, or exclusions. Sibling tools like list_payments or list_subscriptions exist but no comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List payments with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Unix timestamp — start date | |
| to | Yes | Unix timestamp — end date | |
| count | No | Number of records (max 100) | |
| skip | No | Number of records to skip | |
| status | Yes | Filter by payment status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose safety (read-only), authentication needs, pagination behavior, or any side effects. The minimal wording 'List payments' leaves significant gaps.
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 very short and front-loaded, but it is under-specified for a tool with 5 parameters. While it has no wasted words, the brevity sacrifices necessary information, making it borderline adequate.
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 5 parameters, no output schema, and no annotations, the description should explain pagination (skip/count), output format, or when to use filters. It fails to provide this context, leaving the agent underinformed.
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 100% coverage with descriptions for every parameter. The description only adds the generic phrase 'optional filters', which adds no specific meaning beyond what the schema already provides.
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 resource 'payments', and mentions optional filters. However, it does not distinguish from sibling list tools like list_orders or list_subscriptions, though the resource name provides clarity.
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 no explicit guidance on when to use this tool versus alternatives such as get_payment or list_refunds. The phrase 'optional filters' implies usage for filtered queries but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List refunds for a payment
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | Payment ID to list refunds for | |
| count | No | Number of records | |
| skip | No | Number of records to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only indicates a read operation but fails to mention pagination (though hinted by parameters), ordering, rate limits, or potential side effects. The agent lacks insight into what happens if the payment has numerous refunds.
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, making it very concise. However, it omits useful context that could be added without sacrificing brevity, such as clarifying the output format or filtering capabilities.
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?
Without an output schema, the description should explain return values. It simply says 'list refunds' but does not specify whether the result is an array of refund objects, IDs, or a paginated response. This gap hinders agent understanding.
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?
All three parameters are fully described in the input schema, leaving no undocumented fields. The tool description adds no extra semantic value beyond the schema, so a baseline score 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 action (list) and resource (refunds) along with the context 'for a payment'. While it implies association with a payment ID, it could further distinguish itself from the sibling 'get_refund' by noting that it returns multiple refunds per payment.
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 like 'get_refund' or other list tools. There is no mention of prerequisites (e.g., payment existence) or limitation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List subscriptions with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Unix timestamp — start date | |
| to | Yes | Unix timestamp — end date | |
| count | No | Number of records (max 100) | |
| skip | No | Number of records to skip | |
| status | Yes | Filter by subscription status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It only states the basic operation, omitting details on pagination (e.g., max 100 records from schema), sorting, rate limits, or that it is a read-only operation. The agent lacks critical usage constraints.
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 short sentence, which is concise but lacks detail. While no words are wasted, the brevity comes at the cost of missing crucial usage and behavioral information, making it less helpful.
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 complexity (5 parameters with 3 required) and lack of output schema or annotations, the description is insufficient. It does not explain pagination defaults, return format, or how filtering works. The tool's context is not fully addressed.
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 100% description coverage, so the schema already explains parameters. The description adds minimal value with the phrase 'optional filters', but does not elaborate on parameter semantics beyond what the schema provides. Baseline 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 action (list) and resource (subscriptions), and mentions optional filters, which aligns with the input schema. However, it does not differentiate from sibling list tools (e.g., list_customers) beyond the resource name, and the phrase 'optional filters' is vague.
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 like get_subscription for a single entity or other list tools. There is no mention of use cases, prerequisites, or exclusion criteria.
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.0get_customerget_dashboard_summaryget_failed_payment_analysisget_orderget_paymentget_payment_analyticsget_refundget_subscriptionget_subscription_analyticslist_customerslist_orderslist_paymentslist_refundslist_subscriptionsScored across 14 tools
Every tool targets a distinct resource or analysis type (customers, orders, payments, refunds, subscriptions, dashboard, failed payment analysis), with no overlapping purposes. An agent can clearly differentiate between them.
All tools follow a consistent verb_noun pattern using lowercase and underscores: 'get_' for single items and 'list_' for collections. No mixing of conventions.
14 tools is well-scoped for a payment gateway MCP, covering all major entities and analytics without being excessive or insufficient.
The tool surface is entirely read-only (get and list operations), lacking any create, update, or delete tools. For a payment gateway, this is a significant gap that prevents agents from taking actions like creating payments or refunds.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
