Click on "Deploy 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., "@whop-mcp list my recent payments"
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.
A community-built Model Context Protocol (MCP) server for the Whop.com Company API. It enables AI assistants (Claude, Cursor, etc.) to fully manage your Whop business — payments, memberships, products, promo codes, affiliates, and more.
🔐 Secure API key authentication via environment variable
📦 Full TypeScript with strict type-safety
🔄 Automatic retry & rate-limit handling
🛡️ Comprehensive error handling (401, 403, 404, 429)
🚀 Works with Claude Desktop, Cursor, and any MCP-compatible client
📡 stdio transport (works as a CLI binary or subprocess)
Related MCP server: VoIPBin MCP Server
Install the whop-mcp server in VS Code with one click:
Note: Replace
YOUR_WHOP_API_KEY_HEREwith your actual Company API key from the Whop Developer Dashboard.
Add to your Claude Desktop config file:
macOS/Linux: ~/.config/claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"whop": {
"command": "npx",
"args": ["-y", "@furkankoykiran/whop-mcp"],
"env": {
"WHOP_API_KEY": "YOUR_WHOP_API_KEY_HERE"
}
}
}
}Add to your Cursor MCP settings (Cursor Settings -> MCP Servers):
{
"whop": {
"command": "npx",
"args": ["-y", "whop-mcp"],
"env": {
"WHOP_API_KEY": "YOUR_WHOP_API_KEY_HERE"
}
}
}Click Create in the Company API Keys section
Give your key a name (e.g. "Claude Integration")
Select the appropriate permissions (Payments, Memberships, Products, etc.)
Copy the key — you'll never see it again!
Tool | Description |
| List payments with filters (status, product, date range, pagination) |
| Get full details of a specific payment |
| Issue a full or partial refund for a payment |
| Retry a failed payment attempt |
| Void an open/uncollected payment |
| High-level revenue, refund, and fee summary |
Tool | Description |
| List memberships with filters (status, product, user, validity) |
| Get full membership details including license key and expiry |
| Validate a license key and check if its membership is active |
| Extend a membership by adding free days |
| Cancel a membership at period end |
| Immediately revoke a membership |
| Update metadata on a membership |
Tool | Description |
| List all products with plans and experiences |
| Get full product details, plans, and experiences |
| Create a new product |
| Update product name, visibility, or description |
| Delete a product permanently |
| List all pricing plans for a product |
Tool | Description |
| List all promo codes with optional status filter |
| Get details of a specific promo code |
| Create a new discount code (% or $ off) |
| Update an existing promo code (status, expiry, etc.) |
| Permanently delete a promo code |
Tool | Description |
| List all affiliates with commission and earnings data |
| Get detailed stats for a specific affiliate |
| Aggregate affiliate program performance with top performers |
Tool | Description |
| Look up a Whop user by username or user ID |
| Find customers by email address |
| Fetch customer reviews with optional star rating filter |
| Aggregate review statistics (avg rating, distribution) |
Once connected, you can ask your AI assistant:
"Show me all payments from the last 30 days"
"Refund payment pay_123abc"
"Add 7 free days to membership mem_456def"
"Create a 20% off promo code called SUMMER20 that expires December 31, 2025"
"What's my average customer review rating?"
"Who are my top 5 affiliates by earnings?"
"Validate license key ABC-1234-XYZ"
# Install deps
npm install
# Run in dev mode (auto-reload)
npm run dev
# Build
npm run build
# Test manually
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | WHOP_API_KEY=test node dist/index.jsContributions are welcome! Please see CONTRIBUTING.md for guidelines.
This project is licensed under the MIT License.
⚠️ Disclaimer: This is a community-led project and is NOT an official Whop.com product. It is not affiliated with, endorsed by, or supported by Whop.com. Always test in a non-production environment before running actions like refunds or membership terminations.
Extend a membership by adding free days to it.
| Name | Required | Description | Default |
|---|---|---|---|
| membership_id | Yes | The membership ID to extend. | |
| days | Yes | Number of free days to add. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects or requirements. It only states the action without explaining what happens to the membership (e.g., if already expired, impact on billing) or needed permissions.
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 no redundancy, effectively conveying the core action. It is appropriately concise given 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?
The description is too minimal for a mutation tool. No output schema, no annotations, so it should explain expected behavior, side effects, or return value. Currently lacks 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?
The input schema already describes both parameters (membership_id, days) with 100% coverage. The description adds the term 'free days' but does not clarify semantics beyond the schema.
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 extends a membership by adding free days, which is specific. However, it does not differentiate from sibling tools like update_membership, which could also modify membership duration.
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 such as update_membership or cancel_membership. The description lacks context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a membership at period end (member retains access until expiry).
| Name | Required | Description | Default |
|---|---|---|---|
| membership_id | Yes | The membership ID to cancel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds key behavior: member retains access until expiry. However, lacks details on reversibility, permissions, or side effects.
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 conveying essential information. No wasted words, 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?
Given the simple tool (1 param, no output schema, no annotations) the description provides necessary behavioral context. Could optionally mention that it's a mutation, but overall adequate.
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 the single parameter. Description does not add any extra meaning beyond the schema's description of membership_id.
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?
Clear verb (cancel) and resource (membership). Explicitly states 'at period end' which distinguishes from immediate cancellation tools like terminate_membership.
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 it states 'at period end', it does not explicitly contrast with siblings like terminate_membership. The context implies graceful cancellation, but lacks direct when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new product in your Whop company catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Product name. | |
| visibility | No | Product visibility (default: visible). | visible |
| description | No | Product description (optional). | |
| headless | No | Whether the product is headless (no Whop storefront). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the action itself, such as destructive nature, permissions required, or side effects.
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, front-loaded sentence with no wasted words. It is appropriately sized 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?
The description is minimal but adequate for a simple create operation. However, it does not mention what the tool returns (e.g., created product details), leaving some gap in completeness given no output schema.
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%, so the schema already documents all parameters. The description adds no additional meaning beyond what is in the schema, earning 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 verb 'Create' and the resource 'a new product in your Whop company catalog', distinguishing it from siblings like 'update_product' and 'delete_product'.
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 when-to-use or when-not-to-use guidance is provided. The description implies usage for creating a product but doesn't mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new promo code with discount configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The promo code string customers will enter at checkout (e.g. SAVE20). | |
| discount_type | Yes | Type of discount: percentage (%) or dollar ($). | |
| discount_amount | Yes | Discount value. For percentage, use 0-100. For dollar, use amount in cents. | |
| currency | No | Currency code for dollar discounts (e.g. USD). Required for dollar type. | |
| quantity | No | Max number of times this code can be used. Omit for unlimited. | |
| expiry_date | No | Expiry date as ISO 8601 string (e.g. 2025-12-31). Omit for no expiry. | |
| product_ids | No | Restrict code to specific product IDs. Omit for all products. | |
| plan_ids | No | Restrict code to specific plan IDs. Omit for all plans. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but only states 'Create new...'. No information on idempotency, error behavior (e.g., duplicate code), authorization needs, or side effects is included.
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, front-loaded sentence with no wasted words. It is appropriately concise, though could benefit from a brief additional clause.
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 an 8-parameter creation tool without annotations or output schema, the description is too minimal. It does not address return values, validation behavior, or error cases, leaving an 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?
Schema coverage is 100%, so parameters are already well-documented. The description adds high-level context ('with discount configuration') but no additional meaning beyond the schema.
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 uses a specific verb-resource pair ('Create a new promo code') and mentions 'discount configuration', clearly differentiating it from sibling tools like delete_promo_code or update_promo_code.
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 creation usage, it provides no explicit guidance on when to use this tool versus alternatives (e.g., update_promo_code) or prerequisites like checking for existing codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a product from your catalog. This action is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | The product ID to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses irreversibility, a key behavioral trait. However, with no annotations provided, it fails to mention potential side effects on related data (e.g., orders, memberships), authorization needs, or whether the operation is synchronous.
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 extremely concise with two short sentences, front-loading the main action. Every word is essential and no extraneous information is present.
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 tool with one parameter and no output schema, the description covers the key action and irreversibility. However, it lacks mention of prerequisites or post-conditions, leaving gaps for an AI agent unfamiliar with the system.
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%, with product_id described as 'The product ID to delete.' The description adds no extra semantic value beyond the schema's own description, 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 verb 'Delete' and resource 'product' are explicitly stated, making the action unmistakable. It clearly distinguishes from sibling tools like create_product and update_product.
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 notes the action is irreversible, implying caution, but does not specify when to use this tool versus alternatives (e.g., when a product should be removed from catalog vs. deactivated). No prerequisites or context for safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a promo code. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| promo_code_id | Yes | The promo code ID to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the destructive nature ('Permanently delete', 'cannot be undone'), which is critical behavioral transparency. However, it omits potential side effects like cascading deactivations or authentication requirements, but for a simple delete operation this is acceptable.
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 extremely concise, consisting of two short sentences with no extraneous words. The key information (action and consequence) is front-loaded, making it efficient for an AI agent to parse.
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 one-parameter delete tool without output schema, the description is largely complete. It covers the action and irreversibility. A minor gap is whether the promo code can be deleted if it is in use, but this is not critical for basic usage.
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 provides complete coverage (100%) for the single parameter, including a description. The tool description does not add any additional semantic information about the parameter beyond what the schema already provides, 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 'delete' and the resource 'promo code', distinguishing it from sibling tools like 'update_promo_code' or 'get_promo_code'. The action is unambiguous.
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 mentions permanence and irreversibility, which implies careful usage, but it does not explicitly state when to use this tool versus alternatives such as 'update_promo_code' for deactivation. No alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed statistics for a specific affiliate partner by their affiliate ID.
| Name | Required | Description | Default |
|---|---|---|---|
| affiliate_id | Yes | The affiliate ID (e.g. aff_xxxx). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. Description only mentions 'detailed statistics' but does not specify return fields, idempotency, rate limits, or side effects. Minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct, no unnecessary words. Efficiently conveys core 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?
Tool is simple with one required param and no output schema. Description provides basic purpose but lacks details on output behavior. Adequate but could mention read-only or idempotent nature.
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% for the single parameter. Description adds no extra meaning beyond what the schema already provides (e.g., example aff_xxxx). Baseline 3 for high coverage.
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?
Description clearly states verb (Get), resource (detailed statistics for a specific affiliate partner), and identifier (affiliate ID). It is distinct from siblings like get_affiliate_summary, though not explicitly contrasted.
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 like list_affiliates or get_affiliate_summary. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an aggregate summary of all affiliate performance: total sales, earnings, and top performers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 indicates a read-only operation returning aggregate data but does not disclose whether results are cached, real-time, or require specific permissions. For a simple summary tool, this is adequate but not richly 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 sentence of 15 words, efficiently conveying the tool's purpose and output. No filler or redundant information is present.
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 parameterless tool with a clear purpose, the description is mostly sufficient. It explains the output but could benefit from mentioning the output structure or type (e.g., object with specific fields). However, given the simplicity, a score of 4 is appropriate.
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?
There are no parameters, so the input schema is fully covered. The description adds meaning by specifying the contents of the output (total sales, earnings, top performers), which compensates for the lack of output schema according to the baseline guideline for 0 parameters.
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 uses a specific verb 'Get' and identifies the resource 'aggregate summary of all affiliate performance', listing included fields (total sales, earnings, top performers). This clearly distinguishes it from sibling tools like 'get_affiliate' (individual) and 'list_affiliates' (list without summary).
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 summaries but does not explicitly state when to use this tool versus alternatives like 'get_affiliate' or 'get_financial_summary'. No exclusion criteria or alternative recommendations are provided.
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 financial summary: total revenue, refunds, fees, and payment breakdown by status.
| Name | Required | Description | Default |
|---|---|---|---|
| company_id | No | Company ID to scope the summary. | |
| after_date | No | ISO 8601 start date (e.g. 2024-01-01). | |
| before_date | No | ISO 8601 end date (e.g. 2024-12-31). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It only lists output contents but does not mention side effects, authentication needs, rate limits, or whether the operation is read-only. The absence of any behavioral notes 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?
Single sentence, front-loaded with verb and resource, no waste. Efficiently conveys the tool's 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 exists, so the description should detail return structure. It lists summary components but lacks specifics on grouping, pagination, or defaults for optional parameters. Incomplete for a tool with three optional parameters.
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% with well-described parameters (company_id, after_date, before_date). The description does not add extra 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 clearly specifies the verb ('Get') and the resource ('high-level financial summary') and lists key components (total revenue, refunds, fees, payment breakdown by status), distinguishing it from sibling tools like get_affiliate_summary or 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?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies it's for high-level summaries, but doesn't mention alternatives or context for filtering (e.g., use get_payment for individual payments).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific membership by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| membership_id | Yes | The membership ID (e.g. mem_xxxx). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. While it states 'detailed information', it does not specify what information is included (e.g., plan, dates, status). It also fails to note that this is a read-only operation with no side effects. For a fetch tool, this is insufficient 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, complete sentence that conveys the core functionality without any fluff. It is perfectly sized for a simple retrieval operation.
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 lack of an output schema and no annotations, the description should provide more detail about what the returned 'detailed information' includes. Without this, an agent cannot anticipate the response structure, which is critical for a get operation. The description is too minimal for a tool with zero additional context.
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 its single parameter 'membership_id', with a clear description. The tool description echoes the need for an ID but adds no additional semantic value beyond what the schema already 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 ('Get detailed information') and the resource ('specific membership') with the identifier ('by its ID'). This immediately distinguishes it from sibling tools like 'list_memberships' (which returns multiple) and 'update_membership' (which modifies).
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 via a membership ID, which is sufficient for a straightforward get-by-ID operation. However, it provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or context that would help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific payment by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | The payment ID (e.g. pay_xxxx). |
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 auth requirements, rate limits, or whether the action is read-only. The term 'detailed information' is vague and does not clarify the scope of the response.
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 front-loads the action and resource. No unnecessary words or 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?
Given the low complexity (one param, no output schema), the description minimally defines the tool's purpose but lacks specifics about the response structure or 'detailed information'. It is adequate but not comprehensive.
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% for the single parameter payment_id, which already includes an example. The tool description does not add extra 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 uses specific verb 'Get' and resource 'detailed information about a specific payment', clearly distinguishing it from sibling tools like list_payments (list) and refund/retry/void (mutations).
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 does not explicitly state when to use this tool vs alternatives, but the purpose is implied by the name and context. No guidance on prerequisites or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific product including its plans and experiences.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | The product ID (e.g. prod_xxxx). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose side effects, authorization needs, rate limits, or whether it's a read-only operation. The brief description only implies a safe retrieval.
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, clear sentence with no redundant words. It is appropriately 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?
For a single-parameter get tool with no output schema, the description hints at return structure (plans and experiences) and is mostly complete. It lacks mention of error conditions but is adequate.
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 the single parameter product_id. The description adds context about 'plans and experiences' but does not add parameter-specific meaning beyond the schema.
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 'Get' and the resource 'detailed information about a specific product including its plans and experiences.' It distinguishes from siblings like get_membership, get_payment, etc.
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 list_products. There is no mention of prerequisites or avoided scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific promo code by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| promo_code_id | Yes | The promo code ID (e.g. promo_xxxx). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read operation ('Get detailed information') but does not disclose any behavioral traits such as authentication needs, rate limits, or side effects. It is adequate for a simple get but lacks depth.
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 contains all necessary information. No wasted words, and the key action and resource are 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?
For a simple get tool with one parameter and no output schema, the description is fairly complete. It could mention that it returns detailed information or include a brief note about the return format, but it is sufficient for an agent to understand the basic purpose.
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% with one parameter well-described. The description adds the example format 'promo_xxxx' but the schema already states 'e.g. promo_xxxx'. Thus the description adds minimal meaning beyond the schema.
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 action ('Get'), the resource ('detailed information about a specific promo code'), and the identifier ('by its ID'). It distinguishes from sibling tools like create_promo_code, delete_promo_code, list_promo_codes.
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 a specific promo code ID is known, but does not explicitly state when to use it versus alternatives like list_promo_codes, or provide any exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate review statistics for your company: average rating, distribution by star count.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | No | Scope stats to a specific product ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that the tool returns aggregate stats for the company, but doesn't explicitly state it's a read-only operation or mention any authentication requirements. Adequate but not thorough.
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, clear sentence that front-loads the core purpose. No unnecessary words, making it highly 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?
Given the tool has only one optional parameter and no output schema or annotations, the description is mostly complete. It could mention the structure of the return (e.g., 'returns an object with averageRating and ratingDistribution'), but still adequate.
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% with a well-described optional 'product_id' parameter. The description adds little beyond the schema, simply restating the tool's purpose. No additional semantics or usage context for the parameter.
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 retrieves aggregate review statistics (average rating, distribution by star count) for the company, which distinguishes it from siblings like 'list_reviews' that likely return individual reviews.
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 this tool vs alternatives. The description implies it's for company-level stats, but does not mention when to prefer it over, e.g., 'get_product' or 'list_reviews', nor does it set exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a Whop user by their username or numeric user ID.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Username (e.g. john) or user ID (e.g. user_xxxx) to look up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'look up', implying a read operation, but it does not disclose any behavioral traits such as permissions needed, rate limits, or whether the user info is detailed or minimal.
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 with no wasted words, front-loading the core 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 lookup tool with one parameter and no output schema, the description is minimally adequate. However, it lacks any hint about the return structure or fields retrieved, which could be helpful given the number of sibling tools.
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 matches the schema's parameter description, but adds no extra 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 tool looks up a Whop user by username or numeric user ID, using a specific verb and resource, distinguishing it from sibling tools that handle other 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 guidance is provided on when to use this tool versus alternatives like search_users_by_email, which also retrieves users. The description does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all affiliate partners for your Whop company with their commission and earnings data.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter affiliates by status. | |
| page | No | Page number. | |
| per | No | Items per page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It does not mention pagination, read-only nature, auth requirements, or rate limits. Only states it lists data, but lacks behavioral context beyond what schema implies.
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, to the point, no wasted words. Could be slightly improved by hinting at pagination, but overall 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?
Given no output schema, description should indicate response format. It mentions commission and earnings but not structure or pagination. With 3 simple params and full schema coverage, it's adequate but missing some context.
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. Description adds no extra meaning beyond schema—parameters like 'status', 'page', 'per' are self-explanatory. No elaboration on how commission/earnings data is structured.
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?
Description clearly states it lists affiliate partners with commission and earnings data, using specific verb 'list' and resource 'affiliate partners'. It distinguishes from siblings like 'get_affiliate' and 'get_affiliate_summary'.
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?
Implied usage is to list all affiliates, but no explicit guidance on when to use this vs alternatives like 'get_affiliate' for a single affiliate. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all memberships for your Whop company with optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | No | Filter by product ID. | |
| plan_id | No | Filter by plan ID. | |
| user_id | No | Filter by user ID. | |
| status | No | Filter by membership status. | |
| valid | No | Filter by validity (true = currently active). | |
| page | No | Page number. | |
| per | No | Items per page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It indicates a read operation with no side effects, but does not disclose potential rate limits, authentication requirements, or exact return structure (pagination, count). Adequate but not detailed.
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 unnecessary words, front-loaded with key action and resource. Efficient and clear.
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 and no output schema, the description lacks details on pagination behavior, result structure, or how to handle responses. While adequate for a simple list tool, it leaves gaps for effective invocation (e.g., how to iterate pages).
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%, so the schema already documents all parameters. The description adds 'with optional filters' but does not provide additional meaning beyond what the schema conveys. 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?
Description clearly states verb (List), resource (memberships), and scope (with optional filters). Distinguishes from sibling tools like get_membership, cancel_membership, etc., as a listing operation.
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?
Usage is implied from the description (use for listing memberships with filters), but no explicit guidance on when to use vs siblings (e.g., get_membership for a single membership, or cancel_membership for mutations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all payments for your Whop company with optional filters (status, product, date range, pagination).
| Name | Required | Description | Default |
|---|---|---|---|
| company_id | No | Filter by company ID (e.g. biz_xxxx). Uses your API key's company by default. | |
| product_id | No | Filter by product ID. | |
| plan_id | No | Filter by plan ID. | |
| status | No | Filter by payment status. | |
| billing_reason | No | Filter by billing reason. | |
| user_id | No | Filter by user ID. | |
| after_date | No | ISO 8601 start date filter (e.g. 2024-01-01). | |
| before_date | No | ISO 8601 end date filter (e.g. 2024-12-31). | |
| page | No | Page number (default 1). | |
| per | No | Items per page (1-100, default 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not explicitly state that this is a read-only operation, nor does it disclose pagination behavior or any limitations. The word 'list' weakly implies read, but fails to provide safety or side-effect details.
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, front-loaded sentence with no redundant words. It efficiently conveys the core action and scope, earning its place without unnecessary detail.
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 10 parameters and no output schema, the description is minimal. It does not mention the response format (e.g., paginated list of payment objects) or default ordering. Schema covers parameters, but the lack of output schema and additional behavioral context leaves some gaps.
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 no additional meaning beyond labeling filters as 'optional'. The schema already documents each parameter and defaults (e.g., company_id default). No new semantics are provided.
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 resource ('payments'), action ('list'), and scope ('for your Whop company'). It distinguishes from siblings like get_payment (singular) and mutation tools. The optional filters are mentioned, reinforcing the purpose.
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 listing multiple payments but provides no explicit guidance on when to use this tool versus alternatives like get_payment for a single payment, or refund_payment for refunds. 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.
List all pricing plans for a specific product.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | The product ID whose plans you want to list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action. It does not disclose any behavioral traits such as pagination, rate limits, authorization needs, or whether the listing is exhaustive.
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 clear sentence with no unnecessary words. It is concise, though slightly more context could be added without losing conciseness.
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 no output schema and simple parameters, the description lacks information about the return format (e.g., what fields are in the plan list). This is a significant gap 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?
Schema coverage is 100%, and the schema already describes the product_id parameter. The description adds no additional meaning beyond what the schema 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 the resource 'pricing plans for a specific product'. It distinguishes this tool from sibling listing tools that deal with different resources (e.g., list_products, list_memberships).
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 retrieving plans for a product but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all products in your Whop company catalog, including plans and experiences.
| Name | Required | Description | Default |
|---|---|---|---|
| visibility | No | Filter by product visibility. | |
| page | No | Page number. | |
| per | No | Items per page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states it lists products, implying a read operation, but does not disclose pagination behavior, rate limits, or authorization requirements. It lacks transparency for a tool with three parameters and default values.
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 wasted words. However, it could be slightly more informative without losing conciseness—for example, noting defaults or filtering options.
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 three parameters are fully described in the schema and no output schema exists, the description is minimally adequate. It covers the basic resource but lacks details on return format, pagination defaults, or filtering behavior, leaving gaps for an agent.
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 the baseline is 3. The description adds no extra meaning beyond the schema; it does not explain how parameters like visibility or pagination interact. The description's 'including plans and experiences' adds context but not parameter details.
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 uses 'List products' as verb+resource, and specifies scope as 'in your Whop company catalog, including plans and experiences.' This distinguishes it from sibling tools like get_product (single product) and list_plans (only plans), but does not explicitly differentiate from other listing tools.
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 usage guidance is provided. There is no mention of when to use this tool versus alternatives like list_plans or search tools. The agent is left to infer context from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all promo codes for your Whop company, with optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter promo codes by status. | |
| page | No | Page number. | |
| per | No | Items per page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It implies a read operation but does not mention pagination details, rate limits, or that the result is a list of promo code objects. This lack of detail hinders an AI agent from understanding the full 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?
A single sentence that efficiently conveys the purpose. However, it could be improved by adding a second sentence about pagination or default ordering without becoming overly long.
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 listing tool with 3 parameters, no output schema, and no annotations, the description is too minimal. It omits return format, pagination behavior, and any ordering or limitations, leaving the agent with incomplete context.
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 for all three parameters (status, page, per). The description adds only that filters are optional, which is already implied by the schema. No additional semantic value beyond the schema.
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', the resource 'promo codes', and the scope 'for your Whop company'. It also mentions optional filters, which differentiates it from sibling tools like 'get_promo_code' (single) and 'create_promo_code' (creation).
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., 'get_promo_code' for a single code). It does not state when not to use it or provide context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the latest customer reviews left for your Whop company or a specific product.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | No | Filter reviews by product ID. | |
| min_rating | No | Filter reviews with rating >= this value (1-5). | |
| page | No | Page number. | |
| per | No | Items per page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description only mentions 'Fetch' implying read-only, but lacks details on authentication, rate limits, ordering, or side effects. The word 'latest' suggests sorting but is not explained.
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?
One concise sentence that conveys the core purpose without excess. Front-loaded with key action and resource.
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 4 parameters, pagination, and no output schema, the description is too sparse. Lacks details on pagination behavior, response format, sorting, and error conditions.
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 covers 100% of parameters with descriptions. The tool description adds minimal value beyond schema examples (e.g., 'for your Whop company or a specific product' hints at product_id usage).
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 'Fetch the latest customer reviews' with specific verb and resource. Distinguishes between company-wide and product-specific reviews, matching the optional product_id parameter. No sibling tool directly overlaps.
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 like get_review_stats. No prerequisites or contextual usage hints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check server connectivity and uptime
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently states the tool checks connectivity and uptime, implying a non-destructive read operation. No contradictions exist, and the description is adequate for this 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?
The description is a single sentence with no extraneous words. Every word serves a purpose, making it highly concise and 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?
Given the tool has no parameters, no output schema, and a simple purpose, the description is contextually complete. It could optionally mention return value format (e.g., status message), but this is not critical for a ping 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?
There are 0 parameters, and the schema is empty. The description does not need to add parameter semantics. Baseline for 0 parameters is 4, and the description meets this standard.
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 'Check server connectivity and uptime' uses a specific verb ('check') and resource ('server connectivity and uptime'), clearly distinguishing it from all sibling CRUD and action tools. No sibling tool has a purpose related to connectivity checks.
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 this tool versus alternatives is provided. The context is simple enough that usage is implied (e.g., before other operations), but explicit instructions could improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue a full or partial refund for a payment. Use with caution — this action cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | The payment ID to refund (e.g. pay_xxxx). | |
| amount | No | Refund amount in cents. Omit for a full refund. | |
| reason | No | Reason for the refund. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions irreversibility but does not describe other effects like payment status changes, confirmation steps, or side effects beyond the refund itself.
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 extremely concise with two sentences. The first sentence states the purpose, the second adds a key caution. No unnecessary words.
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 presence of siblings and no output schema, the description covers the basic purpose and a warning but lacks details on return values, error conditions, or post-refund state. It is adequate but not thorough.
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%, so the schema already explains each parameter. The description adds no additional meaning beyond the schema; it repeats the full/partial refund concept which is already implied by omitting the amount.
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 ('Issue a full or partial refund for a payment'), specifying the verb and resource. It distinguishes this tool from siblings like 'void_payment' or 'retry_payment' by mentioning partial refunds.
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 includes a caution that the action cannot be undone, which provides minimal guidance. However, it does not explicitly state when to use this tool versus alternatives, nor does it give prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retry a failed payment attempt for a given payment ID.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | The payment ID to retry (e.g. pay_xxxx). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action. It fails to disclose whether retrying triggers a new charge, idempotency, or any side effects. This is insufficient for a payment operation.
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 with no wasted words. 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?
For a simple single-param tool, the description is minimal but missing behavioral details. Without output schema, more context on return values or error states would improve 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?
The input schema already documents the parameter with a clear description and example. The description adds no extra semantic value, 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 clearly specifies the action ('retry') and the resource ('failed payment attempt'), distinguishing it from payment-related siblings like refund or void. However, it does not elaborate on the exact meaning of retry.
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 retry versus using alternatives like refund_payment or void_payment. The description lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Whop users who have purchased from your company, filtered by email address.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to search for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It doesn't disclose whether the tool returns a single user or a list, what fields are in the response, or what happens if no match is found. Lacks details on authentication or rate limits.
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 front-loads the purpose and context. No unnecessary wording. Appropriate length 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?
Given low complexity (1 param, no output schema), the description is minimally adequate. However, it lacks details about output format and behavior on no results, which are important for the agent to use correctly. Sibling tools and context don't fill this 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?
Parameter 'email' has 100% schema description coverage. The description adds no extra value beyond restating 'filtered by email address.' Schema already explains it's an email address to search for, so description is adequate but not enhancing.
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 searches for Whop users who have purchased from the user's company, filtered by email. It distinguishes from sibling tools like 'get_user' (likely by ID) and 'list_memberships' by specifying the email filter and the purchaser context.
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 this tool versus alternatives. For example, it doesn't mention that 'get_user' requires a user ID or that this tool only works for purchasers. The agent must infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Immediately terminate a membership and revoke all access. This is permanent.
| Name | Required | Description | Default |
|---|---|---|---|
| membership_id | Yes | The membership ID to terminate immediately. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the action is immediate and permanent, indicating destructiveness. However, it omits details like required permissions or whether it triggers downstream effects.
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, front-loaded sentences with no superfluous information. Every word adds value.
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 single-parameter, no-output-schema tool, the description covers the essential action. It is nearly complete but could mention prerequisites or confirmations.
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 parameter description is clear: 'The membership ID to terminate immediately.' The tool description adds no additional meaning beyond the schema.
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 it terminates a membership and revokes all access, emphasizing permanence. However, it does not explicitly differentiate from the sibling tool 'cancel_membership', leaving ambiguity about when to use each.
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 'cancel_membership'. The description mentions permanence but lacks explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update metadata or notes on a membership record.
| Name | Required | Description | Default |
|---|---|---|---|
| membership_id | Yes | The membership ID to update. | |
| metadata | No | Key-value metadata to store on the membership. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, authorization requirements, or whether the operation is reversible. For a mutation tool, this is insufficient behavioral information.
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 with no unnecessary words, directly conveying the tool's purpose. Excellent conciseness.
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?
Tool has no output schema and uses a nested object parameter. The description does not explain return values or usage patterns for the metadata object. Adequate but not comprehensive.
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% with descriptions for both parameters. The description adds 'notes' which is not in the schema, but overall does not provide significant additional meaning beyond the schema. 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?
Description clearly states the verb 'update' and resource 'membership record', and specifies scope as 'metadata or notes'. It distinguishes from sibling tools like cancel_membership or terminate_membership, though does not explicitly differentiate.
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 such as cancel_membership or terminate_membership. Context or conditions for usage are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing product's name, visibility, or description.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | The product ID to update. | |
| name | No | New product name. | |
| visibility | No | New visibility. | |
| description | No | New description. |
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 indicates mutation but does not disclose side effects (e.g., impact of visibility changes), idempotency, permission requirements, or whether only provided fields are updated. Minimal disclosure beyond the 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 that is front-loaded with the action and lists the fields. No unnecessary words.
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 mutation tool with 4 parameters and no output schema, the description is adequate but lacks behavioral context such as whether it performs partial updates and what the response contains. The schema covers parameter semantics, so it is minimally 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?
Schema description coverage is 100%, so the description adds no new meaning beyond what the schema already provides. Baseline of 3 is appropriate given high coverage.
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 the verb 'update' and the resource 'product', and lists the specific fields (name, visibility, description) that can be updated. It clearly distinguishes this from sibling tools like 'create_product' (creation) and 'delete_product' (deletion).
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 an existing product's name, visibility, or description needs modification, but it provides no explicit guidance on when not to use it (e.g., for bulk updates) or alternatives among siblings like 'update_membership'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing promo code (e.g. disable it or change expiry).
| Name | Required | Description | Default |
|---|---|---|---|
| promo_code_id | Yes | The promo code ID to update. | |
| status | No | New status. | |
| quantity | No | New usage limit. | |
| expiry_date | No | New expiry date as ISO 8601 string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states 'update' with two examples, but does not disclose mutation behavior, idempotency, authorization needs, or effects of omitting fields.
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, front-loaded with the verb, and contains no fluff. It is slightly minimal but 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?
With 4 parameters, no output schema, no annotations, and numerous sibling tools, the description is insufficient. It fails to explain behavior for optional fields, field interactions, or expected outcomes.
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%, so baseline is 3. The description adds marginal value by exemplifying 'disable it' (status) and 'change expiry' (expiry_date), but does not elaborate on quantity or promo_code_id beyond schema.
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 'Update an existing promo code' with specific examples (disable it or change expiry), clearly identifying the verb and resource, and differentiating from sibling tools like create, delete, get, and list.
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 when to use (to modify an existing promo code) but lacks explicit guidance on prerequisites, alternatives, or when not to use. No exclusionary context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a license key and check if it maps to an active, valid membership.
| Name | Required | Description | Default |
|---|---|---|---|
| license_key | Yes | The license key string to validate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions validation and membership check but does not state whether the tool is read-only, requires permissions, or handles invalid keys. Minimal but not explicit.
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, front-loaded with verb, zero unnecessary words. Highly 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?
Given simplicity (1 param, no output schema), description is adequate but does not mention return value format or error behavior. Could be slightly more 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?
Schema coverage is 100% and already describes the parameter. The description adds no extra meaning beyond the schema. Baseline of 3 applies.
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 verb 'validate', resource 'license key', and outcome 'check if it maps to an active, valid membership'. Differentiates from siblings as the only license validation tool.
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 this tool versus alternatives. Does not mention when not to use or provide any context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Void an open or uncollected payment. The payment must not yet be collected.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | The payment ID to void (e.g. pay_xxxx). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the precondition and action, lacking details on side effects, reversibility, or error handling.
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, efficient and front-loaded with essential information.
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 void operation with one parameter, but lacks mention of error cases or what happens if payment already voided.
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 has 100% parameter coverage with description for payment_id; the tool description adds no extra parameter-level detail beyond the condition on the payment state.
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 'void', the resource 'payment', and specifies conditions 'open or uncollected', distinguishing it from sibling tools like refund_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?
Explicitly states the required condition 'payment must not yet be collected', but does not name alternative tools like refund_payment for collected payments.
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.
v1.1.2add_free_dayscancel_membershipcreate_productcreate_promo_codedelete_productdelete_promo_codeget_affiliateget_affiliate_summaryget_financial_summaryget_membershipget_paymentget_productget_promo_codeget_review_statsget_userlist_affiliateslist_membershipslist_paymentslist_planslist_productslist_promo_codeslist_reviewspingrefund_paymentretry_paymentsearch_users_by_emailterminate_membershipupdate_membershipupdate_productupdate_promo_codevalidate_licensevoid_paymentScored across 32 tools
Each tool targets a distinct action on a specific resource. Cancel vs. terminate memberships and refund vs. void payments are clearly differentiated by description. No overlapping tool purposes.
The vast majority use a consistent verb_noun pattern in snake_case (e.g., create_product, list_memberships). The only exception is 'ping', which is a single verb and slightly breaks the pattern.
32 tools is above the typical 3-15 range but appropriate for a comprehensive commerce platform covering products, memberships, payments, affiliates, reviews, promo codes, users, and licenses. Slightly over but reasonable given the scope.
The tool set provides complete CRUD and lifecycle coverage for all major entities: products, memberships, payments, promo codes, affiliates, reviews, and users. Missing operations like update_affiliate are minor and non-essential.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
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.
A Model Context Protocol server for Wix AI tools
