Stocks On Chain

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple lookup by explicitly stating what the tool does NOT do ('never says an address is safe, genuine or correct') and explains the reproducibility of the bytecode hash (fetch eth_getCode and take keccak256). This is valuable context about limitations and methodology, though it doesn't mention side effects or error behavior.

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 medium-length paragraph packed with useful information, but it is not front-loaded and the opening phrase ('What this site holds about one address') is indirect. It could be more concise by leading with 'Gets registry and code details for a contract address' and then elaborating. Every sentence earns its place, but the structure could be improved.

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?

Despite lacking an output schema, the description enumerates the expected return fields (name, category, source, bytecode hash, proxy implementation, count of identical code), which gives the agent a clear idea of what to expect. It also includes the safety disclaimer and reproducibility note. It does not mention handling for unknown addresses or chain-specific behavior, but the schema covers chain filtering. Overall, it is reasonably complete for a read-only 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?

The input schema already provides complete descriptions for both parameters: 'address' (the contract address) and 'chain' (optional chain slug, with omission meaning all chains). The description adds no additional parameter semantics beyond what the schema provides. Since schema coverage is 100%, baseline 3 is appropriate.

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 what the tool retrieves: registry information (name, category, source) and code information (bytecode hash, proxy implementation, count of identical code) for a given contract address. It distinguishes itself from siblings like get_stock (stock lookups) and get_manifest by focusing on contract addresses, making its purpose specific and unambiguous.

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 implies the tool should be used when you need details about a contract address, but it does not explicitly state when to use it over alternatives or when not to use it. The safety caveat ('check it against the issuer before you act on it') is a caution, not a usage guideline. Sibling tools cover different domains, but the description doesn't point to them or provide exclusion criteria.

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?

Since no annotations are provided, the description carries full behavioral disclosure burden. It mentions the tool is free ('no human reader is ever charged or asked to connect a wallet'), but lacks details on rate limits, authentication, side effects, or other behavioral constraints.

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 short sentences that front-load the key information about what the manifest contains. Every word contributes to the description, with 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?

With no output schema, the description must explain return values. It lists the contents (endpoints, bulk dataset, price, license) but does not describe the structure or format of the returned data, leaving some ambiguity for an AI agent.

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, so the description does not need to add parameter semantics. Baseline of 4 is appropriate as no parameter information is required.

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 specifies exactly what the tool returns: free keyless endpoints, bulk dataset info (with price if live), and license. It clearly distinguishes this manifest tool from sibling tools like get_stock or list_chains, which serve different purposes.

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?

No explicit guidance on when to use this tool versus alternatives. The description only states what it returns, not the context or prerequisites for use.

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 burden. It includes a caution about reading `mechanics.kind` before other fields, which adds behavioral context. However, it does not disclose read-only nature, idempotency, or auth requirements.

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 two well-structured sentences plus a key caution, all front-loaded. Every sentence adds useful information with no redundancy.

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?

Given the tool's complexity (multiple sub-components) and no output schema, the description covers the main return types (instruments, listings, events) and provides structural hints. It is complete for practical use, though a brief note on output format would elevate it.

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 input schema covers the single parameter `ticker` with 100% description coverage. The description adds value by clarifying that ticker can be a slug and provides an example ('NVDA or nvda').

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 it returns 'everything known about one stock' and enumerates the components: instruments, listings, events. It distinguishes between instruments and listings, providing precise vocabulary.

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 implies use when you need full details on a single stock, but does not explicitly state when to prefer this over siblings or when to avoid it. No alternatives or exclusions are mentioned.

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 provided, so description carries full burden. It mentions completeness ('every chain') and ordering behavior, but does not disclose auth requirements or side effects. However, for a read-only list tool, this is minimally adequate.

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?

Single sentence with high information density, front-loaded with key details. Every word earns its place; no waste.

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 tool with no output schema, the description is mostly complete. It explains what is listed and ordering, though slightly more behavioral context (e.g., read-only nature) would improve completeness.

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?

No parameters defined; baseline is 4. The description adds value by explaining what the output contains (chains, explorer, matrix) and ordering, exceeding the baseline.

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 it lists all chains carrying tokenized stocks, includes explorer and issuer listing matrix, and notes the order is registry order, not ranking. This distinguishes it from siblings like list_issuers and search_stocks.

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?

No explicit guidance on when to use or alternatives, but the purpose is clear enough that an agent can infer usage for getting chain data. No exclusions or prerequisites mentioned.

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 full burden. It discloses that events are read from chain state and ordered chronologically (newest first). It does not mention side effects, error conditions, or rate limits, but for a read-only list operation it is fairly transparent.

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 concise sentences front-load the core function and ordering, with no fluff. Every sentence adds value.

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, but description covers event types, transaction hash, and ordering. It does not detail exact fields returned or default limit, but schema provides that. Overall adequate for a list endpoint with simple parameters.

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 100% (both parameters described). The description adds meaning by clarifying ordering semantics ('chronology, not ranking'), which helps interpret the 'since' parameter and overall output. This goes slightly beyond baseline.

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 it lists corporate actions (splits, distributions, multiplier changes) from chain state with transaction hashes. It is distinct from sibling tools like get_stock or list_issuers.

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 does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied by describing what it does, but no 'when to use' or 'when not to use' is stated.

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 exist, so the description carries the full burden. It excels: it discloses that the rule itself is deliberately excluded, explains the reason (it can change without this site noticing), and gives explicit guidance to send callers to eligibility.sourceUrl rather than restating the rule. This is far beyond a basic one-liner and helps set correct 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?

The description is two well-structured sentences. The first front-loads the core purpose and return contents. The second adds a critical behavioral caveat with a clear directive. Every phrase earns its place, with no superfluous language.

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?

Given the tool has no parameters, no annotations, and no output schema, the description covers all essential ground: what is returned, the design decision behind excluding the rule, and how to handle eligibility questions. There is no obvious missing context an agent would need beyond perhaps the exact response structure, which is not required here.

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 0 parameters and schema coverage is trivially 100%. Per the rubric, a score of 4 is the baseline for a parameterless tool. Nothing in the description changes this.

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 specifies the resource (every tracked issuer), the returned components (legal wrapper, chains, eligibility rule link), and the scope ('whose tokens are tracked'). It inherently distinguishes itself from siblings like list_chains and get_contract by defining its exact domain.

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 through the detailed caveat about not stating eligibility rules and redirecting to eligibility.sourceUrl, which tells an agent how to handle certain calls. However, there is no explicit statement of when to use this tool versus a named alternative, nor an explicit 'use this when...' formulation.

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 provided, but description discloses key behaviors: returns matches with issuers and chains, and handles untokenized stocks informatively. Adds context beyond schema.

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 purpose, no wasted words. Efficiently communicates all necessary 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?

Given single parameter, no output schema, and no annotations, the description fully covers functionality, return content, and edge case behavior. Complete for agent use.

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 covers parameter with description; tool description adds case insensitivity and value types (ticker or part of name), enhancing semantic understanding.

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?

Description clearly states verb 'Find' and resource 'tokenized stocks', distinguishing from siblings like get_stock or list_chains by focusing on search by ticker or company 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?

Provides guidance on interpreting results: untokenized stocks reported as correct answers, not empty results. Implicitly suggests when to use but lacks explicit exclusions or alternatives.

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