BULLY Crypto Agent

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

Annotations already declare readOnlyHint and openWorldHint, but the description goes well beyond: it discloses data sources (public RPC plus DexScreener/GeckoTerminal), that third-party market data is 'labelled unverified', that the swap simulation uses eth_simulateV1 with 'no transaction sent', and that 'Unreadable fields are reported as unknown.' These are exactly the operational facts an agent needs before trusting output.

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 opening clause is well front-loaded, but the remainder is one enormous run-on sentence enumerating roughly twenty returned fields. Since there is no output schema, the enumeration earns its place, yet it would read far better as a structured list rather than a comma-spliced block.

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 tool with no output schema, the description compensates well by enumerating the returned facts, naming the data sources, and stating coverage limits. The only missing operational detail is cost/latency for what is clearly a heavy multi-API call.

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 parameter at 100% schema description coverage, the baseline is 3. The description adds only the chain context (chain ID 4663) and the 0x-address assumption; the format itself is already fully specified by the schema pattern.

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?

Opens with a specific verb and resource: 'Read-only on-chain facts for one 0x contract address on Robinhood Chain (chain ID 4663).' The scope (single contract, specific chain) is unambiguous and clearly distinct from the sibling overview/disclaimer/links tools.

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 bounds the tool with negatives: 'Not a safety verdict, not an audit, no guarantee; other DEX designs and liquidity locks are not covered.' This tells the agent when the result should not be relied on. However, it never names a sibling alternative or a triggering condition (e.g. 'use get_bully_overview for the official contract'), leaving routing to inference.

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?

The annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by identifying the content as static press-kit facts rather than market data and noting that it includes the official contract and project disclaimer. It does not contradict the 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?

Two sentences deliver the tool's content, source, and exclusion with no wasted wording. The key scope limitation, "not market data," is front-loaded effectively.

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 no-parameter, read-only overview tool, the description is mostly complete about what it returns. However, because sibling tools separately expose contract and disclaimer data, the description does not clarify how this overview relates to those tools or whether it duplicates them, leaving a notable completeness gap.

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 has zero parameters and 100% schema description coverage, so there are no parameter semantics to explain. The description appropriately avoids unnecessary parameter detail, matching the no-input design.

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 that this tool returns an overview of American Bully ($BULLY), including official contract and disclaimer content, and distinguishes it from market data. It is specific about the resource and content type, but it does not differentiate the tool from siblings such as check_contract and get_disclaimer, whose content it appears to overlap with.

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 phrase "Static facts from the press kit, not market data" gives an implied usage boundary and one exclusion. However, it does not explain when to use this overview instead of check_contract, get_disclaimer, or get_official_links, so the agent must infer the right choice among siblings.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context about the nature of the content (a risk statement asserting the token is for entertainment, not financial advice), but says nothing about format, length, or whether the text is static.

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 short sentence with no wasted words, front-loading what the resource is before its substance. Nothing extraneous is included.

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 zero-parameter read-only tool with no output schema, the description gives enough to know what comes back: the project's own risk statement with its core claim. Only the return format is unspecified, which is a minor gap.

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 zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies a parameterless fetch of a single fixed statement.

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 specifically as "the project's own risk statement" and summarizes its content (entertainment token, not financial advice), so an agent knows exactly what it retrieves. It does not explicitly contrast with siblings like check_contract or get_official_links, but the resource is distinct enough that confusion is unlikely.

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 only implied: an agent can infer it should call this when it needs the project's risk disclosures. There is no explicit when-to-use framing, no mention of when a sibling such as check_contract would be preferable, and no stated prerequisites.

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?

Annotations already declare this a read-only, closed-world operation, so the safety profile is covered. The description adds that the content is 'official' (curated/authoritative) website pages and channels, which is mild but useful context; it says nothing about how many links, whether they are URLs, or how they are labeled.

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 short sentence with no filler, front-loading the resource type. It reads as a fragment rather than a statement of action, but nothing 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?

With no output schema, the description is the only source of return-value information and it only says 'website pages and project channels'. For a no-param link fetcher that is probably enough to call correctly, but the shape of the response (list of URLs, labels, categories) is unstated.

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 zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description does not misrepresent the input surface.

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 specifically ('official website pages and project channels') and ties it to the $BULLY token, so an agent knows this returns a curated set of links. It does not distinguish this from siblings such as get_bully_overview, which likely also surfaces project information.

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 guidance on when to call this versus get_bully_overview or the contract tools, and no stated preconditions. Usage is only inferable from the tool name itself.

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