Read-only tokenized stock data: issuers, chains, contract addresses and corporate actions.
Scored across 7 tools
Each tool targets a distinct entity type (contract, manifest, stock, chain, event, issuer) with clear boundaries. Slight potential confusion between get_contract and get_stock when looking up a token address, but descriptions clarify the distinction (code record vs. listing/instrument data).
Consistent verb_noun pattern throughout: get_contract, get_manifest, get_stock, list_chains, list_events, list_issuers, search_stocks. The get/list/search prefixes map cleanly to single-lookup, enumeration, and search semantics.
Seven tools is well-scoped for a read-only registry-style service covering contracts, stocks, chains, issuers, events, search, and service metadata. Each tool earns its place with no redundancy.
Strong read coverage across all core entities plus search and a manifest. However, the surface is purely read-only with no way to paginate or filter events, and no tool to resolve the eligibility URL target, though that is arguably out of scope by design.
What this site holds about one address: the name and category our registry records and who told us, plus what the code at that address actually 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. The code half is reproducible: fetch eth_getCode and take its keccak256 and you get the same hash. An address that is a token listing but not in the contract registry returns the listing (stock, issuer, chain) with no code record. 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 whole burden and does substantial work: it states the hash is independently reproducible via eth_getCode + keccak256, that token-listing-but-not-registered addresses return a partial (listing-only) record, and that no field asserts safety or correctness. It omits auth requirements, error behavior for a wholly unknown address, and any rate-limit context, which keeps it below a 5.
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?
It is front-loaded with the payload summary and the later sentences each carry a distinct claim (reproducibility, partial-record case, safety disclaimer). The prose is dense and somewhat circuitous, but no sentence is pure 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 and no annotations, the description must describe returns, and it does so thoroughly, including the degenerate listing-only response and an explicit statement of what the data does not mean. It is nearly complete for a read-only lookup tool; only failure/empty-result handling is unaddressed.
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%, so the schema already documents both parameters, including the any-case address and the chain-omission-broadens-search behavior. The description adds no syntax, format, or default detail beyond that, so the 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?
It gives a concrete inventory of what is returned: registry name/category and source, runtime bytecode hash, proxy implementation, and count of byte-identical deployments. It also distinguishes the token-listing-only case from the contract-registry case. It stops short of naming which sibling to use instead (e.g. get_stock for a token listing), so differentiation is implied 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 explains result contents but never says when to reach for this tool versus get_stock, get_manifest, or the list_* tools. The closest thing to usage guidance is the closing caution to check the record against the issuer before acting, which is advice about trust, not tool selection. No exclusions or prerequisites are given despite six siblings.
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.
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.
get_contractget_manifestget_stocklist_chainslist_eventslist_issuerssearch_stocksRead-only public-company financials, KPIs, benchmarks, filings, and insider activity.
Read-only MCP server for Belarusian securities: tokens, shares, bonds, companies.
Read-only crypto and traditional portfolio: holdings, PNL, FIFO tax figures and market data.
SEC dilution data, live market data, and news for U.S. equities, with point-in-time as-of queries.
Add one secure layer between your agents and this server.