hotmart-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources and actions in the Hotmart domain, such as subscriptions, commissions, sales, products, and users. There is no overlap or ambiguity between tools like 'cancel_subscription' and 'list_subscriptions', or 'get_sale' and 'list_sales', making it easy for an agent to select the correct tool.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as 'cancel_subscription', 'get_commission', and 'list_products'. This uniformity enhances readability and predictability, with no deviations in naming conventions across the toolset.
Tool Count5/5
With 8 tools, the server is well-scoped for managing a Hotmart platform, covering key operations like sales, subscriptions, products, users, and refunds. Each tool serves a specific and necessary function without being overly sparse or bloated, fitting typical expectations for such a domain.
Completeness4/5
The toolset provides strong coverage for core Hotmart workflows, including CRUD-like operations for sales, subscriptions, products, and users, as well as actions like refunds and cancellations. A minor gap exists in update operations (e.g., updating a subscription or user details), but agents can likely work around this with the available tools.
Average 2.3/5 across 8 of 8 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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 but fails completely. It doesn't indicate whether this is a read-only operation, what permissions might be required, whether it's paginated (though parameters suggest it might be), what the response format looks like, or any rate limits. The description provides zero behavioral context beyond the basic verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this is under-specification rather than effective conciseness. The description fails to provide necessary context and doesn't front-load important information. Every word should earn its place, but here the words don't provide enough value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what subscriptions are being listed, what the response contains, how pagination works, or any behavioral characteristics. The description fails to compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all three parameters (page, limit, status) having descriptions in the schema. The tool description adds no parameter information beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List subscriptions' is a tautology that merely restates the tool name without adding any meaningful context. It doesn't specify what kind of subscriptions (e.g., user subscriptions, product subscriptions, service subscriptions) or provide any distinguishing characteristics from sibling tools like list_products or list_sales.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, appropriate contexts, or differentiation from sibling tools like list_products or list_sales that might also list subscription-related data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List users' reveals nothing about whether this is a read-only operation, what permissions might be required, whether it's paginated (though parameters suggest it is), what format the results take, or any rate limits. For a tool with zero annotation coverage, this minimal description provides essentially no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two words, which could be considered appropriately sized for such a simple concept. However, this brevity comes at the cost of being under-specified rather than truly efficient. There's no wasted language, but also no helpful information beyond the absolute minimum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description should provide more complete context about this listing operation. A simple 'List users' doesn't explain what information is returned about users, whether there are filtering options, how results are structured, or any limitations. For a tool with pagination parameters and multiple sibling list operations, this description leaves too many contextual questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents both parameters (page and limit) with their types, defaults, and basic descriptions. The tool description adds no additional parameter information beyond what's in the schema. Since schema coverage is complete, the baseline score of 3 is appropriate - the description doesn't compensate for schema gaps because there are none, but it also doesn't add value beyond the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List users' is essentially a tautology that restates the tool name with minimal additional information. It specifies the verb 'list' and resource 'users', but lacks any distinguishing details about scope, format, or context that would differentiate it from generic list operations. Compared to sibling tools like 'list_products' or 'list_sales', this description provides no indication of what makes listing users unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or relationships to sibling tools. With multiple list operations available (list_users, list_products, list_sales, list_subscriptions), the description fails to help an agent understand when user listing is appropriate versus other listing operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to deliver. It doesn't indicate whether this is a read-only operation (likely, but not stated), whether it requires authentication, what the return format looks like, if there are rate limits, or if it's paginated (though parameters suggest pagination). The description adds no behavioral context beyond the minimal verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words: 'Get commission summary'. It's front-loaded with the core action and resource, with no wasted words or unnecessary elaboration. While it's under-specified, it earns full marks for conciseness as every word contributes directly to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what a 'commission summary' contains, how results are structured, or any behavioral traits. For a tool that presumably returns financial data, more context about the return format and usage would be needed for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('page' and 'limit') documented in the schema as pagination controls. The description doesn't add any meaning beyond what the schema provides—it doesn't explain how pagination works, default values, or parameter interactions. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get commission summary' is a tautology that essentially restates the tool name 'get_commission'. It doesn't specify what kind of commission (sales commission, affiliate commission, etc.) or what 'summary' entails (aggregated totals, detailed breakdown, etc.). While it includes a verb ('Get') and resource ('commission summary'), it lacks the specificity needed to distinguish it from potential sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or differentiate it from sibling tools like 'get_sale', 'list_sales', or 'list_users' that might relate to commission data. There's no indication of when this tool is appropriate or when other tools should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Get sale details', implying a read-only operation, but does not specify permissions, rate limits, error handling, or what 'details' entail. This leaves significant gaps in understanding the tool's behavior beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 'Get sale details', but it is under-specified rather than efficiently informative. It lacks front-loading of critical information, making it too brief to be helpful, though it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that retrieves details. It does not explain what 'details' include, potential return values, or error cases. For a tool with one required parameter and no structured output information, more context is needed to be fully usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'transaction_id' documented as 'Transaction ID'. The description adds no additional meaning beyond this, such as format examples or constraints. Since the schema handles parameter documentation adequately, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get sale details' restates the tool name 'get_sale' with minimal elaboration, making it tautological. It specifies the verb 'Get' and resource 'sale details', but lacks specificity about what details are retrieved or how it differs from sibling tools like 'list_sales', resulting in a vague purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_sales' or other siblings. The description does not mention prerequisites, context, or exclusions, leaving the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to deliver. 'List products' doesn't indicate whether this is a read-only operation, whether it requires authentication, what the output format might be, or any rate limits. For a tool with zero annotation coverage, this minimal description leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two words. While this represents under-specification rather than ideal conciseness, according to the scoring framework, 'Process' received a 2 for being under-specified, whereas this is even more minimal. However, every word earns its place - there's no wasted language or unnecessary elaboration in the description itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity (2 parameters, no output schema, no annotations), the description is incomplete. While the schema covers parameters adequately, the description fails to provide necessary context about what 'listing products' entails, how results are structured, or when this tool should be used versus alternatives. For even a simple listing tool, more guidance would be helpful for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('page' and 'limit') having descriptions in the schema. The tool description adds no parameter information beyond what's already documented in the structured schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List products' is a tautology that merely restates the tool name without adding specificity. It doesn't distinguish this tool from sibling tools like 'list_sales' or 'list_subscriptions' beyond the resource name. While it identifies the resource (products), it lacks a specific verb or scope that would clarify what kind of listing operation this performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of context, prerequisites, or comparison with sibling tools like 'list_sales' or 'list_subscriptions'. The agent receives no help in determining when this specific listing operation is appropriate versus other listing tools available on the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Cancel a subscription' implies a destructive mutation, but the description doesn't specify whether this is reversible, what permissions are required, whether it triggers notifications or refunds, or what happens to associated data. For a mutation tool with zero annotation coverage, this leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by directly conveying the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations, no output schema, and a description that only states the basic purpose, the description is incomplete. It doesn't address behavioral aspects like side effects, permissions, or return values, nor does it provide usage context relative to sibling tools. For a tool that performs a potentially significant action like subscription cancellation, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('subscriber_code' and 'send_email') with their types and descriptions. The description adds no additional meaning about these parameters beyond what the schema provides, such as explaining what a subscriber code represents or the implications of sending email. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cancel a subscription' clearly states the action (cancel) and resource (subscription), but it's quite basic and doesn't differentiate from potential sibling tools. It doesn't specify what type of subscription or cancellation process is involved, making it somewhat vague despite having a clear verb+resource structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'list_subscriptions' and 'refund_purchase' available, there's no indication of whether this tool should be used for active vs. pending subscriptions, or how it relates to refund operations. No context about prerequisites or exclusions is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List sales history' implies a read-only operation, but it doesn't specify whether this is a safe query, what permissions might be required, if there are rate limits, or how results are returned (e.g., paginated format). The description lacks critical behavioral details needed for reliable tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'List sales history' is extremely concise at three words, with zero wasted language. It front-loads the core action ('List') and resource ('sales history'), making it easy to parse quickly. This is an example of efficient communication that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a list operation with filtering and pagination), no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the return format, error conditions, or behavioral traits like pagination handling, leaving gaps that could hinder the agent's ability to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with parameters 'page', 'limit', and 'status' clearly documented in the schema. The description 'List sales history' adds no additional meaning about these parameters beyond what the schema provides, such as explaining 'status' values or usage context. This meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List sales history' clearly states the verb ('List') and resource ('sales history'), providing a basic understanding of what the tool does. However, it doesn't distinguish this tool from potential siblings like 'get_sale' (which might retrieve a single sale) or 'list_products' (which lists different resources), leaving room for ambiguity about its specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'get_sale' for retrieving a single sale or 'list_products' for different resources, nor does it provide context such as prerequisites or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'refund' implies a financial mutation, it doesn't specify whether this is reversible, requires specific permissions, affects user accounts, or has rate limits. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core purpose without any wasted language. Every word earns its place by clearly communicating the tool's function in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It lacks information about behavioral traits, return values, error conditions, and how it differs from sibling tools, leaving too many contextual gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'transaction_id' documented in the schema. The description adds no additional parameter details beyond what the schema provides, so it meets the baseline for adequate but unenhanced parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('refund') and resource ('a purchase'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'cancel_subscription' or 'get_sale' that might involve similar financial operations, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'cancel_subscription' or 'get_sale', nor does it mention prerequisites such as transaction status or permissions. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hotmart-mcp MCP server](https://glama.ai/mcp/servers/theYahia/hotmart-mcp/badges/card.svg)](https://glama.ai/mcp/servers/theYahia/hotmart-mcp)

Score Badge

Copy to your README.md:

[![hotmart-mcp MCP server](https://glama.ai/mcp/servers/theYahia/hotmart-mcp/badges/score.svg)](https://glama.ai/mcp/servers/theYahia/hotmart-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/theYahia/hotmart-mcp'

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