mcp-red-web-utils

deployer

Retrieves a Base token creator profile by address, so agents can verify deployment context before onchain actions; paid per call in USDC on Base via x402.

Instructions

Base token deployer profile (paid per call, USDC on Base via x402)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "deployer"
  }
}

Input Schema

Name	Required	Description	Default
`address`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

C2.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does add genuinely useful behavioral context: the call is paid, priced in USDC on Base via x402, which tells the agent to expect a payment handshake and a cost. It does not disclose what the response contains, failure modes for unknown addresses, or whether caching/retry is safe.

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?

One compact parenthetical phrase with zero filler and the payment constraint front-loaded. It is terse to the point of under-specification rather than being padded, so it scores well on structure but the terseness costs elsewhere.

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

Completeness2/5

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

For a paid, unannotated, no-output-schema tool, the description omits the identifier semantics, the expected return shape, and any error/payment-failure behavior. Payment disclosure is the one strong element; the rest of what an agent needs before spending USDC is missing.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the single parameter "address" is completely undocumented. The description never clarifies whether the address is the deployer wallet, the deployed token contract, or both — a critical ambiguity when calling an endpoint that takes only one identifier.

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

Purpose3/5

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

The phrase "Base token deployer profile" identifies the resource and chain, but there is no explicit verb (fetch/retrieve) and no differentiation from the sibling tool deployer_score, which sounds like it operates on the same entity. An agent can guess it retrieves a deployer profile, but the boundary between deployer and deployer_score is left to inference.

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

Usage Guidelines2/5

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

No statement of when to use this tool versus siblings such as deployer_score, reader, or metadata. The only usage-relevant fact given is the payment model, not selection guidance.

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

Deploy Server