Check, quote and register or renew Basenames (name.base.eth), paying in USDC on Base. No ETH needed.
Scored across 4 tools
Each tool occupies a distinct step in the registration workflow: check (free availability read), quote (create a priced quote), submit_payment (pay and trigger registration), and order (look up order status by id). There is no meaningful overlap between these purposes, so an agent can select correctly without confusion.
All four tools use the same namedrop_ prefix followed by a clear snake_case action/noun (check, order, quote, submit_payment). The convention is uniform and predictable throughout.
Four tools map cleanly onto the check → quote → pay → verify/status lifecycle with nothing superfluous. The count is well-scoped for a focused payment-gated registration service.
The core lifecycle (availability, quoting, payment submission, order status) is fully covered, and refunds are handled automatically on payment. Minor gaps exist, such as no tool to list prior orders or explicitly request a refund/cancellation, but agents can work around these.
Is yourname.base.eth available to register (or registered and renewable)? Free, read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Label without .base.eth, e.g. alice |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so 'Free, read-only' largely restates them. It does add one piece of real value by disclosing the two outcome branches (registerable vs. registered-and-renewable), but says nothing about the taken-and-not-renewable case or any latency/auth expectations.
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 compact clauses, the core question front-loaded, no filler. Slightly terse to the point of under-specification, but every sentence earns 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 carries the burden of explaining returns and does only half the job: it frames the available/renewable outcomes but omits what an unavailable, non-renewable result looks like. Adequate for a one-param read tool, not 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?
Only one parameter and schema coverage is 100%, so the schema already documents the label format ('alice', no .base.eth). The description's 'yourname.base.eth' example mildly reinforces the domain form, but adds no syntax the schema lacks — baseline 3.
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 (check) and resource (a .base.eth basename) plus the exact question answered: available to register, or registered and renewable. It is clearly distinguishable from the write-side siblings (order/quote/submit_payment), though it never names them 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?
'Free, read-only' implies this is the safe first step before the ordering flow, but the description never states when to use it or when to reach for namedrop_quote/order instead. Usage is inferred rather than taught.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status of a NameDrop order by id (paid, registered with tx, or refunded with tx).
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the bar is lower, but the description adds real value by disclosing the three terminal states and that a tx accompanies registered/refunded. It omits behavior for unknown ids or pending states.
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, with no filler. The parenthetical states are compact and informative.
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 partially shoulders that burden by naming the possible statuses. It does not cover not-found/error behavior, which keeps it from being complete for a lookup 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?
With one required parameter at 0% schema coverage, the description compensates by identifying it as an order id used for lookup. A single obvious id argument leaves little more to explain.
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 ('Status of a NameDrop order by id') and enumerates the possible states, so the agent knows exactly what comes back. It does not explicitly contrast itself with siblings like namedrop_check, so it falls short of the top mark.
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?
There is no statement of when to use this versus namedrop_check or namedrop_submit_payment, and no prerequisites named. Usage is only implied by 'by id' — the agent must infer this is a post-payment lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a 30-minute quote to register (to an owner address) or renew a Basename, priced in USDC on Base (live Basenames fee + gas + $1 service). Returns quote_id, exact usdc amount, pay_to and instructions. Nothing is charged by quoting.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| type | No | register | |
| owner | No | 0x address that will own the name (required for register) | |
| years | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by disclosing the 30-minute validity window, the exact pricing composition (live Basenames fee + gas + $1 service), and that nothing is charged. It does not explain auth prerequisites or whether re-quoting the same name is safe, despite idempotentHint=false. No contradiction with readOnlyHint=false, since a quote is a created object.
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, front-loaded with the core action and price model. Every clause carries information; the second sentence summarizes return fields efficiently without bloat.
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 correctly compensates by naming the return payload (quote_id, usdc amount, pay_to, instructions). The remaining gap is parameter-level detail on years and the type default, which matters for a purchase flow.
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 only 25%, and only the owner parameter is documented in the schema. The description recovers some meaning by naming register/renew (the type enum) and implying the name argument, but says nothing about the years parameter or its 1–5 bound.
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 — 'Create a 30-minute quote to register ... or renew a Basename' — and adds pricing context (USDC on Base). It does not name any sibling tool, but the clause 'Nothing is charged by quoting' implicitly separates it from namedrop_order and namedrop_submit_payment.
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 rather than stated: it is a quote, so it precedes an actual order, and the no-charge line hints at that relationship. There is no explicit 'use this before X, use Y instead when Z' guidance naming the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
After sending EXACTLY the quoted USDC on Base to pay_to, submit the quote_id and your Base tx hash. NameDrop verifies the transfer on-chain and registers/renews the name (or refunds the USDC if the name was taken first).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | register | |
| tx_hash | Yes | 0x-prefixed Base transaction hash of the USDC transfer | |
| quote_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and openWorldHint=true; the description goes well beyond by disclosing that the transfer is verified on-chain, that a name is registered or renewed, and that the USDC is refunded if the name was taken first. That failure/refund path is exactly the kind of consequence an agent needs before invoking a write 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?
Two sentences, front-loaded with the required precondition, then the outcome. No filler or redundancy; the parenthetical refund clause is load-bearing 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?
Covers the precondition, the two required inputs, and the success/failure outcomes, which is sufficient for a no-output-schema write tool. It omits whether resubmitting the same tx is safe, what happens if the tx amount/recipient is wrong, and how errors surface, which would fully round it out.
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 only 33% (only tx_hash is documented). The description clarifies that tx_hash is the Base tx hash of the USDC transfer to pay_to and that quote_id comes from the quoted payment, adding real meaning, but it never explains the 'type' enum's register/renew distinction or default, leaving a gap given low coverage.
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?
Names a specific action (submit the quote_id and Base tx hash after sending the quoted USDC), the resource (NameDrop name registration/renewal payment), and the effect (on-chain verification plus register/renew, with refund fallback). It is clearly distinguishable from siblings namedrop_quote, namedrop_order, and namedrop_check, which are pre-payment steps.
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?
States a clear precondition and trigger: call only after sending EXACTLY the quoted USDC on Base to pay_to, tying it to the prior quote/order flow. It does not name sibling tools or state exclusions (e.g., what to do if a quote expired), so it stops short of full routing 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.
namedrop_checknamedrop_ordernamedrop_quotenamedrop_submit_paymentBuy, sell and bid on vote-escrow NFTs and .base.eth names. Non-custodial, settles on Seaport.
Rent verified subdomains by the hour, day, or month. Free 24h trials, x402 USDC on Base.
Base token risk (honeypot sim), prices, balances, Basenames, tx data. Pay-per-call in USDC via x402.
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.
