@deonpay/mcp-server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., create, get, list, update) for specific entities like products, links, subscriptions, customers, and transactions. Even similar-sounding tools (e.g., get_subscription vs get_customer_subscription) are clearly differentiated by scope (plan vs individual subscriber).
Naming Consistency5/5
All tools follow a consistent `deonpay_<verb>_<resource>` pattern in snake_case (e.g., deonpay_create_product, deonpay_list_transactions). There are no deviations, making the convention predictable and easy to navigate.
Tool Count5/5
20 tools cover the key operations for a payment processing domain (CRUD for products, links, subscriptions, customers, transactions, plus metrics and checkout). The count is well-scoped—neither excessive nor insufficient—for the apparent purpose.
Completeness4/5
The tool surface covers core workflows (create/read/update/list for products and links, list/read for customers and transactions, subscription management). Minor gaps exist: lack of update_subscription (plans) and cancel customer subscription. Otherwise, the set is thorough.
Average 4.3/5 across 20 of 20 tools scored.
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 is failing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the response contains `url` and `session_id`, mentions expiry (30 min default, override with expires_in), and notes amounts are in centavos. With no annotations, it carries the full burden but omits details like side effects, required permissions, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (6 sentences) and well-structured, front-loading the key purpose and usage. Every sentence provides distinct value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, no output schema), the description covers the core purpose, response, and key constraints. However, it lacks details on numerous optional parameters and does not fully distinguish the tool from siblings like create_link or create_subscription.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds limited value beyond the schema: it mentions centavos for amounts, mode default, and expiry range. With 18 parameters and ~50% schema description coverage, many optional fields (customer details, metadata, customization, etc.) are left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an ephemeral checkout session for one-time payments (Stripe-style) and specifies the e-commerce use case, distinguishing it from siblings like subscription or link creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (e-commerce flow) and mode selection guidance ('redirect' default, 'embedded'/'modal' only if supported). However, it lacks explicit exclusions or comparisons to sibling tools like deonpay_create_link or deonpay_create_subscription.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses partial update behavior ('Only fields you send are changed') and HTTP method (PATCH). However, lacks details on idempotency, rate limits, authorization needs, or error conditions.
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?
Two sentences with no redundant words. Purpose and key behavior are front-loaded. Every sentence adds value.
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?
With 11 parameters, no output schema, and no annotations, the description is too brief. Missing return format, error handling, pagination hints, and nuance about nested metadata field. Incomplete for complex tool.
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 only 18% (2 of 11 parameters described). Description compensates by clarifying the identifier resolution and partial update semantics, but does not explain parameters like metadata, stock_tracking, or currency beyond what schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb and resource: 'Update an existing product (resolved by UUID or SKU).' Differentiates from sibling tools like deonpay_create_product and deonpay_get_product by specifying update behavior and identifier type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'price adjustments, renaming, toggling is_active, updating stock_quantity, or swapping the image_url.' Lacks explicit when-not-to-use or alternatives, but context is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes search, filtering, sorting, and return fields. However, lacks mention of pagination behavior (page/limit) and any side effects or auth requirements. For a list endpoint, pagination metadata (total count, next page) is important but omitted.
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?
Three sentences: purpose, usage guidance, capabilities. Every sentence adds value, no fluff. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description includes return fields (id, name, unit_amount in centavos, etc.), which is good. However, missing pagination structure (array vs object, metadata) and error handling. Still sufficiently complete for most use cases.
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 baseline is 3. The description summarizes parameters (search, is_active, sort) but adds no new meaning beyond the schema. No parameter-specific additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists products in the merchant catalog, using specific verb 'list' and resource 'products'. Provides example user queries and distinguishes from sibling tools like deonpay_get_product (single) and deonpay_create_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete examples of when to use ('user asks what products do I have') but does not explicitly state when not to use or name alternative tools. Implicit differentiation from single-product retrieval is clear but could be more direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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. It discloses that the tool returns paginated transactions with customer info, card brand/last_four, amount in centavos, status, and that the link can be referenced by UUID or short_code. It implies read-only behavior and does not contradict any annotations.
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 four sentences long, all relevant and front-loaded with the core purpose. It is efficient but could be slightly more streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the key return fields (customer info, card, amount, status) and pagination behavior. It is complete enough for an agent to understand what to expect, though it does not detail the exact schema of the response.
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 coverage is 100%, so baseline is 3. The description adds that the 'id' parameter can be a UUID or short_code (matching schema) and mentions paginated results, but does not add significant meaning beyond the schema descriptions for page and limit. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all transactions associated with a specific payment link' and provides concrete example queries like 'who paid for this link' and 'how much did link X collect'. It distinguishes itself from siblings such as deonpay_list_transactions (general list) and deonpay_get_transaction (single transaction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('when the user asks who paid for this link...') and implicitly excludes use cases for listing all transactions or getting a single transaction. However, it does not explicitly mention when not to use it or list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: partial update, merge behavior for customization, and type change limitation. It does not cover idempotency, side effects, or auth, but provides useful context beyond a generic 'update'.
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 a few concise sentences that each add value: identification, partial update, common uses, customization merge, and type limitation. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, low schema coverage, no output schema, and no annotations, the description should cover more. It explains update semantics and merge behavior but omits response format, error handling, and parameter formatting details. Adequate but incomplete.
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 coverage is low (29%), and description adds meaning by explaining partial update and customization merge. It gives an example for 'status' and describes 'customization' merging. However, many parameters remain undocumented, partially compensating but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies 'Update an existing payment link' with the verb and resource, and lists common uses like pausing, changing amount, extending expiration, or renaming. It distinguishes from sibling tools such as create_link and get_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Guidance includes 'Only send the fields you want to change — others are preserved' and explains customization merging. It notes that type cannot typically be changed after payments exist. However, it lacks explicit 'when not to use' or comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses key behavioral traits: unit_amount is in centavos with a minimum, SKU must be unique, and stock_tracking requires stock_quantity. These constraints are important for correct usage. It does not cover error handling or response format, but the core behaviors are well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences), front-loads the main purpose, then provides usage context, and ends with key parameter constraints. Every sentence adds value, no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and no output schema, the description covers the primary purpose, usage context, and important constraints. It lacks details on authentication, error behavior, or return value, but it is sufficient for an agent to select and invoke the tool correctly in most cases.
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 already has a high description coverage (70%) with detailed comments on unit_amount (centavos, minimum) and stock_quantity (required when stock_tracking is true). The description repeats these constraints without adding new semantic information, so the added value is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new product in the catalog' with a specific verb and resource. It also provides example user phrases like 'add a product called X for $Y', which makes the purpose unmistakable. The tool name and context distinguish it from sibling create tools (e.g., for checkout sessions or links).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when the user says...' or 'wants to register inventory items', providing clear guidance on when to invoke. It does not explicitly mention when not to use, but the specificity of the usage scenarios sufficiently differentiates from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key output elements: denormalized plan, last 20 recurring charges with status, charge_type, attempt_number, error_message, and timestamps, plus cancellation flags. It does not detail error behavior or rate limits, but the provided information is sufficient for the tool's read-only nature.
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 two sentences, front-loaded with the core purpose, then adding valuable details and a usage example. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema, no annotations), the description provides a solid overview of the response content. It could mention what happens on missing UUID, but overall it covers the essential context 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 covers the single parameter 'id' with full description (UUID). The description adds context by mentioning 'by UUID' but does not elaborate beyond what the schema already provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a single customer subscription by UUID, specifying what is included (plan, last 20 charges, cancellation flags). It distinguishes from siblings like 'deonpay_get_subscription' by emphasizing 'customer subscription' and denormalized plan details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case: investigating a subscriber's history or a failed charge, with an example question ('why did Juan's subscription go past_due?'). It guides the agent on when to use this tool, though it does not explicitly exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses return structure (fields like id, short_code, amount in centavos, status, type, url, stats) and notes that amounts are in centavos. It implies a read-only operation but does not explicitly state it. The description adds value beyond the schema.
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 compact (four sentences) with the main action upfront ('List payment links for the authenticated merchant'), followed by usage examples and filter details. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description compensates for the missing output schema by listing return fields and noting the centavos unit. It covers pagination implicitly via 'paginated list' but does not mention sorting order or response metadata. Sufficient for a typical list endpoint.
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 all 7 parameters with clear descriptions. The tool description does not add new parameter-level meaning; it merely summarizes filter options (status, type, search, date range) which are already in the schema. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists payment links for the authenticated merchant, provides example user requests, and distinguishes from siblings like deonpay_get_link (single retrieval) and deonpay_create_link (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete use cases ('show me my payment links', 'what links did I create last week') and lists supported filters, effectively guiding when to use the tool. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions return content (paginated results with fields) and amounts in centavos, but lacks information on idempotency, authorization needs, rate limits, or any side effects. The read-only nature is implied but not stated.
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 a single paragraph that front-loads the purpose and examples, then details filters and output. It could be slightly more concise, but every sentence contributes information. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 optional parameters and no output schema, the description covers most aspects: it lists all filter types, explains return fields, and notes pagination. Missing details include pagination iteration (e.g., next page hints) and exact response structure, but overall it's fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 69%, and the description adds significant value: it explains filter behavior (partial match for email, exact for merchant_reference, enum values for status/source_type/card_brand), date format (ISO 8601), and amount unit (centavos). This compensates for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('List transactions') and includes example queries that clarify scope. It differentiates itself from siblings like deonpay_get_transaction (single) and deonpay_list_link_transactions (link-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage contexts via example queries and lists many filter options. However, it does not state when not to use this tool (e.g., for single transaction retrieval) or mention alternatives, though the sibling context implicitly fills that gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: amounts in centavos, type defaulting to 'single', optional MSI, expiry, customization, and the response containing the shareable URL. It does not mention side effects, auth requirements, or error scenarios, but the provided information is sufficient for safe invocation.
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 a single paragraph that efficiently packs essential information: purpose, usage hints, centavos note, amount modes, type default, optional fields, and response content. It is front-loaded with the purpose and maintains clarity without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters, nested objects), the description covers key operational context: centavos, amount modes, type default, and the response URL. While it could include examples or warn about missing required fields, it provides enough completeness 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by explaining the dual amount modes (fixed vs line_items) and the centavos requirement. It also highlights the type default and optional features. The schema already describes most parameters (88% coverage), so the description provides useful high-level context without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear statement 'Create a new payment link' and provides specific example intents (e.g., 'create a link for $X for product Y'). It distinguishes itself from sibling tools like deonpay_create_checkout_session and deonpay_create_subscription by focusing on payment links rather than checkout sessions or subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit user intents and explains the critical centavos requirement. It also clarifies the two ways to specify the amount (fixed amount or line_items). However, it does not explicitly state when to prefer this tool over alternatives like create_checkout_session or update_link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the resolution logic (UUID vs SKU) and lists all return fields. This provides good behavioral context beyond the schema.
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?
Two concise sentences with no wasted words. The most critical information (purpose and parameter behavior) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description enumerates all returned fields. For a simple get-by-id tool with one parameter, the description covers all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'id' parameter. The description adds extra semantic value by explaining the UUID/SKU resolution and listing the returned fields, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches a single product by UUID or SKU, which is a specific verb and resource. Distinguishes from sibling tools like list_products that return multiple products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives. While the purpose is clear, it does not mention that for non-identifier-based queries one should use list_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the required fields, amount format (centavos, min 100), trial behavior (charges $10 MXN on first day), error condition (ondemand_key_missing), and the effect of optional flags on customer self-service. While it doesn't mention idempotency or rate limits, the coverage is solid for a create 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 a single, well-structured paragraph. It front-loads the purpose and example, then lists required fields, followed by a critical production note, trial behavior, and optional flags. Every sentence earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description could hint at the return value (likely the created plan object), but it doesn't. However, it covers prerequisites, an error condition, and key parameter behaviors. For a tool with 16 parameters, the description provides sufficient context to use the tool correctly, though a note on what is returned would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (81%), so the baseline is 3. The description adds value by explaining the centavos unit for amount (not just 'integer'), the min amount in MXN, the special trial_days behavior (card-validation charge), and the collective effect of optional flags. This goes beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new subscription PLAN (template)'), and includes an example use case ('create a $299 monthly plan called Premium'). It distinguishes itself from sibling tools like deonpay_create_checkout_session by focusing on recurring charge template creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage context ('when the user wants to set up a recurring charge') and important prerequisites (merchant must have On-Demand NetPay key). It also explains the behavior of trial_days and optional flags. However, it doesn't specify when not to use the tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full transparency burden. It details what extra fields are returned beyond the list view (NetPay timeline, charge_id, metadata, refund details, IP/user-agent). However, it does not mention error handling or potential side effects, which are minimal for a read operation.
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?
Two sentences, front-loaded with the core action, followed by a concise list of additional return data and usage scenarios. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no output schema, and no annotations, the description provides sufficient context about what the tool returns and when to use it. Minor gaps: no mention of error responses or pagination, but not critical for this focused read operation.
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?
There is a single parameter 'id' with UUID format and 100% schema description coverage ('Transaction UUID'). The description reinforces its purpose but adds no new semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch the full detail of a single transaction by UUID' with a specific verb and resource. It distinguishes from list views by listing additional fields, making its purpose unambiguous and differentiating it from sibling tools like deonpay_list_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage scenarios provided: 'Use this when debugging a failure, building a refund decision, or when the user asks what happened with transaction X.' This gives clear guidance on when to invoke, implicitly excluding use cases better served by list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It discloses the list operation (read-only implied), filter behavior for each parameter, and the environment override quirk (silently ignored if mismatch). Missing explicit read-only statement but still informative.
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?
Single lean paragraph, front-loaded with purpose and use cases, then detailed filter options and return fields. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description covers key return fields (plan, charges, period dates, etc.). Pagination parameters are in schema but not described in detail; otherwise complete for listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 83% schema coverage baseline, description adds significant meaning: explains subscription_id as plan filter, customer_email case-insensitivity, status enum values, environment override behavior, and return fields (plan sub-object, charges, etc.). Goes beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists per-customer subscriptions (not plans), provides specific use cases like 'who is currently subscribed to plan X', and distinguishes from sibling tools that list plans or single subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use the tool (answering questions about subscribers, trialing, etc.) and differentiates from plans. Lacks explicit 'when not to use' or alternatives but provides sufficient context for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the fields returned and notes that the environment parameter is silently ignored if mismatched. However, it does not mention read-only nature, authorization needs, or pagination behavior beyond schema.
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?
Two sentences plus a compact field list. Concise, front-loaded, and no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return fields. Parameter coverage is high, sibling tool is mentioned. Lacks only minor details like rate limits or pagination specifics.
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 80%, so baseline is 3. The description adds value by explaining 'centavos' for amount, but otherwise provides little beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists subscription PLANS (recurring templates), not individual subscribers, and distinguishes from the sibling tool deonpay_list_customer_subscriptions. It also provides example queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit example queries are given, and the description directs users to deonpay_list_customer_subscriptions for drilling into actual subscribers of a plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. Describes returned fields (line_items, customization, etc.) and enrichment with product data. Lacks error or auth details, but adequate for a read operation.
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?
Two sentences with no fluff: first states purpose, second gives usage guidance. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple fetch with one parameter and no output schema, the description covers purpose, usage, and return details comprehensively. Sibling list provides differentiation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter. Description adds value by specifying the parameter can be UUID or short_code and includes an example, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Fetch', the resource 'payment link', and identifiers 'UUID or short_code'. Distinguishes from siblings like list_links by focusing on a single link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use scenarios: referencing by name/short_code from a list or pasting a URL. Does not explicitly mention alternatives but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses key behavioral details: returns aggregated stats and limits to 10 recent recurring charges. Lacks mention of error behavior or required permissions, but adequate for a simple read operation.
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?
Two sentences, no fluff, front-loaded with the main action and key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description fully covers what the tool returns (stats and recent charges) and provides usage context via sibling reference. For a simple fetch with one parameter, no gaps.
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 coverage is 100% with clear description for 'id' parameter. Description repeats 'by UUID' but adds no new semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action ('Fetch') and resource ('single subscription plan by UUID'), and specifies included data (aggregated stats and recent 10 charges). Differentiates from sibling tools like deonpay_get_customer_subscription and deonpay_list_subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use ('when the user wants a quick health view of a specific plan') and provides a clear alternative for per-subscriber detail (deonpay_list_customer_subscriptions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description compensates by detailing what is returned (safe metadata for cards, active subscription statuses, last 20 transactions excluding certain charges) and the silent behavior of the environment parameter. It could mention authentication requirements, but overall transparent.
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?
Four sentences with a clear front-loaded purpose. Each sentence adds essential information without redundancy. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description thoroughly explains the return fields (basic info, saved_cards, subscriptions, last 20 transactions). It covers the tool's key behavior and constraints. Could mention transaction ordering or pagination, but sufficient for the parameter set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by noting automatic URL encoding for email and the environment parameter's behavior (silently ignored on mismatch). This enriches understanding beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a customer's full profile by email, listing specific data returned (saved_cards, subscriptions, transactions). It distinguishes itself from siblings like deonpay_list_customers or deonpay_get_customer_subscription by focusing on a complete profile retrieval via email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage examples ('show me everything about cliente@x.com' or 'what cards does this customer have on file'), and explains that email is URL-encoded automatically, reducing user effort. This gives clear guidance on when to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral disclosure burden. It explains that customers are defined as having at least one non-validation transaction, details sort options with meanings, lists returned fields, and describes the environment parameter's silent override behavior. This covers safety, scope, and return format comprehensively.
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 a single paragraph but achieves clarity without wasted words. It front-loads the core purpose and then details parameters. While a bulleted list could improve scannability, the current structure is acceptable and not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description lists all returned fields (email, name, phone, first_seen_at, etc.), covers pagination (page, limit), sorting, search, and environment override. For a list endpoint, this provides complete context without missing crucial details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining the search parameter covers email/name/phone, defining sort option semantics ('recent' = last transaction, 'revenue' = most spent, 'transactions' = most active), and clarifying environment override behavior. This enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists customers who have completed at least one non-validation transaction, distinguishing it from sibling tools like deonpay_get_customer (single customer) or deonpay_list_customer_subscriptions. The verb 'list' and resource 'customers' are clear, with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example questions that the tool can answer (e.g., 'who are my top customers', 'find customers with email containing X'), giving clear guidance on when to use it. However, it lacks explicit guidance on when not to use it or alternatives, though sibling names hint at other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly explains the return fields, including important nuances: subscriptions fields ignore `period`, mrr is always a 30-day run-rate, while revenue/transactions/churn_rate honor `period`. This goes beyond simple field listing.
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 well-structured: a clear purpose statement, concrete examples, then a detailed list of return fields with annotations. Every sentence adds value, and it's not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description enumerates all return categories with subfields and units. It covers edge cases like snapshot behavior. For a metrics tool, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description adds extra context about `period` affecting some fields and not others, which is valuable. For `environment`, it adds no further meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a curated set of business metrics for the merchant, with specific examples like 'how much have I sold this month'. This distinguishes it from sibling tools which focus on creating or retrieving individual entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this as the FIRST tool for high-level questions', providing clear when-to-use guidance. It does not explicitly mention when not to use or alternatives, but the context implies it's for overviews.
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:

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

Score Badge

Copy to your README.md:

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

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/hectortemich/deonpay-mcp-server'

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