Publish a school or teacher website for $1 USDC/month on Base. Agents upload a zip, inspect, then claim a hostname.
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.1/5 across 6 of 6 tools scored. Lowest: 2/5.
Most tools have distinct purposes: claim (go live), connect_custom_hostname (custom domain), edit (redeploy), inspect (scan), publish_website (orchestrator), upload_url (upload). However, 'claim' and 'publish_website' both relate to going live, creating slight overlap, but descriptions clarify roles.
Tool naming is a mix of short verbs (claim, edit, inspect) and verb_noun patterns (publish_website, connect_custom_hostname, upload_url). The style is inconsistent, but the names themselves are readable and generally indicative of their function.
6 tools is a reasonable number for a website deployment MCP server, covering core actions. The count is appropriate, not too thin or overwhelming.
The tool set covers the core lifecycle: upload, scan, claim, edit, and connect custom hostname. However, there are notable gaps: no delete/teardown tool, no listing or status check for existing sites, and no way to manage domains beyond adding one. These gaps could limit agents in managing ongoing site lifecycle.
claimCInspectGo live. $1 USDC first month. Ask the human before calling this.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | ||
| uploadId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description hints at a need for human approval but does not disclose side effects, permissions, reversibility, or any other behavioral aspects. With no annotations to supplement, transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with no unnecessary words. It is front-loaded with the main action, but its brevity sacrifices essential 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?
The description is severely incomplete. It lacks parameter explanations, output information, usage scenarios, and behavioral details, making it inadequate for a user to understand or safely invoke the 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?
The two parameters (slug, uploadId) are not described at all. The schema covers them, but the description provides no meaning or usage context, leaving them completely unexplained.
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 states the primary action ('Go live') but does not specify the resource or object being activated. While sibling tools suggest a hosting context, the description alone is ambiguous about what exactly goes live.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The instruction to ask a human before calling is a caution, not a usage guideline about appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
connect_custom_hostnameAInspectConnect an existing hostname via CNAME only (no registrar) — +$1 USDC / month
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| hostname | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the monthly cost ('+$1 USDC / month') and clarifies that it does not involve registration. However, it does not mention other potential side effects (e.g., DNS propagation, reversibility), though the cost and method are transparent.
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, concise sentence that conveys the core purpose, method, and cost without any redundant information. It is efficiently structured and easy to parse.
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 provides the main purpose and cost, but lacks explicit usage guidance, parameter explanations, and details on expected outcomes or edge cases. It is moderately complete but leaves several gaps given the minimal schema and annotations.
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 parameters 'slug' and 'hostname' are not explained in the description or schema. While 'hostname' is inferable from the context, 'slug' is ambiguous and no details are provided for either, leaving the user guessing about acceptable formats or meanings.
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 ('Connect an existing hostname') and the specific method ('via CNAME only'), which distinguishes it from other tools that might involve registration or different connection types.
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 implies when to use it ('no registrar') and mentions cost, but does not explicitly contrast with sibling tools or provide broader usage context. The absence of explicit alternatives makes it slightly less clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
editCInspectRe-scan and redeploy. Token-metered, floor $0.10 USDC. JS uses paid GLM.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| tokens | No | ||
| uploadId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full behavioral burden. It discloses token metering and a $0.10 floor, but omits side effects such as overwriting a deployment, authentication expectations, and the unclear meaning of 'JS uses paid GLM.'
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 brief and front-loaded, but the brevity is under-specification rather than efficient structure. The final clause about paid GLM is cryptic and adds little clarity.
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 three parameters, no output schema, and empty annotations, this is not sufficient. It does not explain what input values mean, what the call returns, or how a redeploy behaves beyond cost.
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 explain the parameters. It does not define uploadId, slug, or tokens; only a loose link exists between 'Token-metered' and the tokens property. Required parameters are effectively undocumented.
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 names a concrete operation ('Re-scan and redeploy') but does not identify the resource being edited or what 'edit' modifies. This is too generic to reliably distinguish the tool from siblings like publish_website or upload_url, though it is not a pure tautology.
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 no explicit guidance about when to use this tool versus any sibling. The token-metering sentence is a cost constraint rather than usage context; there is no mention of prerequisites or after-upload workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inspectCInspectScan an uploaded zip. Ask the human before going live.
| Name | Required | Description | Default |
|---|---|---|---|
| uploadId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral transparency. It mentions 'Ask the human before going live' but is ambiguous whether the tool itself prompts the human or the agent should ask. It omits details on scan behavior, return values, side effects, or permissions needed.
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 consists of two terse sentences with no filler. Both sentences contribute distinct information: the action and the workflow guidance. It is appropriately front-loaded and wastes no 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?
Given the single parameter and lack of output schema, the description is too sparse to be operationally complete. It doesn't cover what the scan produces, what happens after the human is asked, or any prerequisites, leaving significant gaps for the agent.
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 for uploadId, and the description does not explain what 'uploadId' refers to beyond the vague 'uploaded zip'. The agent cannot infer the expected value format or how to map it to the parameter.
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 ('Scan') and the resource ('an uploaded zip'), providing a specific verb and resource. It does not explicitly differentiate from siblings like edit or publish_website, but the distinct 'scan' concept is evident.
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 phrase 'Ask the human before going live' implies this tool is used as a pre-flight check before publishing, giving some usage context. However, it doesn't explicitly state when to use this tool versus alternatives like publish_website, nor does it provide exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_websiteAInspectPublish a website. ALWAYS ask the human first: go live for $1 USDC/month? content legal? Then: upload_url → PUT putUrl if you have the zip (else give dropUrl to the human) → inspect → claim. Never put the zip in chat.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It discloses the $1 USDC/month subscription gate, the legal-content check, the required multi-step sequence, and the guardrail 'Never put the zip in chat.' It does not describe failure behavior or revert options, but it offers substantial operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is well contained and every clause earns its place: the purpose, the human gate, the step sequence, the conditional path, and the zip-handling rule. The arrow-chain syntax is a bit dense but remains scannable and unambiguous.
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 0-parameter tool with no annotations and no output schema, the description covers the essential operational contract: steps for consent, pricing, content legality, orchestration, conditional handoff, and the no-zip-in-chat rule. It does not describe return values or failure modes, but the overall workflow is adequately specified.
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, so the baseline is 4. The description adds meaningful semantic context about implicit inputs and transfer flow ('PUT putUrl if you have the zip', 'else give dropUrl to the human'), which the empty schema cannot express.
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 states the verb and resource clearly: 'Publish a website.' The chained workflow (upload_url → PUT putUrl → inspect → claim) makes it obvious this is the end-to-end go-live orchestrator, distinguishing it from sibling primitives like upload_url, inspect, and claim.
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 usage context: 'ALWAYS ask the human first' with the specific consent and billing questions, and it defines a conditional path ('if you have the zip (else give dropUrl to the human)'). It lacks explicit when-not-to-use language, so it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_urlCInspectIf you have the zip, PUT putUrl yourself (max 3MB). Do not put zip in chat. Only send dropUrl to the human if you have no file.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full transparency burden. It does disclose the 3MB limit and some chat-behavior rules, but it does not explain side effects, failure modes, permissions, or what the agent should observe after uploading. It also relies on unexplained putUrl/dropUrl terms.
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 compact two sentences and contains no filler; each instruction is directly operational. However, the brevity contributes to ambiguity because key concepts like putUrl and dropUrl are never defined.
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 is structurally poor and lacks output schema or annotations. It does not explain what the tool returns, how dropUrl and putUrl relate, or what the human is expected to do with them. For a zero-schema tool with no annotation support, the description is under-specified.
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 zero parameters and 100% coverage, so semantic parameter depth is trivially satisfied. The description mentions putUrl and dropUrl, but they are not actual schema parameters, so there is no additional parameter meaning needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description never clearly states what the upload_url tool actually does. It instructs the agent to "PUT putUrl yourself" and mentions dropping the URL, but it does not define whether the tool creates a URL, uploads a file, or performs an HTTP request. The purpose is implied rather than explicitly explained.
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 gives concrete conditional instructions: if the agent has the zip, it should PUT to putUrl, must not put the zip in chat, and should only send dropUrl to the human if no file is available. This is explicit usage guidance, though it does not compare against sibling tools.
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!
