Domains, static hosting, DNS and email forwarding. Publish with your AI. It never spends money.
Scored across 10 tools
Each tool maps to a distinct resource and action: deploy, list, domain search, payment link, domain pointing, free-link renaming, backend linking, award readiness, badge embedding, and account confirmation. The domain-related tools are clearly separable by read-only vs. payment vs. account rearrangement.
Most tools follow a snake_case verb_noun pattern such as deploy_site, list_sites, search_domain, point_domain, and set_backend. The noun phrases award_readiness and site_of_the_day_badge plus the single-word whoami are minor deviations, but the set remains readable.
Ten tools is well-scoped for a static-site hosting and domain-management server. Each tool covers a distinct workflow and none feels redundant or missing from the apparent scope.
Core deploy, update, list, domain, backend, and award workflows are covered. There is no explicit delete or unpublish site operation, which is a minor lifecycle gap, but agents can still handle most common tasks.
(needs account token) Check whether a site on this account is ready to be considered for an award. Read-only. No money. Returns favicon, share image, title and description, mobile viewport, page weight, custom domain, https, and a real page (not the DropTheHassle placeholder), each with a fix hint. Never buy anything without asking me. Never buy a domain, email or subscription for me without asking first. When something costs money, give me the payment link and let me pay.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | The public host of a site on this account, e.g. "example.com". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so the safety profile is covered. The description usefully enumerates what is checked (favicon, share image, mobile viewport, page weight, https, real page) and notes each comes with a fix hint. However it wastes trust on payment-policy boilerplate irrelevant to a read-only check.
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 final three sentences ('Never buy anything...', 'Never buy a domain...', 'When something costs money...') are boilerplate policy irrelevant to a read-only readiness check and inflate the description substantially. Front-loading of the purpose is fine, but the trailing content does not earn its place.
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?
With no output schema, the description compensates by enumerating the returned readiness signals and fix hints, and it covers the auth prerequisite and read-only nature. It is nearly complete for a one-parameter read-only tool, marred only by off-topic payment text.
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% and the single host parameter is fully documented in the schema with an example. The description adds only the '(needs account token)' auth note, so the baseline of 3 applies.
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 a specific verb+resource: 'Check whether a site on this account is ready to be considered for an award.' An agent can tell this apart from list_sites or deploy_site. It does not explicitly name a sibling it replaces, so it stops short of 5.
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 '(needs account token)' parenthetical gives a prerequisite, which is useful context. However there is no when-to-use/when-not guidance and no pointer to how to obtain the host (list_sites). Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
(needs account token) Rename a site's free link to .dropthehassle.app. Changing a public URL is the human owner's decision: propose the name first, and only call this with confirm=true after they explicitly said yes. Safe: the old link keeps redirecting to the new name. No money. Never buy anything without asking me. Never buy a domain, email or subscription for me without asking first. When something costs money, give me the payment link and let me pay.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The label only, e.g. "myproject" for myproject.dropthehassle.app. | |
| confirm | Yes | true ONLY after the human owner explicitly approved this exact name. | |
| site_id | Yes | The site to rename (from list_sites). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the safety flags (destructiveHint=false, readOnlyHint=false), and the description adds value beyond them: the account-token auth requirement and the redirect guarantee ('the old link keeps redirecting to the new name') that explains why the rename is safe. It does not describe failure modes or whether a name can be reclaimed later.
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 tool-specific content (rename, approve-first, redirect safety) is front-loaded well, but roughly half the text is generic payment policy ('No money. Never buy anything...') that is irrelevant to renaming a free link and is repeated boilerplate rather than tool guidance.
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 non-destructive mutation with no output schema and full schema coverage, the description supplies the auth requirement, approval gate, and redirect-safety behavior an agent needs. Only failure/revert behavior and post-rename verification are unaddressed.
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 name, confirm, and site_id are already documented — including that confirm requires explicit human approval, which the description merely restates. Baseline 3 applies since the description adds no syntax or format detail 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?
States a precise verb+resource: 'Rename a site's free link to <name>.dropthehassle.app', with the exact resulting format. The 'free link' scoping implicitly separates it from sibling tools like point_domain and search_domain, so an agent can tell what resource this mutates.
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?
Gives an explicit precondition workflow: propose the name first and only call with confirm=true after the human explicitly approves. It also states the change is the owner's decision, which is clear when-not-to-act guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Put a static site online on a free link. Pass files inline as {path, content, encoding} where encoding is utf8 or base64. This server cannot read a folder on your machine. The server chooses index.html, dist/, build/, out/, _site/ or public/. Do not pick the folder yourself. With a token: pass site_id to update that site. Omitting site_id fills the oldest reserved address on the account (from Get an AI code) instead of creating a second site. Without a token the site goes live anonymously and you MUST give the human the claim_url. Free only; never buys a name. Decoded files stay within the existing upload cap (100 MB signed in, smaller before the site is claimed). Never buy anything without asking me. Never buy a domain, email or subscription for me without asking first. When something costs money, give me the payment link and let me pay.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Optional: the address label for a NEW site, e.g. "myproject". Errors when taken, so propose another. | |
| files | Yes | Site files sent inline. Each item has path, content, and encoding utf8 or base64. Leave out node_modules, .git and hidden files. .well-known is allowed. | |
| site_id | No | Optional: an existing site to update. Omit it to fill the oldest reserved site on this account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly=false, idempotent=false, destructive=false) but say nothing about cost, auth, or limits. The description adds critical behavior beyond them: free-only, never purchases a name, upload cap of 100 MB signed in, and the claim_url obligation for anonymous sites.
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?
Front-loaded with the core action and the file contract, then the token/site_id logic. Slightly padded by three overlapping sentences forbidding purchases ('Never buy... without asking'), which restate one policy point.
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, but the description covers the one return-relevant item an agent needs (claim_url), plus auth modes, size limits, and folder-selection rules. Nothing needed to invoke it correctly 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 coverage is already 100%, so baseline is 3, but the description adds real meaning: site_id's reserve-vs-create semantics and the slug 'errors when taken' behavior are not fully spelled out in the schema. Inline file/encoding expectations are reinforced.
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?
Opens with a specific verb+resource+scope: 'Put a static site online on a free link.' It clearly distinguishes itself from siblings like list_sites, point_domain, and get_checkout_link by describing the actual deployment action.
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 routing rules: use a token + site_id to update, omit site_id to fill the oldest reserved address, omit the token to go live anonymously. It also tells the agent not to pick the folder itself and to hand the human a claim_url in anonymous mode — genuine when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
(needs account token) Get a payment link for a domain on one of your sites. The HUMAN opens and pays it; you never can. After payment the domain goes live on that site automatically. Only for sites on the user's account. For an anonymous site, give the human the claim link first. Never buy anything without asking me. Never buy a domain, email or subscription for me without asking first. When something costs money, give me the payment link and let me pay.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The domain to register, e.g. "myidea.com". | |
| extras | No | Optional extra domain names on the same payment. | |
| site_id | Yes | The site the domain should attach to (from list_sites). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annnotations only cover the safety/idempotency profile, so the description adds substantial value: it discloses the auth requirement ('needs account token'), the human-in-the-loop payment flow, and the post-payment consequence ('the domain goes live on that site automatically'). This is exactly the behavioral context an agent needs before invoking a money-spending tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core instruction is front-loaded and useful, but the closing three sentences all restate the same 'don't spend money without asking' rule, which is redundant padding rather than new 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?
For a 3-parameter tool with no output schema, the description covers the auth prerequisite, the payment flow, and the automatic post-payment state change. Only the shape of the returned link is unaddressed, which is minor given there is no output schema to reference.
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 name, extras, and site_id are already fully documented in the schema. The description adds no syntax, format, or constraint detail about the parameters themselves, so the baseline 3 applies.
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 a specific verb and resource ('Get a payment link for a domain') plus the scope constraint ('on one of your sites', 'Only for sites on the user's account'). It implicitly separates itself from search_domain/point_domain by framing this as the payment step, though it never names a sibling tool explicitly.
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?
Gives explicit when-to-use context and a clear prerequisite/alternative path: 'For an anonymous site, give the human the claim link first.' It also states the hard boundary that the agent itself can never pay and that the human must be asked first, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
(needs account token) List the account's sites with their live URL, status and the domains pointing at each. Use to find a site_id to deploy to or point a name at. Never buy anything without asking me. Never buy a domain, email or subscription for me without asking first. When something costs money, give me the payment link and let me pay.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds the auth prerequisite ('needs account token') that annotations do not express, which is genuine behavioral context for a read-only tool. The trailing purchase-policy sentences ('never buy...', 'give me the payment link') are agent conduct rules tangential to a read-only listing tool, so they add length rather than relevant behavior.
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 core purpose and use case are front-loaded and efficient, but three sentences restate the same 'ask before buying' rule, which is redundant and pads a description that otherwise needed two sentences.
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, and the description compensates by describing the returned shape (URL, status, domains) plus the auth requirement, which is what an agent needs to call and consume this tool. The purchase warnings are extra but harmless to completeness.
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?
Zero parameters, so the baseline is 4; there is nothing for the description to compensate for and it correctly avoids describing nonexistent options.
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 a specific verb and resource ('List the account's sites') and enumerates the returned fields (live URL, status, pointing domains). It also positions itself against siblings by naming its downstream use ('find a site_id to deploy to or point a name at'), so an agent can distinguish it from deploy_site and point_domain without opening either schema.
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 the context of use: find a site_id for deployment or domain pointing. It gives clear positive guidance but names no exclusions or alternative lookup tools, so it falls short of the 5-level 'when-not/alternatives' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
(needs account token) Rearranges a domain already on the account. It does not buy a name and it does not edit DNS at someone else's registrar. No money. Never buy anything without asking me. Never buy a domain, email or subscription for me without asking first. When something costs money, give me the payment link and let me pay.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | A domain already on this account. | |
| to_site_id | Yes | The site to point it at (from list_sites). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=false, readOnlyHint=false. The description adds genuinely new context: an account token is required, no money moves, and the domain must already be on the account. It does not explain what 'rearranging' changes on the target site, but the added auth and no-cost disclosures go beyond the 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 front-loaded first sentence is efficient, but three of the remaining sentences repeat the same anti-purchase instruction in slightly different words ('never buy anything without asking', 'never buy a domain, email or subscription without asking', 'when something costs money, give me the payment link'). That redundancy consumes roughly half the description without adding tool-specific 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?
For a two-parameter idempotent mutation tool with no output schema, the description covers the auth prerequisite, the mutation scope, and the cost boundary. What is left implicit is the resulting state change on the target site, a minor gap given the annotations already signal safety and idempotency.
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 both parameters (domain, to_site_id) are already self-documented in the schema. The description restates that the domain must already be on the account, which duplicates the schema description rather than adding syntax or format detail. Baseline 3 applies.
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 first sentence states a specific verb+resource: rearranging/pointing a domain that is already on the account, which distinguishes it from search_domain (find) and get_checkout_link (purchase). The negative scoping ('does not buy a name', 'does not edit DNS at someone else's registrar') sharpens the boundary further. It stops short of the crispness of naming a specific sibling.
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?
Gives strong when-not guidance: this is not a purchase tool and not a third-party registrar DNS editor, so an agent knows not to route buying or external DNS tasks here. However, it never names the correct alternative sibling (search_domain, get_checkout_link) for those excluded cases, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a domain name is available to register and what it would cost (EUR). A full name such as myidea.com is one lookup, the same result as the website search. A name with no ending, such as mybakery, is checked as .com, .nl and .app, with availability and price for each. Works with no account. Read-only: use it to propose a REAL free name. Buying is a human step in the dashboard; this never spends money. Never buy anything without asking me. Never buy a domain, email or subscription for me without asking first. When something costs money, give me the payment link and let me pay.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A full domain such as "myidea.com", or a bare name such as "mybakery" (checked as .com, .nl and .app). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context: it works with no account, prices are in EUR, and buying is a human dashboard step that this tool never performs. The repeated 'never buy without asking' sentences add emphasis but little new 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 purpose and pricing behavior are well front-loaded. However, the final three sentences ('Never buy anything... Never buy a domain, email or subscription... give me the payment link') are substantially redundant with each other, diluting an otherwise efficient definition.
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?
There is no output schema, and the description compensates by stating what comes back (availability and price per TLD, in EUR) and that no account is needed. This is sufficient for a single-parameter read tool, though it could say more about result shape for multi-TLD lookups.
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% and the single parameter is fully documented in the schema, so the baseline is 3. The description restates the same full-name vs bare-name behavior rather than adding format or constraint detail 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?
States a specific verb and resource: check domain availability and price. It clearly separates this lookup action from siblings like point_domain and get_checkout_link, which perform different tasks. An agent can identify the intent without opening the schema.
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?
Gives concrete input-format guidance: a full name is one lookup, a bare name is checked across .com/.nl/.app, and it frames the use case ('use it to propose a REAL free name'). It also clarifies that buying is a separate human step. No sibling tool is explicitly named as an alternative, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
(needs account token) Link an HTTPS backend (Railway, Render, Fly, anywhere) behind a DropTheHassle name. With uploaded files the path rules (default /api/*) reverse-proxy to the backend and the rest stays static; without uploaded files the WHOLE site serves from the backend. WITHOUT site_id it creates a fresh FREE site first: a backend-only project goes live on its own link in one call. Perfect for a deploy script: call this with the new URL after every backend deploy. Pass url="" (with site_id) to unlink. No money. Never buy anything without asking me. Never buy a domain, email or subscription for me without asking first. When something costs money, give me the payment link and let me pay.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The HTTPS origin of the backend, e.g. "https://myapp.up.railway.app". Empty string (with site_id) unlinks. | |
| slug | No | Optional address label for a NEW site, e.g. "myapp" -> myapp.dropthehassle.app. Errors when taken. | |
| paths | No | Optional path rules for split mode, e.g. ["/api/*", "/webhooks/*"]. Default ["/api/*"]. | |
| site_id | No | Optional: an existing site to link (from list_sites). Omit to create a new free site served fully from the backend. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true). The description adds real state semantics beyond them: with uploaded files only /api/* (or supplied paths) is proxied and the rest stays static; without uploaded files the whole site serves from the backend; omitting site_id creates a new site. The trailing money warnings are off-topic for this tool but do not contradict the 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 first sentences are well front-loaded around the core behavior, but the block is dense and ends with four sentences of generic payment policy that have nothing to do with this tool and dilute the signal.
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 that can either create or link a site and switch between split and full serving, the description covers the decision-relevant modes and the unlink path; the only gap is what is returned (e.g. the new link), which is partially implied by 'goes live on its own link in one call' and there is no output schema requiring it.
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% and the schema descriptions already state the url="" unlink behavior, the slug format, the paths default, and the site_id omission semantics, so the description mostly repeats structured data. Baseline 3 applies when the schema does the heavy lifting.
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 a specific verb and resource (link an HTTPS backend behind a DropTheHassle name) and enumerates the two serving modes, which clearly separates it from siblings like deploy_site and point_domain. An agent can tell what this does without opening the schema.
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?
Gives explicit when-to-use guidance: call it with the new URL after every backend deploy, omit site_id to create a fresh free site, and pass url="" with site_id to unlink. Includes an explicit when-not/alternative condition (unlink vs link) rather than leaving it to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
(needs account token) Get the one line that embeds a Site of the day award, plus instructions for pasting it. The ribbon names the award and the period and links to the verification page. Read-only. No money. Pass site_id for a site on this account, or host for any confirmed winner. Omit both to list awards this account has earned. Never buy anything without asking me. Never buy a domain, email or subscription for me without asking first. When something costs money, give me the payment link and let me pay.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Optional. The public host that was featured. | |
| site_id | No | Optional. A site on this account (from list_sites). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the 'Read-only. No money.' line adds little. The genuinely additive context is '(needs account token)' and the description of the ribbon's contents, which stands in for a missing output schema. The three trailing sentences about never buying things repeat a policy rather than disclose tool behavior.
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 core sentence and the parameter modes are front-loaded and efficient, but three near-identical sentences about not buying domains, emails, or subscriptions without asking are irrelevant to this read-only tool and pad the description substantially.
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 two-optional-parameter read tool with no output schema, the description covers auth requirements, the three usage modes, and what the returned ribbon contains. It is largely complete; the main detraction is the off-topic purchasing boilerplate rather than missing information.
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, but the description goes beyond the schema by explaining the mutually exclusive modes (site_id vs host vs omit both to list), which the schema does not express. That is real added meaning.
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 a specific verb and resource: it returns an embed line for a Site of the day award plus paste instructions, and it names what the ribbon contains. It is clear on its own, but it does not distinguish itself from named siblings such as award_readiness or choose_link.
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 explicit selection rules: pass site_id for a site on this account, host for any confirmed winner, or omit both to list earned awards. This is a complete set of when-to-use branches with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm the connection. With no token this lists what already works: deploy_site and search_domain. With a token it names the account. Never buy anything without asking me. Never buy a domain, email or subscription for me without asking first. When something costs money, give me the payment link and let me pay.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and a closed world, so the safety profile is covered. The description usefully adds that an unauthenticated call enumerates deploy_site/search_domain while an authenticated call returns the account name, but it says nothing about failure modes and spends three sentences on purchasing rules that have little to do with a read-only identity check.
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 first two clauses are front-loaded and efficient, but 'Never buy anything without asking me' and 'Never buy a domain, email or subscription for me without asking first' are near-verbatim restatements, and the payment-link sentence repeats the same idea a third time. Roughly half the text is redundant.
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, read-only identity tool with no output schema, the description does cover the main return behaviors, so an agent can call it correctly. However, it omits any error/unauthorized behavior and pads the remainder with off-topic commerce policy that dilutes the signal.
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 takes zero parameters, so there is no schema semantics for the description to expand; baseline 4 applies. The implicit 'with a token' notion is ambient configuration rather than a parameter and is not misleading.
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 opening sentence 'Confirm the connection' gives a specific verb and states the tool's outcome, and the two clauses differentiate behavior with and without a token. It is clearly not the same as siblings like deploy_site or list_sites, though the naming of siblings here is about what the tool reports, not about routing to alternatives.
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 the usage context (verify credentials/connectivity before acting) and explains the two operational modes, but never explicitly says when to call it versus get_checkout_link or the other setup tools. The bulk of the text is purchasing policy rather than when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_domain1 field changedInput schema / properties / name / descriptionPrevious value: -"The domain to check, e.g. \"myidea.com\"."New value: +"A full domain such as \"myidea.com\", or a bare name such as \"mybakery\" (checked as .com, .nl and .app)."award_readinesschoose_linkdeploy_siteget_checkout_linklist_sitespoint_domainsearch_domainset_backendsite_of_the_day_badgewhoamiDomain search, registration, DNS, marketplace, and checkout with your AI agent.
Buy & manage domains from any AI chat: availability, register, DNS, email forwarding, AI bot stats.
Hosts AI-generated web content (HTML, images, SVG, JSON) at a public URL, with custom domains.
Internet identity for AI agents: register or broker domains, email, DNS - pay by card or USDC.
Add one secure layer between your agents and this server.
