aegis-x402-mcp

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

With no annotations, the description must carry the full behavioral burden, and it does disclose a useful trait: a per-call cost of $0.20 USDC on Base and the fact that checks are aggregated from multiple oracles. It does not say whether the call is read-only, what happens on an unknown or unsupported token, latency, or rate limits.

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 front-loaded sentence with the trigger condition first and no filler. The feature list is dense and slightly comma-spliced, but every clause carries information.

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 and no annotations, so the description is the only source of behavioral detail for a four-parameter, multi-check composite tool. It never describes what the response contains (verdict, scores, flags, mandate result), which is the biggest omission for an agent deciding whether to call it or how to consume the result.

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 75%, so the schema already explains tokenAddress, tradeAmountUsd, and counterpartyAddress. The description only indirectly maps its listed checks onto those parameters ('counterparty KYA' implies counterpartyAddress, 'spend mandate limits' implies tradeAmountUsd) and says nothing about the chain enum or required vs optional fields.

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 composite capability: honeypot audit across multiple oracles, DEX liquidity depth, counterparty KYA, and spend-mandate limits, all in one pre-swap call. It is distinguishable from siblings like aegis_token_audit or aegis_wallet_kya because it is explicitly framed as a bundle, though it never says 'returns' or otherwise pins down the action verb.

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?

'USE WHEN: An autonomous trading agent or sniper bot needs all-in-one pre-swap security' is a clear trigger condition with audience and timing spelled out. It lacks any exclusions or routing advice, so an agent doing only a single check gets no hint to prefer aegis_token_audit or aegis_wallet_kya instead.

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

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

There are no annotations, so the description carries the full behavioral burden. It usefully discloses cache bypass, priority execution, and a concrete price point ($0.05 USDC on Base). It does not explain payment/auth mechanics, failure behavior, or what an audit result contains.

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 front-loaded USE WHEN sentence with no wasted words, embedding cost and freshness up front. It is terse to the point of omitting operational detail, but nothing is padded.

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 two-parameter tool with no output schema and no annotations, the definition covers the 'why' (freshness, priority, cost) but not the 'how' (payment flow, expected return shape, per-chain differences). Adequate to select the tool, thin for invoking it confidently.

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 50%: chain is self-documenting via enum and default, while address has its own description. The description adds no meaning to either parameter — no note on address format per chain or which chain values are meaningful for the priority path. Baseline 3 fits.

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 specific verb and resource: a multi-oracle token security audit, qualified as 100% fresh, un-cached, and priority-executed. That scope distinguishes it from the plainer aegis_token_audit sibling, although it never names the alternative 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?

It gives an explicit use condition: a sniper bot or high-frequency trading agent that requires a fresh, un-cached audit. That is a clear context for selection. It stops short of stating when NOT to use it or routing to aegis_token_audit for cheaper, cached lookups.

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

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 useful context: the tool is FREE, covers Base only, and returns settled/verified audits rather than pending ones. It omits how many records come back, whether results are paginated or time-windowed, and whether the agent should poll for a live stream — gaps that matter for a monitoring tool with zero annotation coverage.

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 front-loaded clause with the trigger condition first and no filler — efficient. It is arguably too terse for a feed tool, since a second clause on return shape would have earned its place, but nothing present is wasted.

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?

Zero parameters makes invocation trivial, so the only real unknown is the return shape, and with no output schema the description should describe it — it does not say how many audits, over what window, or in what form. Coverage of chain, cost, and verification status is a helpful partial, but the response contract is left entirely to inference.

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 no parameter semantics to explain and the baseline of 4 applies. The description correctly implies the tool is callable without any input, consistent with the empty schema.

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 specific resource domain (verified on-chain settled token audits on Base) and implies a recency/stream view, but never states the actual operation — e.g. 'returns the most recent audits' — so the agent must infer that this is a list/feed tool rather than an audit-execution tool. It does not distinguish itself from siblings like aegis_token_audit or aegis_priority_audit by name.

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 'USE WHEN: Monitoring the real-time stream...' framing gives an implied trigger condition, which is better than nothing. However, there is no when-not guidance and no routing to alternatives, which matters here because several siblings (aegis_token_audit, aegis_priority_audit, aegis_preflight_bundle) could plausibly be chosen for audit-related needs.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses a cost of $0.01 USDC on Base, which is useful, but it does not explain permissions, rate limits, whether the operation is read-only, what happens for unsafe tokens, or what the audit result contains.

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 a single front-loaded sentence and wastes no words. It is concise, though the brevity contributes to gaps in behavioral and parameter detail.

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 paid audit tool with no annotations and no output schema, the description is too sparse. It gives usage timing and price but does not explain the audit output, result interpretation, supported-chain behavior, or operational constraints.

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 50%: the address parameter is described in the schema, while the chain parameter only has an enum and default. The description adds no meaning about the address, the supported chains, or when to use a non-default chain.

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 clear purpose: verifying token contract security, honeypot traps, and buy/sell taxes before a swap. It is specific enough to distinguish auditing from generic token data lookup, though it does not explicitly differentiate from sibling tools such as aegis_priority_audit or aegis_preflight_bundle.

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 'USE WHEN' phrasing gives clear timing: before executing a token swap. It does not state when not to use the tool or name alternatives among the sibling audit tools, so it falls 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.

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

