Track domain, hosting, SSL and licence renewals. Check WHOIS and SSL expiry dates from chat.
Scored across 10 tools
Most tools have clearly distinct purposes: adding tracked items, listing tracked/upcoming renewals, account overview, SSL checking, and removal are well separated. The main overlap is between lookup_domain and check_domain_expiries, which both return domain expiry information, though bulk unauthenticated checks versus detailed single-domain WHOIS lookup are distinguishable from the descriptions.
All tool names follow a consistent snake_case verb_noun convention: add_*, check_*, get_*, list_*, lookup_*, and remove_*. The pattern is predictable and readable throughout.
Ten tools is well-scoped for a domain and renewal tracking service. Each tool covers a distinct operation or resource type, and there is no excessive surface area.
The surface covers the core lifecycle: adding domains, hosting and licence renewals; listing tracked items and upcoming renewals; checking expiries and SSL; viewing account limits; looking up domains; and removing tracked items. The notable gap is updating existing tracked items or alert settings, though remove-and-re-add provides a workaround.
Adds a domain to the signed-in user's TLDix tracking list so they get expiry alerts. Looks the domain up first; fails with a clear message if it is not registered or the plan's domain limit is reached. Adding a domain that is already tracked changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name, e.g. example.com. A URL or www. prefix is accepted and stripped. | |
| alert_days | No | Days before expiry to send email alerts. Defaults to all of 60, 30, 14, 7, 3 and 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by disclosing the internal lookup, the two failure modes with clear messages, and the no-op behavior on duplicates (reinforcing idempotentHint). It doesn't state permissions or what the success response contains, but with annotations covering safety profile this is solid added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core action and outcome, then failure modes, then idempotency. No filler.
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 2-parameter mutation with no output schema and full annotation coverage, the description covers purpose, failure modes, and idempotency. Minor gap: no mention of what a successful add returns or how alert_days interacts with the tool (though the schema handles that).
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 domain normalization (URL/www stripping) and alert_days defaults are already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, so 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 ('Adds a domain to the signed-in user's TLDix tracking list') plus the outcome (expiry alerts). This clearly separates it from lookup_domain (read-only lookup) and list_tracked_domains.
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 conditions: it looks the domain up first, fails if unregistered or the plan limit is reached, and is a no-op if already tracked. It doesn't explicitly name sibling alternatives like lookup_domain or list_tracked_domains, 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.
Adds a hosting plan renewal (provider, the site it hosts and its renewal date) to the signed-in user's TLDix list. Alerts go out 30, 7 and 1 days before the date.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name, e.g. example.com. A URL or www. prefix is accepted and stripped. | |
| provider | Yes | Hosting company, e.g. SiteGround. | |
| renewal_date | Yes | Renewal or expiry date in YYYY-MM-DD format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely new behavior: the notification cadence of 30/7/1 days and that the item lands in the signed-in user's list. It does not disclose what happens on a duplicate submission, which matters given idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The core action and scope come first, and the alert-schedule sentence carries distinct information rather than padding.
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 and three fully documented required parameters, the definition covers what an agent needs to call it. The remaining gap is post-call behavior: it doesn't say what is returned or whether an existing tracked entry causes an error or a duplicate, which is notable since idempotentHint=false.
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 baseline is 3. The description restates the three inputs (provider, hosted site, renewal date) but adds no format or edge-case detail beyond what the schema already says, such as URL stripping or the YYYY-MM-DD requirement.
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 (adds) and a precise resource (a hosting plan renewal, with its three fields), plus the scope (signed-in user's TLDix list). The specificity of 'hosting plan renewal' lets an agent distinguish this from add_domain and add_license_renewal without opening any 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?
Usage is implied by the alert schedule ('alerts go out 30, 7 and 1 days before the date'), which explains why one would track a renewal. But there is no explicit when-to-use guidance, no mention of when to prefer add_license_renewal or add_domain, and no stated preconditions or duplicate handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds a software licence, plugin, theme, SaaS subscription or other service renewal to the signed-in user's TLDix list. Alerts go out 30, 7 and 1 days before the date.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | What renews, e.g. "Elementor Pro". | |
| notes | No | Free-text notes (optional, up to 1000 characters). | |
| client | No | Client or reference this item belongs to (optional). | |
| category | No | Category such as plugin, theme, saas, email (optional). | |
| provider | No | Vendor (optional). | |
| renewal_date | Yes | Renewal or expiry date in YYYY-MM-DD format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the mutation/safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description's disclosure that alerts fire at 30, 7 and 1 days before the date adds genuinely useful post-call behavior. It also states the record is scoped to the signed-in user. It stops short of covering duplicate handling, which matters given idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste: the first establishes what is created and where, the second delivers the non-obvious consequence (alert schedule). Front-loaded and appropriately sized for a simple create 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?
For a 6-parameter create tool with full schema coverage, no output schema and informative annotations, the description covers purpose, scope and the alert side effect. The remaining gap — whether re-adding the same renewal creates a duplicate, given idempotentHint=false — is minor but would help.
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% — all six properties carry their own descriptions including the YYYY-MM-DD date format — so the schema does the heavy lifting. The description adds no per-parameter meaning beyond what is already structured, which is the baseline case.
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 (adds) and clearly scoped resource (software licence, plugin, theme, SaaS subscription or other service renewal) in the signed-in user's list. The type enumeration implicitly separates it from add_domain and add_hosting_renewal, but no sibling is named, so an agent must infer the boundary.
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 item types (licence/plugin/theme/SaaS/service) imply when to pick this tool over add_domain or add_hosting_renewal, but that routing is never stated and there are no explicit exclusions or prerequisites. Usage is inferred rather than declared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks up to 25 domains at once and returns each one's expiry date, days left and registrar, sorted by what expires first. Domains that time out are marked "pending" and can be checked again. Does not need a TLDix account.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Domain names to check (1 to 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the bar is lower; the description still adds real behavior: a hard 25-domain batch cap, a "pending" state for timeouts, and the fact that pending entries are re-checkable. It stops short of saying whether results are cached or rate-limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the highest-value facts (batch cap, returned fields, sort order) come first, with the timeout caveat and no-account note trailing.
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?
Absent an output schema, the description carries the return-value burden and does so by naming the three result fields plus the sort order and the timeout sentinel. Minor gaps remain around invalid-domain handling and the pending re-check mechanics.
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 a single parameter at 100% schema coverage, the schema already documents the 1-25 array bounds via minItems/maxItems and its own description. The description's "up to 25 domains at once" merely restates that constraint rather than adding format guidance such as accepted domain syntax or TLD handling.
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 verb and resource ("Checks up to 25 domains at once") and enumerates the returned fields (expiry date, days left, registrar), which lets an agent separate it from lookup_domain and check_ssl_certificate without opening any 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?
"Does not need a TLDix account" tells the agent this works without authentication, distinguishing it from the account-bound siblings like list_tracked_domains and list_upcoming_renewals. It also covers the retry path for timed-out domains, but never explicitly says when to prefer lookup_domain or the tracked-domain tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connects to the domain on port 443 and returns the TLS certificate's issuer, validity dates, days until expiry and the names it covers. Does not need a TLDix account.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name, e.g. example.com. A URL or www. prefix is accepted and stripped. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive behavior, so the bar is lower. The description still adds valuable non-structured context: it makes an outbound connection to port 443 and requires no account, which tells the agent about network dependence and auth needs. It does not mention failure modes for unreachable or expired certificates.
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, no filler, and the behavioral facts (port 443, returned fields) are front-loaded before the auth note. Every clause contributes information an agent would otherwise have to guess.
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, so the description compensates by enumerating the returned fields — issuer, validity dates, days until expiry, covered names. Combined with the auth disclosure and the fully documented single parameter, an agent has everything needed to call this correctly.
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% for the single 'domain' parameter, including the note that a URL or www prefix is accepted and stripped. The description adds no parsing or format detail beyond that, so the schema does all the work and 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 and resource — connects on port 443 and returns issuer, validity dates, days until expiry and covered names. The scope is unambiguous, though it never names a sibling it is distinguished from; the 'no TLDix account' note only implicitly separates it from account-scoped 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 line 'Does not need a TLDix account' tells the agent this tool requires no authentication, which is genuine usage context. However, there is no statement of when to prefer this over lookup_domain or check_domain_expiries, and no exclusion conditions, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the signed-in user's TLDix plan, how many domains, hosting and licence items they track against their plan limits, and the next five renewals.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description still adds genuinely behavioral detail: the result is scoped to the signed-in user and the renewals list is truncated to five, which is a disclosure an agent could not get from 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?
A single sentence that front-loads the resource and then enumerates the returned fields with no filler. Every clause carries information about the payload.
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 must describe return values, and it does so field-by-field. Minor gaps remain – it does not characterize the shape of nested objects (e.g. per-item renewal entries) or error cases such as an unauthenticated session – but an agent has enough to call and use 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?
The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-param tool applies. The description correctly implies that account scope comes from the session rather than from arguments.
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 concrete verb ('Returns') and enumerates the exact contents: plan, tracked domain/hosting/licence counts against plan limits, and the next five renewals. That said, it does not explicitly name the sibling it differs from (list_upcoming_renewals), leaving the agent to infer the distinction from 'next five renewals'.
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?
Usage is only implied – an agent can guess this is the dashboard/summary call, and 'against their plan limits' hints at a quota-checking use case. There is no explicit when-to-use, no statement of when to prefer list_upcoming_renewals or list_tracked_domains instead, and no prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the domains the signed-in user tracks in TLDix with expiry date, days left, registrar and which alert days are on. Supports a name filter and paging.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by soonest expiry (default) or by name. | |
| limit | No | Page size. Default 50. | |
| offset | No | Items to skip. Default 0. | |
| search | No | Only domains containing this text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: the result is scoped to the signed-in user, and it names the payload fields (expiry date, days left, registrar, alert days) even though no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The core listing behavior and scope come first, with the optional capabilities summarized after.
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 usefully names the returned fields, and annotations carry the safety semantics. What remains unaddressed is paging behavior on the response side (total counts, whether more pages exist), though that is a minor gap for a 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?
Schema description coverage is 100%, so all four parameters are already documented in the schema, including the sort enum and paging defaults. The description only restates the name filter and paging at a high level and omits the sort option, so it adds little beyond the schema baseline.
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 ("Lists the domains the signed-in user tracks") and enumerates the fields returned, so the agent knows exactly what it gets back. It does not, however, distinguish itself from close siblings like list_upcoming_renewals or check_domain_expiries.
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?
Usage is only implied: the scoping phrase "the signed-in user tracks" plus the mention of a name filter and paging hint at when this is appropriate, but there is no explicit when-to-use or when-not-to-use guidance against the renewal/expiry siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the signed-in user's domains, hosting and licence/service renewals that expire within the given number of days (already expired items are included), sorted by date.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-ahead window in days. Default 60. | |
| type | No | Which kind of item to include. Default all. | |
| limit | No | Maximum items to return. Default 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds real behavior: results are scoped to the signed-in user, expired items are included, and output is sorted by date. It does not describe pagination or response shape, keeping it short of a 5.
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?
A single sentence, front-loaded with the verb and resource, that packs scope, window and sort order with no filler. Nothing is wasted and the key constraint appears immediately.
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, three optional bounded parameters all fully documented, and rich annotations, the description covers what an agent needs to call it correctly. The remaining gap is return-value detail (ordering is stated, shape and count behavior are not), which is minor for a read-only 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?
Schema description coverage is 100% and all three parameters carry descriptions plus defaults and bounds, so the schema does the heavy lifting. The description only restates the days window and the item categories, adding no format or edge-case semantics beyond 'expired items are included'.
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 set (lists the signed-in user's domains, hosting and licence/service renewals) with the expiry-window scope and sort order. That is enough to separate it from check_domain_expiries and list_tracked_domains, though it never names those siblings 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?
The description implies usage through 'expire within the given number of days' and clarifies that already expired items are included, which is a meaningful inclusion rule. It gives no explicit when-not guidance or named alternative, so an agent must infer that targeted expiry checks belong to check_domain_expiries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up one domain in WHOIS/RDAP and returns whether it is registered, its expiry and registration dates, days until expiry, registrar, status codes and nameservers. Results may be cached for up to 48 hours. Does not need a TLDix account.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name, e.g. example.com. A URL or www. prefix is accepted and stripped. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent and non-destructive, so the safety profile is covered. The description adds real context beyond them: the upstream data sources (WHOIS/RDAP), a staleness caveat ('cached for up to 48 hours'), and that no account is required — all of which materially affect how an agent should trust and interpret results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action and the return set, then the two operational caveats (caching, no account). Nothing is redundant and nothing is buried.
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 carries the return-value burden and does so well by enumerating the fields. Minor gaps remain around edge cases — behavior on an invalid or malformed domain, and any rate limiting — but for a single-parameter read tool it is nearly complete.
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 single parameter already documents format, URL acceptance and www stripping, so the description needn't compensate. It adds no parameter detail at all, which is the baseline-3 case rather than a gap.
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 ('Looks up one domain in WHOIS/RDAP') and enumerates exactly what comes back: registration status, expiry/registration dates, days until expiry, registrar, status codes, nameservers. The word 'one' plus the enumerated return set distinguishes it from list_tracked_domains and add_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?
Usage is implied by the purpose ('look up a domain'), and 'Does not need a TLDix account' gives a useful precondition, but there is no explicit when-to-use/when-not guidance and no reference to the obvious alternative, check_domain_expiries, which an agent could easily confuse this with.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Removes one item from the signed-in user's TLDix list: a domain by name, or a hosting or licence item by the id shown in list_upcoming_renewals. Its alerts stop.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Item id, for type "hosting" or "license". | |
| type | Yes | Kind of item. | |
| domain | No | Domain name, for type "domain". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real context beyond that by naming the observable consequence ('Its alerts stop'), which tells the agent what effect the mutation has.
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 short sentences; the resource and scope come first, then the behavioral consequence. Nothing redundant and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, idempotent, non-open-world mutation with no output schema, the description covers the target, the identifier sourcing, and the user-visible effect. It could still say whether removal is reversible or whether errors occur for untracked items, but annotations carry most remaining weight.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description goes further by tying each type value to the correct parameter (domain name for 'domain', id for 'hosting'/'license') and telling the agent where that id originates. This resolves the conditional-parameter ambiguity faster than the schema alone.
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 ('Removes') and a precisely scoped resource: one item from the signed-in user's TLDix list, enumerating the three item kinds. It is clearly distinguishable from sibling add_* tools and from list_upcoming_renewals, which it references as the id source.
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?
Tells the agent exactly how to obtain the identifier ('the id shown in list_upcoming_renewals') and which identifier form each type takes, which is the main decision an agent faces here. There is no explicit when-not-to-use statement (e.g. that untracked items error), so it stops 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_domainadd_hosting_renewaladd_license_renewalcheck_domain_expiriescheck_ssl_certificateget_account_overviewlist_tracked_domainslist_upcoming_renewalslookup_domainremove_tracked_itemTrack domain and SSL certificate expiry for your agency clients from any MCP client.
SSL certificate, domain expiry, DNS and uptime monitoring for web agencies, grouped by client.
Track domain expiry, DNS, SSL and email security across registrars, and explain what changed.
Monitor website uptime, SSL certificates, DNS, domain expiry and page changes, and manage alerts.
Add one secure layer between your agents and this server.
