check_contract_freeFree, no wallet. Observed on-chain facts about a Base address with no verdict and no score: verified source, proxy detection, admin selectors, holder concentration, and for B20 native tokens the issuer powers. Rate limited; a monthly quota applies.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Contract or B20 token address on Base mainnet (eip155:8453), 0x + 40 hex. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description goes beyond these by adding operational constraints: rate limiting, a monthly quota, free usage, no wallet requirement, and the lack of a verdict/score in the output. This is valuable behavioral context not present in 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 description is three sentences with no filler: the first sentence front-loads the free/no-wallet value proposition, the second lists the fact categories, and the third covers the operational constraint. 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?
For a single-parameter tool with no output schema, the description is quite complete: it explains what the tool returns (fact categories), the scope (Base addresses and B20 tokens), and key constraints (rate limit, monthly quota, free, no wallet). The only minor gap is the lack of any detail about the response format, but the fact list largely compensates.
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 already fully describes the address parameter including its pattern and mainnet scope. The description's mention of 'Base address' and 'B20 native tokens' adds no new semantic meaning beyond what the schema already provides, so the baseline score 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?
The description clearly states a specific verb ('check') and resource ('Base address'), then enumerates the exact categories of observed on-chain facts it returns: verified source, proxy detection, admin selectors, holder concentration, and B20 issuer powers. It also distinguishes itself from the flash-audit siblings by explicitly saying 'no verdict and no score'.
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 provides clear context for when to use the tool: when you need free, no-wallet, fact-only observations on a Base address. The phrase 'no verdict and no score' implicitly signals that for verdicts or scores one should use a different tool, but it never explicitly names the sibling flash-audit tools or states when to prefer them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct stage: getting payment terms, initiating a paid audit, collecting its result, or performing a free on-chain check. The overlap between flash_audit_terms and the unpaid response from buy_flash_audit is clearly explained, so an agent can reliably tell them apart.
buy_flash_audit and collect_flash_audit follow a clear verb_noun pattern, but check_contract_free adds a trailing adjective and flash_audit_terms drops the verb entirely. The names are readable and descriptive, yet the conventions are mixed.
Four tools exactly cover the server's narrow scope: one free check, plus the three-step paid audit workflow of terms, buy, and collect. No tool feels redundant and the count is well below any bloat threshold.
The free check is a self-contained operation, and the paid audit flow is complete from fetching terms to buying and polling for the delivered report. There are no obvious dead ends or missing lifecycle steps for the stated purpose.