MCP Server for AgentRadar — the on-chain trust oracle for the agent economy. Provides 18 tools for verifying, scoring, and attesting AI agent trustworthiness directly from Claude, Cursor, or any MCP-compatible client.
Live API: https://api.vvpro.ai
Web: https://vvpro.ai
MCP Registry: io.github.Bichev/agentradar
This package is a thin client wrapper around the public AgentRadar API. The full source is auditable here — anything npx @agentradar/mcp runs is in this repo, MIT-licensed.
Tool | Description |
| Full 6-signal trust verification |
| Side-by-side comparison of two agents |
| Verify up to 10 agents at once |
| Quick cached trust score lookup |
| Generate embeddable trust badge URL |
| Score + write on-chain EAS attestation |
| List all attestations |
| Look up attestation by tx hash |
| On-chain identity (ERC-8004) |
| Reputation signals |
| Resolve agent URI/metadata |
| Check scam database |
| Report malicious wallet |
| Human-readable score explanation |
| API health check |
| Dashboard statistics |
| List scoring signals + weights |
| API pricing info |
Related MCP server: revettr
Add to your project's .cursor/mcp.json:
{
"mcpServers": {
"agentradar": {
"command": "npx",
"args": ["-y", "@agentradar/mcp"],
"env": {
"AGENTRADAR_OPERATOR_KEY": "your-key-here"
}
}
}
}Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"agentradar": {
"command": "npx",
"args": ["-y", "@agentradar/mcp"],
"env": {
"AGENTRADAR_OPERATOR_KEY": "your-key-here"
}
}
}
}npx @agentradar/mcpgit clone https://github.com/Bichev/agentradar-mcp.git
cd agentradar-mcp
npm install
npm run build
node dist/index.jsVariable | Required | Default | Description |
| No |
| API base URL |
| No | — | Operator key for admin endpoints and bypassing x402 payment |
Once connected, you can ask your AI assistant:
"Verify this agent: 0x742d35Cc6634C0532925a3b844Bc9e7595f2bD28"
"Is 0xdead...beef a known scam wallet?"
"Compare these two agents and tell me which is more trustworthy"
"Explain why this agent scored 45/100"
"Write an on-chain attestation for this verified agent"
verify_agent: $0.005 per call (x402) or free with operator key
attest_agent: $5.00 per attestation (x402) or free with operator key
get_score: Free
Admin endpoints: Operator key required
MIT
Report a malicious wallet address to the AgentRadar scam database. Requires operator key. Include chain, severity level, source of intel, and optional notes.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chain | Yes | ||
| severity | Yes | ||
| source | Yes | ||
| notes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions the operator key requirement, but omits details on side effects, success/failure behavior, or rate limits. This is insufficient.
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. The first sentence states the main purpose, and the second lists key requirements. Highly 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?
Given 5 parameters (4 required), no output schema, and no annotations, the description is incomplete. It doesn't describe the output, error conditions, or any validation behavior, leaving the agent without enough context to fully understand the tool's behavior.
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 0%, so the description must compensate. It says 'Include chain, severity level, source of intel, and optional notes', which adds some meaning to the parameters beyond their names. However, it does not explain all parameters fully (e.g., format of severity) or provide values.
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 ('Report') and the resource ('AgentRadar scam database'), with a specific verb and resource. It is distinct from siblings like 'check_scam' which would be for querying.
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 'Requires operator key', which indicates a prerequisite. However, it does not specify when to use this tool over alternatives like 'check_scam' or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score an AI agent and write an on-chain EAS attestation recording the trust score permanently. Costs $5 via x402 or requires an operator key. Use when you need a verifiable, immutable trust record for an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry behavioral info. It mentions permanence and cost, but does not disclose failure modes, reversibility, return value, or what happens to duplicate attestations. Could be more detailed.
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 fluff. Front-loads purpose and adds cost/usage context. Could benefit from a slightly more structured format, but overall concise.
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 one parameter and no output schema, the description covers key aspects: purpose, cost, and when to use. Missing details on failure behavior, return information, and edge cases, making it adequate but not thorough.
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 0% and the description does not explicitly explain the 'address' parameter beyond implying the agent's address. An agent would benefit from knowing that the address must be an Ethereum address (implied by regex) and what it represents.
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: 'Score an AI agent and write an on-chain EAS attestation recording the trust score permanently.' It distinguishes well from sibling tools like get_score (read) and verify_agent (check), as it creates a permanent record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit cost and authorization requirements ('Costs $5 via x402 or requires an operator key') and a clear use case ('Use when you need a verifiable, immutable trust record for an agent'). Lacks explicit when-not-to-use or alternatives, but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify multiple AI agent addresses in a single call (max 10). Returns trust scores for each address. Efficient for evaluating a list of candidate agents.
| Name | Required | Description | Default |
|---|---|---|---|
| addresses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions max 10 and returns trust scores, but lacks details on input validation (schema covers pattern), error handling, rate limits, or concurrency concerns.
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 extraneous information, directly addresses functionality and benefit. Efficient and clear.
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, description covers purpose, usage context, and return type ('trust scores'). Lacks output structure and error behavior, but sufficient for common 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 has 0% description coverage, so description must add meaning. It calls the parameter 'AI agent addresses,' clarifying context over generic Ethereum addresses. However, the schema already defines the pattern, so added value is limited.
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 verifies multiple AI agent addresses in a single call, max 10, and returns trust scores. Distinguishes from sibling verify_agent (single) and check_scam (different purpose).
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?
Says 'Efficient for evaluating a list of candidate agents,' providing context. Does not explicitly mention when not to use or list alternatives, but the batch nature implies use for multiple addresses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a wallet address is in the AgentRadar scam database. Returns matching scam records with severity, chain, source, and notes. Use this as a quick safety check before any transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks disclosure of key behavioral traits like read-only nature, side effects, or limitations.
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 and usage, 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?
Adequately explains returns with fields listed, but lacks details on empty results or error handling.
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?
Description adds minimal context for the 'address' parameter beyond schema pattern; does not clarify format or source.
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 a wallet address against a scam database, distinguishes from siblings like add_scam_wallet and verify_agent.
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 advises use as a quick safety check before transactions, providing clear context but no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two AI agents side-by-side on trust scores and security signals. Useful for choosing between competing agents that offer similar capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| address1 | Yes | ||
| address2 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only mentions the comparison aspects but does not state whether the operation is read-only, what happens with invalid addresses, or any side effects. Insufficient for a comparison 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?
The description is two sentences, no redundant information, and effectively communicates the purpose. Every phrase 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?
With two required parameters, no output schema, and no annotations, the description is minimal. It does not explain the output format or how the comparison is presented, which is needed for full context.
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 0%, so the description must add meaning. It does not mention the two parameters (address1 and address2) at all. The schema provides patterns, but the description adds no value beyond that.
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 compares two AI agents on trust scores and security signals, with a specific verb and resource. It also notes the use case of choosing between competing agents, distinguishing it from sibling 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 provides a clear use case ('useful for choosing between competing agents'), but lacks explicit when-not-to-use guidance or alternatives. This is still helpful for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a human-readable explanation of an agent's trust score. Returns a narrative breakdown of each signal's contribution, risk factors, and actionable recommendations. Best for presenting trust analysis to end users.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
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 the output (narrative breakdown) but does not mention side effects, authorization needs, or error handling. The tool appears safe and read-only based on description.
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 main purpose, and no unnecessary details. 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?
For a simple tool with one parameter and no output schema, the description covers purpose and output content adequately. It could explicitly mention the input parameter, but overall it is sufficient.
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 (address) with 0% description coverage. The description does not mention the parameter or its purpose, relying solely on the schema for meaning. The agent must infer the address is the agent's address from context.
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 a human-readable explanation') and the resource ('an agent's trust score'), and specifies it returns a narrative breakdown. This distinguishes it from sibling tools like get_score or check_scam.
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 includes 'Best for presenting trust analysis to end users', which provides clear usage context. However, it does not explicitly exclude alternative uses or compare with siblings.
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 attestation by its transaction hash. Returns the full attestation record including the scored address, trust score, and on-chain details.
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It indicates a read-only operation (returns a record) but does not mention authentication, rate limits, or error conditions. This is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, 22 words, no redundancy. Every word adds value; the description is efficiently structured and front-loaded with the core action.
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 lookup tool with one parameter and no output schema, the description covers the return content (full attestation record, scored address, trust score, on-chain details). It is nearly complete, though it omits potential constraints like data freshness or pagination (likely not needed).
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 0% parameter descriptions, so the tool description must compensate. It adds meaning by stating the parameter is a 'transaction hash', which is essential context beyond the regex pattern. This provides sufficient clarity for the single 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 action (look up) and the resource (attestation by transaction hash). It distinguishes the tool from siblings like get_attestations (which likely returns multiple) by specifying a single lookup via hash.
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: when you have a transaction hash, use this tool. It does not explicitly exclude alternatives, but the intent is evident from the sibling list where get_attestations handles broader queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all on-chain trust attestations written by AgentRadar. Returns paginated attestation records including addresses, scores, and transaction hashes. Requires operator key.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses it returns paginated records with specific fields and requires an operator key. It does not mention side effects (likely none) or rate limits, but adequately describes the general 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, concise and front-loaded with the primary action. No redundant 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?
No output schema exists. The description lists some return fields but not the full structure or pagination metadata (e.g., total count). Adequate for a simple list tool, but lacks details on ordering or defaults.
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 0% description coverage. The description mentions pagination, implying 'page' and 'limit' are for that purpose, but does not explicitly define each parameter's meaning or constraints. Partial compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists on-chain trust attestations by AgentRadar, specifying the verb 'List' and the resource 'attestations'. It distinguishes from siblings like 'get_attestation_by_tx' by focusing on paginated listing.
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 'Requires operator key' as a prerequisite, but does not provide explicit guidance on when to use this tool over alternatives like 'get_attestation_by_tx' or 'get_stats'. Usage context is implied but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a trust badge URL for an AI agent. Returns an embeddable SVG badge showing the agent's trust score. Useful for displaying trust status in UIs or documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| style | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It indicates a read-like operation (generating a URL) but does not disclose potential side effects, error handling, or whether it makes external calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose and usage. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the core purpose and usage context but lacks parameter details. It is minimally adequate but not fully 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 description does not explain the parameters 'address' and 'style'. With 0% schema description coverage, the description should compensate but fails to add meaning beyond the schema structure.
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 generates a trust badge URL and returns an SVG badge. The verb 'generate' and resource 'trust badge URL' are specific, and the tool is distinct from siblings like 'get_score'.
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 usage context ('useful for displaying trust status in UIs or documentation') but does not explicitly state when not to use it or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check AgentRadar API health and connectivity status. Returns service status, uptime, and version info. Use to verify the API is reachable before making other calls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses the behavior: returns status, uptime, and version info. Safe, read-only operation with no 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 concise sentences, front-loaded with purpose and usage guidance. 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 health check tool, the description provides all necessary context: purpose, return information, and usage guidance. No 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?
No parameters exist, and schema coverage is 100%. The description correctly omits parameter details as none are 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?
The description clearly states the tool checks API health and connectivity, returns service status, uptime, and version info. It distinguishes itself from sibling tools that deal with agents and scams.
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 to verify the API is reachable before making other calls,' providing clear guidance on when 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.
Get AgentRadar API pricing information. Shows costs for each endpoint including x402 micropayment amounts and free tier details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It indicates that the tool returns pricing data, but it does not mention any potential side effects, rate limits, authentication requirements, or data freshness. The description is straightforward 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 extremely concise with two short sentences that front-load the purpose. There is no redundant or unnecessary phrasing.
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 (no parameters, no output schema), the description is adequate but could be improved by mentioning the format of the returned data (e.g., JSON object with endpoint keys) or any caching behavior. It misses an opportunity to fully inform the agent about the response 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?
There are no parameters in the input schema, so the description does not need to add parameter information. The baseline for zero parameters is 4, and no additional details are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves pricing information for the AgentRadar API, specifying that it shows costs per endpoint, x402 micropayment amounts, and free tier details. This directly distinguishes it from sibling tools like get_health or check_scam.
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 that one should use this tool to obtain pricing information, but it does not provide explicit guidance on when not to use it or mention alternatives. For example, it could note that if you need cost calculations per request, this is the tool to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a cached trust score for an AI agent address. Faster than full verification — returns the last computed score without re-running signals. Free endpoint, no payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes caching behavior, no re-running signals, and free access. Lacks details on error handling or staleness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. Front-loaded with main 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?
Adequate for a simple retrieval tool with one parameter. Covers purpose, speed, and cost. Could mention what happens if no cached score exists.
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 0% and description does not explain the 'address' parameter beyond context. The parameter is self-evident from name and schema pattern, but description adds no additional meaning.
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 gets a cached trust score for an AI agent address, distinguishing from full verification. Uses specific verb and resource.
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 notes faster than full verification and free endpoint, implying when to use. However, no direct mention of alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AgentRadar dashboard statistics — total verifications, attestations written, scam wallets tracked, and API usage metrics. Requires operator key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry transparency. It discloses the auth requirement (operator key) and implies read-only behavior via 'statistics'. However, it does not mention side effects, rate limits, or error handling. 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?
Single sentence that efficiently conveys purpose, key metrics, and auth requirement. No wasted words. Front-loaded with the core action.
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 parameters, the description covers the tool's purpose and return content (list of metrics) sufficiently. Minor gap: could state return format (e.g., JSON object), 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?
The input schema has zero parameters (100% coverage), so the description does not need to add parameter details. Baseline score of 4 is appropriate as no parameter ambiguity exists.
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 dashboard statistics and enumerates specific metrics (verifications, attestations, scam wallets, API usage). It distinguishes itself from sibling tools which perform specific actions like adding scam wallets or verifying agents.
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 mentions an authentication requirement ('Requires operator key') but provides no guidance on when to use this tool versus alternatives like get_health or get_score. No exclusions or context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all trust scoring signals used by AgentRadar with their weights and descriptions. Helps understand how the composite trust score is calculated.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies a read-only listing without side effects. Adequate for a simple list operation, but could mention that it's static or requires no special permissions.
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 clear sentences, no redundant words. Purpose and benefit 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; description lacks detail about the return format (e.g., array of objects, field names). Could be improved for an agent to know 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?
No parameters; schema coverage is 100%. Description adds meaning by specifying that signals come with weights and descriptions, which is 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?
Clearly states the tool lists trust scoring signals with weights and descriptions, differentiating from siblings like get_score or explain_score. The verb 'list' and resource 'trust scoring signals' are 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?
Implied usage from description ('helps understand composite trust score'), but no explicit when-to-use or alternatives among sibling tools like explain_score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an AI agent's on-chain identity (ERC-8004 registration, ENS name, contract metadata). Returns who the agent claims to be and whether those claims are verified.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation by stating 'look up' and indicates what is returned, but it does not explicitly confirm read-only behavior, error handling, prerequisites, or side effects. With no annotations, the description carries full burden and is moderately informative.
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 well-structured sentences, front-loaded with the action verb, no redundancy. 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?
Given the tool's simplicity (single param, no output schema), the description covers the main purpose and output, but lacks details on error cases, behavior when address not found, and explicit read-only indication.
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 'address' with a pattern but no description, and the tool description does not provide any additional context about the parameter. With 0% schema coverage, the description should compensate but does not explain the parameter beyond implying its use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'look up', the resource 'AI agent's on-chain identity', and lists specific sub-items (ERC-8004 registration, ENS name, contract metadata). It clearly distinguishes from siblings like lookup_reputation and resolve_agent_uri.
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 such as check_scam or verify_agent. The description lacks any context for selection among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an AI agent's on-chain reputation — ERC-8004 feedback history, attestation count, and community signals. Shows how established and trusted the agent is in the ecosystem.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It mentions the output contents (feedback history, etc.) but does not state that the operation is read-only, whether permissions are needed, or any data freshness or limitation. This leaves significant gaps for a tool with no annotation support.
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 with no unnecessary words. It front-loads the purpose and then lists what it shows. While concise, it could benefit from bullet points or a more structured format, but it is 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 output schema, the description lists three key components of the response, which helps set expectations. However, it lacks details on the output structure, pagination, or data freshness. For a simple one-parameter tool, it is moderately complete but not exhaustive.
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?
With 0% schema description coverage and only one required parameter, the description fails to explain that 'address' is the Ethereum address of the agent. The schema provides only a regex pattern, and the description adds no semantic meaning, leaving the parameter's meaning unclear.
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 an AI agent's on-chain reputation and lists specific components (ERC-8004 feedback history, attestation count, community signals). This distinguishes it from siblings like get_score or get_attestations, though it could explicitly name alternatives.
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 offers no guidance on when to use this tool versus alternatives like get_attestations or check_scam. It implies it aggregates multiple signals, but no exclusions or situational advice are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve an agent address to its registered URI, metadata, and service endpoints. Useful for discovering how to interact with a verified agent.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as side effects, network calls, permissions, or error handling.
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; the first states action and output, the second adds usage context. 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?
The tool is simple, but the description lacks detail on return format, error conditions, or what happens when an address is not found. Adequate but incomplete.
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 0%, and the description adds no meaning beyond the schema's pattern for 'address'. It does not explain the parameter's format 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?
The description clearly states the tool resolves an agent address to URI, metadata, and service endpoints. It distinguishes from siblings like lookup_identity or verify_agent by focusing on interaction 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 provides context ('useful for discovering how to interact with a verified agent') but does not explicitly contrast with alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a full 6-signal trust verification on an AI agent or wallet address. Returns composite trust score (0-100), individual signal scores, risk flags, and recommendations. Use this before transacting with or delegating to an unknown agent.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes what the tool does but does not disclose behavioral traits such as whether the tool is read-only, rate limits, authentication needs, or any side effects. For a verification tool, non-destructive nature should be implied, but it is not 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 sentences that are concise, front-loaded with the primary action, and contain 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 the tool's simplicity (1 required param, no output schema, no annotations), the description covers the core functionality and return values (composite score, individual signals, risk flags, recommendations). It lacks details on response format but remains sufficiently complete for an agent to understand the tool's purpose and outcomes.
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 one parameter 'address' with a regex pattern. Schema description coverage is 0%, so description must compensate. However, it does not add any meaning beyond the schema (e.g., explaining what types of addresses are supported or any format restrictions).
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 (verify), resource (AI agent or wallet address), and outputs (composite score, individual scores, risk flags, recommendations). Briefly distinguishes from siblings by mentioning 'full 6-signal', but does not explicitly differentiate from sibling tools like batch_verify or check_scam.
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 when to use: 'before transacting with or delegating to an unknown agent.' However, it does not specify when not to use or mention alternatives like batch_verify for multiple addresses.
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.3add_scam_walletattest_agentbatch_verifycheck_scamcompare_agentsexplain_scoreget_attestation_by_txget_attestationsget_badge_urlget_healthget_pricingget_scoreget_statslist_signalslookup_identitylookup_reputationresolve_agent_uriverify_agentEach tool has a clearly distinct purpose. While get_score and verify_agent both return trust scores, the former is a fast cached version and the latter is a full 6-signal verification, making them differentiable. No two tools overlap significantly.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_scam_wallet, verify_agent, get_attestations). Verbs like 'get', 'lookup', 'list', 'check' are used consistently, making the naming predictable and intuitive.
With 18 tools, the server provides comprehensive coverage for AI agent trust verification and scam tracking without being excessive. Each tool addresses a specific need, and the count is well-scoped for the domain.
The tool surface covers the full lifecycle: adding/reporting scams, checking scams, verifying agents (cached and full), comparing, explaining scores, attestations (create, list, get by tx), identity and reputation lookups, URI resolution, badge generation, and API management (health, pricing, stats). No obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Reputation oracle for AI agents on Base: SAFE/CAUTION/BLOCK + 0-100 score before you pay. x402+MCP
On-chain security and market intelligence for trading agents on Base.
Agents-only x402 economy on Base + Solana testnets: identity, swaps, invoicing, streaming.
Agent credit issuance and scoring — programmable credit lines on Base L2
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Bichev/agentradar-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
