btcpay-mcp
Server Quality Checklist
- Disambiguation5/5
Each tool targets a distinct BTCPay resource or operation (invoices vs. payment requests vs. pull payments are clearly differentiated). No functional overlap exists between the 21 tools, and descriptions clarify domain-specific terminology.
Naming Consistency5/5Strict adherence to verb_noun snake_case convention throughout (create_invoice, get_invoice, list_invoices). Pluralization is consistent (list_* for collections, get_* for single items), with no mixing of naming styles.
Tool Count4/5At 21 tools, this exceeds the typical ideal range but remains reasonable for a comprehensive payment processor API covering on-chain, Lightning, webhooks, and store management. Each tool serves a distinct purpose without redundancy.
Completeness4/5Core payment acceptance workflows are fully covered (invoice lifecycle, payment requests, webhooks, refunds). Minor gaps exist in resource management operations (missing update/delete for webhooks and payment requests, no create_payout for arbitrary sends).
Average 4/5 across 21 of 21 tools scored.
See the tool scores section below for per-tool breakdowns.
This repository includes a README.md file.
This repository includes a LICENSE file.
Latest release: v0.3.0
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.
- This server provides 21 tools. View schema
No known security issues or vulnerabilities reported.
Are you the author?
Add related servers to improve discoverability.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adequately describes return values (node alias, version, channel count, balances) but omits safety profile (read-only status), auth requirements, or caching behavior expected for financial node operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: purpose statement, Args documentation, and Returns documentation. Logical front-loaded structure where every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a low-complexity tool (1 optional parameter). Since output schema exists, the brief return value summary is sufficient; no critical gaps remain for invocation decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Excellent compensation for 0% schema coverage. Despite schema lacking descriptions, the text provides clear semantics for crypto_code (Crypto code), concrete examples ('BTC', 'BTCTest'), and default value, fully documenting the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Get) + resource (Lightning node info and balance) + scope (for the store). Effectively distinguishes from siblings like get_wallet_balance (wallet vs lightning) and list_lightning_channels (node metadata vs channel details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit when-to-use guidance or alternatives. While 'for the store' implies context, it does not clarify when to prefer this over list_lightning_channels or get_wallet_balance for balance inquiries.
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 provided, the description must carry full behavioral burden. It discloses return values ('title, amount, status, and generated invoice count'), which is helpful. However, it fails to state this is a read-only/safe operation or mention rate limits, auth requirements, or caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with three distinct, front-loaded sections: purpose statement, Args documentation, and return value description. No redundant text; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and only one simple parameter, the description is sufficiently complete. It appropriately previews the return contents without needing to detail the full schema structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (parameter has title but no description). The Args section compensates adequately by defining 'payment_request_id' as 'The payment request ID', providing sufficient semantic context for this single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Get') and resource ('payment request details'). The word 'specific' effectively distinguishes this from the sibling tool 'list_payment_requests'. However, it doesn't explicitly contrast with 'create_payment_request' or mention that an ID is required upfront.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus alternatives like 'list_payment_requests'. No mention of prerequisites (e.g., needing to obtain the ID first) or error conditions (e.g., invalid ID).
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 provided, the description carries the full burden of behavioral disclosure. It successfully explains what is returned (invoice ID, status, URL, expiration) and where optional data is stored (metadata). However, it omits safety characteristics, error handling behavior, and idempotency details expected for a financial creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring-style structure (Args/Returns) is clear and front-loaded with the purpose statement. Every sentence earns its place given the lack of schema documentation. Slightly verbose format is appropriate for the parameter explanations required.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4-parameter complexity and existence of an output schema, the description adequately covers inputs and return values. Minor gaps remain regarding error states and explicit sibling differentiation, but the core functionality is sufficiently documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by documenting all four parameters in the Args section. It provides critical semantic details: amount precision behavior (strings preserve precision), format examples ('0.001', '10.00'), currency codes, and the tracking purpose of optional metadata fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new BTCPay invoice,' providing a specific verb and resource. It distinguishes from siblings like create_payment_request and create_pull_payment by specifying 'invoice,' though it does not explicitly contrast use cases between these similar creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides post-invocation guidance ('Use the checkout URL to direct users to the payment page') but lacks guidance on when to select this tool versus alternatives like create_payment_request or create_pull_payment. No when-not-to-use or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return structure (amounts, confirmations, statuses) but omits safety properties (read-only status), error handling, pagination behavior, or rate limits despite being a financial data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Uses structured Args/Returns format that efficiently organizes information. Front-loaded with clear purpose statement. Slightly redundant with schema structure but necessary given empty schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter tool with existing output schema. Covers parameter semantics and return value fields, but omits error scenarios (invalid payment_method_id), pagination limits, or maximum date ranges that would be necessary for robust agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Excellent compensation for 0% schema description coverage. Provides concrete example ('BTC') and explains default behavior when empty, which the JSON schema only indicates as empty string default without semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (List) + resource (on-chain wallet transactions) + scope (for a payment method). Clearly distinguishes from siblings like list_invoices or get_wallet_balance by specifying 'wallet transactions' and 'on-chain' (implying blockchain vs Lightning).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides parameter default guidance ('Leave empty to use BTC by default') but lacks comparative guidance on when to use this vs alternatives like get_wallet_balance or list_payouts. No mention of prerequisites or conditions.
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 provided, the description carries the full burden. It discloses the return structure (remote node, capacity, balances, status) but fails to explicitly state safety characteristics (read-only vs. destructive) or performance traits like pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient docstring-style structure with distinct Args and Returns sections. No redundant text; every sentence provides specific value beyond the structured schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a single-parameter tool with an output schema. The parameter is fully documented and return values are previewed. Minor gap: lacks explicit read-only confirmation which would be helpful given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Excellent compensation for 0% schema description coverage. The description fully documents the `crypto_code` parameter with clear semantics (Crypto code), concrete examples (e.g., 'BTC', 'BTCTest'), and default value ('BTC').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action (List) and resource (Lightning channels) with scope (store's Lightning node). However, it does not explicitly differentiate from sibling `get_lightning_info`, which may also return Lightning-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use this tool versus siblings like `get_lightning_info` or `list_invoices`. The description only implies usage through the return value description but lacks when/when-not guidance.
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 provided, the description carries the full burden of behavioral disclosure. It successfully explains the auto_approve mechanism ('without manual review'), return values ('pull payment ID, payment link, and configuration'), and date formatting. However, it omits other critical behavioral traits like idempotency, error conditions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a clear docstring format (Args/Returns) that organizes information efficiently. Despite documenting 6 parameters, there is no extraneous text—every line serves to document inputs or outputs. The structure is slightly formal but highly readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 6 parameters, zero schema coverage, and no annotations, the description provides comprehensive input documentation and summarizes the output. It appropriately leverages the existence of an output schema (per context signals) by only summarizing return values rather than detailing them, while focusing descriptive effort on the poorly-documented inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description fully compensates by comprehensively documenting all 6 parameters. It provides data types, examples (e.g., '0.01' for amount, 'BTC'/'USD' for currency, ISO 8601 format for expires_at), default values, and semantic meaning for each parameter, including the business logic of auto_approve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('pull payment') and specifies concrete use cases (donations, subscriptions, payroll) that help distinguish it from sibling tools like create_invoice or create_payment_request. However, it does not explicitly contrast with these siblings to clarify when to choose one over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through specific examples (donations, subscriptions, payroll), giving the agent context on when this tool is appropriate. However, it lacks explicit 'when-not-to-use' guidance or references to alternative tools for different payment flows.
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 provided, the description carries the full burden and partially succeeds by documenting the BTCPAY_STORE_ID environment variable fallback and listing specific return fields (currency, speed policy), but omits safety information, error handling, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a clean docstring format with Args and Returns sections that front-load the essential information without unnecessary verbosity, though the structured format is slightly more technical than narrative prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, an output schema exists, and the description enumerates the specific configuration fields returned, the documentation provides sufficient context for invocation despite missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates effectively by explaining that store_id is optional and detailing the environment variable fallback mechanism, adding essential semantic meaning missing from the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get detailed information about a specific BTCPay store' with a clear verb and resource, effectively distinguishing it from sibling list_stores by emphasizing 'specific' and 'detailed information' versus listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description effectively describes what the tool returns, it lacks explicit guidance on when to use this versus list_stores or other retrieval tools, relying instead on implicit differentiation through the 'specific store' phrasing.
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 provided, the description must carry the full burden of behavioral disclosure. It successfully documents the archival filtering behavior (default false) and store-level scope, but fails to confirm the read-only nature of the operation or mention pagination/response limits that agents should be aware of when listing resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with the core action, followed by parameter details and conceptual explanation. The structure mixing narrative with an 'Args:' section is slightly unconventional but efficient. No sentences are redundant, though the conceptual explanation of pull payments could arguably be separated from the tool invocation description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single boolean parameter) and existence of an output schema, the description is sufficiently complete. It successfully explains the domain-specific term 'pull payments' which is critical for correct tool selection, and covers the parameter gap left by the schema. A perfect score would require explicit read-only confirmation or pagination notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (only title and type). The description compensates by documenting the single parameter include_archived with its semantics ('Whether to include archived pull payments') and default value ('False'). The 'Args:' formatting is slightly technical but functionally adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'List' and clear resource 'pull payments', immediately establishing the tool's function. The parenthetical examples '(donations, subscriptions, payroll)' effectively distinguish this from sibling tools like list_invoices or list_payment_requests by clarifying the specific use cases for pull payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description explains what pull payments are conceptually ('payment links that others can claim'), it lacks explicit guidance on when to use this tool versus siblings like create_pull_payment or list_payouts. It provides domain context but no explicit when-to-use or when-not-to-use directives.
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 provided, the description carries the full burden. It adds valuable context about the data source ('BTCPay's configured rate provider') and timeliness ('current'), but omits operational details like caching behavior, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear 'Args' and 'Returns' sections. Every sentence provides value—defining the operation, parameter format, and response source without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single optional parameter) and existence of an output schema, the description is appropriately complete. It covers the parameter semantics missing from the schema and identifies the rate provider, though it could explicitly note that the parameter is optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. The 'Args' section effectively documents the currency_pair parameter with format examples ('BTC_USD', 'BTC_EUR') and default value information, significantly augmenting the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('current BTCPay exchange rate') with scope ('for a currency pair'), effectively distinguishing it from sibling tools focused on invoices, payments, and wallets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description doesn't explicitly state 'when to use' rules or alternatives, the specific purpose makes implied usage clear. However, it lacks explicit guidance on prerequisites or when to prefer this over other data sources.
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 are provided, so the description carries the full burden. It successfully explains domain semantics (money movement to destinations) but omits operational details like pagination behavior, result limits, or whether this includes pending vs completed payouts. Since an output schema exists, return value description is not required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences total with no waste. First sentence establishes the action and scope, second and third provide essential domain context defining what payouts are. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the existence of an output schema, the description appropriately focuses on domain explanation. It adequately covers the complexity level of this tool, though could be improved by mentioning if results are filtered by store automatically or if pagination applies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present. Per evaluation guidelines, zero parameters establishes a baseline of 4. The schema coverage is vacuously 100%, and no additional parameter semantics are needed in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb 'List' and resource 'payouts (actual payout transactions)'. The explanation of payouts as 'claims against pull payments' effectively distinguishes this tool from sibling 'list_pull_payments' and 'list_payment_requests' by clarifying the domain relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the conceptual model (payouts as claims against pull payments), providing implicit context about when to use this versus pull payment tools. However, it lacks explicit when-to-use/when-not-to-use guidance or mention of prerequisites like store selection.
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 provided, the description carries the full burden. It successfully explains the conceptual behavior of webhooks (event notifications) but omits operational details like pagination, permissions required, or behavior when no webhooks exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences total with zero waste. The first sentence front-loads the action, while the second efficiently provides essential domain context about webhook functionality without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a zero-parameter list operation. The existence of an output schema (per context signals) excuses the description from detailing return values, and the webhook concept explanation suffices for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema contains zero parameters, establishing a baseline of 4. The description requires no parameter clarification, though it implicitly confirms no filtering is applied by stating 'all webhooks'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('List') and resource ('webhooks') plus scope ('for the store'), clearly distinguishing it from sibling tool 'create_webhook'. It precisely defines the operation's intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what webhooks do (real-time payment event notifications), implying when to use them, but provides no explicit when-not guidance or comparison to alternatives like create_webhook.
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 provided, the description carries the full burden; it successfully discloses that the tool returns a payment request ID and link, but omits other behavioral traits such as idempotency, error conditions, whether the link is active immediately, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description employs a clear docstring structure with Args and Returns sections that efficiently organize information without redundancy, though the format is slightly more verbose than a pure narrative style.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite six parameters and zero schema descriptions, the description successfully documents every parameter plus the return value, providing complete invocation context; the presence of an output schema means the brief return value mention is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description fully compensates by documenting all 6 parameters with semantic meaning, including concrete examples ('0.001', 'BTC', 'USD') and clarifying special values (0 = no expiry) that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Create a new payment request (reusable payment link)' provides a specific verb and resource, while the parenthetical effectively distinguishes this tool from siblings like create_invoice (typically one-time) and create_pull_payment (different funding mechanism).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies the output as a 'reusable payment link,' implying its use case, but it does not explicitly state when to use this tool versus alternatives like create_invoice or create_pull_payment, nor does it mention prerequisites or conditions for 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 successfully discloses the env var fallback mechanism and return value structure (on-chain vs Lightning, connection status). Does not explicitly state read-only nature or error cases, though 'List' implies safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Uses structured Google-style docstring format (Args/Returns). Three concise sentences with zero redundancy; front-loaded purpose followed by parameter and return details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a single-parameter read operation. Describes return content despite presence of output schema, adding value by clarifying the specific data types (BTC, LTC, Lightning) and status fields included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in properties). Description fully compensates by explaining store_id semantics, optionality, and the empty-string default behavior tied to environment variable resolution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (List) and resource (payment methods enabled for a BTCPay store). Clear scope, though it does not explicitly contrast with sibling 'get_store_info' to prevent confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Documents the environment variable fallback behavior (BTCPAY_STORE_ID) which guides usage when store_id is omitted. However, lacks explicit guidance on when to use this versus creating invoices or checking wallet balances.
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?
Without annotations, the description carries the full burden but only partially succeeds. It discloses the return structure (IDs, amounts, statuses, dates) and the 'recent' limitation, but omits safety declarations, pagination behavior, and rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a structured docstring format with 'Args:' and 'Returns:' sections that efficiently convey information without redundancy, though the formatting slightly deviates from standard prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter and existence of an output schema, the description provides adequate context by specifying the default store scope and summarizing return fields, though it could clarify what 'recent' means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully compensates by documenting the `status_filter` parameter with its allowed enum values ('New', 'Processing', 'Settled', 'Expired', 'Invalid') and default behavior (leave empty for all).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with resource 'invoices' and scope 'from the default BTCPay store', clearly distinguishing it from sibling tools like `get_invoice` (single retrieval) and `create_invoice` (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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While it doesn't explicitly name alternatives, it clearly scopes the operation to the 'default BTCPay store' and distinguishes its list-returning behavior from single-item retrieval tools through the explicit return value description.
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 disclosure burden. It adds valuable domain context that payment requests 'generate invoices on demand' and are 'persistent', but omits operational details like pagination behavior, result limits, or explicit read-only safety confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficiently structured sentences with zero redundancy. The first sentence states the action; the second provides essential domain context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a zero-parameter list operation with an output schema available. Explains the critical distinction between payment requests and invoices, but could improve by noting pagination behavior or if the list includes archived items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema contains zero parameters, meeting the baseline requirement. No parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'List' with clear resource 'payment requests' scoped to 'the store'. Parenthetical '(reusable payment links)' effectively distinguishes from siblings like list_invoices and create_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains payment requests are 'persistent' and useful for 'recurring billing, tipping, and donations', implying when to use versus one-time invoices. However, it does not explicitly name alternative tools like list_invoices or create_payment_request.
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 provided, the description carries the full disclosure burden. It adds valuable context about what gets returned ('store IDs, names, and websites') and authorization scope ('accessible with the current API key'). However, it omits pagination behavior, caching, or explicit read-only/safety declarations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: action definition, return value specification, and usage guidance. Information is front-loaded with the core purpose in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a low-complexity listing tool. Given the presence of an output schema (context signal), the description need not fully document return structures, but it helpfully previews the key fields. Covers the essential workflow context for BTCPay Server operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero-parameter tool with 100% schema coverage (empty object). Per baseline rules for 0 params, this scores 4. The description adequately compensates by explaining what the parameterless operation accomplishes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with clear resource ('BTCPay Server stores') and scope ('accessible with the current API key'). It implicitly distinguishes from sibling get_store_info by emphasizing this returns all stores and their IDs, establishing it as the discovery mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: 'Use a store ID from this list as the storeId parameter for invoice operations.' This clarifies when to invoke the tool (when preparing to perform invoice operations) and how to use the output. Lacks explicit 'when not to use' or named 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?
No annotations provided, so description carries full burden. Mentions return value contains 'pull payment ID' (hinting at side effect of creating a pull payment). However, lacks explicit disclosure of mutation nature, idempotency guarantees, or error scenarios. Adequate but not comprehensive for a financial operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear 'Args:' and 'Returns:' sections. Information density is high with minimal waste. Docstring-style formatting is slightly verbose but highly readable and appropriate for the complexity of refund_variant options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage and no annotations, the description successfully documents all inputs. Output schema exists, so brief mention of return value (pull payment ID and amount) is sufficient. Could improve by explicitly stating side effects (creates pull payment) and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description comprehensively documents all 4 parameters. refund_variant includes enum-like values with detailed explanations (RateThen, CurrentRate, etc.). payout_method_id clarifies it's for 'refund destination'. subtract_percentage includes valid range (0-100). Fully compensates for empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb 'Refund' and clear resource 'BTCPay invoice'. Distinct from siblings like create_invoice or get_invoice. Immediately clear this is for processing refunds against existing invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed guidance on refund_variant options (RateThen vs CurrentRate vs Fiat vs OverpaidAmount), explaining when to use each calculation method. Lacks explicit comparison to sibling tools like create_pull_payment, but the variant explanations serve as strong implicit usage guidance.
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 successfully discloses that the operation returns 'confirmed/unconfirmed balance' and specifies default behavior when the parameter is omitted. It does not cover error handling or authorization requirements, preventing a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a structured docstring format (Args/Returns) with zero redundancy. Every line provides essential information: the first sentence establishes purpose, the Args section explains the single parameter, and the Returns line clarifies the output content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional string parameter) and presence of an output schema, the description is appropriately complete. It covers the parameter semantics despite poor schema coverage and identifies the return data type (confirmed/unconfirmed) without needing to detail the full output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully compensates by documenting the `payment_method_id` parameter with a concrete example ('BTC'), explanation of what it references ('store's default BTC wallet'), and detailed default behavior ('Leave empty to use the first BTC-like method').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Get') + resource ('wallet balance') + scope ('for a payment method'), and explicitly qualifies it as 'on-chain wallet' to distinguish from the sibling `get_lightning_info` tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance through the parameter documentation (e.g., 'Leave empty to use the first BTC-like method'), but lacks explicit comparison to siblings like `list_wallet_transactions` or `get_store_payment_methods` to clarify when to query balance versus transaction history or method lists.
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 POST requests, HMAC-SHA256 signature verification, auto-redelivery behavior, and return values (webhook ID and configuration). It omits details like idempotency or validation behavior, but covers the critical security and delivery semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a structured Args/Returns format that is efficiently organized. The event examples add value without verbosity. The single-sentence purpose statement is front-loaded and every subsequent line documents concrete behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 4 parameters and an output schema, the description adequately covers inputs, security considerations (HMAC), return values, and delivery guarantees. It appropriately references the return value without duplicating the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the Args section provides essential semantic context for all 4 parameters: HTTP method context for url, comma-separated format and examples for events, cryptographic purpose for secret, and failure-handling behavior for automatic_redelivery.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new webhook for real-time payment notifications,' providing a specific verb (Create), resource (webhook), and domain context (payment notifications). This clearly distinguishes it from sibling tools like create_invoice or list_webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for real-time payment notifications' provides clear context about when to use this tool versus polling alternatives like list_invoices. However, it lacks explicit exclusions or prerequisites (e.g., URL must be publicly accessible).
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. Enumerates status values (New, Processing, Settled, Expired, Invalid) which is valuable behavioral context. Describes return payload categories (amounts, payments, timing). Does not explicitly state read-only/safe nature, though implied by '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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with clear 'Args' and 'Returns' sections. Every line provides distinct value: purpose, parameter semantics, return structure, and enumerated states. No redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a single-parameter retrieval tool. Despite presence of output schema, the description adds value by enumerating possible status values. References sibling tool to establish context. No gaps given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (only title 'Invoice Id'). Description compensates excellently by specifying format (UUID string) and provenance (returned by create_invoice), giving the agent crucial semantic context for parameter population.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Get' with clear resource 'BTCPay invoice' and scope 'details and status'. Implicitly distinguishes from sibling 'create_invoice' (which creates) and 'list_invoices' (which lists without requiring ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides prerequisite context by noting the invoice_id is 'returned by create_invoice', establishing the workflow sequence. However, lacks explicit contrast with 'list_invoices' for bulk retrieval scenarios.
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 carries full burden. It discloses return values ('server version, supported features, and system status') and authentication requirements ('No store ID or API key required'). It implies read-only safety through 'verify connectivity' but doesn't explicitly state it is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with zero waste. Front-loaded with action, followed by return values, usage context, and authentication requirements. Every sentence provides unique value not found in the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (per context signals), the description provides sufficient coverage of return values and behavioral context without needing to enumerate output fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage (empty object). Per the baseline rules for zero-parameter tools, this earns a default score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Get') and clear resource ('BTCPay Server version and system information'), distinguishing it from sibling tools like get_store_info (store-scoped) and get_lightning_info (lightning-scoped).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('verify connectivity and check what features are available') and provides critical prerequisites ('No store ID or API key required'), which clearly differentiates it from siblings that likely require these credentials.
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:
Score Badge
Copy to your README.md:
How to claim the server?
If you are the author of the server, you simply need to authenticate using GitHub.
However, if the MCP server belongs to an organization, you need to first add glama.json to the root of your repository.
{
"$schema": "https://glama.ai/mcp/schemas/server.json",
"maintainers": [
"your-github-username"
]
}Then, authenticate using GitHub.
Browse examples.
How to make a release?
A "release" on Glama is not the same as a GitHub release. To create a Glama release:
- Claim the server if you haven't already.
- Go to the Dockerfile admin page, configure the build spec, and click Deploy.
- Once the build test succeeds, click Make Release, enter a version, and publish.
This process allows Glama to run security checks on your server and enables users to deploy it.
How to add a LICENSE?
Please follow the instructions in the GitHub documentation.
Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear on the server after some time, you can manually trigger a new scan using the MCP server admin interface.
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.
Latest Blog Posts
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/ThomsenDrake/btcpay-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server