DeFi protocol due-diligence from DeFiLlama (keyless): TVL, category, chains, and a check against DeFiLlama's HACKS database of known past exploits (amount lost, technique, date). Use for any DeFi protocol, dapp, or 'is this project safe to use' question that names a protocol. A hit in the hacks DB is a real red flag; TVL is context, not a safety guarantee.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | the protocol/project name (e.g. Curve, Aave, GMX) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses keyless operation, the included data categories, and importantly interprets the hacks DB results ('A hit in the hacks DB is a real red flag; TVL is context, not a safety guarantee'). This adds valuable nuance beyond a dry API description, though it omits potential error/not-found 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?
Three focused sentences with no redundancy. It front-loads the core purpose, then adds usage guidance and risk interpretation, each sentence earning 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?
Given no output schema and no annotations, the description covers the main data returned, usage context, and risk interpretation. It could be more explicit about behavior when a protocol isn't found or response structure, but it is sufficient for a simple one-parameter lookup.
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 description already covers the single parameter (name) with examples, so the baseline is 3. The description adds minor context by indicating it expects a named protocol, but not enough to elevate above 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 performs DeFi protocol due-diligence from DeFiLlama, listing specific data points (TVL, category, chains, and hacks database). It distinguishes from sibling security tools by focusing on named protocols and DeFiLlama data.
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 specifies when to use: 'Use for any DeFi protocol, dapp, or "is this project safe to use" question that names a protocol.' It does not explicitly mention alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools share the same core purpose (safety checks) differentiated mainly by chain or asset type, and descriptions are detailed enough to distinguish them most of the time. However, pairs like rug_check/rugcheck and deployer_check/deployer_reputation have overlapping purposes that could lead to misselection.
Most tool names follow a lowercase snake_case pattern with clear descriptors, but there are notable exceptions like 'rugcheck', 'defillama', and 'verify'. Additionally, the 'rug_check' vs 'rugcheck' pair is an obvious naming inconsistency.
44 tools is excessive for any server. Even for a broad security/due-diligence purpose, many tools (especially the robinhood_* series) are highly specialized and could be consolidated into fewer actions.
The tool surface is impressively comprehensive, covering token/NFT safety, transaction simulation, whale/address tracking, stock analysis, prediction markets, and project validation. Minor gaps exist (e.g., no ENS resolution or stock price history), but they are not critical for the server's core purpose.
