Provides comprehensive integration with Lemon Squeezy's payment platform, enabling management of stores, products, variants, orders, customers, subscriptions, license keys, checkouts, and webhooks with full audit logging capabilities.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Lemon Squeezy Server list my recent orders from the last month"
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 Model Context Protocol (MCP) server implementation that integrates with Lemon Squeezy for handling subscriptions, checkouts, products, and more. This server provides a structured interface to programmatically manage your Lemon Squeezy store with audit logging and tool-based control.
Python 3.8+
MCP SDK 0.1.0+
aiohttp
python-dotenv
Related MCP server: Indie Founder Revenue MCP
The server provides an MCP-compatible resource for operation auditing:
Stores logs of all tool-based Lemon Squeezy operations
Exposes audit log via read_resource endpoint
Helpful for debugging and audit traceability
Implements a full set of Lemon Squeezy operations via MCP tools:
get_user: Get current Lemon Squeezy user info
list_stores: List all stores
get_store: Fetch a specific store
list_products: List products
get_product: Get product details
get_product_variants: List variants for a product
list_orders: List all orders
get_order: Get details of an order
list_customers: List all customers
get_customer: Fetch customer details
list_subscriptions: List subscriptions
get_subscription: Get a subscription
list_license_keys: List license keys
get_license_key: Fetch license key info
create_checkout: Create a fully customized checkout session
create_webhook: Register a new webhook
list_webhooks: List all webhooks (filterable by store)
Subscription & Checkout Management
Webhook Creation & Listing
Audit Logging of All Actions
MCP-Compatible Tool & Resource Integration
Error Feedback and Logging
To install LemonSqueezy Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @atharvagupta2003/mcp-lemonsqueezy --client claudepython -m venv venv
source venv/bin/activate # On macOS/Linux
venv\Scripts\activate # On Windows
pip install -e .Set up the environment variables in a .env file:
LEMON_SQUEEZY_API_KEY=your_lemonsqueezy_api_keyAdd the server configuration to your Claude Desktop config:
Windows: C:\Users<username>\AppData\Roaming\Claude\claude_desktop_config.json
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"lemonsqueezy": {
"command": "/Users/hp/.local/bin/uv",
"description": "Operations with lemonsqueezy payment platform",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/PARENT/FOLDER/src/mcp_lemonsqueezy",
"run",
"--with",
"fastmcp",
"server.py"
],
"env": {
"LEMONSQUEEZY_API_KEY": "<YOUR-API-KEY>"
}
}
}
}uv run src/mcp_lemonsqueezy/server.py{
"tool": "get_user",
"arguments": {}
}
{
"tool": "list_stores",
"arguments": {}
}
{
"tool": "get_store",
"arguments": {
"store_id": "164870"
}
}
The server provides clear error messages for common scenarios:
401 Unauthorized: Missing or invalid API key
422 Unprocessable Entity: Invalid fields like missing variant/store ID
400 Bad Request: Invalid JSON API structure
Run the MCP Inspector for interactive testing:
npx @modelcontextprotocol/inspector uv run --with fastmcp /ABSOLUTE/PATH/TO/PARENT/FOLDER/src/mcp_lemonsqueezy/server.pyUpdate dependencies:
uv compile pyproject.tomlBuild package:
uv buildWe welcome contributions! Please see our Contributing Guidelines for details.
This project is licensed under the MIT License - see the LICENSE file for details.
Create a Lemon Squeezy checkout session with full custom configuration. Args: data: The checkout data (see LemonSqueezy API docs)
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action of creation without disclosing behavioral traits such as side effects, authentication needs, or success/failure outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two lines including an Args section. The first sentence efficiently conveys the tool's purpose, though it could be slightly more informative without adding bulk.
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 tool with a single nested object parameter and no output schema, the description lacks completeness. It does not explain what constitutes valid 'data', what the response contains, or any behavioral context, making it insufficient for correct invocation.
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 single parameter 'data' is described only as 'checkout data (see LemonSqueezy API docs)', adding minimal meaning. With 0% schema description coverage, the description fails to compensate by explaining the required structure or format.
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 creates a Lemon Squeezy checkout session with full custom configuration, specifying the verb and resource. It distinguishes from sibling tools like create_webhook and various read operations.
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, nor any exclusions or prerequisites. The description does not mention context or conditions for creating a checkout session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a webhook URL for a specific store and events. Args: webhook_data: The webhook data (see LemonSqueezy API docs)
| Name | Required | Description | Default |
|---|---|---|---|
| webhook_data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the basic function but omits critical details like idempotency, side effects, authorization, or rate limits. The parameter 'webhook_data' is left entirely to external docs.
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 short (two lines) but includes 'Args:' which adds minor structure. It could be more concise by integrating the parameter info into the main sentence. However, the brevity is acceptable, though underspecified.
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 a complex parameter (object with additionalProperties), no output schema, and no annotations, the description is severely incomplete. It fails to explain how to structure the webhook_data, what events are available, or what the response looks like.
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 0%, yet the description adds no meaningful information about the 'webhook_data' parameter. It merely repeats 'webhook data' and defers to external docs, failing to compensate for the schema's lack of description.
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 (Register) and the resource (webhook URL for a specific store and events). It distinguishes from sibling tools like list_webhooks (listing) and create_checkout (different resource).
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. The description references 'see LemonSqueezy API docs' but does not provide concrete usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a customer by ID. Args: customer_id: The ID of the customer
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'Get a customer', implying a read operation, but does not mention any other behavioral traits such as authentication requirements, rate limits, 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 very short with two sentences, avoiding fluff. However, it is arguably too terse and could include more useful context without being verbose. The structure is clear but sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description covers the basic purpose but fails to mention what the return value contains (e.g., customer object fields). No output schema is provided, so the description should compensate.
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?
Although the input schema has only one parameter with 0% description coverage, the description adds minimal value by restating 'The ID of the customer', which essentially duplicates the parameter name. It does not provide format or source of the ID, nor any additional context.
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 'Get a customer by ID', which is a specific verb+resource combination. It distinguishes itself from the sibling 'list_customers' which retrieves multiple customers.
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 customer ID is known, but it does not explicitly provide guidance on when to use this tool versus alternatives like 'list_customers' or when not to use it. Lacks any 'when to use' or 'when not to use' instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a license key by ID. Args: license_key_id: The ID of the license key
| Name | Required | Description | Default |
|---|---|---|---|
| license_key_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only says 'get' without clarifying behavior on missing keys, authorization requirements, 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 brief, but it lacks useful details that could be included without becoming verbose. It is not optimally front-loaded with critical 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?
For a simple get tool with one parameter and no output schema, the description should at least hint at the return value (e.g., a license key object). It is too sparse.
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 description restates the parameter name as 'The ID of the license key,' adding no semantic value beyond the schema. Schema description coverage is 0%, and the description does not compensate.
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 gets a license key by ID, specifying the verb and resource. However, it does not differentiate from sibling tools like list_license_keys, but the purpose 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?
No guidance on when to use this tool versus alternatives such as list_license_keys. No context on prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an order by ID. Args: order_id: The ID of the order
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes a simple read operation ('Get an order'), which is fine, but does not specify error cases (e.g., order not found), authentication needs, or performance implications.
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 no unnecessary words. It uses a clear 'Args' format to describe the parameter, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one required parameter and no output schema, the description is adequate. However, it lacks information about the return value (e.g., order object or null) and error handling, which could 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?
There is only one parameter (order_id) with 0% schema description coverage. The description provides a brief explanation ('The ID of the order'), which adds meaningful context beyond the parameter name and title in the schema. This is sufficient for a single simple 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 an order by ID, using the verb 'Get' and resource 'order'. It distinguishes from siblings like list_orders (which returns multiple orders) and other get tools for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_orders or search tools. It does not mention prerequisites or scenarios where one would prefer this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific product by ID. Args: product_id: The ID of the product
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention side effects, auth requirements, or rate limits. Being a simple get operation, it could at least state it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary information, efficiently conveying the purpose and parameter.
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 ID lookup tool, but lacks information about the return value structure, which is not provided via 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?
The description adds a brief explanation for the single parameter, but schema coverage is 0%, so it adds minimal value. Could specify expected format of 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?
The description clearly states it retrieves a product by ID, but does not differentiate from sibling tools like list_products or get_product_variants.
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 list_products for multiple products or get_product_variants for variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all variants for a given product ID. Args: product_id: The ID of the product to fetch variants for
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It only states that variants are fetched, without disclosing whether it is read-only, requires auth, returns paginated results, or defines what 'variants' entails. Minimal behavioral insight.
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?
Exceptionally concise with a single sentence stating the purpose and a brief args section. No wasted words, front-loaded with the core verb 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?
Given the simplicity of the tool (single parameter, no output schema), the description is still incomplete: it does not describe the return format (e.g., list of variant objects) or any potential limits/pagination. An agent would lack critical output 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 0%, and the description merely repeats the parameter name and a tautological explanation ('The ID of the product to fetch variants for'). It adds no semantic detail beyond what the schema title already implies.
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 'variants for a given product ID', distinguishing it from sibling tools like get_product (which gets the product itself) and list_products (which lists all products). However, it does not mention any scope or filtering capabilities beyond the product ID.
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_product' or 'list_products'. The description does not provide when-not or alternative contexts, leaving the agent to infer usage from context signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific store. Args: store_id: The ID of the store
| Name | Required | Description | Default |
|---|---|---|---|
| store_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only states the action without mentioning read-only nature, authentication requirements, error handling, or response format.
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 short (two lines) but lacks detail; it is underspecified rather than concise. Every sentence adds minimal value, and the structure is adequate 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 no output schema and a single parameter, the description fails to explain what details are returned, how errors are handled, or any prerequisites. It is incomplete for effective agent 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 parameter description 'store_id: The ID of the store' merely restates the parameter name and type from the schema. With 0% schema description coverage, the description adds no meaningful semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get details of a specific store,' which is a clear verb+resource action. It effectively distinguishes from the sibling tool 'list_stores' which retrieves all stores.
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: this tool is for a specific store given a store ID. However, no explicit when-to-use or when-not-to-use guidance is provided, nor are alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a subscription by ID. Args: subscription_id: The ID of the subscription
| Name | Required | Description | Default |
|---|---|---|---|
| subscription_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Get a subscription,' omitting whether it's read-only, requires authentication, or what happens for invalid IDs.
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: two short sentences with no redundant information. Purpose is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking output schema and annotations, the description adequately describes the action for a simple get-by-ID tool. However, it does not mention the return value or error behavior, leaving 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 description coverage is 0%, but the description adds 'The ID of the subscription' for the one parameter, clarifying its purpose minimally. This is adequate for a simple ID 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 states 'Get a subscription by ID,' which clearly specifies the verb (Get) and resource (subscription) and differentiates it from list_subscriptions and other get_* 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 guidance on when to use this tool versus alternatives like list_subscriptions for multiple subscriptions. No context about prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current authenticated Lemon Squeezy user.
| 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 must disclose behavior. It only says 'get', implying a read operation, but does not specify authentication requirements, return value structure, or whether the user is already authenticated. Basic behavioral traits are missing.
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 no superfluous information. It is front-loaded with the 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?
Given no output schema and no annotations, the description should explain what is returned (e.g., user object fields). It only states the action and resource, leaving the agent without enough detail on the expected response.
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 0 parameters with 100% coverage. Baseline for 0 params is 4. The description adds value by specifying the user is the 'current authenticated' one, which clarifies the scope beyond the empty 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 retrieves the current authenticated Lemon Squeezy user. The verb 'get' and resource 'current authenticated user' are specific and distinguish from siblings like get_customer or list_customers.
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 get_customer or get_subscription. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all customers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose any behavioral traits such as read-only status, pagination, rate limits, or whether it returns full or partial data. The single sentence omits critical 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?
The description is a single, efficient sentence with no unnecessary words. It is front-loaded and contains no waste, though it could be expanded slightly for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides minimal context. It does not describe the return format, pagination, or any prerequisites. A zero-parameter tool still benefits from describing the output shape or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. However, the description adds no meaning beyond the empty schema—no indication of output structure or optional filters. A brief note like 'Returns an array of customer objects' would add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all customers' clearly states a specific verb and resource. It distinguishes from sibling tools like get_customer (singular) and list_orders, though it could be more precise about the scope (e.g., all customers in the store).
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_customer or search functionality. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all license keys.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 only states 'List all license keys' without revealing details about output format, pagination, rate limits, or whether it returns a full list or summaries.
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 information. It is front-loaded and concise, earning its place without waste.
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's simplicity (no params, no output schema), the description is adequate but lacks details on pagination or default behavior. It is minimally viable but could be more complete for an agent expecting robust guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description adds no parameter-specific meaning, but none is needed given the simplicity. A baseline score of 4 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 'List all license keys' uses a specific verb and resource, clearly indicating the tool's function. It distinguishes itself from sibling tools like get_license_key and other list_* tools by its focus on license keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_license_key or other list tools. The description is purely declarative without context on appropriate scenarios 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 orders.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral burden. It only says 'list all orders', implying a read operation but not explicitly stating side effects, performance, or 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?
Very concise (two words), front-loaded, but lacks structure or additional context. Could be longer but still acceptable.
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 zero-parameter tool, the description is adequate but missing details like return format, pagination, or ordering. With no output schema, these gaps are notable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%, so description adds no parameter info but also does not need to. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'orders', making the purpose clear. It distinguishes from sibling list_* tools by specifying the resource.
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 vs alternatives like get_order or other list tools. No context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all products.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits such as authentication needs, rate limits, or side effects. The read-only nature is only inferred.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Extremely concise and front-loaded with 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?
Adequate for a simple list operation with no parameters, but lacks mention of pagination, ordering, or any constraints. Could be improved with minimal 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?
No parameters exist, so the description adds no additional meaning. With 100% schema coverage (none needed), baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all products' clearly states the verb (list) and resource (products), distinguishing it from sibling tools like get_product. However, it does not specify scope like pagination or store 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 guidance on when to use this tool versus alternatives like get_product or list_orders. Usage context is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Lemon Squeezy stores.
| 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 must carry the burden. 'List' implies read-only, but the description does not explicitly state read-only behavior or any other traits like side effects. No contradictions.
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, straightforward sentence with no wasted words. Front-loaded with verb 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?
For a parameterless list tool, the description is minimally adequate. However, it could mention that it returns all stores or that it is a read-only operation, but given simplicity, a score of 3 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 schema coverage is 100%. The description adds no parameter info, which is acceptable given zero parameters. Baseline at 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Lemon Squeezy stores' clearly indicates the verb 'List' and the resource 'stores'. It distinguishes from sibling 'get_store' which would retrieve a single store.
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 is implicit in its purpose, it does not explicitly state when to use this tool over alternatives like 'get_store' for a specific store. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all subscriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose whether the operation is read-only, any limitations, or pagination 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?
Very concise, no wasted words. However, could benefit from slight elaboration on the scope of 'all'.
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 zero-parameter list tool, but missing details on output format or any constraints, leaving room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. The description correctly implies the tool lists all subscriptions without filters.
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 lists subscriptions, using a specific verb and resource. However, no differentiation from sibling tools like list_orders or list_products.
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. The description merely states the action without 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 webhooks. Optionally filter by store ID. Args: store_id: If provided, only webhooks for this store will be returned
| Name | Required | Description | Default |
|---|---|---|---|
| store_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'List all webhooks,' implying a read-only operation without side effects. It does not mention auth requirements, rate limits, or return format, but for a simple list tool, this is minimally adequate.
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 that front-load the core purpose. Every word adds value, and there is no extraneous 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?
Given the simplicity of the tool (one optional parameter, no output schema), the description is nearly complete. However, it lacks information about return type, pagination, or error handling, which would be expected for a list operation.
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 0%, but the description adds meaningful semantics for the only parameter 'store_id' by explaining that filtering is optional and what it does. This compensates for the lack of schema descriptions.
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 'List all webhooks' with the option to filter by store ID, providing a specific verb and resource. It distinguishes from sibling tools like 'list_customers' or 'list_orders' by explicitly naming webhooks.
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 usage hint for the optional store_id parameter ('If provided, only webhooks for this store will be returned'), but does not offer any guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct entity-action pair (e.g., get vs list for customers, orders, etc.), and there is no overlap. The only specific variant is get_product_variants, which is clearly a sub-resource.
All tool names follow a consistent verb_noun pattern in snake_case (get_, list_, create_), with no deviations or mixed conventions.
17 tools cover the main entities of the Lemon Squeezy platform (customers, orders, subscriptions, products, stores, webhooks, license keys, checkout) without being excessive. The scope is well-matched to a commerce API.
The tool set is heavily read-oriented with only two create operations (checkout and webhook). Missing update, delete, and other mutation operations for most entities (e.g., customers, products, stores) creates significant gaps that would hinder agents needing full lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Lemon Squeezy — stores, products, orders, subscriptions, license keys.
Create and manage checkout pages, event ticketing, forms, customers, payments and subscriptions.
Read products, sales, subscribers and offer codes; verify, enable and disable product licenses.
Stripe payments for AI agents. Create links, verify, manage customers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/atharvagupta2003/mcp-lemonsqueezy'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
