This server (Metis MCP) lets you research and monitor tokenized real-world assets (RWAs) on Solana, combining live on-chain data with published AI research.
On-chain analysis: list/filter 72+ known RWAs, inspect issuer controls (mint/freeze authority, permanent delegate, transfer hooks), read live supply, analyze holder concentration, get DEX liquidity/volume, and compare token price to reference asset to detect premiums/discounts.
Research & history: run observation cycles with deterministic confidence scoring, retrieve stored observation history, list/fetch published research, check agent status, and diagnose data source health.
Asset identification & filtering: use registry symbols (e.g., TSLAx) or raw Solana mint addresses; filter by query/type and set limits on holder, pool, and history counts.
Integration & customization: connect as a Claude plugin, hosted HTTP endpoint, or local stdio server; configure Solana RPC, add custom tokenized assets via JSON, manage observation storage; use prebuilt prompts/skills like rwa_due_diligence and premium_watch.
Provides tools for researching tokenized real-world assets on the Solana blockchain, including reading token controls, supply, holder concentration, market liquidity, and reference premium, as well as accessing published research from the Metis agent.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@metis-mcp Check token controls and supply for TSLAx"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for researching tokenized real-world assets on Solana.
It gives an assistant twelve tools: six that read chain and market state live, and six that reach the research the Metis agent has already published. Every figure it returns comes from a fresh read, stamped with its source, the time it was taken, and a hash of the raw payload.
The point is the first question anyone should ask about a tokenized asset and almost nobody can answer quickly: who controls this token, and what happens to my position if they use that control?
As a plugin. The easiest path, and the only one that also carries the skills. In Claude Code:
/plugin marketplace add metis-rwa/mcp/plugin install metis@metis-rwaIn Claude Desktop or on the web, open Customize, then Plugins, then add from a
repository with https://github.com/metis-rwa/mcp.git. The plugin connects to
the hosted endpoint and adds /metis:due-diligence, /metis:premium-watch,
and a token-safety skill that runs whenever someone asks who controls a
token. See plugin/README.md.
Hosted, nothing to install. The same tools are served over HTTP at
https://metisagent.co/mcp:
claude mcp add --transport http metis https://metisagent.co/mcpThe hosted endpoint answers observation questions from the research agent's own stored history, which goes back further than any single machine can. It reads only, needs no key, and holds no session.
Local, over stdio. Run the package when you want your own RPC endpoint, your own asset list, or history kept on your machine:
npx -y @metisagent/mcpOr clone and build:
git clone https://github.com/metis-rwa/mcp.git
cd mcp
npm install
npm run build
node dist/index.jsThe server speaks MCP over stdio.
Related MCP server: Memecoin Observatory MCP
Claude Code:
claude mcp add metis -- npx -y @metisagent/mcpClaude Desktop, in claude_desktop_config.json:
{
"mcpServers": {
"metis": {
"command": "npx",
"args": ["-y", "@metisagent/mcp"],
"env": {
"SOLANA_RPC_URL": "https://your-endpoint.example/rpc"
}
}
}
}Any other MCP client works the same way: run metis-mcp (or
node dist/index.js) and speak MCP on stdin and stdout.
On-chain checks:
Tool | What it answers |
| Which assets this server knows by symbol, and their mints |
| Can the issuer mint, freeze, seize, pause, or gate transfers |
| How many tokens exist, and whether supply is capped |
| Who holds the supply, and is any of it frozen |
| How deep the liquidity is, pool by pool |
| Is the token trading away from the security it tracks |
Research:
Tool | What it answers |
| One full research cycle: read everything, compare against history, report detections and confidence |
| What this server has recorded for the asset so far, and the trend |
| What the Metis agent has published, filtered by asset or category |
| The full object behind one publication: claims, evidence, methodology, provenance |
| What the agent is investigating right now, and source health |
| Which data sources are answering, and how fast |
Every tool takes either a registry symbol (TSLAx) or a raw Solana mint
address, so assets outside the registry work too.
The registry ships with the 72 xStocks on Solana, from AAPLx through XOMx,
including the index and commodity fund shares (SPYx, QQQx, GLDx, PPLTx,
TBLLx) and the private-market listings (SPCXx, VCXx). Filter it with
list_rwa_assets, by substring or by asset type.
Two prompts ship with the server: rwa_due_diligence walks an asset through
controls, supply, concentration, depth, and premium, and premium_watch reads a
price gap against stored history. Two resources are exposed as well:
metis://registry and metis://methodology.
get_token_controls is forA tokenized equity is a claim on something held off chain, so the issuer keeps powers a plain token does not have. Token-2022 makes those powers explicit on the mint, and this tool translates each one into what it means for a holder:
Permanent delegate: tokens can be moved or burned out of any account without the holder signing.
Freeze authority: any account can be frozen, which blocks selling and redemption.
Transfer hook: every transfer runs through a program that can reject it, which is how an allowlist is enforced.
Default account state frozen: new accounts cannot transact until the issuer thaws them, so the token is permissioned by default.
Pausable: transfers can be halted chain-wide.
Scaled UI amount: displayed balances are rescaled, which is how splits and similar corporate actions land on chain.
None of these are defects. Redeemable backed assets need most of them. They are simply facts about the asset that belong in any answer about whether it is worth its reference price.
Variable | Default | Purpose |
| a public node | Solana JSON-RPC endpoint |
|
| Metis research API |
| none | JSON file of extra assets to register |
|
| Where observation history is stored. Set to |
|
| Network timeout per request |
Set SOLANA_RPC_URL to an endpoint you control if you can. Public nodes
throttle the heavier reads, and get_holder_concentration is the first one they
refuse.
METIS_ASSETS_FILE takes an array. Only symbol and mint are required:
[
{
"symbol": "AAPLx",
"name": "Apple xStock",
"mint": "<mint address>",
"decimals": 8,
"assetType": "tokenized_equity",
"referenceTicker": "AAPL",
"issuerName": "Backed Assets"
}
]Verify a mint against the chain before adding it. A wrong address returns
confident, wrong answers. Everything already in the registry was read back from
Solana first: the names and symbols in src/assets.ts are the ones written into
each mint's own Token-2022 metadata, not labels copied from a token list. Check
them again at any time:
npm run verify-assetsobserve_asset reads supply and holder concentration from Solana, pooled
liquidity and volume from DEX venues, and the token and reference prices from a
public price service. It compares the result against the observations already
stored for that asset, then reports:
Observations: what is true right now, each tied to the reads behind it.
Detections: metrics that crossed a threshold, with the baseline they crossed it against.
Conflicts: sources that disagree, recorded rather than averaged away.
Confidence: computed from source coverage, source failures, cross-source agreement, and how much history backs the comparison. A model's own stated confidence is never an input.
History lives on the machine running the server. The first call on an asset has no baseline, so only the premium threshold can fire. Call it again over time and supply, liquidity, activity, and concentration detections come alive. The hosted endpoint skips that warm-up entirely: it compares against the history the research agent has been recording every ten minutes since it went live.
Largest token accounts are accounts, not beneficial owners. Pools, bridges, and custodial accounts sit at the top of most lists.
DexScreener refuses datacenter traffic. Run the server from a laptop and it answers; run it from a cloud host and pool data falls back to the price service, which reports liquidity, 24h volume, and a holder count but no pool breakdown and no transaction counts. Tools say when a number came from the standby.
A republished reference price can be stale outside market hours, and that alone can look like a premium.
Aggregated venue data covers listed pools. Anything traded over the counter or internally is invisible here.
This is informational research produced by software. It is not financial advice, and it can be wrong.
npm install
npm run typecheck
npm test
npm run inspectorTests cover the analysis rules, the control translations, the registry, and the
history store. They run against the build, so npm test builds first.
The package publishes to npm as @metisagent/mcp, and server.json describes it
for the MCP registry. The registry proves ownership by matching mcpName in
package.json against the server name in server.json, so those two strings
have to stay in step.
Bump the version in package.json and in both places in server.json, then
add a CHANGELOG.md entry.
npm run verify-assets to confirm the registry still matches the chain.
npm test.
npm publish --access public.
mcp-publisher login github then mcp-publisher publish to list the release
in the MCP registry.
MIT
Probe every data source this server depends on (Solana RPC, DEX venue data, and the price service) and report which answered and how fast. Run this when a research tool returns partial data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds behavioral context about what gets probed and the output (which answered and how fast), which is useful beyond the structured 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 tightly written sentences: first defines what the tool does with specific examples, second gives a concrete trigger. No redundant words or repetition of structured fields.
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 parameterless diagnostic tool with no output schema, the description fully covers purpose, scope, output, and usage context. Sibling tools are all data/research-oriented, so the health-check role is unambiguous.
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 baseline is 4. The description correctly focuses on behavior and usage rather than parameter details, which are unnecessary.
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 uses specific verb 'Probe' and identifies the resource as 'every data source this server depends on', listing examples (Solana RPC, DEX venue data, price service). This clearly distinguishes the health-check tool from sibling data/research 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?
Provides explicit when-to-use guidance: 'Run this when a research tool returns partial data.' It does not state when-not-to-use or name alternatives, but the context is clear given no sibling health-check tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the largest token accounts for an asset with each one's share of supply, the wallet that owns it, and whether it is frozen. Concentration is the practical exit-risk measure for a tokenized asset, though the top of this list is usually liquidity pools and custodians rather than end investors.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Registry symbol such as TSLAx, or any Solana mint address. | |
| limit | No | How many accounts to list. The RPC returns at most 20. | |
| resolveOwners | No | Resolve the wallet behind each token account. Costs one extra RPC read. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds interpretive context about the list composition but does not disclose additional behavioral traits like return format, pagination, 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 two sentences, front-loaded with the core purpose, and the second sentence adds valuable interpretation without waste. Every word 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?
For a simple read-only list tool with good annotations and schema, the description is nearly complete. It explains the meaning of concentration and typical composition of the top list, but could optionally mention ordering or edge cases like empty results.
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%, with detailed descriptions for asset, limit (including min/max/default), and resolveOwners (including the extra RPC read). The description adds no further parameter semantics beyond the 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 clearly states the tool lists the largest token accounts for an asset, including share of supply, wallet, and frozen status. This specific verb+resource structure distinguishes it from siblings like get_token_supply or get_token_market.
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 provides clear context for when this tool is relevant (assessing exit risk) and even cautions that top accounts are usually liquidity pools/custodians. However, it does not explicitly compare to alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the observation history this server has stored for an asset, newest last, with the trend across premium, supply, liquidity, and concentration. History is written by observe_asset and lives on the machine running the server, not on any remote service.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Registry symbol such as TSLAx, or any Solana mint address. | |
| limit | No | How many stored points to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations: the data lives on the machine running the server (not remote), is written by observe_asset, and is ordered newest last.
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 sentences, front-loaded with the action, and every sentence contributes useful information (what, ordering, fields, data location, writer). No redundancy or fluff.
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 read tool with 2 parameters and no output schema, the description sufficiently covers purpose, data source, ordering, and content fields. It is complete enough for an agent to select and invoke 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?
Both parameters (asset and limit) are fully described in the schema, so the schema carries the parameter semantics. The description does not add param-specific details beyond what the schema provides, but it does mention ordering which helps interpret the limit parameter.
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 the tool reads observation history for an asset, with specific ordering ('newest last') and fields (premium, supply, liquidity, concentration). It distinguishes itself from siblings like observe_asset, which writes the history.
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 provides clear context: this reads locally stored historical observations written by observe_asset, implying use for retrospective analysis. It lacks explicit 'when not to use' guidance, but the context is sufficient and no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a full published research object: thesis, claims with the evidence each one rests on, methodology, confidence rubric, limitations, and provenance including the content hash and the models used. Returned as JSON because the object model, not the prose, is the source of truth.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Research object id or slug, from list_research. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, establishing safety. The description adds valuable behavioral context by specifying the exact return contents (evidence, methodology, provenance, content hash, models) and explains the JSON format rationale ('object model, not the prose, is the source of truth'). This goes beyond the annotations and helps set expectations for the response.
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 sentences that are dense with information but contain no filler. It front-loads the core function, then lists the object's contents, and closes with a brief, purposeful note on the JSON format. Every sentence 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?
This is a simple tool with one parameter, strong annotations covering safety and idempotency, and no output schema. The description fully enumerates the return payload, making it clear what the agent will receive. No additional context is needed for correct selection and invocation.
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% for the single id parameter, which is already described as 'Research object id or slug, from list_research.' The tool description does not add any additional parameter details or examples. With full schema coverage, a baseline of 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 uses a specific verb ('Fetch') and resource ('full published research object') and enumerates the contents (thesis, claims with evidence, methodology, confidence rubric, limitations, provenance including content hash and models). This clearly distinguishes it from siblings like list_research (listing) and get_research_status (status only).
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 is for retrieving a complete research object when you need its full structure and evidence, but it does not explicitly state when to use it versus alternatives like get_research_status or check_sources. It mentions 'published' but does not contrast with unpublished or list operations. The schema hint 'from list_research' is not part of the description, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read what the Metis research agent is doing right now: the investigation in flight and its stage, what is queued, the health of each source class, and the most recent public runtime events.
| Name | Required | Description | Default |
|---|---|---|---|
| events | No | How many recent events to include. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds content details (e.g., 'investigation in flight', 'health of each source class'), but does not disclose return format, pagination, or any behavioral quirks beyond the annotation.
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 that starts with the core action and then lists specifics efficiently. No filler or redundant wording.
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 single-parameter read-only tool with strong annotations and full schema coverage, the description adequately explains the tool's scope and contents. It does not need to detail return structure since no output schema is present, and the annotation covers side effects.
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 schema fully describes the 'events' parameter with type, default, min, max, and a description. The tool description mentions 'most recent public runtime events' but adds no new semantics about how the parameter affects the response, 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?
The description uses a specific verb ('Read') and identifies the resource ('the Metis research agent...doing right now'), then enumerates key contents (investigation, stage, queue, source health, runtime events). This clearly distinguishes it from sibling tools like get_research (individual research) or check_sources (source checking).
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 usage when you need the runtime state of the agent, but it doesn't explicitly contrast with sibling tools or state when not to use it. For instance, it doesn't say 'for a list of research use list_research'. This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the powers an issuer holds over a token: mint authority, freeze authority, and every Token-2022 extension on the mint, each translated into what it means for someone holding the token. This is the first check to run on any real-world-asset token, because permissioned controls such as a permanent delegate, a transfer hook, or frozen-by-default accounts change what ownership is worth.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Registry symbol such as TSLAx, or any Solana mint address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about what is inspected (mint authority, freeze authority, every Token-2022 extension) and how results are interpreted ('translated into what it means for someone holding the token'), going beyond the annotations without contradicting them.
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 consists of two sentences with no fluff. The first sentence defines what the tool inspects, and the second provides usage rationale with illustrative examples. Every phrase contributes to understanding.
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 one parameter, rich annotations, and no output schema, the description sufficiently covers purpose, usage, and behavioral scope. It gives a sense of the return format via 'translated into what it means' but stops short of listing exact output fields, 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 schema covers the only parameter 'asset' fully with a description ('Registry symbol such as TSLAx, or any Solana mint address'). The tool description does not add new parameter-level detail, so a baseline score of 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 opens with a specific verb 'Inspect' and identifies the resource as 'the powers an issuer holds over a token,' enumerating mint authority, freeze authority, and Token-2022 extensions. This clearly distinguishes it from sibling tools like get_token_supply and positions it as the 'first check' for real-world-asset tokens.
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 states 'This is the first check to run on any real-world-asset token' and explains why with concrete examples such as permanent delegate, transfer hook, and frozen-by-default accounts. It provides strong contextual guidance but lacks an explicit when-not-to-use statement or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read aggregated on-chain market state for a tokenized asset: pooled liquidity, 24h volume, transaction counts, and the individual pools behind those totals. Thin liquidity relative to supply is the usual reason a tokenized asset cannot be exited at its reference price.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Registry symbol such as TSLAx, or any Solana mint address. | |
| pools | No | How many pools to list, largest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that totals are aggregated and individual pools are included, but it does not disclose further behavioral traits such as pagination, rate limits, or exact output structure. This is moderate value beyond 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, no filler. The first sentence efficiently states the operation and return contents; the second provides useful interpretive context in under 20 words. Every sentence 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?
For a read-only market data tool with strong annotations and full parameter documentation, the description sufficiently covers what is returned (liquidity, volume, transaction counts, pools). Pool ordering is captured in the schema, and no output schema is required given this level of detail.
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%; asset and pools are fully documented with formats, defaults, and range. The description does not add parameter-level detail beyond mentioning liquidity/volume/pools, which aligns with the schema. Baseline 3 is appropriate since 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?
Description uses specific verb 'Read' with resource 'aggregated on-chain market state for a tokenized asset' and enumerates concrete metrics (pooled liquidity, 24h volume, transaction counts, individual pools). This clearly differentiates it from siblings like get_token_supply, get_holder_concentration, and get_reference_premium, which target different aspects.
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 when-to-use or alternative guidance is provided. The second sentence implies the tool is useful for assessing why an asset cannot be exited at reference price, but it does not directly state when to choose this tool over siblings. Usage is inferable from the data returned rather than explicitly spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read circulating supply for a tokenized asset directly from Solana, along with decimals, the slot the read was taken at, and the token program that owns the mint. For a backed asset this is the number the issuer's reserves have to cover.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Registry symbol such as TSLAx, or any Solana mint address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds valuable context about on-chain data (slot, token program) and interpretive meaning (reserve coverage), going beyond the safety profile.
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 sentences, front-loaded with the primary action, and every phrase adds informative detail. No fluff or 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?
With only one parameter, clear annotations, and a description that enumerates return values and interpretation, the description is complete enough for an agent to invoke the tool correctly without an output schema.
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 parameter 'asset', with a clear description of accepted values. The tool description does not add additional parameter semantics 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?
The description clearly states it reads circulating supply for a tokenized asset from Solana, with a specific verb and resource. It also lists additional outputs (decimals, slot, token program) and distinguishes from sibling tools by focusing on supply.
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 usage through context: it explains what the supply number means for backed assets, helping the agent decide when to use it. However, it does not explicitly mention alternatives or when-not-to-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List research objects published by the Metis agent, newest first. Each entry carries its confidence band, impact, and content hash. Use get_research to pull the full evidence graph behind one of them.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Filter to one asset symbol, for example TSLAx. | |
| limit | No | ||
| category | No | Filter by research category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive nature. The description adds context about ordering (newest first) and the output fields (confidence band, impact, content hash), which are not in the annotations or schema. This is meaningful behavioral transparency beyond the structured data.
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 sentences, each serving a distinct purpose: purpose, output description, and alternative usage. No wasted words, and the core purpose is front-loaded.
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?
Without an output schema, the description compensates by enumerating the content of each entry (confidence band, impact, content hash) and the ordering (newest first). Combined with the annotations and clear schema, this gives the agent sufficient context to correctly invoke the 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 description does not mention any of the three parameters or their effect on results. Schema coverage is 67%, with the limit parameter lacking a description in the schema and the tool description providing no clarification. Thus, the description adds no parameter meaning beyond what the schema already provides.
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 explicitly states that the tool lists research objects published by the Metis agent, newest first, and distinguishes itself by pointing to get_research for full evidence graphs. This is a specific verb+resource combination that clearly differentiates from siblings.
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 provides a clear alternative: 'Use get_research to pull the full evidence graph behind one of them.' This tells the agent when to use the sibling tool instead, satisfying the when/alternative requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the tokenized real-world assets this server knows by symbol, with their Solana mint and the security each one tracks. Every other tool also accepts a raw mint address, so this list is a starting point rather than a limit.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Filter by substring against symbol, name, or tracked ticker. For example "gold", "AAPL", or "bank". | |
| assetType | No | Filter by what the token tracks. Funds cover index, treasury, and commodity fund shares. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds useful context beyond annotations: it specifies the output fields (symbol, mint, security) and indicates that the tool returns assets known to this server, which helps set expectations. It does not describe pagination or response format, but with the strong annotation coverage this is acceptable.
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 concise, consisting of two sentences that are front-loaded with the primary purpose. The second sentence adds valuable context about how the tool relates to others without unnecessary verbosity.
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 list tool with no output schema and a clear read-only annotation, the description is complete. It explains what the tool returns, that it is a starting point for using other tools, and the schema fully documents the optional filters. No critical information is missing for the agent to select and invoke 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?
Both parameters (query, assetType) have complete descriptions in the input schema (100% schema description coverage). The tool description does not add any additional meaning beyond the schema, so it meets the baseline of 3 but does not exceed it.
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 the tool's function with a specific verb: 'List the tokenized real-world assets this server knows by symbol, with their Solana mint and the security each one tracks.' It also distinguishes itself from sibling tools by noting it is the starting point, while other tools accept a raw mint address.
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 explicitly provides usage guidance: 'Every other tool also accepts a raw mint address, so this list is a starting point rather than a limit.' This tells the agent to use this tool to discover assets and then use other tools with the mint address, effectively directing when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one full research cycle on a tokenized asset: read supply and holder concentration from Solana, read pooled liquidity and volume from DEX venues, read the token and reference prices, then compare all of it against the observations already stored for this asset. Returns the observations, any threshold detections, cross-source conflicts, a deterministic confidence score, and a hash of every payload used. The cycle is appended to local history, so calling it repeatedly deepens the baseline that supply, liquidity, activity, and concentration detections need.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Registry symbol such as TSLAx, or any Solana mint address. | |
| record | No | Append this cycle to the local observation history. | |
| baselineLimit | No | How many stored observations to use as baseline. 0 skips history entirely. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key side effect beyond the annotations: 'The cycle is appended to local history, so calling it repeatedly deepens the baseline.' It also transparently lists the return payload components, including a hash of every payload used, which adds context beyond the readOnlyHint/idempotentHint 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?
Three sentences, every sentence delivers meaningful information. It is front-loaded with the primary action, then details steps and outputs without unnecessary 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 fully specifies what the tool returns (observations, detections, conflicts, confidence score, hash) and the side effect (history append). This makes the tool self-contained and understandable 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?
Schema coverage is 100%, so the parameters are already well-documented. The description adds some context by mentioning 'baseline' and 'history' which aligns with baselineLimit and record, but it does not introduce new parameter details that aren't already in the 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 clearly states the specific verb+resource: 'Run one full research cycle on a tokenized asset' and enumerates the exact steps (read supply, holder concentration, liquidity, volume, prices) and the comparison logic. This distinguishes it from sibling tools that fetch individual data points.
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 when to use the tool: when a full research cycle is needed, and repeated calls build a baseline. It does not explicitly name alternatives or state when not to use it, but the context is clear enough from the comprehensive scope.
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.
v0.1.0check_sourcesget_holder_concentrationget_observation_historyget_reference_premiumget_researchget_research_statusget_token_controlsget_token_marketget_token_supplylist_researchlist_rwa_assetsobserve_assetScored across 12 tools
Each tool targets a distinct facet of tokenized-asset research, from supply and controls to research objects. The only mild overlap is observe_asset, which intentionally bundles several getters, but its aggregate purpose is clearly differentiated.
All tools follow a verb_noun snake_case convention with predictable action verbs like list, get, observe, and check, providing a consistent and readable naming pattern.
With 12 tools, the server is well-scoped for its domain, covering asset listing, granular token metrics, composite observation, research publishing, and source diagnostics without redundancy.
The tool set covers the full research lifecycle: asset enumeration, individual on-chain metrics, aggregated observation with history, published research retrieval, and source health checks. No critical gaps are apparent for its stated purpose.
Crypto market intelligence, token rug-checks, and wallet verification in one MCP server.
Research-only MCP server: your AI as a quant research desk. 90 tools, no trades, no brokers.
Solana on-chain intelligence — token scans, wallet profiling, bundle detection, 19 MCP tools.
Read-only MCP server for Robinhood Chain token discovery, research, and due diligence via GMGN.
