YeetIt
Server Details
Instant web publishing for AI agents. POST HTML, get a live URL. No account needed.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Score is being calculated. Check back soon.
Available Tools
4 toolsdelete_websiteAInspect
Permanently delete a published website. The site will be immediately inaccessible. Requires authentication via edit_key or api_key, and requires confirm: true as a safety mechanism to prevent accidental deletion. Use this when a user explicitly asks you to remove or delete a site. IMPORTANT: Always confirm with the user before calling this tool — deletion cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The slug of the site to delete (e.g. "hello-world-k3m"). | |
| api_key | No | The user's API key (e.g. "yt_abc123..."). | |
| confirm | Yes | Must be set to true to confirm deletion. This is a safety mechanism — the tool will refuse to delete without explicit confirmation. | |
| edit_key | No | The edit key for this site (e.g. "ek_9c4d2e7f..."). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Excellent disclosure given no annotations: declares 'immediately inaccessible' effects, 'deletion cannot be undone' irreversibility, 'Requires authentication via edit_key or api_key' auth requirements, and 'safety mechanism' for the confirm parameter. Covers all 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?
Five sentences with zero waste. Front-loaded with purpose ('Permanently delete...'), followed by effects, requirements, usage condition, and safety warning. Every sentence earns its place with critical 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?
Comprehensive for a destructive mutation tool. Despite no output schema and no annotations, covers purpose, irreversibility, auth requirements, safety mechanisms, and mandatory confirmation. Sufficient 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?
With 100% schema coverage, baseline is 3. Description adds value by clarifying authentication can be via 'edit_key or api_key' (alternative options) and emphasizing confirm: true as a 'safety mechanism to prevent accidental deletion'—adding behavioral context beyond the schema's technical 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?
States specific verb 'delete' with resource 'published website' and scope 'permanently'. Implicitly distinguishes from siblings get_website_status (read), publish_website (create), and update_website (update) by specifying the destructive deletion operation on published 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?
Explicitly states when to use: 'Use this when a user explicitly asks you to remove or delete a site'. Also explicitly states when-not-to-use via mandatory confirmation requirement: 'Always confirm with the user before calling this tool'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_website_statusAInspect
Get information about a published website including its title, view count, size, expiry date, and whether it has been claimed. No authentication required — this is public information. Use this to check if a site is still live, see how many views it has gotten, or check when it expires.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The slug of the site to check (e.g. "hello-world-k3m"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Critically discloses 'No authentication required — this is public information' and lists specific return fields. Minor gap: doesn't mention error behavior when site not found.
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 optimally structured: first establishes capability + auth requirements, second provides usage examples. Zero waste, front-loaded with the critical 'public information' detail.
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 single-parameter read tool with no output schema, the description adequately compensates by listing return fields and authentication requirements. Implicitly covers the 'status' concept through listed fields.
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% (slug fully described with example in schema), so baseline 3 is appropriate. Description implies slug identifies the site but doesn't add semantic value beyond the well-documented 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?
Excellent specificity with verb 'Get' + resource 'published website' + detailed scope (title, view count, size, expiry, claimed status). Clearly distinguishes from mutation siblings (delete/publish/update) by nature of the operation.
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?
Provides explicit 'Use this to...' clause covering three scenarios (check if live, view counts, check expiry). Clear when-to-use guidance, though doesn't explicitly name sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_websiteAInspect
Publish HTML content to a live URL instantly. No account or API key required. Returns a public URL that anyone can visit. Sites expire after 24 hours unless the owner claims them. Use this when a user asks you to build, create, or deploy a website, landing page, invitation, portfolio, report, or any HTML content they want to share as a link. Supports bundled assets (CSS, JS, images) and multi-page sites (include additional .html files in assets, accessible at /{slug}/{pagename}). IMPORTANT: After publishing, always share the live URL and the claim URL with the user. The claim URL lets them take permanent ownership of the site. Store the edit_key from the response silently — do not show it to the user — you will need it if they ask you to make changes to the site later. If you lose the edit_key, ask the user to claim the site first (via the claim URL in the page footer), then provide you with their API key from the dashboard — you can use that instead.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | Complete HTML document to publish. Must be a valid, self-contained page. Inline CSS and JS are supported. External resources (images, fonts, scripts) must use absolute URLs OR be included in the assets field with relative references (e.g. href="./style.css" or src="./logo.png"). Maximum total size including assets: 5.0MB (free tier) or 10 MB (Pro/Business). | |
| title | No | Human-readable title for the published page. Used in social sharing previews and the claim page. Optional. | |
| assets | No | Optional map of filename to content for bundled assets. Keys are filenames (e.g. "style.css", "logo.png", "app.js"). Values are either plain text strings (for CSS, JS, SVG, HTML) or data URIs for binary files (e.g. "data:image/png;base64,iVBOR..."). Reference these in your HTML with relative paths like ./style.css or ./logo.png. For multi-page sites, include additional .html files (e.g. "about.html") which become accessible at /{slug}/about. Limits: 10 assets (free) or 50 assets (Pro/Business), 5 MB max per individual asset, but total site size (HTML + all assets) must be under 5.0MB (free) or 10 MB (Pro/Business). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Comprehensive disclosure despite no annotations: auth requirements ('No account or API key required'), data lifecycle ('expire after 24 hours unless claimed'), visibility ('public URL that anyone can visit'), and sensitive credential handling ('Store the edit_key...silently').
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?
Lengthy but efficient. Front-loaded with core capability, followed by usage triggers, then operational workflow (URLs to share, edit_key handling). Every sentence provides non-redundant instruction or constraint. Caps used sparingly for critical safety instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description fully compensates by detailing the response structure: 'Returns a public URL', 'claim URL', and 'edit_key from the response'. Covers both success outputs and security-critical follow-up requirements.
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?
While schema coverage is 100%, the description adds crucial conceptual context for the 'assets' parameter: 'Supports bundled assets (CSS, JS, images) and multi-page sites (include additional .html files in assets...)'. This explains the *purpose* and *pattern* of usage beyond the schema's technical structure.
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?
Specific verb 'Publish' with clear resource 'HTML content' and immediate scope 'live URL'. Distinguishes from siblings by emphasizing instantiation over modification (update_website) or removal (delete_website).
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?
Explicit trigger conditions: 'Use this when a user asks you to build, create, or deploy a website, landing page...'. Also defines post-hoc workflow (share both URLs, store edit_key silently) and recovery path if edit_key is lost (ask user to claim then use their API key).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_websiteAInspect
Update an existing published website with new HTML content. Requires authentication via edit_key (from the original publish response) or api_key (from the user's dashboard after claiming the site). The html field replaces the entire page — this is a full replacement, not a patch. You can also update assets. Use this when a user asks you to modify, edit, or change a site you previously published. IMPORTANT: You must provide either edit_key or api_key for authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | Complete HTML document to replace the existing page with. Must be a valid, self-contained page. This replaces the entire page content. | |
| slug | Yes | The slug of the site to update (e.g. "hello-world-k3m"). | |
| title | No | Optional new title for the page. | |
| assets | No | Optional map of filename to content. If provided, replaces ALL existing assets. Omit to keep existing assets unchanged. | |
| api_key | No | The user's API key from their dashboard (e.g. "yt_abc123..."). Use this if the user has claimed the site and provided their API key. | |
| edit_key | No | The edit key returned when the site was originally published (e.g. "ek_9c4d2e7f..."). Use this if you still have it from the publish response. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Provides critical behavioral details: authentication requirements (both methods), full replacement semantics ('not a patch'), and asset replacement behavior ('replaces ALL existing assets'). Omits rate limits or error behaviors but covers the essential mutation semantics.
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?
Six sentences covering purpose, auth, mechanics, assets, usage conditions, and auth requirements. Minor redundancy between auth explanation and 'IMPORTANT' auth restatement, but given security criticality this emphasis is earned. Well-structured flow from what → requirements → how → when.
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 mutation tool with zero annotations and no output schema, description adequately covers authentication, destructive replacement behavior, and asset handling. Explains the 'happy path' requirements sufficiently, though specific error scenarios (e.g., invalid slug) are not detailed.
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%, establishing baseline 3. Description adds valuable context beyond schema: explains edit_key comes from 'original publish response' and api_key from 'user's dashboard after claiming the site' — usage context not present in schema descriptions. Also emphasizes the destructive nature of the html replacement.
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?
Clear specific verb (Update) + resource (existing published website) + content type (new HTML). Distinguishes from sibling 'publish_website' by specifying 'existing' vs new, and from 'delete_website' by describing modification rather than removal.
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 this when a user asks you to modify, edit, or change a site you previously published.' References original publish response for edit_key, implicitly guiding toward publish_website for new sites. Could explicitly contrast with publish_website for new sites to reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail — every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control — enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management — store and rotate API keys and OAuth tokens in one place
Change alerts — get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption — public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics — see which tools are being used most, helping you prioritize development and documentation
Direct user feedback — users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!