Agentic Terminal Directory
Server Details
Verified merchants accepting agentic payments on Lightning/L402/BOLT12/USDT — search, verify, pay.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- observer-protocol/at-directory
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 6 of 6 tools scored. Lowest: 3/5.
Each tool has a clearly distinct purpose: retrieving a single merchant, listing categories, listing rails, searching merchants, verifying payment endpoints, and reporting identity/rate limits. No two tools overlap in functionality.
Most tools follow a consistent verb_noun pattern (e.g., get_merchant, list_categories). The only minor deviation is 'whoami', which is a common CLI command and still fits the overall pattern well.
With 6 tools, the set is well-scoped for a directory and verification service. Each tool serves a necessary function without excess or deficiency.
The tools cover core directory operations: retrieval, search, listing of categories and rails, and endpoint verification. While there might be minor gaps (e.g., detailed rail info per merchant is included in get_merchant), the surface is largely complete for the intended domain.
Available Tools
6 toolsget_merchantAInspect
Get the full record for one merchant including all rails, payment endpoints, and OP attestation. Tier 2+ requires an AT credential.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Tool Definition Quality
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 that the record includes rails, payment endpoints, and OP attestation, and notes a credential requirement. However, it does not mention whether the operation is read-only, possible error responses, rate limits, or side effects. For a read operation, it is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no extraneous words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description lists what the record includes (rails, payment endpoints, OP attestation). It lacks mention of output format (e.g., JSON object) or error handling, but for a simple retrieval tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'id' with type string and minLength 1. The description does not explain what 'id' represents (e.g., merchant ID format, source) beyond the schema. With 0% schema coverage, the description should compensate, but it does not add any parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the full record for one merchant including all rails, payment endpoints, and OP attestation.' It specifies the verb (Get), resource (merchant record), and scope. It distinguishes from siblings like search_merchants which is for searching, and list_categories/list_rails which are different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Tier 2+ requires an AT credential,' providing a specific usage condition. It implies this is for retrieving a single merchant record while search_merchants is for finding merchants, but does not explicitly state when not to use it or provide alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesAInspect
List the category taxonomy with merchant counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It implies read-only operation but doesn't mention any limitations, pagination, or whether counts are live. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words. It is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool without output schema, the description covers the basic purpose. However, it could mention the output format or structure of the taxonomy to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so schema coverage is 100%. The description adds no parameter info, which is acceptable since there are none. Baseline 4 due to high coverage and no params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists category taxonomy with merchant counts, which is a specific verb+resource. It distinguishes from sibling tools like get_merchant or search_merchants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For a simple listing tool, it's adequate but lacks context like 'use this to explore categories' or 'for detailed merchant info use get_merchant'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_railsAInspect
List supported payment rails and their current merchant counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states a read operation listing rails and counts, which is transparent for this simple tool. However, no additional traits like rate limits, prerequisites, or response structure are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is largely complete for a simple list tool. It could mention the return format or sorting, but the core purpose is clear and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. Per guidelines, the baseline for 0 parameters is 4. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('supported payment rails') and clearly explains scope ('current merchant counts'). It distinguishes the tool from siblings like get_merchant (single merchant) and search_merchants (search, not listing rails).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or not use this tool. No alternatives are mentioned. The description implies it is for retrieving the list of payment rails, but it lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_merchantsBInspect
Search OP-verified merchants by rail, chain, category, agent-callable tier, trust tier, and free text. Ranked by trust tier then verification recency.
| Name | Required | Description | Default |
|---|---|---|---|
| rail | No | ||
| chain | No | ||
| limit | No | ||
| query | No | ||
| category | No | ||
| accepts_usdc | No | ||
| trust_tier_min | No | ||
| agent_callable_tier | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Implies read-only search but does not explicitly state safety or behavior beyond the ranking. No annotations present, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence plus ranking note; clear but could separate filter list and ranking for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description lacks return value structure or pagination hints, but search tools with simple list output are common.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Lists several filter fields (rail, chain, category, etc.) but omits 'limit', 'accepts_usdc', 'query'; schema coverage is 0%, so description should describe all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches OP-verified merchants with specific filters and mentions ranking, distinguishing it from sibling get_merchant which retrieves a single merchant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs siblings like get_merchant or list_categories; no scenarios or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_payment_endpointAInspect
Run a live check against a merchant's declared payment endpoint for a rail. Returns health, detail, and rail-specific evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| rail | Yes | ||
| merchant_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it performs a 'live check' (an active test) and returns specific data, but does not disclose potential side effects, permissions, or error behavior. Given no annotations, more detail on side effects would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the action and output. It is front-loaded with the verb and resource, with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool without output schema, the description covers the core purpose and return values. It could mention that it involves a network call or response structure, but is largely complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context by clarifying that merchant_id refers to a 'merchant's declared payment endpoint' and 'rail' specifies the payment rail. However, it does not elaborate on the enum meanings or format constraints, so with 0% schema coverage, it could provide more detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a live check against a merchant's payment endpoint for a specific rail, and describes the output (health, detail, evidence). It effectively distinguishes from sibling tools like get_merchant and list_rails by emphasizing the live testing aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions. The description simply states the action without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiAInspect
Report the resolved credential state and rate limits for the calling agent.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states 'resolved credential state and rate limits', indicating a read-like operation, but does not specify the exact fields returned or any side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and direct, with no unnecessary words or repetition. It earns its place by clearly defining the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides the core purpose but lacks details on the format of the returned data. For a simple tool with no parameters, it is adequate but not fully complete for an agent to predict the exact output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage. The description adds context about the tool's purpose but does not add new meaning beyond what the schema already indicates (no parameters required). Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports credential state and rate limits for the calling agent, using a specific verb and resource. It is distinct from all sibling tools which deal with merchants, categories, rails, search, and payment verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting one's own credentials and rate limits, providing clear context. No explicit exclusions or alternatives are needed since the tool is self-contained and sibling tools are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!