Entity verification, sanctions screening, and trust scoring for AI agents via x402 micropayments.
Scored across 5 tools
check_entity and get_risk_score overlap heavily by accepting the same entity/name/country input, differing mainly in depth and speed. get_trust_score also overlaps with entity trust concepts, though it uses an entity ID. check_agent and verify_wallet are clearly distinct, but the entity-focused tools introduce real selection ambiguity.
The tool names mix check_, get_, and verify_ as interchangeable verbs, with no clear pattern. check_entity and get_trust_score both concern entity trust but use different prefixes, making the naming convention inconsistent.
Five tools is within the well-scoped 3-15 range and covers entity, agent, and wallet trust domains without bloat. However, three of the five are placeholder/unimplemented, so the count feels slightly inflated by nonfunctional tools.
Only check_entity and get_risk_score are real; agent trust, wallet trust, and entity-ID trust are all unimplemented placeholders. This leaves major advertised capabilities as dead ends, so agents cannot complete multi-domain trust workflows.
Unimplemented / beta: returns placeholder data, not a real result. Free ($0) until real logic ships.
Verify AI agent trust via LimitGuard. Today every call returns verified=false,
trust_score=0 and status="unimplemented" regardless of input (#206).
Intended for multi-agent systems to verify delegation targets.
Args:
agent_id: Unique agent identifier
agent_name: Human-readable agent name
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| agent_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so exceptionally well. It explicitly states that every call returns verified=false, trust_score=0, and status="unimplemented" regardless of input, and that it is free until real logic ships.
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 critical 'unimplemented / beta' caveat is front-loaded, and the args list is cleanly structured. Some redundancy exists between the first sentence and the later explanation that every call returns unimplemented values, but the overall structure is still effective.
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 placeholder tool, the description is complete: it states the intended purpose, current behavior, exact return values, cost status, and parameter semantics. An agent can confidently call or avoid this tool knowing exactly what will happen.
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%, but the description compensates by defining both parameters: agent_id as 'unique agent identifier' and agent_name as 'human-readable agent name'. This adds meaningful semantic value beyond the bare schema properties, though it stops short of providing examples or format details.
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 verifies AI agent trust via LimitGuard and is intended for multi-agent systems to verify delegation targets. It also immediately signals that the tool is unimplemented and returns placeholder data, leaving no ambiguity about what it does.
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 an intended use case ('multi-agent systems to verify delegation targets') and clearly warns that the tool currently returns placeholder data. However, it does not name sibling alternatives or state explicit when-not-to-use conditions beyond the unimplemented status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check entity trust score via LimitGuard API.
Full trust intelligence check on a business entity.
Returns trust score (0-100), risk level, and recommendation.
Args:
entity_name: Full legal name of the entity
country: ISO 3166-1 alpha-2 country code (e.g., NL, BE, DE)
kvk_number: Optional Dutch KVK registration number (8 digits)
domain: Optional company website domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | ||
| country | Yes | ||
| kvk_number | No | ||
| entity_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 does disclose the main behavioral outcome: returns a trust score (0-100), risk level, and recommendation. However, it does not mention authorization needs, rate limits, whether any external side effects occur, or failure behavior. It is more transparent than a bare mutation tool, but still incomplete for a no-annotation case.
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 well-structured and efficient, with a one-line purpose, a brief output summary, and a clear Args section. It is slightly redundant between the opening line and 'Full trust intelligence check,' but overall every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and a solid parameter description, the tool is fairly complete for invoking it. However, with four sibling tools in the same domain and no usage guidance or differentiation, the description is not fully complete for an agent deciding which tool to select. The gap is mostly in routing and alternatives rather than parameter 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 0%, so the description must fully explain the parameters, and it does. Each argument is described concisely: entity_name is the full legal name, country uses ISO 3166-1 alpha-2, kvk_number is an optional 8-digit Dutch registration, and domain is optional. This adds meaningful semantic detail the schema lacks.
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 states a specific verb and resource: 'Check entity trust score via LimitGuard API' and expands with 'Full trust intelligence check on a business entity.' It clearly identifies what the tool does and what it returns, but it does not explicitly differentiate itself from sibling tools such as get_trust_score or get_risk_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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of check_agent, get_trust_score, get_risk_score, or how the full check relates to them. The usage context is only implied by 'Full trust intelligence check,' but no when-to-use or when-not-to-use instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick risk assessment without full trust check.
Faster endpoint that focuses on risk signals only.
Use when you only need basic risk evaluation.
Args:
entity_name: Full legal name of the entity
country: ISO 3166-1 alpha-2 country code
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ||
| entity_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool is faster and limited to risk signals, but it does not state whether the operation is read-only, what the response contains, whether there are rate limits, or any error conditions. This lack of operational detail is a notable gap for a tool with zero 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 compact and front-loaded with the core purpose. The only waste is minor redundancy between 'Quick risk assessment without full trust check' and 'Faster endpoint that focuses on risk signals only,' which restate the same idea. The Args section is clean and useful.
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 essential invocation details are present: when to use, both parameter meanings, and the lightweight scope. An output schema exists, so not explaining return values is acceptable. However, the description remains thin on behavioral context and does not explicitly route the agent to get_trust_score for full trust checks, so it is 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?
Schema description coverage is 0%, but the description compensates by defining both parameters: entity_name as 'Full legal name of the entity' and country as 'ISO 3166-1 alpha-2 country code.' This adds critical meaning beyond the bare schema titles and gives the agent what it needs to supply valid inputs.
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 states a specific action ('risk assessment') and resource ('risk score'), and differentiates itself from a full trust check: 'Quick risk assessment without full trust check.' It also positions itself as a faster endpoint focused only on risk signals, which clearly distinguishes it from the sibling get_trust_score and aligns with the tool name.
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 says 'Use when you only need basic risk evaluation,' providing a clear use condition. However, it does not explicitly say when not to use it or name an alternative tool for full trust checks, relying on the implied contrast with 'full trust check.' This is solid guidance but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unimplemented / beta: returns placeholder data, not a real result. Free ($0) until real logic ships.
Quick trust score lookup by entity ID. Today every call returns trust_score=0
and trust_level="unknown" regardless of input (#206).
Args:
entity_id: Entity identifier (KVK number, domain, or hash)
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's placeholder behavior: 'every call returns trust_score=0 and trust_level="unknown" regardless of input (#206).' It also notes the tool is free until real logic ships. This is exemplary transparency for an unimplemented tool, going far beyond what the schema or annotations would convey.
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 appropriately compact and front-loads the critical beta/unimplemented warning. The format is slightly informal with the Args section embedded, but every sentence earns its place and there is 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?
For a stub tool, the description covers the essential facts: what it does, that it is unimplemented, what it returns, and how to format the parameter. It does not point to a real alternative (e.g., get_risk_score), which would be helpful given the tool's placeholder status, but the caveat alone is enough to prevent misuse.
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 merely describes entity_id as a string, but the description explicitly defines it as 'Entity identifier (KVK number, domain, or hash)' and clarifies that the input is ignored. With 0% schema description coverage, the description fully compensates for the parameter's meaning and accepted formats.
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 states a clear verb and resource: 'Quick trust score lookup by entity ID.' This is specific and distinguishes the tool from siblings like get_risk_score, though it does not explicitly name a sibling for differentiation. The 'Unimplemented / beta' caveat adds important context without obscuring the core 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?
The description immediately warns it is 'Unimplemented / beta' and 'returns placeholder data, not a real result,' which serves as a clear when-not-to-use instruction. It does not explicitly name alternatives, but the caveat effectively tells an agent not to rely on this tool for real decisions. This is clear context beyond a bare statement of function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unimplemented / beta: returns placeholder data, not a real result. Free ($0) until real logic ships.
Check wallet trust score for crypto payments. Today every call returns
risk_score=0 and scam_probability=0.0 regardless of input (#206).
Accepts EVM (0x...) and Solana (base58) addresses.
Args:
wallet_address: Blockchain wallet address
chain_id: CAIP-2 chain ID (default: eip155:8453 for Base)
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | No | eip155:8453 | |
| wallet_address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Excellent transparency: it discloses that every call returns risk_score=0 and scam_probability=0.0 regardless of input, references issue #206, and explicitly labels the output as placeholder data. Since there are no annotations, the description carries the full burden and does so thoroughly.
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 well-structured: warning first, then purpose, current behavior, and parameter explanations. There is minor redundancy between 'returns placeholder data, not a real result' and 'Today every call returns...' but each sentence contributes necessary 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?
For a simple 2-parameter stub tool, the description covers purpose, placeholder behavior, parameter semantics, and supported address formats. It does not describe the full output shape, but since it explicitly lists the two fields it returns, the agent has enough to invoke and interpret the result.
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 adds meaningful context: wallet_address is 'Blockchain wallet address' and chain_id is 'CAIP-2 chain ID (default: eip155:8453 for Base).' It also mentions supported formats (EVM 0x..., Solana base58), which goes beyond the schema's bare titles.
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 states a specific verb and resource: 'Check wallet trust score for crypto payments.' It clearly identifies the tool's function, and the behavior 'returns placeholder data' is upfront. However, it does not explicitly differentiate itself from sibling tools like get_trust_score, which likely serves a similar purpose in a non-stub form.
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 clearly implies the tool should not be used for real results ('Unimplemented / beta... not a real result') and notes it is 'Free ($0) until real logic ships.' This gives context but does not explicitly state when to use it versus alternatives, nor name a preferred sibling tool for production use.
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.
check_agentcheck_entityget_risk_scoreget_trust_scoreverify_walletCounterparty risk scoring for agentic commerce via x402 micropayments.
Verify x402 payment endpoints before an AI agent pays: scam scan, on-chain checks, trust scores.
High-frequency OFAC wallet screening and recurring signed x402 checks for autonomous agents.
AI agent execution safety via x402 micropayments: risk scoring, integrity, memory checks
Add one secure layer between your agents and this server.