Enables AI agents to query abuse.ch services such as ThreatFox for malware IOCs, URLhaus for malicious URLs, and other threat intelligence feeds.
Facilitates blockchain intelligence by tracing Bitcoin transactions and checking abuse reports on the Bitcoin blockchain.
Allows AI agents to search for breached accounts, credentials, and pastes using the Have I Been Pwned API.
Provides .onion hidden service access via Tor SOCKS5 proxy, enabling dark web scraping, onion search, and exit node checks.
Click on "Install 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., "@darknet-mcp-server check if example.com has any data breaches"
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.
Dark web intelligence is the missing layer in every security investigation. Breach databases, ransomware trackers, Tor hidden services, malware sandboxes, stealer logs, blockchain forensics, exploit databases — the data you need is scattered across dozens of platforms, each with its own API, its own auth, its own rate limits, its own output format. Today you check HIBP in one tab, ThreatFox in another, browse ransomware leak sites through Tor, pull up MalwareBazaar for a hash, check blockchain transactions on a block explorer, and then spend an hour manually piecing it all together.
Traditional dark web intel workflow:
check breach exposure -> HIBP web interface (paid API)
search leaked credentials -> IntelligenceX web interface
track ransomware groups -> ransomware.live + ransomlook.io (2 separate UIs)
access .onion hidden services -> Tor Browser manually
analyze malware samples -> Hybrid Analysis + MalwareBazaar (2 more UIs)
check IP abuse history -> AbuseIPDB + GreyNoise (2 more UIs)
trace cryptocurrency -> blockchain.info + ChainAbuse
search for exploits -> Vulners web interface
check phishing URLs -> PhishTank web interface
correlate everything -> copy-paste into a report
────────────────────────────────
Total: 60+ minutes per investigation, most of it switching contextsdarknet-mcp-server gives your AI agent 66 tools across 16 data sources via the Model Context Protocol. The agent queries all sources in parallel, correlates data across the surface and dark web, identifies threats, and presents a unified intelligence picture — in a single conversation.
With darknet-mcp-server:
You: "Investigate the breach exposure and threat landscape for target.com"
Agent: -> HIBP: 3 known breaches (Adobe 2013, LinkedIn 2021, Collection #1)
-> ThreatFox: 2 IOCs associated with domain (C2 callback, phishing)
-> URLhaus: 1 malicious URL hosted on subdomain
-> Ransomware: No victim listings found (good)
-> Stealer logs: 47 compromised employee credentials found
-> OTX: 5 threat pulses referencing the domain
-> AbuseIPDB: Primary IP has 12 abuse reports (brute force)
-> "target.com has been in 3 data breaches exposing 2.1M records.
47 employee credentials found in stealer logs — immediate
password reset recommended. 2 active ThreatFox IOCs suggest
ongoing targeting. No ransomware listings, but the abuse
reports on the primary IP warrant investigation."Related MCP server: wrg-mcp-server
Existing tools give you raw data one source at a time. darknet-mcp-server gives your AI agent the ability to reason across surface web and dark web intelligence simultaneously.
npx darknet-mcp-serverFree tools work immediately. No API keys required for ransomware tracking, breach listings, GreyNoise, blockchain, OTX, and more.
git clone https://github.com/badchars/darknet-mcp-server.git
cd darknet-mcp-server
bun install# Breach & credential intelligence
export HIBP_API_KEY=your-key # Enables breach account search & paste search
export INTELX_API_KEY=your-key # Enables 4 IntelligenceX tools
# Threat intelligence
export OTX_API_KEY=your-key # Increases AlienVault OTX rate limits
export ABUSEIPDB_API_KEY=your-key # Enables 4 AbuseIPDB tools
export ABUSECH_AUTH_KEY=your-key # Higher rate limits for abuse.ch suite
export PULSEDIVE_API_KEY=your-key # Higher rate limits for Pulsedive
# Stealer logs & credentials
export HUDSONROCK_API_KEY=your-key # Enables 3 Hudson Rock stealer log tools
# Exploit & malware analysis
export VULNERS_API_KEY=your-key # Enables Vulners search & exploit tools
export HYBRID_API_KEY=your-key # Enables 3 Hybrid Analysis malware tools
# Phishing
export PHISHTANK_API_KEY=your-key # Higher rate limits for PhishTank
# Tor SOCKS5 proxy (for .onion access)
export TOR_SOCKS_HOST=127.0.0.1 # Default: 127.0.0.1
export TOR_SOCKS_PORT=9050 # Default: 9050All API keys are optional. Without them, you still get ransomware tracking, breach listings, GreyNoise, blockchain intelligence, OTX, Tor exit node checks, onion search, CIRCL onion lookup, and more.
# With npx
claude mcp add darknet-mcp-server -- npx darknet-mcp-server
# With local clone
claude mcp add darknet-mcp-server -- bun run /path/to/darknet-mcp-server/src/index.tsAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"darknet": {
"command": "npx",
"args": ["-y", "darknet-mcp-server"],
"env": {
"HIBP_API_KEY": "optional",
"INTELX_API_KEY": "optional",
"ABUSEIPDB_API_KEY": "optional",
"HUDSONROCK_API_KEY": "optional",
"HYBRID_API_KEY": "optional",
"VULNERS_API_KEY": "optional"
}
}
}
}Same JSON config format. Point the command to npx darknet-mcp-server or your local installation path.
The 7 Tor tools (tor_fetch_onion, tor_scrape_onion, etc.) require a running Tor SOCKS5 proxy.
# macOS
brew install tor && brew services start tor
# Linux
sudo apt install tor && sudo systemctl start tor
# Docker
docker run -d -p 9050:9050 dperson/torproxy
# Verify connectivity
npx darknet-mcp-server --check-torYou: "Check if example.com has been in any data breaches and look for stealer logs"That's it. The agent handles breach lookups, credential searches, threat correlation, and more automatically.
You: "Check if example.com has been in any data breaches"
Agent: -> breachList {domain: "example.com"}
-> breachSearch {account: "admin@example.com"}
-> stealer_domain {domain: "example.com"}
-> intelx_search {term: "example.com"}
-> "example.com appears in 5 known breaches:
- ExampleDB 2023: 4.2M records (emails, passwords, IPs)
- Collection #1: credential stuffing list
- Combolist 2024: 890K email:password pairs
Stealer logs: 23 compromised machines with saved credentials
for example.com found in Hudson Rock database.
IntelligenceX: 47 results across paste sites and dark web."You: "What ransomware groups are targeting healthcare?"
Agent: -> ransomwareBySector {sector: "healthcare"}
-> ransomwareRecent {}
-> ransomlookRecent {}
-> "Healthcare sector ransomware activity:
142 victims across 12 groups in the last 12 months.
Top groups: LockBit3 (38 victims), BlackCat/ALPHV (24),
Cl0p (19), Royal (15).
Most recent: MedCorp Inc. listed by LockBit3 (2 days ago).
3 new healthcare victims in the last week across
ransomware.live and RansomLook feeds."You: "Search for mentions of our company on .onion sites"
Agent: -> tor_search_onion {query: "AcmeCorp"}
-> intelx_search {term: "acmecorp.com"}
-> onion_lookup {address: "relevant-onion-address.onion"}
-> "Dark web search results for AcmeCorp:
Ahmia.fi: 3 .onion pages mention AcmeCorp
- Forum post discussing AcmeCorp employee list (leak forum)
- Marketplace listing for AcmeCorp database (unverified)
- Blog post referencing AcmeCorp breach
IntelligenceX: 12 results on paste sites
Recommendation: investigate the forum post and marketplace
listing for potential active data sales."You: "Analyze this file hash for malware indicators: abc123def456..."
Agent: -> malware_search {hash: "abc123def456..."}
-> malware_overview {sha256: "abc123def456..."}
-> bazaarHash {hash: "abc123def456..."}
-> threatfoxSearch {searchTerm: "abc123def456..."}
-> otx_hash {hash: "abc123def456..."}
-> "Malware analysis for abc123def456:
Hybrid Analysis: MALICIOUS (threat score 95/100)
- Family: AgentTesla (info stealer)
- MITRE ATT&CK: T1555 (Credential Access), T1071 (C2)
- Network IOCs: 3 C2 domains, 2 IPs
MalwareBazaar: First seen 2024-03-15, tagged 'AgentTesla'
ThreatFox: 2 IOC entries linking to same campaign
OTX: Referenced in 4 threat pulses"Tool | Description |
| Check if the local Tor SOCKS5 proxy daemon is running and accessible |
| Fetch raw HTML from a .onion URL via Tor SOCKS5 proxy (DNS leak prevention via socks5h) |
| Fetch and parse a .onion site — returns structured data: title, links, body text |
| Search for .onion sites using Ahmia.fi search engine |
| Get current Tor exit node IP addresses from the official Tor Project bulk exit list |
| Check if a specific IP address is a known Tor exit node |
| Get detailed Tor exit node information including fingerprints and publish timestamps |
Tool | Description |
| Fetch the most recent ransomware victims from ransomware.live |
| List all known ransomware groups tracked by ransomware.live |
| Get a detailed profile for a specific ransomware group by name |
| Get all victims claimed by a specific ransomware group |
| Search ransomware victims by keyword (company name, domain, etc.) |
| Get ransomware victims filtered by ISO 3166-1 alpha-2 country code |
| Get ransomware victims filtered by sector/industry (healthcare, finance, etc.) |
| List all 582+ ransomware groups tracked by RansomLook |
| Fetch the most recent ransomware posts and victim claims from RansomLook |
Tool | Description |
| List all known data breaches from HaveIBeenPwned, optionally filter by domain — free |
| Get details of a specific data breach by name — free |
| Get the most recently added data breach — free |
| List all data classes (types of compromised data) known to HIBP — free |
| Check if a password has appeared in known breaches (k-anonymity, only 5-char SHA-1 prefix sent) — free |
| Search all breaches for a specific account (email/username) — requires |
| Search for an email address in publicly posted pastes — requires |
Tool | Description |
| Get recent IOCs from ThreatFox reported in the last N days |
| Search ThreatFox IOCs by IP, domain, hash, or URL |
| Search ThreatFox IOCs by tag (e.g., Cobalt Strike, Emotet) |
| Search ThreatFox IOCs by malware family using Malpedia naming |
| Look up a URL or host in URLhaus for malware distribution |
| Search URLhaus entries by tag |
| Look up a malware sample in MalwareBazaar by MD5, SHA1, or SHA256 hash |
| Get the most recently submitted malware samples from MalwareBazaar |
| Search MalwareBazaar by tag or YARA signature name |
Tool | Description |
| Look up threat intelligence for an IP address — pulse info, reputation, country, ASN |
| Look up threat intelligence for a domain — pulse info, whois, reputation |
| Look up threat intelligence for a file hash (MD5, SHA1, SHA256) |
| Look up threat intelligence for a CVE — related pulses and indicators |
| Search OTX threat pulses by keyword |
Tool | Description |
| Check an IP address for abuse reports — confidence score, ISP, country, report count |
| Get individual abuse reports for an IP with detailed comments and categories |
| Get AbuseIPDB's blacklist of the most reported malicious IP addresses |
| Check an entire CIDR network block for abuse reports |
Tool | Description |
| Look up an IP on GreyNoise — classification (benign/malicious/unknown), scanner status |
| Quick check: is this IP a known scanner or known benign service? |
Tool | Description |
| Look up an indicator (IP, domain, URL, or hash) — risk level, threats, feeds |
| Search Pulsedive indicators by value |
| Explore linked indicators using advanced queries (related IOCs with risk levels) |
Tool | Description |
| Search stealer log entries by domain — compromised machines, credentials, malware details |
| Search stealer logs by email address — compromised machines with that email in browser credentials |
| Search stealer logs by IP address — compromised machines originating from that IP |
Tool | Description |
| Search the Vulners vulnerability database using Lucene queries |
| Look up a specific vulnerability or exploit by ID (CVE, EDB, GHSA) — free |
| Search specifically for exploits (ExploitDB entries) |
Tool | Description |
| Look up a Bitcoin address — balance, transaction count, recent transactions |
| Get Bitcoin address balance in satoshi (quick check without full history) |
| Get detailed Bitcoin transaction information by hash — inputs, outputs, fees, block info |
| Check a Bitcoin address for abuse reports on ChainAbuse — scam reports with categories |
Tool | Description |
| Search Hybrid Analysis sandbox by file hash — verdict, AV detection rate, analysis details |
| Full malware analysis overview — MITRE ATT&CK techniques, network indicators, processes |
| Get the latest malware detonation feed — recently analyzed samples with verdicts |
Tool | Description |
| Look up metadata for a .onion address via CIRCL AIL project — first/last seen, status, tags, certs, ports, BTC addresses |
Tool | Description |
| Initiate a search on IntelligenceX for leaked data, dark web content, and more |
| Retrieve results for an IntelligenceX search by ID |
| Phonebook search — find emails, domains, URLs associated with a term |
| Retrieve phonebook search results by ID |
Tool | Description |
| Check if a URL is a known phishing site via PhishTank |
Tool | Description |
| List all available data sources with configuration status, API key status, and tool counts |
# List all available tools
npx darknet-mcp-server --list
# Check Tor SOCKS5 proxy connectivity
npx darknet-mcp-server --check-tor
# Run any tool directly
npx darknet-mcp-server --tool breachList '{"domain":"adobe.com"}'
npx darknet-mcp-server --tool ransomwareRecent '{}'
npx darknet-mcp-server --tool tor_search_onion '{"query":"marketplace"}'
npx darknet-mcp-server --tool btc_address '{"address":"1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa"}'
# Tools requiring API keys
HIBP_API_KEY=your-key npx darknet-mcp-server --tool breachSearch '{"account":"user@example.com"}'
HYBRID_API_KEY=your-key npx darknet-mcp-server --tool malware_search '{"hash":"abc123..."}'Source | Auth | Rate Limit | What it provides |
| 1 req/1.5s | Breach search, paste search, password check, breach listings | |
| 1 req/s | Dark web content, leaked data search, phonebook (emails/domains/URLs) | |
Optional | 1 req/s | Threat intel for IPs, domains, hashes, CVEs; threat pulse search | |
| 1 req/s | IP abuse reports, confidence scoring, blacklist, CIDR block check | |
Optional | 2 req/s | IOC search, malware family tracking, tag-based search | |
Optional | 2 req/s | Malware distribution URL tracking, host/URL lookup | |
Optional | 2 req/s | Malware sample repository, hash lookup, YARA signature search | |
None | 1 req/s | IP classification (benign/malicious), internet scanner detection | |
Optional | 1 req/s | Indicator enrichment, risk scoring, linked IOC exploration | |
| 1 req/s | Stealer log search by domain, email, or IP | |
Optional | 1 req/s | Vulnerability/exploit database, CVE lookup, ExploitDB search | |
None | 1 req/s | Bitcoin address lookup, balance, transaction details | |
None | 1 req/s | Bitcoin address abuse/scam reports | |
| 1 req/s | Malware sandbox detonation, MITRE ATT&CK mapping, sample feed | |
None | 0.5 req/s | .onion address metadata, first/last seen, associated BTC addresses | |
None | N/A | Exit node list, .onion fetching/scraping, Ahmia.fi search |
src/
index.ts # CLI entrypoint (--help, --list, --check-tor, stdio server)
protocol/
mcp-server.ts # MCP server setup (stdio transport)
tools.ts # Tool registry — all 66 tools assembled here
types/
index.ts # Shared types (ToolDef, ToolContext, ToolResult)
utils/
rate-limiter.ts # Per-provider rate limiter
cache.ts # TTL cache for API responses
tor-fetch.ts # Tor SOCKS5 proxy HTTP client
require-key.ts # API key validation helper
tor/ # Tor Network tools (7)
ransomware/ # Ransomware Intelligence tools (9)
breach/ # HIBP Breach tools (7)
abusech/ # ThreatFox + URLhaus + MalwareBazaar tools (9)
otx/ # AlienVault OTX tools (5)
abuseipdb/ # AbuseIPDB tools (4)
greynoise/ # GreyNoise Community tools (2)
pulsedive/ # Pulsedive tools (3)
hudsonrock/ # Hudson Rock stealer log tools (3)
vulners/ # Vulners exploit tools (3)
blockchain/ # Blockchain Intelligence tools (4)
hybrid/ # Hybrid Analysis malware tools (3)
onionlookup/ # CIRCL Onion Lookup tool (1)
intelx/ # IntelligenceX tools (4)
phishing/ # PhishTank tool (1)
meta/ # Meta tools (1)Design decisions:
16 providers, 1 server — Every data source is an independent module. The agent picks which tools to use based on the query.
Per-provider rate limiters — Each data source has its own RateLimiter instance calibrated to that API's limits. No shared bottleneck.
TTL caching — Ransomware data (15min), breach lists (10min), abuse.ch (5min) results are cached to avoid redundant API calls during multi-tool workflows.
Graceful degradation — Missing API keys don't crash the server. Tools return descriptive error messages: "Set HIBP_API_KEY to enable breach account search."
DNS leak prevention — Tor .onion tools use socks5h:// protocol to resolve DNS through Tor, preventing DNS leaks to the local resolver.
4 dependencies — @modelcontextprotocol/sdk, zod, socks-proxy-agent, and cheerio. All clearnet HTTP via native fetch. All Tor traffic via SOCKS5.
HIBP account/paste search requires a paid API key ($3.50/month)
IntelligenceX, AbuseIPDB, Hudson Rock, and Hybrid Analysis require API keys for their tools
Tor .onion tools require a running Tor SOCKS5 proxy (not bundled)
abuse.ch free tier has lower rate limits without ABUSECH_AUTH_KEY
Ransomware.live and RansomLook data depends on upstream scraping frequency
Blockchain tools support Bitcoin only (no Ethereum/Monero)
PhishTank database can lag behind real-time phishing campaigns
macOS / Linux tested (Windows not tested)
Project | Domain | Tools |
Browser-based security testing | 39 tools, Firefox, injection testing | |
Cloud security (AWS/Azure/GCP) | 38 tools, 60+ checks | |
GitHub security posture | 39 tools, 45 checks | |
Vulnerability intelligence | 23 tools, 5 sources | |
OSINT & reconnaissance | 37 tools, 12 sources | |
darknet-mcp-server | Dark web & threat intelligence | 66 tools, 16 sources |
Get AbuseIPDB's blacklist of the most reported malicious IP addresses. Requires ABUSEIPDB_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| confidence | No | Min confidence score (default 90) | |
| limit | No | Max entries (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits. It only states the requirement for an API key. It does not mention if the operation is read-only, rate limits, response format, or pagination 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 main purpose, followed by a requirement. Every sentence is necessary and there is no 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 tool with two parameters and no output schema, the description is mostly complete. It covers purpose and the key prerequisite. It could be improved by briefly mentioning the return format (e.g., list of IPs) but is sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents both parameters with descriptions and defaults. The tool description does not add any additional meaning beyond what the schema 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?
Description clearly states it gets a blacklist of malicious IPs from AbuseIPDB, using the verb 'Get' and specifying the resource as 'AbuseIPDB's blacklist'. It distinguishes from sibling tools like abuseipdb_check (individual IP check) and abuseipdb_reports.
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 mentions the requirement of an API key, but does not provide when to use this tool versus alternatives (e.g., for bulk retrieval vs individual checks). No exclusions or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an IP address against AbuseIPDB for abuse reports. Returns confidence score, ISP, country, and report count. Requires ABUSEIPDB_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IP address to check | |
| max_age | No | Max age of reports in days (default 90) | |
| verbose | No | Include recent reports in response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must cover behavior. It states inputs and outputs (confidence score, ISP, country, report count) but omits details like rate limits, idempotency, or any potential side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second lists outputs and requirement. No redundancy or fluff; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by listing return fields. Parameter details are in schema. For a simple check tool, coverage is sufficient; missing only rate limits and error handling details.
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 descriptions already cover all three parameters (ip, max_age, verbose) with clear defaults. The description adds no new parameter-level information beyond summarizing output fields.
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 clearly states the tool checks an IP against AbuseIPDB for abuse reports and lists returned fields (confidence score, ISP, country, report count). However, it does not explicitly distinguish from sibling tools like abuseipdb_check_block or abuseipdb_reports.
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?
Description mentions the required API key but provides no guidance on when to use this tool vs siblings (e.g., abuseipdb_blacklist, abuseipdb_reports) or context like when to use max_age or verbose parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an entire CIDR network block for abuse reports on AbuseIPDB. Requires ABUSEIPDB_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | CIDR block (e.g. 192.168.1.0/24) | |
| max_age | No | Max age in days (default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits (e.g., read-only, rate limits, pagination). Only states operation and API key requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, first front-loads purpose, second adds essential prerequisite. No fluff, but could possibly be more efficient.
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?
Adequate for a simple tool with only 2 parameters and no output schema. Covers basic purpose and requirement, but lacks usage context and behavioral details.
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 already fully describes both parameters (100% coverage). Description adds no extra meaning beyond 'CIDR block' context, meeting baseline for high schema coverage.
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 'Check' and resource 'entire CIDR network block', clearly distinguishing from siblings like abuseipdb_check (single IP) and abuseipdb_blacklist (list of bad IPs).
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?
Only prerequisite mentioned (API key), no guidance on when to use this tool vs siblings like abuseipdb_check for single IP or abuseipdb_reports for specific reports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get individual abuse reports for an IP from AbuseIPDB. Returns detailed report comments and categories. Requires ABUSEIPDB_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IP address | |
| max_age | No | Max age in days (default 90) | |
| limit | No | Max reports to return (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes the tool as non-destructive ('Get... returns...') but omits details like rate limits, pagination, or error handling. The description is generic and does not add behavioral context beyond the obvious.
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 succinct with two sentences: the first explains the core function, and the second mentions the API key requirement. It is front-loaded and contains no filler, though structurally it could be improved by positioning the API key info earlier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 3 parameters, absence of output schema, and no annotations, the description is moderately complete. It states what the tool does and what it returns, but lacks details on the return format, error conditions, or usage scenarios. More context would be beneficial 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 description coverage is 100%, so the schema already documents all parameters. The description adds general context ('individual abuse reports', 'detailed report comments and categories') but does not enhance understanding of specific parameters beyond what the schema provides. 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 clearly states the tool's function: 'Get individual abuse reports for an IP from AbuseIPDB.' It specifies the source (AbuseIPDB) and the output ('detailed report comments and categories'). While it distinguishes from siblings implicitly (other abuseipdb tools likely have different purposes), it does not explicitly differentiate.
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 only mentions a prerequisite ('Requires ABUSEIPDB_API_KEY') but provides no guidance on when to use this tool versus alternatives like abuseipdb_check or abuseipdb_blacklist. There is no mention of best practices, exclusions, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a malware sample in MalwareBazaar (abuse.ch) by hash. Accepts MD5, SHA1, or SHA256.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | MD5, SHA1, or SHA256 hash of the malware sample |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose behavioral traits such as rate limits, authentication needs, or what happens when a hash is not found. Minimal transparency beyond the basic function.
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 convey all necessary information without any wasted words. The most critical details (function, resource, accepted hashes) are 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?
No output schema exists, but the description does not explain what the tool returns (e.g., sample details, tags, or error messages). For a lookup tool, this is a significant gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description is clear. The description adds no additional meaning beyond what the schema provides; the 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 clearly states the action ('Look up a malware sample'), the specific resource (MalwareBazaar), and the accepted hash types (MD5, SHA1, SHA256). It effectively distinguishes from sibling tools like bazaarRecent or bazaarTag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like otx_hash or pulsedive_indicator. The description implies usage when a hash is available, but does not mention exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent malware samples from MalwareBazaar (abuse.ch). Returns the most recently submitted samples.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | No | Selector for recent samples (default: time) | time |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it returns recent samples, but lacks details on number of samples, pagination, rate limits, or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundancy. Every sentence is necessary and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain the return format or fields. For a list tool, more context about what is returned (e.g., sample details, limits) would be needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add extra meaning beyond the schema. The parameter 'selector' is explained in the schema as 'Selector for recent samples (default: time)', so the description adds no further value.
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 verb 'Get' and the resource 'recent malware samples' from MalwareBazaar. It distinguishes itself from sibling tools like bazaarHash and bazaarTag by specifying 'recent' and the source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving recent samples but provides no explicit guidance on when to use this tool versus alternatives. No when-not or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search MalwareBazaar (abuse.ch) by tag or YARA signature name. Use 'tag' for tag-based search or 'signature' for signature-based search.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Tag to search for (e.g., Emotet, AgentTesla) | |
| signature | No | YARA signature name to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the purpose (search) but does not mention read-only nature, rate limits, or response format. For a read-only search tool, this is adequate but not comprehensive.
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 with no redundant information. All content is essential and 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?
Given no output schema or annotations, the description is somewhat minimal. It does not describe return values, pagination, or potential errors. For a simple search tool it is functional but could be more informative.
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%, but the description adds value by instructing exactly when to use each parameter ('Use tag for tag-based search or signature for signature-based search'), clarifying the intended mutual exclusivity beyond the schema's optional definitions.
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 searches MalwareBazaar by tag or YARA signature name, specifying the exact resource and action. It distinguishes itself from siblings like bazaarHash (search by hash) and bazaarRecent (recent additions).
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 explicit guidance on when to use 'tag' vs 'signature', but does not mention when to avoid this tool in favor of sibling tools (e.g., bazaarHash for hash searches).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all data classes (types of compromised data) known to HaveIBeenPwned. Free endpoint, no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is free and requires no API key, but does not describe rate limits, response format, or other behavioral aspects. For a simple list endpoint, this is adequate but minimal.
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, 15 words, front-loading the core purpose followed by access requirements. Every sentence is necessary and efficient.
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 tool with no output schema, the description covers purpose, free availability, and no API key requirement. Could optionally describe output format, but not essential.
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 and the schema coverage is 100% (empty schema). The description adds no extra parameter information, which is acceptable given no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'list', the resource 'data classes', and the scope 'all...known to HaveIBeenPwned'. This clearly distinguishes it from sibling tools like breachList or breachSearch.
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?
It notes the endpoint is free and requires no API key, implying it's safe to call without authentication. However, it doesn't explicitly state when to use this vs alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific data breach by name from HaveIBeenPwned. Free endpoint, no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The breach name (Pascal-cased, e.g. 'Adobe' or 'LinkedIn') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only notes that the endpoint is free and no API key is needed, but does not mention that it is a read-only operation, rate limits, or any other behavioral characteristics beyond the implied 'get' operation.
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 extremely concise with two sentences, no unnecessary words, and front-loaded key information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description covers the purpose and key constraint (free, no API key), but it lacks any description of the return format or fields, which would help the agent understand what data to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a description for the single parameter 'name', including Pascal-case examples. The description adds no additional meaning or context beyond what the schema 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 clearly states the verb 'Get', the resource 'details of a specific data breach', and the source 'HaveIBeenPwned'. This distinguishes it from sibling tools like breachList, breachSearch, and breachLatest.
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 mentions that it is a free endpoint with no API key required, providing useful context. However, it does not explicitly compare to sibling tools or state when to use this tool versus alternatives like breachSearch or breachList.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most recently added data breach from HaveIBeenPwned. Free endpoint, no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it's free and no API key needed, which is helpful since no annotations exist. However, it omits potential rate limits, error behavior, or response format details.
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 efficient sentences with no filler. Front-loaded with the action and source.
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, output-schema-less tool, the description covers what it does, the data source, and auth requirement completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and the schema coverage is 100%. Per guidelines, 0 parameters defaults to baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Get the most recently added data breach' with a clear verb and resource, distinguishing it from siblings like breachList and breachGet which provide different access patterns.
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?
It states it's free and requires no API key, implying ease of use, but does not explicitly compare to alternative breach tools 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.
List all known data breaches from HaveIBeenPwned. Optionally filter by domain. Free endpoint, no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Optional domain to filter breaches (e.g. 'adobe.com') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. It correctly notes that the tool is free and requires no API key. However, it omits details on rate limits, pagination, or data freshness, leaving some behavioral aspects unclear.
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 extremely concise at two sentences, with the purpose stated first and an additional useful detail (free, no key) in the second sentence. Every word serves a purpose, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description provides sufficient context: it lists all breaches, filters by domain optionally, and notes the free access. No critical gaps are present, though it could optionally specify the output format or scale.
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 optional 'domain' parameter, with the description repeating the schema's example. As the schema already fully describes the parameter, the description adds no extra semantic value, meeting the baseline of 3.
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 verb 'List', resource 'all known data breaches', and source 'HaveIBeenPwned', with an optional domain filter. While it distinguishes from siblings like breachGet and breachSearch, it does not explicitly differentiate from them.
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 mentions 'Free endpoint, no API key required', providing some context on accessibility. However, it lacks explicit guidance on when to use breachList versus related tools such as breachSearch or breachLatest, and does not mention any restrictions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a password has appeared in known data breaches using the Pwned Passwords k-anonymity API. Only the first 5 characters of the SHA-1 hash are sent to the server. Free, no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | The password to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It reveals that only the first 5 characters of the SHA-1 hash are sent (privacy), and that no API key is needed. However, it does not describe the response format (e.g., boolean, count), rate limits, or error handling. The description adds some transparency but misses key behavioral details for a tool that expects a 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 exceptionally concise: two sentences cover purpose, privacy method, and cost. Every word adds value. There is no fluff or repetition. It is front-loaded with the main action and then provides essential context.
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 that there is no output schema, the description should explain what the agent can expect as a result. It says 'Check if a password has appeared' but does not specify the return format (e.g., boolean, count, or summary). For a single-parameter tool without output schema, this gap reduces completeness. The input handling is well covered, but output is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'password' with a generic description. The description adds significant meaning beyond the schema: it explains that the password is SHA-1 hashed and only the first 5 characters are sent (k-anonymity). This tells the agent how the parameter is processed internally, which is valuable for understanding privacy and security implications.
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 verb 'Check' and the resource 'password has appeared in known data breaches'. It uses the specific 'Pwned Passwords k-anonymity API', which distinguishes it from sibling tools like breachSearch that check accounts or domains. The purpose is unambiguous and specific.
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 practical context: it explains that only the first 5 characters of the SHA-1 hash are sent (privacy feature) and that it is free with no API key required. This helps the agent understand when to use this tool (low-barrier, privacy preserving). However, it does not explicitly state when not to use or mention alternatives among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for an email address in publicly posted pastes (Pastebin, etc.) via HaveIBeenPwned. Requires HIBP_API_KEY (paid endpoint).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email address to search for in pastes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the data source (HaveIBeenPwned), the type of data (public pastes), and the API key requirement. It could add details about rate limits or result format, but is sufficiently transparent for a simple search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no redundant words. Efficient and easy to parse.
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?
The tool is simple with one parameter and no output schema. The description covers purpose, source, and requirements. It could mention the response structure, but overall it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the email parameter as 'The email address to search for in pastes'. The description adds no additional parameter information beyond what is in the schema, so 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 clearly states the action (search), resource (publicly posted pastes via HaveIBeenPwned), and input (email address). It distinguishes from sibling tools like breachSearch by specifying the data source and endpoint.
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?
It explicitly mentions the requirement for a HIBP_API_KEY and that it is a paid endpoint, providing crucial usage constraints. However, it does not compare to alternatives or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search all data breaches for a specific account (email or username) via HaveIBeenPwned. Requires HIBP_API_KEY (paid endpoint).
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | The email address or username to search for | |
| truncateResponse | No | If true, only return breach names (not full details). Default false. | |
| includeUnverified | No | If true, include unverified breaches. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must bear full burden. It discloses the need for a paid API key and that it calls an external endpoint, but does not mention rate limits, destructive behavior (likely none), or what happens on no results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and front-loaded with the core purpose. No unnecessary words.
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 3 parameters, the description covers the essential purpose and requirement but does not describe return format or behavior when no breaches found. Adequate but could be more complete.
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 baseline is 3. The description adds context for 'account' (email or username) and requires API key, but does not elaborate on boolean parameters beyond what schema 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 clearly states the tool searches data breaches for a specific account using HaveIBeenPwned. It distinguishes from sibling tools like breachGet and breachList by specifying the search by account.
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 indicates when to use this tool (searching by account) and mentions the prerequisite HIBP_API_KEY. It does not explicitly state when not to use it, but the sibling tools cover other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a Bitcoin address for abuse reports on ChainAbuse. Returns scam reports with categories and descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Bitcoin address to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It states the tool is a 'check' (implying read-only) and returns reports, but does not mention any prerequisites, rate limits, or authentication needs, which are important for agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise, front-loaded, and contains no superfluous information. 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 tool with one parameter and no output schema, the description provides adequate information: what it does and what it returns. No critical gaps are apparent.
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% with a clear description for the 'address' parameter. The description adds the context of ChainAbuse but does not significantly enhance parameter meaning beyond the schema. 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?
Description clearly states the verb (check), resource (Bitcoin address), and what it returns (scam reports). It differentiates from sibling tools like abuseipdb checks by specifying ChainAbuse as the source and focusing on Bitcoin addresses.
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?
Description lacks explicit guidance on when to use this tool versus alternatives, such as other abuse check tools. The context is implied but not stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a Bitcoin address on blockchain.info. Returns balance, transaction count, and recent transactions.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Bitcoin address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries burden. States what is returned (balance, tx count, recent txs) but not rate limits, authentication, or potential delays. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with all essential info: action, source, output. No 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 tool with no output schema, description adequately communicates return values. Could include whether 'recent transactions' is limited or paginated, but fine for most cases.
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 has 100% coverage with description 'Bitcoin address'. Description adds no extra format hints (e.g., 'base58' or 'starts with 1/3/bc1'). Baseline score.
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?
Clearly states it looks up a Bitcoin address on blockchain.info and returns balance, transactions. Differentiates from siblings like btc_balance and btc_tx implicitly by combining both, but no explicit distinction.
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 guidance on when to use vs siblings (e.g., btc_balance for just balance, btc_tx for just transactions). Assumes user knows to use for full address lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Bitcoin address balance in satoshi from blockchain.info. Quick balance check without full transaction history.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Bitcoin address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses that the tool is a read-only, lightweight operation ('Quick balance check'). No contradictory or missing behavioral details for a simple balance query.
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 wasted words. Front-loaded with the key action and resource. Highly efficient.
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?
The description is complete for a simple tool with one parameter and no output schema. It explains the purpose, source, and speed, allowing an agent to infer the output format. No significant gaps.
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% with a single parameter described. The description adds value by specifying the result unit (satoshi) and data source (blockchain.info), which are not 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?
Clearly states the action (Get), resource (Bitcoin address balance), unit (satoshi), and source (blockchain.info). Distinguishes from sibling tools like btc_address and btc_tx by noting it's a quick balance check without full 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?
Provides context for when to use (quick balance check, no full transaction history) but does not explicitly state when not to use or mention alternative tools. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed Bitcoin transaction information by hash. Returns inputs, outputs, fees, and block info.
| Name | Required | Description | Default |
|---|---|---|---|
| txhash | Yes | Bitcoin transaction hash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses that the tool returns inputs, outputs, fees, and block info, indicating a read operation. Lacks details on rate limits or caching, but for a simple lookup it gives adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Clearly front-loaded with the action and resource. 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?
No output schema exists, so description explains return fields (inputs, outputs, fees, block info). Covers the essential behavioral aspects for a simple retrieval tool. No gaps noted.
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 has 100% coverage with description for parameter 'txhash'. Description adds 'by hash' but does not significantly augment the schema meaning. Baseline 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?
Description clearly states verb 'Get' and resource 'Bitcoin transaction information by hash'. It lists specific return fields (inputs, outputs, fees, block info) and distinguishes from sibling tools like btc_address and btc_balance.
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?
Description indicates when to use (get transaction details by hash) and implies it's for detailed info versus other btc tools. Does not explicitly state when not to use or mention alternatives, but sibling names provide sufficient differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available darknet-mcp data sources with their configuration status, required API keys, and available tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output contents but does not explicitly state that the tool is read-only or whether it requires authentication. However, given no parameters, the behavioral impact is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, no extraneous words, every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool lists, but does not specify the output format (e.g., array of objects, list of strings). Given no output schema, a brief mention of format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters and schema coverage is 100%. According to the rubric, zero parameters earns a baseline of 4. The description adds no parameter info because none exist.
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 verb 'list' and the resource 'all available darknet-mcp data sources', specifying three output aspects: configuration status, required API keys, and available tools. This distinguishes it from sibling tools which are specific data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a discovery/configuration use case but does not explicitly state when to use this tool versus the individual data source tools (siblings). No alternatives or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick GreyNoise check: is this IP a known scanner or known benign service? Returns simplified classification.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IP address to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Does not disclose whether read-only, API limits, or any side effects. Minimal insight into behavior beyond basic check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded with action and resource.
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?
Simple tool with one param and no output schema. Description explains purpose but not return format or classification details. Adequate but leaves ambiguity about what 'simplified classification' means.
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% with a single IP parameter. Description adds no extra meaning beyond what schema already provides. Baseline 3.
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?
Clearly states it checks an IP for known scanner or benign service, returning a simplified classification. Does not explicitly differentiate from sibling greynoise_ip, but purpose is clear.
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 guidance on when to use this vs alternatives like greynoise_ip. The 'Quick' prefix implies lightweight use, but no explicit when-not or scenario context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an IP address on GreyNoise Community API. Returns classification (benign/malicious/unknown), scanner status, and last seen timestamp. Free, no API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IP address to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool is free and requires no API key, and lists return fields. However, it does not disclose potential side effects, rate limits, or error states. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no wasted words. Every sentence adds value: the first states purpose and outputs, the second highlights key differentiators (free, no key).
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, the description adequately summarizes return values (classification, scanner status, last seen). It provides key usage context (free, no key) but could mention error handling or additional fields for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'ip' parameter. The tool description does not add additional meaning 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?
Clearly states 'Look up an IP address on GreyNoise Community API' with specific verb and resource. Lists return fields (classification, scanner status, last seen) and notes it's free with no API key, helping distinguish from sibling tools that may require keys or have different sources. However, does not explicitly contrast with other IP lookup 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 useful context: 'Free, no API key required' suggests it's for quick, unauthenticated lookups. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., abuseipdb_check) and does not mention limitations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initiate a phonebook search on IntelligenceX — finds emails, domains, URLs associated with a term. Returns search ID. Requires INTELX_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | Search term | |
| target | No | Target type: 0=all, 1=emails, 2=domains, 3=URLs | |
| max_results | No | Max results (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return value (search ID) and the API key requirement. However, it does not mention any potential side effects, rate limits, or whether the search is synchronous. The description is adequate but lacks depth.
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 long, concise, and front-loaded with the core action. Every sentence adds value: the first explains the operation, the second states the return type and a key requirement. No wasted words.
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 tool with three parameters and no output schema, the description covers the essential aspects: what it does, what it returns, and a prerequisite. It does not explain how to use the returned search ID (e.g., with intelx_phonebook_results), but the sibling tool list implies the workflow. Overall, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all three parameters. The description does not add new semantic meaning beyond what the schema provides, earning the baseline score of 3.
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 initiates a phonebook search on IntelligenceX, specifying it finds emails, domains, and URLs associated with a term and returns a search ID. This is a specific verb+resource combination that distinguishes it from sibling tools like intelx_search.
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 mentions the requirement for INTELX_API_KEY, which is a crucial usage condition. It does not specify when to use this tool versus alternatives, but the phonebook specialization implies its context. The sibling intelx_phonebook_results suggests a workflow, but no exclusion guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve phonebook search results from IntelligenceX by ID. Use after intelx_phonebook. Requires INTELX_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Phonebook search ID from intelx_phonebook | |
| offset | No | Result offset (default 0) | |
| limit | No | Max results per page (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions API key requirement and sequencing but does not state whether the tool is read-only, pagination behavior, or error handling. Minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second gives usage and prerequisite. No unnecessary words or repetition.
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 essential workflow (sequencing, authentication) but lacks details on return format, pagination, or error cases. For a simple retrieval tool, it is mostly complete.
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 parameters are well-documented. Description adds value by linking the 'id' parameter to the preceding intelx_phonebook call, clarifying the workflow. Offset and limit are defined in schema; no additional semantics needed.
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 clearly states the action ('Retrieve phonebook search results') and the resource ('by ID from IntelligenceX'). It distinguishes from sibling intelx_phonebook by specifying this tool is for retrieving results after the search is initiated.
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 says 'Use after intelx_phonebook' and 'Requires INTELX_API_KEY', providing clear sequencing and prerequisite. Does not explicitly list when not to use, but context makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initiate a search on IntelligenceX for leaked data, dark web content, and more. Returns a search ID to retrieve results. Requires INTELX_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | Search term (email, domain, IP, Bitcoin address, etc.) | |
| max_results | No | Max results (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool requires an API key and returns a search ID, which is adequate. However, it does not discuss rate limits, error handling, or whether the search is asynchronous.
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 extremely concise with three short sentences. Every sentence adds essential information: action, output, and requirement. No unnecessary words.
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 two-parameter tool with no output schema, the description covers the key aspects: input, output (search ID), and prerequisite (API key). It could be improved by mentioning that results are fetched via intelx_search_results, but it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both 'term' and 'max_results' have clear descriptions in the schema. The description adds no additional semantic value 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 clearly states the verb 'Initiate a search' on IntelligenceX for leaked data and dark web content, and specifies that it returns a search ID. This distinguishes it from sibling tools like intelx_search_results, which retrieves results.
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: provide a search term, get an ID, then use that ID to fetch results. It also notes the required INTELX_API_KEY. However, it lacks explicit when-not-to-use or alternatives, but the context of sibling tools provides clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve results for an IntelligenceX search by ID. Use after intelx_search to get actual data. Requires INTELX_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Search ID from intelx_search | |
| offset | No | Result offset (default 0) | |
| limit | No | Max results per page (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions the API key requirement and basic operation, omitting details about pagination, rate limits, error handling, or data freshness. Minimal behavioral disclosure.
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, zero waste. Every word is informative and necessary. The description is front-loaded with the core action and provides usage context succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, so description must be more complete. It covers the basic workflow and prerequisites but lacks details on result format, pagination behavior, and error states. Adequate for a simple retrieval tool but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents each parameter's meaning. The description adds slight value by clarifying that 'id' is from intelx_search, but offset and limit are standard. Baseline score achieved without significant added semantics.
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 ('Retrieve results') and resource ('IntelligenceX search by ID'), clearly distinguishing it from sibling tools like intelx_search (which initiates the search) and intelx_phonebook_results.
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 'Use after intelx_search to get actual data' and mentions the API key requirement, providing clear sequencing context. No explicit alternatives or exclusions, but sufficient for the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest malware detonation feed from Hybrid Analysis. Returns recently analyzed samples with verdicts. Requires HYBRID_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It mentions authentication (API key) but does not disclose rate limits, pagination, data freshness, or potential destructive behavior. The description is minimal.
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 with no waste: first states purpose, second states requirement. Front-loaded and efficient.
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 parameters and no output schema, the description is adequate but incomplete. It does not specify return format, data volume, or whether the feed is filterable. More detail would help agent planning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100%. The description adds meaning by explaining what the tool does without parameters, meeting the baseline 4 for 0-parameter tools.
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 retrieves the latest malware detonation feed from Hybrid Analysis, specifying it returns recently analyzed samples with verdicts. This verb+resource combination is distinct among 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 mentions requiring HYBRID_API_KEY but provides no guidance on when to use this feed over sibling tools like malware_search or bazaarRecent. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full malware analysis overview from Hybrid Analysis for a SHA256 hash. Returns MITRE ATT&CK techniques, network indicators, processes, and extracted files. Requires HYBRID_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | Yes | SHA256 hash of the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that an external API key (HYBRID_API_KEY) is required, which is a crucial behavioral constraint. It also summarizes the output categories, but does not cover rate limits, destructive potential (none), or response format limitations. For a simple read tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: the first covers purpose and outputs, the second states a critical requirement (API key). No redundant phrases, and the most important information 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?
For a simple tool with one input, no output schema, and no nested objects, the description covers the main response types and a key prerequisite. It lacks information on error handling, pagination, or response size limits, but given the tool's straightforward nature, it is largely complete.
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 'sha256', and its schema description ('SHA256 hash of the file') is clear. The tool description does not add extra details such as expected length, character set, or examples. Since the schema already provides sufficient semantic meaning, 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?
Description clearly states the verb 'Get', the resource 'malware analysis overview', and the required input (SHA256 hash). It lists specific return types (MITRE ATT&CK, network indicators, etc.), distinguishing it from sibling tools that handle IPs, domains, or other indicator types.
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 a SHA256 hash is available and a full analysis is needed, but it does not explicitly compare with alternative hash-analysis tools (e.g., bazaarHash, otx_hash) or provide when-not-to-use guidance. No exclusions or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Hybrid Analysis sandbox by file hash (MD5, SHA1, SHA256). Returns verdict, AV detection rate, and analysis details. Requires HYBRID_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | File hash (MD5, SHA1, or SHA256) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behaviors. It states the tool returns verdict, AV detection, and analysis details, and requires an API key. However, it does not mention rate limits, pagination, or any side effects. For a read-only lookup, this is adequate but lacks detail on potential constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core action and purpose, and includes necessary context (API key requirement). Every word is informative; there is 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?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is mostly complete. It specifies input, output summary, and authentication. A minor gap is the lack of mention of possible error conditions or response format, but for this type of tool the description suffices.
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 sole parameter 'hash' has schema description 'File hash (MD5, SHA1, or SHA256)', which is clear. The description adds value by enumerating the acceptable hash types, going beyond the schema's generic string type. Schema coverage is 100%, so the description supplements rather than repeats.
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 clearly states the verb 'search', the resource 'Hybrid Analysis sandbox', and the type of input (file hash). It lists the hash types accepted and what is returned, making the purpose unambiguous. It distinguishes from siblings which target different services like AbuseIPDB, Bazaar, or OTX.
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 indicates the tool is for searching Hybrid Analysis using a file hash and mentions the API key requirement. However, it does not explicitly state when to use this tool over other hash lookups like otx_hash or bazaarHash, nor does it provide guidance on when not to use it. The sibling list contains many similar tools, so more explicit guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up metadata for a .onion address via CIRCL AIL project. Returns first/last seen dates, status, tags, certificates, ports, and associated Bitcoin addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | .onion address or full URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return fields but omits whether read-only, potential rate limits, or authentication. With no annotations, this is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence front-loaded with action and source, followed by list of return fields. No wasted words.
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 one-param tool with no output schema, description covers purpose and return data well. Could mention that it's a lookup from CIRCL AIL with no 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?
Single parameter 'address' with schema description '.onion address or full URL'. Description adds slight nuance (accepts full URL) but schema coverage is 100%, baseline 3.
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?
Clearly states verb 'Look up' for '.onion address' via 'CIRCL AIL project', distinct from sibling tor tools that scrape or search. Lists specific return fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs. sibling tools like tor_search_onion or tor_fetch_onion. Context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up threat intelligence for a CVE via AlienVault OTX. Returns related pulses and indicators.
| Name | Required | Description | Default |
|---|---|---|---|
| cve | Yes | CVE ID (e.g. CVE-2024-1234) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states it is a lookup operation returning data, implying no side effects, but does not explicitly confirm read-only nature or mention any authentication or rate limits. Adequate for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, no redundant information. Every part 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?
The description explains both input (CVE) and output (pulses and indicators), which is sufficient given the simplicity of the tool and lack of output schema. Could be more precise about the format of returns, but overall complete.
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% with the 'cve' parameter fully described. The description only rephrases the schema (e.g., 'CVE ID') and adds an example format, adding no significant new meaning beyond what the schema 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 clearly states the verb 'Look up', the resource 'threat intelligence for a CVE via AlienVault OTX', and explicitly mentions the return types 'related pulses and indicators'. It uniquely identifies this tool for CVE lookups among siblings like otx_domain, otx_hash, etc.
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 tool name and description make it obvious it should be used for CVE lookups. Sibling tools cover different indicator types (domain, hash, IP, search pulses), providing clear context. However, there is no explicit 'when-not' or alternative suggestion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up threat intelligence for a domain via AlienVault OTX. Returns pulse info, whois, reputation.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to look up (e.g. example.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavioral traits. It states the tool returns data but does not mention side effects, authentication needs, rate limits, or any constraints. Adequate for a read-only lookup but lacks depth.
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 deliver the essential purpose and output without any wasted words. Perfectly concise and 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?
For a single-parameter lookup tool with no output schema, the description is sufficiently complete. It explains what the tool does and what it returns. Could mention update frequency or data freshness, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the 'domain' parameter. The description adds no new semantic detail beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up threat intelligence for a domain via AlienVault OTX and specifies the output (pulse info, whois, reputation). This distinguishes it from siblings like otx_ip, otx_hash, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for domains but provides no explicit guidance on when to use this tool versus alternatives. Given many sibling tools for different indicator types, a usage directive would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up threat intelligence for a file hash via AlienVault OTX. Supports MD5, SHA1, SHA256.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | File hash (MD5, SHA1, or SHA256) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only states the supported hash types but does not disclose rate limits, API key requirements, response format, or behavior when a hash is not found. Minimal behavioral insight.
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 efficiently worded sentences. No superfluous information. Purpose is front-loaded, making it easy to quickly understand the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description lacks information about return values, error handling, or prerequisites (e.g., API key). For a simple hash lookup tool, more context about expected output is necessary for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'hash' described as 'File hash (MD5, SHA1, or SHA256)'. The description reiterates this and adds context about threat intelligence, but does not provide additional semantic meaning beyond the schema. 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 clearly states the action ('Look up'), the resource ('file hash'), and the source ('AlienVault OTX'). It specifies supported hash types, distinguishing it from sibling tools like otx_domain and otx_ip.
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 for threat intelligence lookups but does not explicitly state when to use this tool versus alternatives (e.g., other hash lookup tools like bazaarHash or threatfoxSearch). No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up threat intelligence for an IP address via AlienVault OTX. Returns pulse info, reputation, country, ASN.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IPv4 address to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only lists outputs without discussing side effects, rate limits, authentication, or data freshness. As a read-only lookup, minimal behavioral disclosure is acceptable but not explicitly stated.
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 efficient sentences with purpose and outputs front-loaded. No wasted words.
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?
Simple tool with one parameter and no output schema; description adequately covers purpose and returned data. Could mention error conditions or data format, but overall complete for typical use.
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 'ip' parameter, with clear schema description. Description adds minimal context ('via AlienVant OTX') but does not enhance parameter understanding beyond 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?
Description clearly states 'Look up threat intelligence for an IP address via AlienVant OTX' with specific outputs (pulse info, reputation, country, ASN). This distinguishes it from sibling tools like abuseipdb_check or greynoise_ip.
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?
Implied usage is for IP threat intelligence from AlienVant OTX, but no explicit guidance on when to use this versus alternatives among many sibling threat intelligence tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search AlienVault OTX threat pulses by keyword. Returns matching pulses with tags, malware families, and IOC counts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| limit | No | Max results (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description gives minimal behavioral info: it's a search and returns data. Does not disclose rate limits, authentication needs, or whether it is read-only (though implied).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, no redundant words. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two documented parameters and no output schema, the description covers the basic purpose and return fields. Minor gap: no mention of pagination or ordering, but adequate overall.
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 both parameters (query and limit). The tool description adds 'keyword' but does not significantly enhance understanding 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?
Clearly states the action 'Search', the resource 'AlienVault OTX threat pulses', and what is returned (tags, malware families, IOC counts). Distinct from sibling tools like otx_hash or otx_ip.
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 guidance on when to use this tool vs alternatives. Does not mention that for other OTX indicators (domains, hashes) different tools should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a URL is a known phishing site via PhishTank. Returns whether the URL is in their database and if it has been verified.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to check for phishing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses the source (PhishTank) and return fields, but lacks details on API behavior, rate limits, authentication, error handling, or latency. Adequate but not comprehensive.
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?
Extremely concise with two sentences containing all essential information. No wasted words; front-loaded with the action and source.
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 check tool with one parameter and no output schema, the description covers the basic purpose and return intent. However, lacking an explicit output structure leaves some ambiguity about the exact return format, making it only moderately complete.
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% with a clear parameter description. The tool description does not add additional semantics beyond 'URL to check for phishing,' so it adds minimal value over 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 checks if a URL is a known phishing site via PhishTank and specifies the return information (whether in database and verified). This distinguishes it from sibling tools that check other threat intelligence sources like URLhaus or ThreatFox.
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 guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, conditions, or exclusions, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explore linked indicators on Pulsedive using advanced queries. Returns related IOCs with risk levels.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Explore query (e.g. 'ioc=pulsedive.com' or 'threat=Zeus') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returning 'IOCs with risk levels,' but does not disclose safety (e.g., read-only), authentication needs, rate limits, or potential side effects. For a tool that likely performs only reads, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences efficiently convey purpose and output. No extraneous information. Slight improvement could be front-loading the output type, but overall well-structured.
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 simple single parameter and no nested objects, the description combined with the schema provides adequate context. It mentions the return value (IOCs with risk levels) which compensates for the lack of output schema. However, missing details like pagination or query limitations reduce completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description and example for the single 'query' parameter. The description adds 'advanced queries' but no additional syntax or constraints beyond what the schema provides. Baseline 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 clearly states 'Explore linked indicators on Pulsedive using advanced queries' and 'Returns related IOCs with risk levels,' providing a specific verb and resource. It distinguishes from siblings like pulsedive_indicator (single indicator) and pulsedive_search (search by keyword).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., pulsedive_search, pulsedive_indicator). The phrase 'advanced queries' is vague and does not clarify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an indicator (IP, domain, URL, or hash) on Pulsedive. Returns risk level, threats, feeds, and properties.
| Name | Required | Description | Default |
|---|---|---|---|
| indicator | Yes | Indicator value (IP, domain, URL, or hash) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates read-only retrieval ('look up', 'returns risk level...'), so no hidden destructive behavior. But lacks details on side effects, rate limits, or dependency on external data freshness. Adequate for a simple lookup but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently captures purpose and output. No wasted words; front-loaded with actionable verb and resource.
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?
Low complexity tool (1 param, no nested objects, no output schema). Description covers purpose, input types, and key output fields. Could briefly mention expected format (e.g., full URL vs domain) or error handling, but meets minimum for a straightforward 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?
Schema already provides 100% coverage with description for the single parameter. Tool description repeats same info (IP, domain, URL, or hash) but adds no new semantic detail beyond schema. Baseline 3.
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?
Clear verb 'look up' + specific resource 'indicator on Pulsedive' and types listed (IP, domain, URL, hash) and return values. However, does not differentiate from sibling tools pulsedive_explore or pulsedive_search, which could be confused for similar functions.
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 guidance on when to use this tool versus siblings, no exclusions or prerequisites. Agent must infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Pulsedive indicators by value. Returns matching indicator IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the basic functionality and output type. It does not mention whether the tool is read-only, if any authentication or rate limits apply, or the scope of the search. This is insufficient for an agent to understand the tool's operational 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 extremely concise at two sentences, with no unnecessary words. It directly states the action and result. Fits the principle of front-loading essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the basic purpose and return type. However, for complete context, an agent might need more details about the search scope, data coverage, or expected response structure. It meets minimal viability but leaves gaps.
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% but the schema description for 'query' is generic ('Search query'). The tool description adds value by specifying that query is an 'indicator value' (by value), which clarifies the parameter's semantics. However, no further detail is given about acceptable value formats or constraints.
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 clearly states the tool searches Pulsedive indicators by value and returns matching indicator IDs. The verb 'Search' and resource 'indicators' are specific, and the return type is mentioned. Distinguishes from sibling tools like pulsedive_explore and pulsedive_indicator which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as pulsedive_indicator (for individual indicator details) or pulsedive_explore. No mention of query format, limitations, or prerequisite knowledge. The description is too minimal to provide effective usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all ransomware groups tracked by RansomLook. Returns 582+ groups with names and associated onion/clear-web URLs. Complementary source to ransomware.live.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It states it lists groups with names and URLs, which is a straightforward read operation. However, it could mention idempotency, rate limits, or output format. The description is adequate for a simple list tool but not rich.
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 extremely concise: two sentences with no extraneous words. It front-loads the core action ('List all ransomware groups') and provides key details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the essential aspects: what it does, what it returns, and a usage hint. It could mention whether it requires authentication or pagination, but for a straightforward list tool, it is fairly complete.
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 no parameters, and the schema coverage is trivially 100%. The description adds value by specifying that it returns 582+ groups with names and onion/clear-web URLs, which goes beyond the empty 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 it lists all ransomware groups tracked by RansomLook and specifies the return content (names, URLs). It distinguishes itself from sibling tools by mentioning it's a complementary source to ransomware.live, though it doesn't explicitly differentiate from the similar 'ransomwareGroups' tool.
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 hint about when to use it ('Complementary source to ransomware.live') but lacks explicit when-to-use, when-not-to-use, or direct comparisons with sibling tools. The guidance is implied rather than concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the most recent ransomware posts and victim claims from RansomLook. Returns group name, post title, URL, and discovery timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only states what it does. Lacks details on rate limits, pagination, ordering, or freshness of 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?
Single sentence with all key information: purpose, source, and return fields. No wasted words.
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 parameterless fetch tool, description is sufficient. Could mention ordering or limit, but not required for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description adds no parameter info. Baseline for zero parameters is 4; description is clear about what it returns.
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 clearly states the verb 'Fetch' and resource 'most recent ransomware posts and victim claims', and lists return fields. Differentiates from siblings like ransomlookGroups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives, but as a parameterless tool it is straightforward. Minimal context for choosing over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ransomware victims filtered by country using ISO 3166-1 alpha-2 country code. Example codes: US, GB, DE, TR, FR, JP.
| Name | Required | Description | Default |
|---|---|---|---|
| countryCode | Yes | ISO 3166-1 alpha-2 country code (e.g. 'US', 'GB', 'DE', 'TR') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Get ransomware victims' implying read-only, but lacks details on response format, pagination, rate limits, or error handling. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence defining the tool's purpose followed by example codes. No extraneous information, 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 tool with one required parameter and no output schema, the description is adequate but lacks details about the response structure or potential errors. It does not explain the format of the returned data or any limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameter as 'ISO 3166-1 alpha-2 country code' with examples. The description adds example codes but does not add meaning beyond the schema. With 100% schema coverage, baseline 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 clearly states the tool retrieves ransomware victims filtered by country, with a specific action 'Get' and resource 'ransomware victims'. This distinguishes it from siblings like ransomwareBySector or ransomwareSearch which filter by other criteria.
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 example country codes but does not explicitly state when to use this tool versus alternatives like ransomwareBySector or generic search. No exclusions or context for 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.
Get ransomware victims filtered by sector or industry. Examples: 'healthcare', 'finance', 'education', 'government', 'technology'.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | Yes | Sector or industry name (e.g. 'healthcare', 'finance', 'education') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes basic behavior but lacks details on data freshness, response format, or authentication needs. For a simple read tool, this is adequate but not comprehensive.
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 one concise sentence with examples, no fluff, and front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not explain the return format (e.g., list of names, details). However, given the simplicity and sibling tools, it is moderately complete for a filtered 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?
Schema coverage is 100% with the description of 'sector' already clear. The description adds a few more examples ('government', 'technology') but does not significantly enhance meaning 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 action ('Get') and resource ('ransomware victims filtered by sector or industry'), and provides examples. It distinguishes from sibling tools like ransomwareByCountry and ransomwareGroup.
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 for sector-based filtering but does not explicitly compare to alternatives like ransomwareByCountry. However, the context of sibling names clarifies its role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a detailed profile for a specific ransomware group by name. Includes description, known URLs, locations, and profile metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Ransomware group name (e.g. 'lockbit3', 'clop', 'blackcat') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, requires authentication, or has rate limits. It only lists the included data fields without addressing side effects or prerequisites.
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 concise sentence that effectively communicates the tool's purpose and included data. It is appropriately front-loaded, though it could be slightly more structured.
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 only one required parameter, no annotations, and no output schema, the description provides adequate detail about what the tool returns (description, URLs, locations, metadata). It is complete enough for a simple lookup 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 input schema covers the sole parameter 'name' with a description and examples, achieving 100% coverage. The tool description adds no extra meaning beyond 'by name', so baseline score 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 the tool retrieves a detailed profile for a specific ransomware group by name, listing included data (description, URLs, locations, metadata). This distinguishes it from sibling tools like ransomwareGroups (list all groups) or ransomwareGroupVictims (list victims).
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 details of a known group, but does not explicitly state when to use this tool versus alternatives like ransomwareGroups or ransomwareGroupVictims. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all known ransomware groups tracked by ransomware.live. Returns group names, descriptions, onion URLs, and profile information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present. Description mentions return fields but does not disclose limitations such as rate limits, data freshness, or authentication needs. Adequate for a read-only listing tool.
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 clearly structured: first states purpose, second details returns. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is complete: specifies it returns all known groups and key fields. No output schema, but description compensates adequately.
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?
Input schema has 0 parameters with 100% coverage. Description adds value by specifying the output (group names, descriptions, onion URLs, profile information) beyond the schema. Baseline 4 applies for 0 parameters.
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 clearly states 'List all known ransomware groups tracked by ransomware.live.' with specific verb (list), resource (ransomware groups), and source. Distinct from siblings like ransomwareGroup (single group) and ransomwareGroupVictims.
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?
Description implies usage for getting all groups but does not explicitly state when to use vs alternatives like ransomwareGroup or ransomwareSearch. No exclusions or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all victims claimed by a specific ransomware group. Returns victim names, countries, sectors, and publication dates.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Ransomware group name (e.g. 'lockbit3', 'clop', 'blackcat') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a read operation ('Get all victims') and lists return fields, which is sufficient for a straightforward query tool. No contradictory statements.
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 front-loaded sentences with zero waste. Clearly states action, resource, and return data without unnecessary details.
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 single-parameter query tool with no output schema, the description adequately covers purpose and return fields. Could mention potential large result sets or rate limits, but not essential for basic use.
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 already provides parameter description with examples ('e.g. 'lockbit3', 'clop', 'blackcat''). The tool description does not add additional semantic meaning beyond what the schema offers, so baseline 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?
Description clearly states 'Get all victims claimed by a specific ransomware group', specifying the verb and resource, and lists return fields (names, countries, sectors, publication dates). It differentiates from sibling tools like 'ransomwareByCountry' and 'ransomwareGroup' by focusing on victims of a specific group.
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?
Usage is implied from the tool name and description, but no explicit guidance on when to use versus alternatives like 'ransomwareSearch' or when not to use. Lacks exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the most recent ransomware victims from ransomware.live. Returns victim name, group, country, sector, publication date, and associated URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it fetches data and returns specific fields, but does not mention any behavioral traits such as freshness guarantees, rate limits, or pagination. For a read operation, more context about data recency or size would be helpful.
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 only two sentences, front-loaded with the action verb 'Fetch'. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description provides sufficient context: data source, list of returned fields, and purpose. It lacks mention of ordering or maximum results, but for a simple recent-victims tool, it is largely complete.
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 and schema coverage is 100%, so the description does not need to add parameter details. It adds value by listing the return fields, which compensates for the lack of output 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 uses specific verb 'Fetch' and resource 'most recent ransomware victims' from a named source (ransomware.live), and lists the returned fields (name, group, country, sector, publication date, associated URLs). This clearly distinguishes it from sibling tools like ransomwareSearch (which filters) and ransomwareGroupVictims (by group).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving recent victims without filters, but does not explicitly state when to use this tool versus alternatives like ransomwareSearch or ransomwareByCountry. No 'when-not-to-use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ransomware victims by keyword. Matches against victim names, descriptions, and other fields. Useful for checking if a specific company has been listed as a victim.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search keyword (company name, domain, or other identifier) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only describes the search functionality without mentioning any behavioral traits such as rate limits, authentication requirements, or result limits. The description is insufficient for a tool with no 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?
The description is extremely concise, consisting of two short sentences that convey the purpose, matching criteria, and use case without any filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and no output schema, the description is sufficiently complete. It explains what it searches, what fields it matches, and provides a typical use case. Minor gap: it does not specify the format or scope of 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 coverage is 100% and the parameter 'keyword' is described in the schema. The description adds value by clarifying that matches occur against 'victim names, descriptions, and other fields,' which is not explicitly stated 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 verb 'Search', the resource 'ransomware victims', and specifies matching fields (victim names, descriptions, etc.). It distinguishes this tool from sibling tools like ransomwareByCountry or ransomwareBySector by focusing on keyword search.
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 use case: 'checking if a specific company has been listed as a victim.' It implies alternatives (e.g., other ransomware tools) but does not explicitly state when not to use it or differentiate from all siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Hudson Rock Cavalier for stealer log entries by domain. Returns compromised machines, credentials, and malware details. Requires HUDSONROCK_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to search (e.g. example.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the API key requirement and the type of data returned, but does not mention rate limits, pagination, error behavior, or the read-only nature of the operation. The description is adequate but lacks depth beyond the basic function.
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 extremely concise with two sentences covering purpose, output, and prerequisites. No unnecessary words or repetition, making it efficient for an AI agent to parse.
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 simplicity of the tool (single parameter, no output schema), the description covers the essential information: purpose, input, output type, and authentication. It lacks some edge-case details but is largely complete for a straightforward lookup 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?
Schema coverage is 100% with a clear description for the 'domain' parameter. The tool description adds the API key requirement but provides no additional semantic detail about the parameter itself beyond what the schema already offers. 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 specifies the action ('Search'), the data source ('Hudson Rock Cavalier for stealer log entries'), the scope ('by domain'), and the output ('compromised machines, credentials, and malware details'). It clearly distinguishes from sibling tools like stealer_email and stealer_ip by focusing on domain-based lookup.
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 states what the tool does and the prerequisite (API key), but does not explicitly explain when to use this vs alternatives. The domain parameter and name imply usage for domain-based stealer log searches, which differentiates it from email or IP based siblings, though no direct 'when-not-to-use' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Hudson Rock Cavalier stealer logs by email address. Returns compromised machines with that email in browser credentials. Requires HUDSONROCK_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the API key requirement and states the return type (compromised machines, browser credentials). While it lacks details on response structure or rate limits, it sufficiently indicates the tool's safe, read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that effectively front-load the purpose and essential constraint (API key). No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description is mostly complete. It explains the action, required key, and result. It could mention whether results are real-time or historical, but this is not crucial for a simple lookup 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 only parameter 'email' has 100% schema coverage with a basic description. The tool description adds no additional meaning beyond what the schema provides, so the 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 clearly states the action ('Search'), the specific resource ('Hudson Rock Cavalier stealer logs'), and the search key ('by email address'). It also describes the output ('Returns compromised machines with that email in browser credentials'), effectively distinguishing it from siblings like stealer_domain and stealer_ip.
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 mentions a prerequisite ('Requires HUDSONROCK_API_KEY'), but does not provide guidance on when to use this tool vs alternatives or any context for exclusion. Usage is implied but not explicitly directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Hudson Rock Cavalier stealer logs by IP address. Returns compromised machines originating from that IP. Requires HUDSONROCK_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IP address to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that results are compromised machines from that IP and the API key requirement, but does not detail limitations or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no unnecessary words, front-loaded with core action and result.
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 one-parameter tool with no output schema, the description sufficiently covers input, output, and requirements.
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 already describes 'ip' parameter, but description adds value by explaining the search returns compromised machines from that IP, not just any search results.
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 clearly states the tool searches stealer logs by IP address and returns compromised machines, distinguishing it from sibling tools like stealer_domain and stealer_email which search by other criteria.
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?
Mentions requirement of HUDSONROCK_API_KEY but does not explicitly state when to use this tool versus alternatives; however, the tool name and sibling names imply IP-specific searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent IOCs from ThreatFox (abuse.ch). Returns indicators of compromise reported in the last N days.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days to look back (1-30, default 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states that it returns IOCs. It fails to disclose potential limitations (e.g., result count limits, pagination), whether the operation is idempotent, or any rate limits. The description is insufficient for an agent to understand side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that gets to the point without unnecessary words. However, it sacrifices helpful detail for brevity, preventing a higher score.
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 tool returning IOCs, the description omits important context such as the format or structure of the output (e.g., list of hashes, IPs, etc.), any default ordering, or whether output is paginated. With no output schema and no annotations, the description should fill this gap but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'days' parameter with full details (range, default). The description adds no extra semantic meaning beyond what the schema provides, so 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 clearly states the tool retrieves recent IOCs from ThreatFox with a time range parameter. It does not explicitly differentiate from sibling tools like threatfoxSearch or threatfoxTag, but the purpose is specific enough to distinguish from broader threat intelligence 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?
The description gives no guidance on when to use this tool versus alternatives. It does not mention when to prefer this over other ThreatFox tools (e.g., threatfoxTag for tag-specific IOCs) or any non-ThreatFox tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ThreatFox IOCs by malware family using Malpedia naming convention (e.g., "win.cobalt_strike", "win.emotet").
| Name | Required | Description | Default |
|---|---|---|---|
| malware | Yes | Malware family name in Malpedia format (e.g., win.cobalt_strike) | |
| limit | No | Max results to return (1-1000, default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the input format and that it returns IOCs, but does not mention behavioral traits such as rate limits, authorization requirements, or the nature of the output (e.g., list of indicators, pagination). Since no annotations are provided, the description carries the full burden of transparency, and it falls short on these details.
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, well-structured sentence that front-loads the essential information. Every word serves a purpose, with no redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description covers the core action and input format. However, it lacks information about the return value (e.g., structure of IOCs, whether it returns a list or details), which would be expected without an output schema. This gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters. The description reiterates the malware family naming convention (Malpedia format), which is already present in the schema. Thus, the description adds minimal meaning beyond what the schema provides, justifying a baseline score of 3.
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 specifies the action (search), the resource (ThreatFox IOCs), the filter (malware family), and the required naming convention (Malpedia). It effectively distinguishes this tool from sibling tools like threatfoxSearch (general search) and threatfoxTag (by tag).
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 implicitly guides when to use this tool: when searching for IOCs by a specific malware family in Malpedia format. It does not explicitly state when not to use it or suggest alternatives, but the context of sibling tool names (threatfoxGetIocs, threatfoxSearch) provides some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ThreatFox IOCs by term. Accepts IP addresses, domain names, hashes (MD5/SHA256), or URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| searchTerm | Yes | Search term: IP, domain, hash (MD5/SHA256), or URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only describes input types and does not disclose return format, pagination, side effects, or whether the operation 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. The purpose is front-loaded and immediately understandable.
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 simple structure (1 param, no output schema, no annotations), the description provides basic context but lacks behavioral details like return format or error conditions, which an agent needs for correct 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 coverage is 100%, and the schema already describes the parameter. The description adds no additional meaning beyond listing the accepted types, which is 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 tool searches ThreatFox IOCs by a term, specifying the accepted types (IP, domain, hash, URL). It differentiates from siblings like threatfoxGetIocs or threatfoxTag, but does not explicitly contrast them.
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 have a specific IOC to search for, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it 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.
Search ThreatFox IOCs by tag (e.g., "Cobalt Strike", "Emotet", "AgentTesla").
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag to search for (e.g., Cobalt Strike, Emotet) | |
| limit | No | Max results to return (1-1000, default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It only says 'Search ... by tag' without mentioning that it is read-only, what the response format is, or any side effects. For a simple search tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and examples. No unnecessary words.
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 2 simple parameters and no output schema, the description is adequate but omits details like result format. It is minimally complete for a basic search 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?
Schema coverage is 100%, baseline 3. The description adds example values for 'tag' but no additional meaning for 'limit'. It does not significantly enhance parameter understanding 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 searches ThreatFox IOCs by tag, with concrete examples. It is specific and distinguishes from siblings like threatfoxSearch or bazaarTag.
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 (when searching by tag) but does not explicitly mention when not to use it or suggest alternative tools for other search criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a specific IP address is a known Tor exit node. Uses cached exit node list.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IP address to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially compensates by disclosing that the check uses a cached list, hinting at staleness. However, it does not detail cache refresh behavior or rate limits, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no redundant information, directly conveys the purpose and key attribute (cached list).
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 check with one parameter and no output schema, the description covers the essential use case. It could mention return type (e.g., boolean) but is adequate given the tool's simplicity.
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 benchmark is 3. The description adds no extra meaning beyond the schema's 'IP address to check,' failing to specify format (e.g., IPv4 vs IPv6) or valid ranges.
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?
Clearly states the tool checks if a specific IP is a Tor exit node, with a specific verb and resource, and hints at its cached nature which distinguishes it from related tools like tor_exit_nodes and tor_exit_details.
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 via 'Uses cached exit node list,' suggesting it's for quick checks, but does not explicitly state when to use this tool over siblings or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed Tor exit node information including fingerprints, publish timestamps, and exit addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entries to return (default: all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to disclose whether the operation is read-only, requires authentication, or has rate limits. The only behavior implied is 'get info', which is insufficient for safe AI invocation.
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, direct sentence that front-loads the main action. However, it could be slightly more structured by separating the purpose and details, but it remains efficient.
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 simple interface (one optional parameter, no output schema), the description covers the basics. It mentions key return fields, but lacks context like default limit behavior (though schema says default: all) or pagination. Adequate for minimal viability.
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 schema already describes the 'limit' parameter adequately. The description adds no extra meaning beyond what the schema provides—it only lists return fields, which are not part of the 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 verb 'Get' and the resource 'detailed Tor exit node information', including specific data types (fingerprints, publish timestamps, exit addresses). This distinguishes it from sibling tools like 'tor_exit_nodes' (simple list) and 'tor_exit_check' (single check).
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 guidance is provided on when to use this tool versus alternatives. For example, it doesn't contrast with 'tor_exit_nodes' for simple listing or mention prerequisites. The many similar Tor-related siblings make this omission significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of current Tor exit node IP addresses from the official Tor Project bulk exit list.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max IPs to return (default: all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits, but it only states what the tool does. It does not disclose read-only behavior, external data fetching, rate limits, or default behavior of the limit parameter.
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 concise sentence that adequately covers the tool's function. However, it is so minimal that it sacrifices completeness for brevity.
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 one optional parameter and no output schema, the description provides the essential purpose but does not describe the return format (e.g., an array of IPs) or any pagination. It is minimally acceptable but not rich.
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% with a clear description for the only parameter 'limit' ('Max IPs to return (default: all)'). The tool description adds no new parameter information, so 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 clearly states the verb 'Get', the resource 'list of current Tor exit node IP addresses', and the source 'official Tor Project bulk exit list'. It distinguishes from sibling tools like tor_exit_check and tor_exit_details.
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 guidance is provided on when to use this tool versus siblings or what context is appropriate. The description fails to mention if there are prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch raw HTML from a .onion URL via Tor SOCKS5 proxy. Requires a running Tor daemon. Only .onion URLs are allowed (DNS leak prevention via socks5h).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The .onion URL to fetch (http:// or https://) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses operational requirements (Tor daemon, proxy type, URL restriction) but does not cover error handling, timeouts, or return format details. Adequate for a simple fetch but leaves some behavioral traits implied.
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 fluff. First sentence states action, second adds constraints and requirements. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, no output schema), the description covers the main points: what it does, prerequisites, and constraints. Lacks potential details on output format or error behavior but is largely complete for typical use.
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?
Only one parameter 'url' with schema description 'The .onion URL to fetch (http:// or https://)'. Description adds context about the URL format and allowed protocol. Since schema coverage is 100%, baseline is 3; description provides minor additional value beyond 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 'Fetch raw HTML from a .onion URL via Tor SOCKS5 proxy', which is a specific verb+resource. It distinguishes itself from sibling tools like tor_search_onion and tor_scrape_onion by focusing on raw HTML fetching.
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 prerequisites (running Tor daemon) and constraints (only .onion URLs, DNS leak prevention via socks5h). It implies when to use (fetching .onion content) and when not (non-.onion URLs). No explicit alternatives mentioned, but context given is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and parse a .onion site via Tor. Returns structured data: page title, all links, and visible body text. Requires running Tor daemon.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The .onion URL to scrape |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the behavioral trait of requiring a running Tor daemon and specifies the output structure. However, it does not discuss potential errors, timeouts, or size limits.
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 concise sentences that efficiently convey the tool's function, output, and a key requirement, with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers purpose, input, output structure, and a critical prerequisite (Tor daemon), making it wholly complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'url' is fully described in the schema ('The .onion URL to scrape'). The description does not add significant meaning beyond the schema, as 'onion' is already implied by the tool name.
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 fetches and parses a .onion site via Tor, and specifies the returned structured data (page title, links, body text). It distinguishes itself from siblings like tor_fetch_onion and tor_search_onion through the parsing aspect.
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 mentions a requirement (Tor daemon) but does not provide explicit guidance on when to use this tool versus alternative sibling tools like tor_fetch_onion or tor_search_onion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for .onion sites using Ahmia.fi search engine. Returns titles, URLs, and descriptions of matching hidden services.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| limit | No | Max results (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the search engine used and the return format (titles, URLs, descriptions), but does not mention rate limits, authentication requirements, or any potential side effects. For a simple search tool, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no extraneous information. The purpose is front-loaded, and every word adds value. It is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description adequately covers the tool's behavior: it searches .onion sites via Ahmia and returns titles, URLs, and descriptions. No critical information is missing.
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% with both parameters described (query and limit). The description adds context beyond the schema by specifying the search engine and the structure of results, which helps the agent understand what each parameter contributes.
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 searches for .onion sites using the Ahmia.fi search engine and returns titles, URLs, and descriptions. It specifies the verb 'Search' and the resource '.onion sites', effectively distinguishing it from sibling tools like tor_fetch_onion which likely retrieves a specific page.
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 to use this tool (searching for .onion sites via Ahmia), but does not explicitly mention when not to use it or suggest alternatives. It is implied that this is the appropriate tool for searching hidden services, but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the local Tor SOCKS5 proxy daemon is running and accessible. Returns connectivity status for .onion fetching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It honestly states the tool checks local daemon accessibility and returns connectivity status. It does not specify the return format (e.g., boolean or object), but given the simplicity, this is acceptable. No behavioral contradictions.
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, 16 words, no unnecessary information. The verb 'Check' is front-loaded, and every word earns its place. Extremely concise and well-structured.
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 probe tool with no parameters and no output schema, the description provides sufficient context: it checks local Tor daemon and returns connectivity status. It could mention expected prerequisites (e.g., Tor installed) but is otherwise complete.
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 no parameters, and schema coverage is 100%. The description does not need to add parameter semantics; a baseline of 4 is appropriate for zero-parameter tools.
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 verb 'Check' and identifies the resource as 'local Tor SOCKS5 proxy daemon'. It specifies the purpose ('Returns connectivity status for .onion fetching'), which distinguishes it from sibling tools like tor_fetch_onion or tor_exit_nodes that deal with actual onion fetching or exit node details.
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 context: check before fetching .onion sites. While it does not explicitly state when not to use or name alternatives, the context of sibling tools makes the intended use clear. A more explicit statement about prerequisites or alternatives would elevate the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a URL or host in URLhaus (abuse.ch). Provide either a full URL for URL lookup or a hostname/IP for host lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full URL to look up (e.g., http://evil.com/malware.exe) | |
| host | No | Hostname or IP to look up (e.g., evil.com or 1.2.3.4) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as rate limits, data freshness, authentication requirements, or what the response contains. The simple 'look up' does not disclose important operational traits.
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 extremely concise with two sentences, no redundancy, and immediately conveys the core functionality.
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 is insufficient for a complete understanding. It does not explain what the result of a lookup looks like or any additional context needed for effective use.
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% with clear parameter descriptions. The description adds value by explaining that either a full URL or hostname/IP can be provided, clarifying the complementary nature of the two parameters.
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 verb 'Look up' and the resource 'URL or host in URLhaus (abuse.ch)', distinguishing between two lookup modes. This effectively communicates the tool's purpose and differentiates it from sibling threat intelligence 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?
The description does not provide guidance on when to use this tool versus alternative siblings or when to prefer URL lookup over host lookup. No context is given for selecting this tool among many similar threat intelligence lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search URLhaus (abuse.ch) entries by tag (e.g., "Emotet", "Dridex", "elf").
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag to search for in URLhaus |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of disclosing behavior. It only states that it searches entries by tag, but omits details about what the entries are (URLs, hashes, etc.), response format, pagination, rate limits, or any behavioral traits. This is insufficient for a tool with zero annotation coverage.
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, well-structured sentence that efficiently conveys the tool's purpose with no filler or redundant information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is largely complete. It explains the search target and provides example inputs. However, it could be improved by briefly noting what kind of data is returned.
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 has 100% description coverage for the single parameter, but the description adds value by providing concrete examples ('Emotet', 'Dridex', 'elf') for the tag parameter, giving agents clearer context on what to input beyond the schema's generic description.
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 searches URLhaus entries by tag, using the verb 'Search' and the resource 'URLhaus entries by tag', and provides specific examples (Emotet, Dridex, elf) to illustrate the tag parameter. This distinguishes it from sibling tools that search other databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like bazaarTag or threatfoxTag. It only implies that it is for URLhaus searches, but lacks explicit context, exclusions, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search specifically for exploits on Vulners (ExploitDB entries). Filters results to exploit type only.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Exploit search query | |
| limit | No | Max results (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only discloses filtering to exploit type, but omits additional behavioral traits such as authorization needs, rate limits, or response details.
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, clear sentence with no wasted words, effectively communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description adequately covers purpose and filtering. It could be slightly improved by mentioning the return format or example result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the parameters. The description adds no extra meaning beyond what the schema provides, meeting the baseline of 3.
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 searches for exploits on Vulners (ExploitDB entries), with a specific verb 'Search' and resource 'exploits', and distinguishes from sibling tools like vulners_search (general) and vulners_id (ID lookup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for exploit-only results, providing clear context. However, it does not explicitly state when not to use or name alternative tools for other searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a specific vulnerability or exploit by ID on Vulners. Free, no API key required. Supports CVE, EDB, GHSA IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Vulnerability ID (e.g. CVE-2024-1234, EDB-ID:12345) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses free usage and no API key needed, but doesn't describe error handling (e.g., if ID not found) or rate limits. For a simple lookup, this is adequate but could be more complete.
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. First sentence defines purpose, second adds important context. Ideal length for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema), the description covers key aspects: lookup action, ID types, and free usage. Lacks output description, but for a straightforward tool, it's nearly complete.
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 has 100% coverage for the single parameter 'id' with a description. The description adds concrete examples (CVE-2024-1234, EDB-ID:12345), enhancing understanding 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?
Cleary states the tool's purpose: lookup a vulnerability/exploit by ID on Vulners. Specifies supported ID types (CVE, EDB, GHSA), differentiating it from sibling tools like vulners_search or vulners_exploit.
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?
Implicitly advises use when you have a specific ID. Mentions it's free and requires no API key, which helps in choosing it over potentially paid alternatives. No explicit exclusions, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Vulners vulnerability database using Lucene queries. Returns CVEs, advisories, and exploits.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Lucene search query | |
| limit | No | Max results (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It states the tool returns results but does not disclose side effects, authentication needs, rate limits, or that it is read-only. This is a significant gap.
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?
Extremely concise: a single sentence with two clauses. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and the description only vaguely mentions return types. Lacks details on output format, pagination, or sorting, which are important for a search tool. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both params have descriptions). The description mentions Lucene queries, matching the schema, but does not add substantial meaning beyond the schema. Baseline 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 clearly states it searches the Vulners vulnerability database using Lucene queries and returns CVEs, advisories, and exploits. It distinguishes itself from sibling tools like vulners_exploit and vulners_id by being the general search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like vulners_exploit or vulners_id. The context of searching the database is implied but not compared to other tools.
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. Dates show when Glama detected each change.
v0.1.0abuseipdb_blacklistabuseipdb_checkabuseipdb_check_blockabuseipdb_reportsbazaarHashbazaarRecentbazaarTagbreachDataClassesbreachGetbreachLatestbreachListbreachPasswordbreachPastesbreachSearchbtc_abuse_checkbtc_addressbtc_balancebtc_txdarknet_list_sourcesgreynoise_checkgreynoise_ipintelx_phonebookintelx_phonebook_resultsintelx_searchintelx_search_resultsmalware_feedmalware_overviewmalware_searchonion_lookupotx_cveotx_domainotx_hashotx_ipotx_search_pulsesphishing_checkpulsedive_explorepulsedive_indicatorpulsedive_searchransomlookGroupsransomlookRecentransomwareByCountryransomwareBySectorransomwareGroupransomwareGroupsransomwareGroupVictimsransomwareRecentransomwareSearchstealer_domainstealer_emailstealer_ipthreatfoxGetIocsthreatfoxMalwarethreatfoxSearchthreatfoxTagtor_exit_checktor_exit_detailstor_exit_nodestor_fetch_oniontor_scrape_oniontor_search_oniontor_statusurlhausLookupurlhausTagvulners_exploitvulners_idvulners_searchEach tool is clearly prefixed by its service name (e.g., abuseipdb_, bazaar_, etc.), and within each group, operations like check, search, list, etc., are distinct. Descriptions further clarify purpose, leaving no ambiguity.
All tools follow a consistent snake_case pattern with service prefix and operation, e.g., abuseipdb_check, intelx_search, ransomwareRecent. No mixing of conventions.
66 tools is high but justified by the server's role as a comprehensive threat intelligence aggregator covering many distinct APIs. Each service has a small, focused number of tools, making the overall set manageable for its scope.
The tool set covers a very broad range of threat intelligence sources with typical operations per service (lookup, search, list). Minor gaps exist (e.g., no submission tools), but the core intel gathering workflows are well covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hyperion — MCP tool marketplace for AI agents: web, OSINT, security, research via one key.
AI-powered threat intelligence, smart contract auditing, and cybersecurity OSINT.
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/badchars/darknet-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
