Easy way to publish static content for free - forever. No hassle way to publish html/css/js, pdf, .md, txt, etc.
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 3.7/5 across 14 of 14 tools scored. Lowest: 2.4/5.
All 14 tools have clearly distinct purposes with no overlap. Related tools like buy_credits, get_balance, and list_topup_packs handle different aspects of credit management without ambiguity.
Tool names follow a consistent verb_noun pattern with snake_case (e.g., attach_domain, delete_site, list_sites). No mixing of conventions.
14 tools cover the core functionality of a static site hosting service: domain management, site publishing/deletion, credit system, key acquisition, and name checking. The scope is well-balanced.
The tool set covers the main lifecycle (create, read, update, delete) for sites and domains. Minor gaps include no direct tool to rename a site or manage keys beyond creation.
attach_domainBInspectAttach a custom domain (apex like example.com, or subdomain like blog.example.com) to a site the key owns. Returns the DNS records the user must add; HTTPS is automatic. Requires a key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| name | Yes | ||
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must inform behavior. It states the tool returns DNS records and HTTPS is automatic, and requires a key. However, it does not disclose potential side effects (e.g., replacing existing domain, ownership verification needs, irreversibility).
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 convey the core information concisely: what it does (attach domain, with examples), what it returns (DNS records), behavioral note (HTTPS automatic), and a prerequisite (requires a key). No unnecessary 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?
The description covers the main action, return value, and a behavioral trait. However, it lacks context on prerequisites (e.g., domain verification), state changes (e.g., overwriting existing domains), and failure cases. Adequate but not comprehensive.
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 only implicitly explains parameters: 'key' is mentioned as required, 'domain' is the custom domain, and 'name' is inferred as the site name. No explicit descriptions of formats, constraints, or parameter relationships are provided.
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?
Description clearly states the action 'attach a custom domain' and provides examples of domain formats. It specifies the resource ('site the key owns') and outcome ('returns DNS records; HTTPS automatic'). While the purpose is distinct from sibling tool 'detach_domain', no explicit differentiation is provided.
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 like 'detach_domain' or other domain-related tools. The description implies usage for attaching domains, but lacks explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buy_creditsAInspectGet a Stripe Checkout URL to load credits onto this account. Returns a payment link the HUMAN must open in a browser to pay — this tool does not itself charge anything. amount_usd must be one of the available top-up amounts (call list_topup_packs to see them). After they pay, the balance updates automatically; then call set_no_ads. Requires a key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | boom_sk_ key. | |
| amount_usd | Yes | Credit amount in US dollars — one of the amounts from list_topup_packs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses that the tool returns a payment link for the human to pay in a browser, does not charge, and that balance updates automatically. Also states it requires a key. No contradictions.
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 no redundancy. Front-loaded with the core action, then behavioral notes, parameter guidance, and follow-up instruction. 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?
Given no output schema and no annotations, the description covers purpose, prerequisites, human involvement, follow-up, and authentication. Complete for a simple two-parameter tool.
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 100%, so baseline is 3. The description adds context by explaining that amount_usd must match a pack from list_topup_packs and that the output is a payment URL, going beyond the schema's property descriptions.
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 obtains a Stripe Checkout URL to load credits. Distinguishes from sibling tools like get_balance or list_topup_packs by specifying its role in the payment flow.
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 when to use (to load credits), prerequisite (list_topup_packs to see available amounts), post-requisite (call set_no_ads after payment), and that the tool itself does not charge. Provides a clear sequence of actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_nameBInspectCheck whether a boomurl site name is available (and get nearby suggestions). No key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Desired site name (lowercase letters, digits, hyphens). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool is a check (likely read-only) and requires no key, but fails to disclose any potential side effects, rate limits, error handling, or what happens when the name is taken. This is minimal behavioral disclosure.
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 conveys the core purpose and a key usage hint. Every word earns its place with no fluff.
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 check tool with no output schema, the description covers the essential: what it does and a key access requirement (no key). Minor omissions (e.g., format of suggestions) are acceptable given the tool's simplicity.
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 100%, with a clear description for the 'name' parameter. The tool description reinforces that the parameter is the site name to check, but adds no further semantic detail beyond the schema. Baseline score of 3 is appropriate.
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 checks name availability and returns suggestions. The verb 'check' and resource 'boomurl site name' are specific. While it doesn't explicitly differentiate from siblings, the purpose is distinct enough given the sibling list contains action-oriented 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 for checking name availability when creating a site. It mentions 'No key needed', which is a usage hint. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_publish_keyAInspectStep 2: exchange the emailed 6-digit code for a boom_sk_ API key. Returns the key ONCE — reuse it for this user's later publish/list/delete calls.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The 6-digit code from the email. | |
| Yes | Same email used in request_publish_key. | ||
| label | No | Optional label for the key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the key is returned once and should be reused, implying non-idempotency. No annotations, so description carries burden. However, lacking details on error handling, invalid code, or persistence.
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, efficient, front-loaded with 'Step 2'. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple exchange tool with 3 params and no output schema, description covers purpose, sequence, and output usage. Lacks error handling or retry info, but adequate for the 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?
Schema covers 100% of parameters with descriptions. Description adds context for email ('Same email used in request_publish_key') but not for code or label. Baseline 3 with minor addition.
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?
Description clearly states it is Step 2 to exchange a 6-digit code for an API key, distinguishing it from request_publish_key (Step 1). Verb 'exchange' and resource 'code for API key' are specific.
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 positions as Step 2 in a sequence, and instructs to reuse the key for later calls. Provides clear context but lacks explicit when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_siteCInspectPermanently delete a site the key owns. Requires a key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It discloses the destructive nature ('permanently delete') and the auth requirement ('requires a key'), but lacks details on side effects, error handling, or consequences (e.g., if the site is published).
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 with no fluff, but it omits essential parameter details. Conciseness is present but at the expense of completeness.
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 destructive tool with no output schema or annotations, the description is insufficient. It does not cover return values, error states, or confirmation behavior, leaving agents with significant gaps for correct invocation.
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, yet the description does not explain the role of the 'name' or 'key' parameters. The description only mentions 'key' implicitly but does not map parameters to their purpose.
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 'Permanently delete a site the key owns' with a specific verb (delete) and resource (site), and adds scope (owned by the key). This distinguishes it from sibling tools like create_publish_key or list_sites.
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 deleting sites owned by a key but does not provide when-not-to-use guidance or mention alternatives. The requirement for a key is stated but no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detach_domainCInspectDisconnect a custom domain from a site the key owns. Requires a key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| name | Yes | ||
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must compensate. It only states the basic action and a prerequisite. It does not disclose behavioral traits such as whether the action is destructive, any side effects on the site, rate limits, or authentication requirements beyond the key.
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 short (two sentences) and front-loads the action. However, it sacrifices critical information for brevity. Every sentence serves a purpose, but the overall conciseness results in under-specification.
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 lack of annotations, output schema, and parameter details, the description is incomplete. It fails to clarify input semantics, success/failure indicators, or what happens post-detachment. For a tool with three required parameters and no additional schema richness, more detail is needed.
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%, meaning the schema provides no parameter descriptions. The description does not explain any of the three parameters ('key', 'name', 'domain'). The phrase 'from a site the key owns' vaguely relates 'key' to ownership, but 'name' and 'domain' remain completely unexplained. This is insufficient for an agent to fill in the parameters correctly.
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 (disconnect) and resource (custom domain from a site owned by the key). It distinguishes from the sibling 'attach_domain' by using 'disconnect' and 'custom domain'. Could be improved by specifying that the site must own the domain, but overall it is specific.
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. The description only mentions 'Requires a key' as a prerequisite but does not advise on scenarios where detaching is appropriate or warnings about consequences. Lacks when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balanceAInspectGet this key's prepaid credit balance (USD) and recent ledger (top-ups and monthly no-ads charges). Requires a key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | boom_sk_ key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations so description bears full burden. The verb 'Get' implies read-only, but no explicit statement about side effects, required permissions, error handling, or rate limits. Provides minimal behavioral context beyond the obvious.
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 efficient sentences, front-loaded with purpose. No redundant or extraneous information.
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 has no output schema. The description gives a general idea of return content (balance, ledger) but lacks specific format, structure, or pagination details. Adequate but could be more precise.
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 covers 100% of the single parameter with 'boom_sk_ key.' description. The tool's description only says 'Requires a key,' adding no new meaning beyond the schema. Baseline of 3 is appropriate.
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 retrieves a prepaid credit balance and recent ledger for a given key, specifying currency and ledger contents. It distinguishes from sibling tools like buy_credits or list_topup_packs.
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 when to use (checking balance/ledger) but does not explicitly state when not to use or provide alternatives. It lacks guidance on preferring other tools for related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_siteBInspectGet the status of one site owned by this key (exists / live URL). Requires a key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| name | 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 implies a read operation ('Get the status') but does not explicitly state read-only nature, side effects, or authentication details beyond requiring a key. Inadequate for a tool with no 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 short (one sentence), but it omits critical details such as parameter explanations and return value. It is terse, not efficiently informative.
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 lack of output schema, no annotations, and two parameters, the description is incomplete. It does not explain the return format, what 'status' entails, or how the URL is provided. Sibling tools are listed but not differentiated in usage context.
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?
With 0% schema description coverage, the description should explain the parameters. It mentions 'key' but not the 'name' parameter, leaving its role ambiguous. The description does not compensate sufficiently for the missing schema descriptions.
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 specifies the verb 'Get', the resource 'status of one site', and adds clarifying examples 'exists / live URL'. It clearly distinguishes from sibling tools like list_sites (which lists all sites) and check_name.
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 states 'Requires a key', which is a usage prerequisite, but provides no guidance on when to use this tool versus alternatives like list_sites or check_name. Context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_domainsCInspectList a site's custom domains with live status (delegated, TLS ready, live). Requires a key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'live status' but fails to specify whether the tool is read-only, potential side effects, rate limits, or authentication details beyond requiring a key.
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 front-loaded with the main action, but it is too terse and omits essential details. Every word is earned, but the result is under-specification.
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 absence of an output schema and two parameters with no descriptions, the description is incomplete. It does not cover input details, return format, or error conditions, making it insufficient for reliable tool invocation.
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%, yet the description adds no meaning to the parameters 'key' and 'name'. It does not explain what these parameters represent, their format, or how they relate to the site.
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 verb 'list', the resource 'custom domains', and the outcome 'live status (delegated, TLS ready, live)'. It distinguishes this tool from siblings like 'attach_domain' and 'detach_domain'.
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 'Requires a key' as a prerequisite but provides no guidance on when to use this tool versus alternatives like 'list_sites' or 'get_site'. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sitesBInspectList the sites owned by this key (name, live URL, updated time). Requires a key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | boom_sk_ key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose any behavioral traits such as read-only, side effects, rate limits, or error handling.
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?
Single sentence, front-loaded with primary action, no wasted 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?
Missing output schema; description gives only a hint of return fields but lacks details on format, pagination, or error conditions. For a list tool with no annotations, more context is needed.
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 100% with description of the key parameter. Description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
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 verb 'List', resource 'sites', and scope 'owned by this key'. Provides hint about returned fields (name, live URL, updated time).
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?
Only states 'Requires a key' but does not explain when to use this tool versus siblings like get_site or list_domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_topup_packsAInspectList the credit top-up amounts (in USD) and the monthly no-ads price. No key needed. Credits are prepaid; $2/site/month (deducted from the balance) removes the boomurl banner.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes that no key is needed and explains the credit deduction mechanism for removing ads, but does not disclose potential side effects, authorization needs, or error conditions. Since no annotations exist, the description partially covers behavioral traits.
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 long, front-loads the core purpose, and includes only necessary extra context (no key needed, credit usage). 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 parameterless tool with no output schema, the description is fairly complete: it lists what is returned (amounts and monthly price) and explains how credits work. It could optionally describe the output format, but overall it covers the essential context.
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 no parameters, and schema coverage is 100%. Per guidelines, a baseline of 4 is appropriate as there is no need for parameter explanation.
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 lists credit top-up amounts in USD and the monthly no-ads price, using a specific verb (list) and resource (top-up packs). This distinguishes it from sibling tools like buy_credits or get_balance.
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 explicit guidance is given on when to use this tool versus alternatives. The usage is implied by the tool's nature (listing packs), but there is no mention of contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_siteAInspectCreate or update (idempotent) a static site the key owns. files maps relative path -> file contents. No index.html required — a lone .md/.txt/.pdf becomes a page; index.html is the front door when present. Returns the live URL. Requires a key from create_publish_key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | boom_sk_ key from create_publish_key. | |
| name | Yes | Site name (lowercase slug). | |
| files | Yes | Map of relative path -> file contents (UTF-8, or base64 when base64=true). | |
| base64 | No | Treat file values as base64 (for binary files like images). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses idempotency, file handling rules (index.html behavior), return value (live URL), and authentication requirement. No annotations provided, so description carries full burden and does so thoroughly.
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, front-loaded with purpose, then details, then return and requirement. No redundant information.
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?
Covers purpose, parameters, return, and prerequisite. No output schema, but return is described. Missing error conditions or rate limits, but sufficient for the tool's modest 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?
Schema coverage is 100%, baseline 3. Description adds meaning: explains key source, name requirement, file mapping, and base64 parameter. Extra context beyond schema schemas present.
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 creates or updates a static site, is idempotent, and explains file mapping. Distinguishes from sibling tools by referencing prerequisite key from create_publish_key.
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?
Describes when to use (create/update static site) and prerequisite (key from create_publish_key). Lacks explicit comparisons or when-not-to-use, but context from sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_publish_keyAInspectStep 1 of getting a publishing key (there are no accounts). Emails a 6-digit code to the given address. Then ask the user for that code and call create_publish_key.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The user's email address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses key behaviors: emails a 6-digit code, there are no accounts, and it is Step 1. Minor missing details like error handling or idempotency but not crucial for this simple 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?
Two sentences, zero wasted words. Front-loaded with purpose, immediately useful for an AI agent.
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 one simple parameter, no output schema, and no annotations, the description fully covers the tool's behavior and follow-up step. Complete for its complexity level.
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 100% but description adds context: the email is used to send a code. This goes beyond the schema's 'user's email address,' explaining the purpose and outcome.
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 two-step process to get a publishing key. It specifies the action (sends a 6-digit code to email) and distinguishes from the sibling 'create_publish_key' by indicating the next step.
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 describes the correct usage sequence: first call this tool, then ask the user for the code, then call create_publish_key. This provides clear when-to-use and excludes alternative paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_no_adsAInspectTurn the boomurl banner off (enabled=true) or back on (enabled=false) for a site the key owns. Enabling charges $2 from the credit balance immediately for a 30-day period and renews monthly while credits last. If the balance is too low it returns an insufficient_credits error — call buy_credits first. Requires a key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | boom_sk_ key. | |
| name | Yes | Site name. | |
| enabled | Yes | true = remove ads (charges $2/mo); false = stop renewing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses billing behavior ($2 charge for 30-day period, monthly renewal), error conditions (insufficient_credits error), and prerequisite (requires key, call buy_credits if needed). It does not mention idempotency or behavior if already in same state, but covers the most critical behavioral traits.
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 efficient, using three sentences to convey purpose, cost, error handling, and prerequisite. It is front-loaded with the main action. Could potentially drop 'while credits last' or combine sentences, but it remains clear and without waste.
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, the description adequately covers what a user needs: action, cost, renewal, error scenario, and prerequisite. It explains the business logic (insufficient credits) and how to recover. It does not describe the success response format, but for a simple toggle tool, this is sufficient for agent invocation.
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 covers all 3 parameters with descriptions (100% coverage), so baseline is 3. The description adds extra context: explains the 'enabled' boolean meaning (true = remove ads, false = stop renewing) and the billing implications. It also re-emphasizes the 'key' requirement. This exceeds the baseline by providing operational semantics beyond 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 clearly states the action: turn the boomurl banner off or on for a site. It uses specific verbs (turn off/on, enable/disable) and identifies the resource (boomurl banner for a site). It distinguishes from sibling tools like buy_credits or get_balance by being the only tool that directly controls the ad banner.
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 explicitly states when to use the tool (to turn ads off or on) and when not to (if balance too low, must call buy_credits first). It provides clear context for when to use alternatives (buy_credits) and mentions the prerequisite of having a key.
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!
