Loading ToolBench

Reading the current corpus…

frisk MCP server · C · ToolBench

← Browse

frisk

github.com/Jiangw2718i/frisk

MCP server for Frisk: screen an x402 payment counterparty before an agent pays.

2025-06-18+STDIO1 tools

60/100

Definition Quality80

Protocol Readiness45

Supportability38

Spec posture

Inferred effective spec 2025-06-18+·current baseline 2026-07-28

Static source inference · medium confidence · evidence: structured output

No deprecated protocol patterns detected

Summary

Single tool 'screen_payment' has a well-structured schema with 8 parameters, all typed and described. Tool description is clear and contextual (changes based on mode: hosted vs offline). Input schema uses Zod with proper type constraints (min/max for strictness, array for allowedAssets). However, output schema is not documented in the source, only a ScreenResult type is imported from frisk-screen library without visible field definitions. Error handling is minimal; no recovery guidance or actionable error messages visible. Tool naming is verb-noun compliant ('screen_payment'). Parameter descriptions are adequate (72 chars average) but lack format/constraint details in some cases (e.g., 'counterparty' should specify EVM address format more explicitly).

Tools (1)

screen_paymentread onlysource verified80/100

Screen a counterparty an agent is about to pay. Runs the local deterministic checks and the hosted reputation graph, and returns allow / review / block with reasons. Advisory: the caller decides.

Issues (5)

HIGHtool ↗

Output schema not documented. ScreenResult type is imported but fields (verdict, trustScore, confidence, source, reasons, policyHits) are not visible in the MCP server definition. LLMs cannot plan downstream actions without knowing what fields to expect.

screen_payment

HIGHrecovery-guide ↗

No error handling guidance. Tool can fail (invalid address, API timeout, policy violation) but no recovery hints provided. LLM receives raw errors with no actionable next steps.

screen_payment

MEDIUMconstrained-input ↗

Parameter 'counterparty' description says 'e.g. an 0x EVM address' but does not specify format constraints (length, checksum validation, chain context). LLMs may pass invalid addresses.

screen_payment

MEDIUMidempotent-operation ↗

No idempotency guarantee documented. Tool modifies state (screens against reputation graph, may log to hosted service) but does not declare idempotent behavior. Agents retrying on ambiguous failures risk duplicate screening records.

Recommendations

Document the ScreenResult output schema explicitly in the tool definition or in a comment. Include field names, types, and what each verdict value (allow/review/block) means for the agent's next action.
Add error handling with recovery guidance: 'Invalid counterparty address. Ensure it is a valid 0x EVM address (42 chars, 0x prefix). If using a name, call resolve_address() first.' Include timeout and API failure scenarios.
Specify format constraints for 'counterparty' parameter: '0x-prefixed Ethereum address, 42 characters, checksummed (optional but recommended).'
Declare idempotency: 'This tool is idempotent, calling it multiple times with the same inputs returns the same verdict and does not create duplicate records.'
Enhance tool description with decision guidance: 'Returns allow (safe to pay), review (manual approval recommended), or block (high risk). The agent should respect block verdicts and ask the user before overriding review verdicts.'

Score history

Overall score trend

First recorded score · v2 rubric

60/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	60	2025-06-18+	v2