Pay any Algorand x402 invoice with any asset, plus DEX swap quotes and unsigned builds.
/.well-known/glama.json file. Claimed server authors can inspect health checks, view analytics, and manage their connector listing.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.
Average 4.1/5 across 12 of 12 tools scored. Lowest: 2.6/5.
Each tool has a clear, distinct purpose: quoting vs building swaps, managing watches, handling payments, registration steps, and LP valuation. Even related tools like get_credit_offer and pay_x402_invoice are clearly separated as 'create offer' vs 'pay invoice'. No two tools appear to duplicate functionality.
All tool names follow a consistent verb_noun pattern in snake_case, using verbs like get, list, build, set, delete, pay, register, verify, value. Read operations are consistently divided into get_ (single item) and list_ (collections), and the rest are action-oriented. This makes the API predictable and easy to navigate.
With 12 tools, the server covers its main domains—swap quoting/building, payment, credit management, watch management, agent registration, and LP valuation—without unnecessary bloat. Each tool earns its place, and the count fits comfortably within the typical 3-15 tool range for a well-scoped server.
The tool set covers core workflows end-to-end: quote to swap, credit top-up to payment, watch registration to listing/deletion, and two-step agent registration. Minor gaps exist, such as no dedicated get_watch (though list_watches covers it) and no way to inspect past transactions or offers, but agents can work around these without major friction.
build_swapAInspectUnsigned transaction group for a get_quote quote_id. Sign every txn with your own wallet and submit as one group. NEVER pass mnemonics or private keys to any tool — signing happens in YOUR wallet, never here.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| quote_id | Yes | ||
| user_address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses critical behaviors: the transactions are unsigned, signing occurs only in the user's wallet, and the tool never handles mnemonics or private keys. It also implies that the tool does not submit transactions, leaving that to the user. This is exemplary transparency for a transaction-building tool.
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 core purpose, and each sentence earns its place. The security warning is essential and adds real value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the essential workflow (build unsigned group, sign, submit) and security requirements. It leverages the existence of an output schema, so details about return values are not needed. It could be more thorough about the exact role of user_address or prerequisites, but it remains sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate for parameter meaning. It only explains quote_id ('for a get_quote quote_id') and indirectly hints at user_address through 'your wallet,' but api_key is completely unexplained. This leaves two of three parameters semantically underexplained.
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 that the tool produces an unsigned transaction group for a get_quote quote_id, which distinguishes it from siblings like get_quote or pay_x402_invoice. However, it lacks an explicit active verb (e.g., 'Builds...') and does not name the resource as 'swap' directly, relying on the tool name for that association.
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 provides clear usage context by requiring a quote_id from get_quote and instructing the user to sign every transaction with their own wallet and submit as one group. It does not explicitly mention alternatives or when-not-to-use, but the context is sufficient given the tool's unique role among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_watchCInspectDelete one of your watches by its client_key.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| client_key | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states that a watch is deleted by client_key, but does not mention that the deletion is permanent, what happens to associated data, or whether the operation is idempotent. This leaves the agent unaware of important destructive side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the core action. It avoids any filler. However, it is so brief that additional relevant details (e.g., api_key purpose) could be included without harming conciseness, so it earns a 4 rather than a 5.
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?
The tool is simple, and an output schema exists, so return values need not be explained. However, the description lacks critical context: it does not explain the api_key parameter, does not indicate that deletion is irreversible, and provides no usage guidance. Given the moderate complexity of two parameters and a destructive action, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the parameters. It explicitly explains client_key as the watch identifier, but api_key is left completely unexplained. Since one of the two parameters is undocumented, the parameter semantics are only partially addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and the resource (watches) using the client_key as the identifier. It is specific and unambiguous, and it naturally distinguishes from sibling tools like list_watches and set_watch by the delete verb.
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 given on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing the client_key from list_watches, nor any conditions under which deletion is appropriate. The description simply states the action without contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balanceCInspectCurrent HOGSWAP credit balance for your API key.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only implies a read-only operation but does not mention authentication, rate limits, response format, or side effects. The optional api_key parameter's behavior is not explained.
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 that efficiently states the tool's purpose. It is not verbose, though it could add more value with additional context.
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?
The tool is simple, but with no annotations and no explanation of the api_key parameter or usage context, the description is not fully complete. It would benefit from a note on how the API key is sourced and when to use this instead of get_credit_offer.
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 does not mention the api_key parameter at all, and schema description coverage is 0%. The schema shows an optional string/null parameter with a default of null, but the description does not clarify whether it overrides authentication or is required.
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 returns the current HOGSWAP credit balance for the API key, which distinguishes it from siblings like get_credit_offer or get_quote. However, it lacks an explicit verb (e.g., 'Gets'), making it slightly less direct.
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 provides no guidance on when to use this tool versus alternatives, such as get_credit_offer, nor any exclusions or prerequisites. It solely states what it returns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_credit_offerAInspectCreate a credit top-up and get the x402 offer (HTTP 402 IS the payment instruction, not an error). Feed accepts[0] straight into pay_x402_invoice (keep the note nonce) to pay with any asset. Credits land ~1 block after payment.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | ||
| usdc_micro | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds valuable behavioral context: 402 is a payment instruction, credits land ~1 block after payment, and the nonce must be preserved. It does not mention auth or rate limits, but the protocol-specific nuance is well disclosed.
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?
Three sentences, each earning its place. The description is front-loaded with the purpose and immediately gives actionable next steps and timing. No filler or redundancy.
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?
The description covers the essential protocol flow and timing, and an output schema exists so return values need not be described. However, the lack of parameter info leaves a gap, and without that, the overall completeness is slightly reduced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never explains the parameters (usdc_micro, api_key). The name 'usdc_micro' hints at amount, but the description provides no meaning or relationship to the offer.
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's function: creating a credit top-up and obtaining an x402 offer. It explains that HTTP 402 is the payment instruction, not an error, and explicitly references the sibling tool pay_x402_invoice, distinguishing this from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on how to use the result: feed accepts[0] into pay_x402_invoice and keep the note nonce. It implies the proper workflow, though it lacks explicit when-not-to-use or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quoteAInspectHOGSWAP swap quote across every Algorand DEX. Give amount (exact input) OR amount_out (exact output — minimum input is solved). Base units (µ); asset 0 = ALGO. Returns expected_out, route legs, and a quote_id for build_swap. expected_out is NET of the 5 bps routing fee; passing sender also returns router_fee_* fields and the wallet's HOG discount (hog_discount_pct, 100 = fully waived at 100 HOG). Optional sender enables HOG-holding fee discounts. Optional max_legs (1-16) caps TOTAL route legs, splits included — slightly worse price at size, 404 if nothing fits; forward (amount) quotes only.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | ||
| sender | No | ||
| api_key | No | ||
| asset_in | Yes | ||
| max_legs | No | ||
| asset_out | Yes | ||
| amount_out | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that 'expected_out is NET of the 5 bps routing fee', reveals optional sender fields (router_fee_*, hog_discount_pct), explains max_legs caps and '404 if nothing fits', and limits to 'forward (amount) quotes only'. This gives the agent a rich understanding of side effects and constraints.
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 dense but every sentence contributes information. It front-loads the main purpose and uses compact phrasing (e.g., 'Base units (µ); asset 0 = ALGO'). Some sentences are long and cram multiple points, but overall it is efficient for the tool's complexity.
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?
The description covers purpose, usage, fees, discounts, error cases, and parameter semantics for a complex quote tool. With an output schema present, return values need not be detailed. The only notable omission is api_key, and the meaning of 'forward (amount) quotes only' is slightly ambiguous, but overall the context is robust.
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?
Given 0% schema description coverage, the description compensates well for most parameters: amount vs amount_out semantics, base units and asset 0 = ALGO, sender's effect on fees/discounts, and max_legs behavior. However, it does not explain api_key, leaving a gap for a 7-parameter tool.
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 opens with 'HOGSWAP swap quote across every Algorand DEX', clearly stating the verb+resource and scope. It also distinguishes itself from sibling tools by mentioning 'quote_id for build_swap', indicating this is the quoting step before building a swap.
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?
Explicitly states when to use amount vs amount_out ('Give amount (exact input) OR amount_out (exact output)'), and explains the effect of passing sender for HOG discounts. It also describes max_legs trade-offs and error behavior. However, it does not explicitly name when to use this tool vs alternatives, though the build_swap reference implies the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_payable_assetsAInspectAssets accepted as payment inputs for pay_x402_invoice and credit top-ups (price-confidence gated; ALGO and USDC always included).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It adds valuable context by noting the price-confidence gating and the always-included ALGO/USDC, which are non-obvious. However, it does not mention output format or further behavioral details, so it is adequate but not exhaustive.
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, dense sentence that communicates the tool's purpose and key constraints without any fluff. Every phrase adds information, making it highly concise and well-structured.
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 zero-parameter list tool with an output schema, the description adequately covers what the tool lists and the gating behavior. It does not explain return values, but the output schema handles that, and the complexity is low, so 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 tool has zero parameters, and the schema reflects this with 100% coverage. The description correctly does not need to explain parameters, and the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose as listing assets accepted for pay_x402_invoice and credit top-ups. It uses a specific verb ('list') and resource ('payable assets'), and the detail about price-confidence gating and guaranteed inclusion of ALGO/USDC distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning pay_x402_invoice and credit top-ups, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or conditions. It gives clear context but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_watchesAInspectList your key's active watches (spec + arming/fired state), quota, and latest event seq. Poll this from MCP to see fires; SSE at GET /watches/stream is the push alternative outside MCP.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description implies a read-only operation by 'List' and mentions polling semantics. It does not explicitly state side effects or permissions, but for a list operation this is sufficiently transparent, and the SSE alternative adds useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences that accomplish purpose, usage guidance, and alternatives without waste. Front-loaded with the main action and details.
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?
Output schema exists, so return values are covered. The description provides essential context (what is listed, polling vs streaming) but omits any mention of the api_key parameter. Overall fairly complete, with a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions the api_key parameter. Even though it is optional and self-explanatory, the description adds no meaning beyond the parameter name, failing to compensate for the lack of schema documentation.
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 the tool lists watches with specific details (spec, arming/fired state, quota, latest event seq). Distinguishes from sibling tools like set_watch and delete_watch by focusing on listing.
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?
Explicitly says to poll this from MCP to see fires and offers SSE as a push alternative outside MCP. Gives clear context for when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pay_x402_invoiceAInspectPay ANY Algorand-settled x402 invoice with any 1-4 routable assets you hold, even holding none of the demanded asset. Pass the accepts entry you picked as invoice (keep its note!) plus your inputs (single input with no amount = minimum solved). Returns UNSIGNED groups — sign all in one pass, submit IN ORDER (swap first; its on-chain floor guarantees the payment is funded; holding the asset already = one direct payment). HOGSWAP credit top-up offers feed this verbatim. EVM invoices unsupported (no bridge). NEVER pass mnemonics or private keys to any tool — signing happens in YOUR wallet, never here.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes | ||
| api_key | No | ||
| invoice | Yes | ||
| user_address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses key behavioral traits: returns UNSIGNED groups, sign all in one pass, submit IN ORDER, swap-first floor guarantee, and that signing happens in the user's wallet. It also warns against passing mnemonics/private keys, addressing security behavior not captured elsewhere.
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 dense but every sentence carries necessary information. It front-loads the core purpose, then provides operational details, unsupported cases, and security warnings. Slightly long, but the complexity of the tool justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, no property schemas, 0% schema coverage), the description is remarkably complete. It covers what settles on Algorand, asset flexibility, return format, signing flow, ordering constraints, swap flooring, unsupported EVM, and security. An output schema exists, so not explaining return values is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds significant meaning to the two core parameters: 'Pass the `accepts` entry you picked as `invoice` (keep its note!)' and 'single input with no amount = minimum solved'. It does not clarify user_address or api_key, but the most complex parameters get meaningful guidance.
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 opens with a specific verb+resource+scope: 'Pay ANY Algorand-settled x402 invoice'. It also adds flexibility details (1-4 routable assets, holding none of the demanded asset) that clearly distinguish it from sibling tools like build_swap or get_quote, which serve different purposes.
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?
It provides explicit when/when-not context ('EVM invoices unsupported'), operational instructions (pass the accepts entry as invoice, keep its note, single input with no amount = minimum solved), and submission order requirements. It does not explicitly name alternative tools, but the scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_agentAInspectSelf-service HOGSWAP API key, step 1 of 2 — zero human. Returns a challenge; sign its exact bytes with the address's key in YOUR wallet tooling, then call verify_registration. NEVER pass mnemonics or private keys to any tool — signing happens in YOUR wallet, never here.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the challenge-response behavior, including that signing happens in the user's wallet and not in the tool, and that secrets must never be shared. It also clarifies that the tool returns a challenge rather than completing registration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading of purpose and step, plus a critical security warning. Every sentence 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?
For a simple one-parameter step in a two-step flow, the description covers purpose, expected output, next step, and security context. The presence of an output schema means return format specifics are not required in the description.
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 schema provides only an 'address' parameter with no description (0% coverage). The description contextualizes it as the address whose key is used for signing, but doesn't explicitly define the parameter's format or details, leaving some interpretation.
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 this is step 1 of a self-service HOGSWAP API key registration, and explicitly distinguishes it from verify_registration (the next step). It identifies the action (registering an agent) and the output (a challenge).
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?
It explicitly instructs to sign the challenge and then call verify_registration, providing a clear workflow. It also warns to never pass mnemonics/private keys, establishing security-related usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_watchAInspectRegister a standing server-side watch (FREE, needs a key; idempotent upsert by client_key — re-registering replaces the watch and resets arming). kind='price': advisory µUSD threshold (asset_id, op gte/lte, threshold_usd_micro). kind='target': size-aware surrogate — would swapping amount_in of asset_in→asset_out deliver ≥ min_out? (margin_bps haircut, default 30; NO quote is run). Edge-triggered one-shot; re-arms after rearm_bps retreat + cooldown_s; ttl_s auto-expiry (default 86400) — refresh by re-upserting. Fires are numbers-only HINTS: re-quote with get_quote. Events push over SSE at GET /watches/stream (outside MCP); from MCP, poll list_watches.
| Name | Required | Description | Default |
|---|---|---|---|
| op | No | ||
| kind | Yes | ||
| ttl_s | No | ||
| api_key | No | ||
| min_out | No | ||
| asset_id | No | ||
| asset_in | No | ||
| amount_in | No | ||
| asset_out | No | ||
| rearm_bps | No | ||
| client_key | Yes | ||
| cooldown_s | No | ||
| margin_bps | No | ||
| threshold_usd_micro | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden and succeeds: it discloses idempotent upsert behavior, edge-triggered one-shot, re-arm conditions, TTL auto-expiry, and that no quote is run for the target kind. It also notes the FREE key requirement and SSE streaming endpoint outside MCP.
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 dense but each clause adds necessary detail for a complex 14-parameter tool. It is front-loaded with the core action and then elaborates. While long, it avoids redundancy and stays structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and many parameters, the description covers the operation, both kinds, parameters, lifecycle (re-arm, TTL), and how to consume events (SSE vs polling). This is sufficient for an agent to invoke it correctly, especially with an output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It names most relevant parameters grouped by kind: asset_id, op, threshold_usd_micro for price; amount_in, asset_in, asset_out, min_out, margin_bps for target; plus client_key, rearm_bps, cooldown_s, ttl_s. It omits explicit mapping of api_key (though 'needs a key' implies it) and doesn't enumerate default values for all params, but the coverage is strong.
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 opens with 'Register a standing server-side watch' and then details two kinds (price/target), making the operation clear. It distinguishes from siblings by stating that fires are hints and that get_quote should be used for re-quoting, and list_watches for MCP polling. This is a specific verb+resource with clear scope.
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 explains when to use the tool (to set up standing watches) and contrasts with get_quote ('Fires are numbers-only HINTS: re-quote with get_quote') and list_watches ('from MCP, poll list_watches'). It does not explicitly state exclusions (e.g., 'use get_quote for immediate quotes') but implies them through the hint/re-quote guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
value_lp_tokenAInspectValue a liquidity-provider position. Give the LP token's asset id (free, no key) and optionally amount in LP BASE units — what the wallet holds — for its USD value and the redeemable amount of each underlying. Also identifies the issuing pool/DEX (and STAMM tier). Per-unit figures are per WHOLE LP token. Values are a proportional-share redemption at analytics prices: no slippage, no exit fee, NOT a market quote — fields are null rather than guessed when supply or a price is missing, so check before reporting a number.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | ||
| asset_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It discloses important behavioral traits: 'Per-unit figures are per WHOLE LP token', 'Values are a proportional-share redemption at analytics prices: no slippage, no exit fee', null behavior when data is missing, and the caveat to check before reporting numbers. This is rich, honest disclosure beyond basic annotations.
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 moderately sized paragraph, but every sentence contributes necessary detail. It front-loads the primary action, then explains inputs, output semantics, and limitations efficiently. It is slightly dense but remains readable and appropriately sized for the tool's complexity.
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?
The tool has an output schema, but the description independently explains what is returned: USD value, redeemable amount of each underlying, and pool/DEX/STAMM tier. It also addresses edge cases (null when supply/price missing) and limitations (no slippage, no exit fee). This makes the description self-sufficient for an agent to understand inputs, outputs, and caveats without needing to inspect the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description directly explains both parameters: 'asset id' identifies the LP token, and 'amount' is in 'LP BASE units — what the wallet holds'. It adds crucial context that 'amount' is optional and that per-unit figures are per whole LP token, providing meaning well beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Value a liquidity-provider position.' It clearly distinguishes from siblings by focusing on LP token valuation, as opposed to swaps, quotes, balances, or watches. The scope is precise and the function's purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit input requirements ('Give the LP token's asset id... and optionally amount') and sets expectations for the output. It clearly states a key exclusion: 'NOT a market quote', which tells the user when not to use this tool. However, it does not name a specific alternative tool (like get_quote) for market quotes, leaving a slight gap in alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_registrationAInspectSelf-service key issuance, step 2 of 2. Returns your hsk_ key ONCE — store it yourself; it is not recoverable and this server does not keep it. Send it on later calls as Authorization: Bearer, X-API-Key, or the api_key argument.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| challenge | Yes | ||
| signature_b64 | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 and succeeds in highlighting the most critical trait: the key is returned only once, is not recoverable, and is not stored on the server. This is essential for preventing data loss. It could add more detail on failure modes or what happens to the registration state, but the core behavior is well covered.
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 just two sentences, with every word earning its place. The critical warning about one-time key retrieval is front-loaded, and the usage instruction for later calls is concise. There is zero redundancy or filler.
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?
The description excels in conveying the tool's purpose and the one-time key behavior, which is contextually important for a key-issuance flow. However, it is incomplete for a tool with three undocumented parameters and no annotations, and it does not explicitly connect to the sibling register_agent step. The presence of an output schema reduces the need to describe return values, but parameter semantics remain a significant gap.
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 provides zero description coverage for the three required parameters (address, challenge, signature_b64), and the description does not compensate. It gives no hints about what these fields represent or how they should be populated, leaving the agent with insufficient guidance for correct invocation.
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's function: 'Self-service key issuance, step 2 of 2' and 'Returns your hsk_ key ONCE', distinguishing it from sibling tools as the final step that returns the API key. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear sequential context as 'step 2 of 2', implying it follows register_agent. It also provides explicit guidance on how to use the key in subsequent calls ('Send it on later calls as Authorization: Bearer, X-API-Key, or the api_key argument'). However, it does not explicitly name alternatives or state exclusions.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.