Skip to main content
Glama

Popdot AI

by ai.popdot

upgrade_trial

Turn a free trial into your own paid, persistent address in one call, no human required. Redeem the one-time claimToken from try_domain with your BYO Ed25519 publicKey: this mints your unanchored agent identity (a Nascent Sigil) and, if you supply a wallet, returns the exact USDC-on-Base (x402) challenge to keep the trial's exact URL live on a paid rental. No wallet yet? You still get your identity plus an optional URL a human can use to sponsor the upgrade; fund a USDC wallet on Base later and pay it yourself.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
durationNoOptional rental length: an ISO 8601 duration (PT1H, PT4H, P1D, P7D, P30D) or hourly/daily/weekly/monthly. Defaults to PT1H (1 hour).
publicKeyYesYour BYO Ed25519 public key. The minted identity is bound to it and you hold the private key.
claimTokenYesThe one-time claim token returned by try_domain / answer_trial_canary.
payerProofNoOptional EIP-191 personal_sign signature proving control of payerAddress.
payerAddressNoOptional 0x wallet you will pay from. Provide it (with payerProof) to receive a self-pay x402 challenge.
requestSponsorUrlNoSet true to also receive an optional URL a human can use to sponsor the upgrade.
payerProofIssuedAtNoOptional ISO 8601 timestamp of the payerProof, within 5 minutes.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sigilYes
upgradeYes
walletGuidanceNo
humanSponsorUrlNo
tierProgressionNoCurrent enforced trust tier and when it is next evaluated. Present only once an identity exists.
sigilEligibilityNoIdentity standing: lifecycle status, canary screen result, and any hard gates.
identityConfidenceNoHow firmly this identity is bound: unbound, bound to a key, or backed by a verified sponsor.

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses meaningful behavior: the claimToken is one-time, a Nascent Sigil identity is minted, a payment challenge is returned rather than completing payment, and no human is required. It also explains the optional sponsor-URL flow, giving the agent a clear model of side effects and next steps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences and front-loaded with the core purpose. It is somewhat dense and uses rhetorical phrasing ('No wallet yet?'), but every sentence earns its place by covering the main flow and both optional modes without unnecessary repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 7-parameter complexity, presence of an output schema, and annotations, the description is complete. It covers the precursor (try_domain claimToken), the two usage modes, the payment challenge outcome, and the sponsor fallback. Nothing critical is missing for an agent to decide when and how to call the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 adds cross-parameter context: it maps 'if you supply a wallet' to payerAddress/payerProof, 'No wallet yet?' to requestSponsorUrl, and explains the relationship between claimToken and try_domain. This goes beyond the raw schema descriptions by showing how parameters fit into the workflow.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action—'Turn a free trial into your own paid, persistent address in one call'—and then details the mechanism: redeeming a claimToken from try_domain with a BYO Ed25519 publicKey to mint an identity and optionally receive a payment challenge. This clearly distinguishes upgrade_trial from its siblings like rent_domain and try_domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly ties the claimToken to try_domain, establishing the precondition for use, and lays out two paths: with a wallet for self-payment, or without a wallet for a sponsor URL. It does not explicitly say when to use rent_domain instead, but the context strongly implies this tool is for upgrading an existing trial.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Popdot AI toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

The tools cover distinct phases of the domain rental workflow: searching, checking availability, quoting, renting, and trial management. However, search_domains and check_availability overlap slightly (both deal with availability), and answer_trial_canary is a step within the trial flow that could be confused with try_domain. Descriptions help clarify, but there's minor ambiguity.

Naming Consistency5/5

All tool names use consistent snake_case with a verb_noun pattern (check_availability, get_price_quote, rent_domain, search_domains, try_domain, upgrade_trial, answer_trial_canary). The pattern is uniform and predictable.

Tool Count5/5

7 tools is well-scoped for a domain rental service covering discovery, pricing, acquisition, and trial conversion. Each tool serves a clear purpose without redundancy.

Completeness3/5

The set covers the entire acquisition lifecycle from search to paid rental, including a trial path. However, there's no tool for managing existing rentals (e.g., listing own domains, extending, or canceling), which is a notable gap for a rental service.

Resources