Get share links, publish and manage websites, artifacts and agents. No account needed.
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.4/5 across 6 of 6 tools scored.
Each tool targets a distinct resource and action: site lifecycle (publish, list, get, delete), access control, and design system retrieval. There is no overlap between tools, and get_site vs list_sites follows the standard singular/plural distinction.
All tool names follow a consistent snake_case verb_noun pattern (publish_site, list_sites, get_site, delete_site, set_site_access, get_design_system). Verbs clearly describe the action and nouns the target resource.
Six tools is well-scoped for a website publishing server: covering creation, retrieval, listing, deletion, access control, and design guidance. Each tool earns its place without unnecessary bloat or gaps.
The tool surface covers the full site lifecycle: publish (create/update via token or name), read (get_site), list (list_sites), delete (delete_site), and access management (set_site_access). The design system tool fills a prerequisite for building pages, and no critical operations are missing.
delete_siteDelete a websiteAPermanently delete a website and stop serving it. Identify it by name, which requires connecting a Valet account, or by the site_token returned when it was published anonymously — whoever published a site can always take it down. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The site's name. Requires a connected Valet account. | |
| org_name | No | The Valet organization the site belongs to. Omit to use the organization the account joined first. | |
| site_token | No | The token returned when the site was published anonymously. It identifies that one site. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description adds critical behavioral details: the deletion is permanent ('This cannot be undone'), and it clarifies the auth requirements and ownership rule ('whoever published a site can always take it down'). This is substantial context that the annotations do not provide.
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 three sentences, front-loaded with the primary action, and each sentence adds essential information. No wasted words 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?
For a simple destructive tool with no output schema, the description is complete. It covers the action, permanence, identification methods, auth requirements, and the rule that publishers can delete. The schema handles parameter details, and the description fills in the operational context effectively.
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 the baseline is 3. The description adds valuable meaning to the parameters by explaining that name requires a connected Valet account and site_token is the anonymous publishing token. It does not mention org_name, but the schema already describes it adequately, and the added context for the two identification paths goes beyond the 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 ('Permanently delete a website and stop serving it') with a specific verb and resource. It also distinguishes the tool from siblings like get_site and publish_site by focusing on deletion, and explains the two identification methods (name or site_token).
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 clear context for when to use the tool (to delete a site) and explains the prerequisites for each identification method: name requires a connected Valet account, while site_token works for anonymous publishers. It does not explicitly list exclusions or alternatives, but the purpose is unambiguous and the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_design_systemGet the design systemAGet the design system to follow before you build or substantially rewrite a page. Returns the caller's organization design system when it has one, otherwise a neutral default. Call it first, then follow what it returns — apply its palette, type scale, spacing, and layout — overriding only for what the user asked for on this page. Files a user supplies finished are published unchanged, not restyled. With no connected account it returns the default.
| Name | Required | Description | Default |
|---|---|---|---|
| org_name | No | The Valet organization whose design system to read. Omit to use the organization the account joined first. With no connected account the built-in default is returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behaviors beyond the readOnlyHint annotation: it returns the organization's design system or a neutral default, explains override rules ('overriding only for what the user asked for'), notes that user-supplied finished files are published unchanged, and describes the no-account fallback. This is rich, non-obvious context that adds significant value.
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 four sentences long, front-loaded with the purpose, then provides usage guidance, behavior specifics, and edge-case handling. Every sentence carries essential information with no redundancy or 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?
Despite having no output schema, the description covers the key return aspects (palette, type scale, spacing, layout), the default behavior, the no-account case, and how to apply the design system. For a read-only tool with one optional parameter, this is complete and actionable.
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 100% coverage for the single optional parameter org_name, including its behavior when omitted. The description adds no new parameter-specific information beyond the schema, so the 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's purpose: 'Get the design system to follow before you build or substantially rewrite a page.' It identifies the resource (design system), the action (get), and the scope (caller's organization or default), distinguishing it from sibling site-management 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 provides explicit usage guidance: 'Call it first, then follow what it returns' and specifies the context ('before you build or substantially rewrite a page'). It does not name alternatives or exclusions, but the context is clear enough 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.
get_siteGet a websiteAGet one website's URL, access mode, version, and expiry. Identify it by name, which requires connecting a Valet account, or by the site_token returned when it was published anonymously.
For a password-protected site read by name, the result also carries its current visitor password, so a member of the owning organization can recover the password to share.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The site's name. Requires a connected Valet account. | |
| org_name | No | The Valet organization the site belongs to. Omit to use the organization the account joined first. | |
| site_token | No | The token returned when the site was published anonymously. It identifies that one site. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that reading by name requires a connected Valet account and that password-protected sites return the current visitor password, which is sensitive. This context goes beyond the readOnlyHint annotation, which only indicates safety, and does not contradict it.
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 focused sentences, front-loaded with the core purpose. No redundant phrases; all information is directly relevant to using the tool.
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 output fields and access methods, which is sufficient given no output schema. It omits edge cases like ambiguity when both identifiers are supplied, but overall provides a complete picture for a read-only retrieval 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%, with each parameter described in the schema. The description adds some context around name vs token authentication but does not add new semantics beyond the schema's existing 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 clearly states the tool retrieves a single website's URL, access mode, version, and expiry, using either name or site_token. It distinguishes from sibling list_sites by focusing on one site and from get_design_system by targeting website settings rather than design system.
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 specifies two identification methods with prerequisites (connected Valet account for name; anonymous token for site_token) and a specific use case for password recovery. It does not explicitly exclude alternatives, but the context implies this tool is for retrieving one site's details, not listing all sites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sitesList websitesAList the websites in a Valet organization: name, URL, access mode, and when each was last published. It is the way to recover a site's name when an earlier publish has scrolled out of the conversation. Requires connecting a Valet account.
| Name | Required | Description | Default |
|---|---|---|---|
| org_name | No | The Valet organization to list. Omit to use the organization the account joined first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to state the tool is safe. It adds behavioral context by enumerating the return fields, explaining a recovery use case, and noting the account connection requirement. This is consistent with annotations and provides valuable context beyond them.
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: first sentence states the action and output fields, second sentence adds a use case and prerequisite. No fluff, front-loaded.
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 one optional parameter, annotations, and no output schema. The description enumerates return fields, gives a specific use case, and states a requirement, which covers the essential context. Minor omissions like pagination or sorting are not critical for this simple list 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 input schema has full coverage for the single optional parameter org_name, including the default behavior when omitted. The description mentions the organization context but does not add syntax or semantics 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's function: listing websites in a Valet organization with specific attributes (name, URL, access mode, last published). This distinguishes it from siblings like get_site, which retrieves a single site, and publish_site, which changes state.
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 an explicit use case: recovering a site's name when a previous publish has scrolled out of conversation, and mentions a prerequisite (connecting a Valet account). It does not explicitly name alternative tools or state when not to use this tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_sitePublish a websiteAPublish files as a live website on the public internet, served over HTTPS. Use it when a report, dashboard, document, or any answer with real layout reads better as a page than as text in the conversation. Before building or substantially rewriting a page, call get_design_system and follow what it returns.
Content is text written here: HTML, CSS, JavaScript, Markdown, JSON, SVG. Images, PDFs, video, and other binary assets are not supported on this surface — publish those with the Valet CLI.
Without a connected Valet account the site is published anonymously: it is public to anyone who has the link, and it may be removed 36 hours after it is created, unless it is claimed. The result carries a claim URL that moves the site into a Valet account and makes it permanent, and a site_token that updates the same site on a later call. Give that token back to revise the site instead of publishing a second copy of it; with an account, give the site's name instead.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The site's name, which becomes part of its URL. Omit to have one generated. Naming a site that already exists republishes it. Requires a connected Valet account. | |
| files | Yes | The site's files. One file named index.html is the minimum; add more for stylesheets, scripts, or further pages. | |
| org_name | No | The Valet organization to publish into. Omit to use the organization the account joined first. | |
| site_token | No | The token an earlier anonymous publish returned. Give it back to update that same site instead of creating another. | |
| idempotency_key | No | An opaque key of your choosing. Repeating a call with the same key returns the first call's result instead of publishing a second site, which makes a retry safe. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (destructiveHint, openWorldHint) are generic, but the description discloses key behaviors: anonymous sites are public, may be removed after 36 hours unless claimed, and the result includes a claim URL and site_token. It also mentions that naming an existing site republishes it. This richly exceeds annotation-only information.
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 structured in three clear paragraphs: purpose and when to use, supported content and exclusions, and behavioral details about anonymity/claim/token. Each sentence adds unique information and the length is justified by the tool's complexity. It is front-loaded with purpose, and no sentence is wasted.
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 5 parameters, 1 required, and no output schema, the description is complete. It covers purpose, constraints (HTTPS, public, 36-hour removal), prerequisites (get_design_system), exceptions (binary assets), return expectations (claim URL, site_token), and how to revise existing sites. No critical operational detail is missing.
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 100%, so the schema already covers all five parameters thoroughly. The description adds no new parameter-level meaning beyond what the schema already states (e.g., name republishes, token updates the same site). Baseline 3 is appropriate; the description does not compensate with additional parameter details.
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 pair: 'Publish files as a live website on the public internet, served over HTTPS.' It clearly distinguishes itself from siblings (delete_site, get_site, etc.) by stating the action and outcome, and adds the use case of converting reports/dashboards into pages.
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 ('Use it when a report... reads better as a page than as text'), instructs to call get_design_system before building, and directs binary assets to the Valet CLI as an alternative. Also explains the token mechanism for updating an existing site instead of republishing, which is strong when-versus-alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_site_accessSet website accessASet who can reach a website: public serves it to anyone who has the link, private serves it only to members of the organization that owns it, and password serves it to anyone who enters a shared visitor password. Requires connecting a Valet account.
Password mode takes the password as the password argument. It is a shared visitor password the owner hands to whoever should see the site, not a Valet credential, and it is at most 72 bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | public serves the site to anyone who has the link. private serves it only to members of the organization that owns it. password serves it to anyone who enters the shared visitor password. | |
| name | Yes | The site's name. | |
| org_name | No | The Valet organization the site belongs to. Omit to use the organization the account joined first. | |
| password | No | The shared visitor password. Required for password mode and rejected for the others. Anyone who enters it can open the site, so a site's owner passes it to whoever should see the page. At most 72 bytes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as mutating and destructive, so the description adds valuable context beyond them: the need for a connected Valet account, the clarification that the password is a shared visitor password and not a Valet credential, and the 72-byte limit. This meaningfully enriches the agent's understanding of behavioral requirements.
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 and front-loaded, with the first sentence establishing the core purpose and modes. The second paragraph adds essential password details. It is slightly redundant with the schema's mode descriptions, but each sentence contributes meaningful information and the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no output schema, and moderate complexity, the description covers the core purpose, mode behavior, a key prerequisite, and password semantics. It does not explain return values or error conditions, but those are less critical for a state-changing access-control tool with strong 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 schema already documents all parameters at 100% coverage, but the description adds extra nuance for the password parameter by emphasizing it is not a Valet credential and explaining the 72-byte constraint. This goes beyond the schema's basic description and helps the agent avoid a common misuse.
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 combination ('Set who can reach a website') and then immediately enumerates the three access modes with their exact meanings. This clearly distinguishes the tool from sibling names like delete_site, get_site, or publish_site.
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 context about what each mode does and mentions the prerequisite of connecting a Valet account, but it does not explicitly state when to use this tool over alternatives or include when-not-to-use guidance. Usage is implied through the mode definitions rather than explicitly contrasted with 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!
