onchain-forensics

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool addresses a distinct security concern or forensic task, from contract powers to meme token verification, theft tracing, scam detection, approval checks, wallet monitoring, agent vetting, and local key scanning. There is no overlap in purpose.
Naming Consistency4/5
Most tool names follow a verb_noun pattern with underscores (e.g., rug_powers, vet_meme, trace_theft), though some are noun_noun (seed_exposure, key_exposure) and one starts with a code (b20_authentic). The naming is clear and descriptive but shows minor inconsistency in pattern.
Tool Count5/5
12 tools is well-scoped for an on-chain forensics server. Each tool covers a specific area without redundancy, and the set feels comprehensive yet manageable for an agent.
Completeness4/5
The tool set covers a broad range of on-chain and local security checks, including contract analysis, token verification, fund tracing, scam detection, wallet monitoring, and key identification. Minor gaps might include lack of NFT-specific tools or integrated reporting, but the overall coverage is strong.
Average 3.6/5 across 12 of 12 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 50 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially discloses behavioral traits (e.g., 'Reports STRUCTURE, never intent', 'shared paymaster proves shared control or shared infrastructure'). However, it omits key details like auth needs, rate limits, or whether the tool is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and not front-loaded. It opens with a rhetorical question and uses figurative language, making it inefficient for quick comprehension. Important operational details are buried or missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and no annotations, the description is severely incomplete. It lacks information on return values, error handling, and operational nuances, making it insufficient for reliable tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (chain and address) with 0% schema description coverage. The description does not explain what these parameters mean, expected formats, or valid values, leaving the agent without necessary guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses metaphorical language ('Who paid for this launch, and what else did they pay for?') but fails to clearly state the tool's action. It hints at tracing funders and clusters but is vague and not actionable for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use launch_funder versus siblings like rug_powers or vet_meme. The poetic description does not provide context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It mentions it grades links and sender wants, and does not score persuasiveness, but fails to explain output format, side effects, or limitations like what 'Never returns safe' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose and reads like a story, burying key functional details. It is not concise and wastes sentences on narrative rather than clear specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is severely incomplete. It does not adequately describe inputs, outputs, or behavior for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only loosely hints at parameters like 'links' and 'asksToInstall'. It does not explain individual parameters, their types, or how they influence behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it judges inbound opportunities by what they ask, and grades links and sender wants, but the purpose is buried in a lengthy narrative. It is vague and not immediately clear what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 its siblings. The description only says 'Never returns safe' but provides no context for appropriate usage or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: B20 tokens are precompiles with low bytecode, and genuine ones allow issuer freeze/burn. However, it lacks details like whether the tool returns a boolean or more info, and does not address side effects (none expected). Without annotations, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but longer than necessary. It front-loads the core question but includes explanatory asides ('As people learn...') that could be trimmed. Every sentence adds some value, but conciseness could be improved by focusing on the key distinction and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should cover return value, error conditions, and usage context. It omits what the tool returns (likely a boolean or object) and does not relate to sibling tools. It explains the domain but leaves the agent uncertain about integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists 'chain' and 'address', but the description provides no explanation of these parameters. With 0% schema description coverage, the description fails to add meaning to the parameters. It should clarify the role of 'chain' (e.g., which Base network) and the format of 'address'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to check if a Base-native B20 asset is genuine or an ordinary ERC-20. It explains the distinction and implications. However, it does not differentiate from siblings directly, though sibling names like 'rug_powers' and 'vet_meme' suggest different verification focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 implies it's for verifying B20 tokens, but siblings like 'vet_approach' or 'open_approvals' might also be relevant. Missing context on prerequisites or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses key behavioral traits: it merges a curated index with live trade simulation, explains that dangerous capabilities only count if someone can fire them, and states it never returns clean on simulation alone. This provides good transparency beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately lengthy with multiple sentences, some of which are explanatory but not strictly necessary (e.g., analogy about scanners). It is structured with the main purpose front-loaded, but could be trimmed for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description does not explain return values or format. It mentions 'never returns clean on simulation alone' but is vague. For a tool assessing powers, the output structure is critical and missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'chain' has description). The description does not add meaning beyond the schema for either parameter; it only indirectly references the address as 'the contract'. No additional guidance on format or constraints is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assesses what powers the deployer still holds over user funds, using specific verbs and resource. It distinguishes from sibling tools like 'vet_meme' by focusing on deployer powers and real-time risk evaluation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for evaluating deployer powers but does not explicitly state when not to use it or provide alternatives among siblings. It gives context about merging index and simulation but lacks clear guidance on when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides significant behavioral details beyond what annotations (none) offer, such as explaining that ERC-20 Transfer logs are attacker-controlled, bridge aggregators write destination into calldata, and TRON accounts are analyzed for relay hops. These insights help the agent understand limitations and inner workings, though side effects or destructive actions are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence but becomes dense and technical in the following sections. Each mode is explained, but the overall length and complexity reduce conciseness. Some sentences are run-on, making the structure less efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, technical domain), the description is incomplete. It thoroughly explains mode behavior but omits details about other parameters, return values, error conditions, or example usage. The lack of output schema increases the need for description completeness, which is not met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 40%, the description must compensate for undocumented parameters. It effectively explains the 'mode' parameter's three values (moved, bridge, tron), but fails to describe the remaining parameters (chain, txHash, maxHops) beyond their names. This leaves significant gaps in understanding their formats and roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool description clearly states 'Follow stolen funds from the victim's transaction to where the trail dies,' establishing a specific verb (follow) and resource (stolen funds). The description distinguishes this tool from siblings by focusing on theft tracing, which contrasts with other sibling tools like 'vet_meme' or 'rug_powers' that serve different investigative purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by detailing three modes (moved, bridge, tron) and their contexts, but it lacks explicit guidance on when to use this tool versus alternatives, when not to use it, or prerequisites. The usage is implied rather than stated outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits: it distinguishes four outcomes, confirms state via on-chain allowance() calls, emphasizes read-only nature, and warns about data interpretation (event vs state). No annotations exist, so the description bears full burden and meets it thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than necessary, including background on ERC-20 approvals that may not be essential. It is front-loaded with a metaphor, but subsequent details could be more compact. Adequate but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately explains the four outcome states and the on-chain verification method. It lacks explicit detail on the return format (e.g., JSON structure), but covers the essential behavioral context. Missing minor details hold it back from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters documented). The tool description adds no additional parameter meaning beyond the schema's brief descriptions, meeting the baseline for high coverage but not enhancing it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: auditing ERC-20 approvals for a wallet, reporting four distinct statuses. It uses a vivid metaphor ('which doors are open') and explicitly distinguishes itself from tools that might revoke or sign, indicating read-only behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., other audit tools). The description explains the importance of approvals but does not compare to sibling tools or specify use cases where this tool is most appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the deterministic behavior ('Answerable with certainty'), the never-returns-safe result, and the reasoning process about legitimate recovery channels. This is strong transparency, though it does not cover all parameter behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a coherent paragraph of about 5 sentences, efficiently conveying key concepts. It is well-structured and front-loaded, but contains some complex sentences that could be simplified. Still among the better examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sparse schema descriptions, the description effectively covers the tool's purpose, logic, and expected results. It adequately informs an agent about what the tool does and how to interpret its output, though it lacks a detailed return format explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 17% (only 'address' described). The description adds meaning by explaining why parameters like 'asksForSignature' and 'asksForUpfrontPayment' are critical, but does not explicitly describe each parameter or their types. It partially compensates for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool judges recovery offers for stolen funds, using the specific verb 'judge' and resource 'offer to recover already-stolen funds'. It distinguishes from sibling tools like 'trace_theft' by focusing on offers rather than tracking, providing a unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use by describing the nature of recovery offers, but does not explicitly state 'use this when you receive a recovery request' or contrast with other tools. It lacks direct usage guidance or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is highly transparent about behaviors: it introspects and never calls a tool, it checks four specific dangers (nonexistent agent, money-moving tools without quantity, key material requests, payment to address with no history), and it returns 'unauditable' for 401/403. This fully compensates for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and discursive, containing philosophical asides and meta-commentary (e.g., 'Deliberately does NOT grade how good the description reads'). It could be more concise while retaining the key points. The structure is a single paragraph rather than a clear list, reducing readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (vetting an agent with no output schema), the description explains the approach well but lacks specification of the return value. It mentions 'unauditable' for HTTP errors but does not describe the normal output format (e.g., boolean, risk score). This gap leaves the agent uncertain about the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the three parameters (url, chain, payTo) with 100% coverage. The description adds significant context beyond the schema, explaining how it interprets these parameters during vetting (e.g., checking for a QUANTITY field in tools, or a private key field). This enrichment justifies a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to check if an agent is safe to connect to and pay. It explicitly lists four dangers it checks and distinguishes itself from siblings like 'vet_meme' and 'vet_approach' by focusing on safety and introspection, never calling a tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (vet an agent before connecting/paying) but does not explicitly state when to use this tool vs alternatives. No exclusions or when-not-to-use guidance is provided, though the context of checking dangers is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the tool's behavior: it checks live liquidity and returns one of four outcomes (genuine, ambiguous, impersonation, thin). The term 'fail-closed' indicates a safety orientation. However, it does not explicitly state whether the tool is read-only or if it has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using just three sentences to convey purpose, context, and possible outcomes. It is front-loaded with a clear question and effectively uses line breaks for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (identifying real contracts among look-alikes) and the lack of an output schema, the description provides sufficient context: it explains the problem and lists the four possible outcomes. It covers the key aspects an agent needs to understand what the tool does and what results to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes three parameters with partial descriptions (67% coverage). The description adds context by mentioning 'the address you passed', but does not explain how the parameters interact with the logic or provide additional details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to identify the real token contract behind a meme ticker among many look-alikes. It uses a specific verb ('vet') and resource ('meme token contracts'), and distinguishes itself from sibling tools by focusing on meme tokens with multiple look-alike contracts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description strongly implies when to use the tool: when dealing with meme symbols that have many look-alike contracts. It also hints at the risks ('buying the wrong one is a total loss'). However, it does not explicitly state when not to use this tool or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses key behaviors: detects new allowances and counterparties, judges against known-bad screens, uses transactions not logs, reports blind spots, and describes persistence effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is overly verbose and metaphorical, with flowery language that obscures clarity. Could be significantly condensed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 sibling tools and no output schema, the description thoroughly explains behavior, differentiation, and edge cases (first run, blind spots). Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions (100% coverage). Description adds minimal extra context (e.g., effect of persist). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool watches for changes around a wallet since last check, distinguishing it from siblings that only answer at a point in time. The verb 'watch' and resource 'wallet' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for monitoring changes over time, contrasts with point-in-time tools. Notes first run is an inventory. However, lacks explicit when-not-to-use or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description explicitly states read-only, no network, zero dependencies, that it never outputs the phrase, only file/line/word count, and lists its blind spots. This fully compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose (multiple sentences) and includes slightly tangential remarks (e.g., 'Self custody if you know how...'). While informative, it could be more concise while retaining key points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains output format (file, line, word count) and what is not output (the phrase). It also covers limitations (blind spots) and safety claims, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'paths', and its description already includes default directories. The tool description adds general scanning behavior but does not provide additional semantics for the parameter beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking if a BIP-39 recovery phrase is in cleartext on the machine. It distinguishes from keyword scans and explains the decidable approach using BIP-39 word list and checksum, making it specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use this tool (to check for cleartext seed phrases) and lists blind spots (images, PDFs, etc.), but does not explicitly contrast with sibling tools like key_exposure 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavioral traits: read-only, never outputs key material, never decrypts, explains what it detects (structure, label, retained copies, browser vaults) and what it avoids (false positives).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but each sentence provides necessary context for a sensitive security tool. Could be slightly more concise, but front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description covers all essential aspects: what it finds, common pitfalls, companion tool, read-only nature, and behavioral constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% with clear parameter description. The description adds default behavior info but does not significantly enhance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool finds key material on disk, distinguishes readable vs encrypted keys, and warns about retained copies. It clearly distinguishes from sibling seed_exposure by explaining it's the companion for key exfiltration scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong context on when to use (key exposure investigation) and references the companion tool seed_exposure. Does not explicitly list exclusions but the narrative implies appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![onchain-forensics MCP server](https://glama.ai/mcp/servers/philpof102-svg/onchain-forensics/badges/card.svg)](https://glama.ai/mcp/servers/philpof102-svg/onchain-forensics)

Score Badge

Copy to your README.md:

[![onchain-forensics MCP server](https://glama.ai/mcp/servers/philpof102-svg/onchain-forensics/badges/score.svg)](https://glama.ai/mcp/servers/philpof102-svg/onchain-forensics)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/philpof102-svg/onchain-forensics'

If you have feedback or need assistance with the MCP directory API, please join our Discord server