With no annotations, the description must carry the behavioral burden. It usefully discloses two traits an agent could not infer: the call is free/no-payment and the security data is only partial. It does not say what 'partial' covers, whether results are cached or rate-limited, or what happens for an unknown/invalid token.

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 compact sentence with the usage trigger front-loaded and no filler. It reads as a sentence fragment rather than a full statement of purpose, but every clause adds information.

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 two-parameter read tool with no output schema, the description covers the data categories returned, which is the essential piece. It omits chain-specific behavior and the shape/limits of the response, so an agent still has gaps before calling it confidently.

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 description never references either parameter. With only 50% schema coverage, the address param is documented only by the schema's own sentence and the chain enum has no prose at all; nothing explains what chains are supported or what the default 'base' implies for result comparability.

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 the resource (any token) and the specific data returned: DEX market pool, price, and partial security flags. The qualifiers 'basic' and 'partial' implicitly separate it from deeper siblings like aegis_token_audit and aegis_priority_audit, though no sibling is named 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?

It opens with an explicit 'USE WHEN' condition, giving a clear trigger context. It stops short of stating when NOT to use it or routing to a named alternative (e.g. the full audit tool) when 'partial security flags' is insufficient.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses GoPlus sanctions sourcing and an apparent $0.01 USDC Base cost, but never states read-only/no state change, auth needs, rate limits, or response format, and the cost phrasing is ambiguous.

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?

One front-loaded 'USE WHEN' sentence with zero padding. Each clause contributes scope, trigger context, or cost information.

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 one-parameter check with no output schema or annotations, listing reputation, transaction count, balances, and sanctions flags tells the agent what comes back. It still leaves read-only status and exact response shape implicit.

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 single address parameter has 100% schema description coverage, including '0x EVM wallet or agent contract address on Base.' The description's 'counterparty wallet' adds little beyond the schema, 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?

Names a specific check and enumerates wallet reputation, transaction count, USDC/ETH balances, and sanctions flags, which separates it from token-audit and preflight siblings. It never explicitly contrasts those siblings, so the purpose is clear but not fully differentiated.

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?

Explicitly says 'USE WHEN' checking a counterparty wallet before transacting, giving a clear trigger context. It does not state when not to use it or name an alternative for token-level checks, so exclusions are absent.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does add real behavioral context beyond the schema: a $0.005 USDC cost on Base (a payment gate the agent must account for) and the output format (LLM Markdown). It omits rate limits, JS-rendering behavior, failure modes, and size limits, which matters for a tool with zero annotation coverage.

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 front-loaded sentence with the trigger condition first and the cost/output details trailing. 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 one-parameter, no-output-schema tool the description covers purpose, trigger, output format, and cost. Only operational details like error behavior and page-size limits are absent, which are minor for this simplicity level.

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 url parameter, so the baseline is already high. The description adds a constraint beyond the schema by specifying 'public URL', narrowing acceptable inputs.

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 (scraping) and resource (public URL) plus the transformation (page → clean LLM Markdown). The conversion output is a meaningful differentiator against the audit-oriented siblings, though it never names them directly.

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 'USE WHEN:' prefix gives a clear triggering condition: any public URL to be scraped. There are no explicit when-not conditions or named alternatives, but for a single-purpose scrape tool the trigger is unambiguous.

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