Read-only tokenized stock data: issuers, chains, contract addresses and corporate actions.
Scored across 8 tools
Each tool targets a distinct entity: get_contract (address halves), get_stock (stock aggregate), get_manifest (service metadata), plus list_/search_/report_ operations. get_contract vs get_stock could be momentarily conflated since both describe on-chain data at an address, but the descriptions sharply separate address-level code/listing data from stock-level aggregation.
Uniform snake_case verb_noun pattern throughout: get_contract, get_manifest, get_stock, list_chains, list_events, list_issuers, search_stocks, report_gap. Verbs (get/list/search/report) map predictably to operation type.
Eight tools for a read-oriented tokenized-stock registry is well-scoped: three getters, three listers/searchers, one write-ish reporting tool, one manifest. Nothing redundant, nothing conspicuously absent.
Covers discovery (search_stocks), enumeration (list_chains/issuers/events), detail (get_stock/get_contract), service metadata (get_manifest), and feedback (report_gap) — good lifecycle for a read-only API. The only gap is that the bulk dataset mentioned in get_manifest has no corresponding retrieval tool, and there is no pagination/limit control surfaced.
What this site holds about one address, in two independent halves. listings says what the token IS - the stock, its company, the issuer and the chain - and is present whenever the address is a listing we track. matches says what the CODE at the address is: its runtime bytecode hash, the implementation behind it if it is a proxy, and how many other addresses we track run byte-identical code; it is present only where we have read the code. The code half is reproducible: fetch eth_getCode and take its keccak256 and you get the same hash. Either half can be empty and both can be present; an address we hold nothing about returns found: false, which is an answer rather than an error. This never says an address is safe, genuine or correct, and there is no field that could: check it against the issuer before you act on it.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain slug, for example ethereum or robinhood-chain. Optional. Omit it to find the address on every chain we hold it. | |
| address | Yes | The contract address, in any case. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so richly: it discloses that the two halves are independent, that either or both may be empty, that a miss returns found:false rather than throwing, and that the code half is reproducible via eth_getCode + keccak256. The explicit safety disclaimer ('never says an address is safe, genuine or correct') is exactly the kind of trust-boundary context an agent needs before acting.
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 passage is dense and front-loaded, leading with what the tool holds before elaborating on each half. It is somewhat long and prose-heavy, but each sentence (reproducibility, found:false semantics, safety caveat) contributes distinct information rather than restating the name.
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, so the description must describe return values itself, and it does so thoroughly: it names both fields, explains when each is populated, and covers the empty and not-found cases. Combined with the safety framing, an agent has everything needed to call and interpret the result correctly.
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 both parameters (chain, address) are documented in the schema itself, including that chain is optional and address is case-insensitive. The description adds no parameter-level detail beyond what the schema already states, so the baseline 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 states a specific verb (look up) and resource (a contract address) and precisely enumerates the two returned halves, 'listings' and 'matches', so an agent knows exactly what domain the tool covers. It does not explicitly differentiate itself from siblings like get_stock or get_manifest, leaving the agent to infer the boundary from the resource 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?
Useful procedural guidance is present ('check it against the issuer before you act on it') and it clarifies that empty halves are normal and that found:false is an answer rather than an error. However, there is no explicit statement of when to reach for this tool versus get_stock or get_manifest, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What this service offers a machine reader: the free keyless endpoints, the bulk dataset and its price if the paid tier is live, and the licence. No human reader is ever charged or asked to connect a wallet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Everything known about one stock: every instrument (one per issuer, with the mechanics union describing how it handles corporate actions), every listing under it (chain, contract address, supply, price), and the events recorded against it. Report instruments as the options; listings are addresses. Read mechanics.kind before reaching for any field inside mechanics.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker or slug, for example NVDA or nvda. |
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.
Every chain carrying tokenized stocks, with its explorer, and the matrix of which issuer has listed what where. Registry order, which is not a ranking.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
The corporate-action tape: splits, distributions and multiplier changes read from chain state, each with a transaction hash. Newest first by the time the event took effect, which is chronology and not a ranking.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many events to return. Default 50, maximum 500. | |
| since | No | ISO 8601 date. Only return events effective on or after this date. |
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.
Every issuer whose tokens are tracked, in registry order, with the legal wrapper it uses, the chains it issues on, and a link to where that issuer publishes its own rule on who may buy. The rule itself is deliberately not included: it can change without this site noticing, so answer eligibility questions by sending the caller to eligibility.sourceUrl rather than by stating a rule.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses the ordering guarantee (registry order), the field contents, and — unusually — a deliberate omission (the eligibility rule) with the reason it is omitted (it can change without the site noticing). That is exactly the kind of behavior an agent cannot infer from an empty 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 what is returned, followed by the usage caveat. The second sentence is slightly long, but every clause (exclusion, rationale, correct behavior) 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?
There is no output schema, so the description must cover return content, and it does: it names the fields per issuer and the ordering. It also flags the key behavioral trap (do not state the rule) that an agent would otherwise get wrong.
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 nothing for the description to disambiguate; baseline for a zero-parameter tool applies. No misleading parameter claims are made.
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 verb (list) and resource (issuers) and enumerates exactly what each entry carries: legal wrapper, chains, and a link to the issuer's eligibility rule. This clearly distinguishes it from siblings like list_chains and list_events, which cover different resources.
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?
Gives an explicit usage directive for the common downstream question: answer eligibility questions by routing the caller to eligibility.sourceUrl rather than stating a rule. It does not contrast with sibling listing tools, but for a zero-parameter enumeration tool that guidance is the meaningful decision point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell us you wanted something and did not get it: a stock we do not track, a chain a stock is not on, a field no endpoint carries, a tool that does not exist, a figure you believe is wrong, or a path that failed. Call this when another tool has just answered with a miss - the answer names the kind to send. THERE IS NO FREE-TEXT FIELD AND THERE WILL NOT BE ONE: a report is an enumerated kind plus a short subject, because the counts are what is useful and prose from an anonymous caller is a prompt-injection surface pointed at the people who read it. Nothing about you is recorded - no address, no header, no identifier - so a report cannot be joined to a caller and there is no reply. The report is counted in aggregate and returned to you with a prefilled link a human can open to track it. Reporting costs nothing and is never required.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | What was missing. One of: missing_stock (A stock this site does not track at all.) missing_listing (A stock we track, but not on the chain the caller wanted.) missing_field (A field no endpoint carries.) missing_tool (An MCP tool that does not exist.) wrong_figure (A published figure the caller believes is wrong.) broken_endpoint (A path that failed or answered in an unusable shape.) | |
| subject | Yes | What it was about - a ticker, a field name, a tool name or a path. Letters, digits, dot, slash, hyphen and underscore, up to 64 characters. Not a sentence: there is no free-text field. A wallet or contract address is refused - send the ticker or the path instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly: it discloses the no-free-text design, the aggregate counting, the anonymity guarantee ("no address, no header, no identifier"), the absence of any reply, and that a prefilled tracking link is returned. It even explains the rationale (prompt-injection surface), which is unusually rich behavioral context.
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?
Front-loaded with what to report and when to call it, before the design rationale and privacy notes. It is longer than typical and the all-caps sentence plus the triple privacy list are slightly emphatic, but each sentence carries non-redundant 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 2-parameter, no-output-schema tool, the description covers everything an agent needs: the trigger, the required format, the enum mapping, what is returned, the anonymity/no-reply expectation, and that it is free and optional. No meaningful gaps remain.
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%, so the baseline is 3, but the description adds real meaning beyond the schema: it reinforces that subject is not a sentence, gives accepted character classes, and explicitly states wallet/contract addresses are refused in favor of a ticker or path. The kind enum values are also tied to their triggering miss conditions.
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 action (send a report) and enumerates the exact kinds of gaps it covers (missing stock, listing, field, tool, wrong figure, broken path), which no sibling tool does — all siblings are read/fetch tools. An agent can tell instantly that this is the meta/feedback channel rather than a data source.
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?
"Call this when another tool has just answered with a miss - the answer names the kind to send" gives an explicit trigger condition tied to sibling behavior, and "Reporting costs nothing and is never required" clarifies it is optional. Nothing about when vs. when-not is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tokenized stocks by ticker or company name. Returns every match with its issuers and chains, alphabetical by ticker. If a ticker is a real stock but has not been tokenized, this reports that too, which is a correct answer rather than an empty result.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A ticker (NVDA) or part of a company name (Nvidia). Case insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose real behavior: it returns every match with issuers and chains, orders results alphabetically by ticker, and — most valuably — explains that a real-but-untokenized ticker produces a reported non-match rather than an empty result. It omits pagination/result limits, but the edge-case semantics are non-obvious and well covered.
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?
Three short sentences with zero filler: purpose first, then return shape, then the surprising edge case. The most decision-relevant constraint (no fake empty results) is deliberately saved for last where it will be read.
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 and no annotations, the description does the work of explaining return contents, ordering, and the untokenized-ticker outcome. It stops short of covering result limits or how it relates to get_stock, but it is sufficient to call the tool correctly.
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% and the schema already documents the ticker/company-name format and case insensitivity, so the description adds no new parameter meaning. Baseline 3 applies when the schema does the heavy lifting.
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 (Find) and resource (tokenized stocks) with the matching key (ticker or company name), which is enough to separate it from a singular lookup like get_stock. It never names a sibling, so the differentiation is inferred from the plural 'search' framing rather than stated.
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 a discovery use case ('by ticker or company name') but never says when to pick this over get_stock or the list_* tools, nor what conditions make it the wrong choice. No alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
report_gapget_contractget_manifestget_stocklist_chainslist_eventslist_issuerssearch_stocksTokenized US stocks onchain: listings, holdings, US prices, pre-filled trade links. Read-only.
Read-only market data for agents: prices, fundamentals, filings, options, credit, private markets.
Read-only public-company financials, KPIs, benchmarks, filings, and insider activity.
Read-only market research: index funds, event cards, CLOB data, fund analytics. No orders.
Add one secure layer between your agents and this server.