Public assessment

payclaw/mcp-server (@kyalabs/mcp-server)

kyalabs-mcp-server · v2.6.1 · scanned Aug 2, 2026

What changed in the harness

Selection accuracy 100→100, token cost up 2%, unconfirmed writes 0%→0%.

Category breakdown

Where the score comes from.

Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.

01Safety

0.0 / 30

0.0 out of 30

02Legibility

27.2 / 30

27.2 out of 30

03Economics

19.3 / 20

19.3 out of 20

04Discoverability

11.9 / 20

11.9 out of 20

Highest-impact fix

Estimated gain +30 points

Add explicit identity and permission preflight tools

Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.

Description evidence

Defects and rewrites.

6 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.

Tool	Defect types	Suggested rewrite
`kya_getAgentIdentity`	no_return_description	Declares your agent identity to a merchant before any shopping action (browsing, searching, buying), presenting proof of authorization so bot defenses let you through. Call before kya_getCard or kya_web_fetch. Takes the merchant name and optionally its URL (to check UCP identity support and generate a checkout patch). Returns a verification_token and trip_id for use in follow-up calls, an agent_disclosure text to present if challenged, and — when merchantUrl is provided — a checkoutPatch to merge into the checkout payload. Issues no card and moves no money.
`kya_reportBadgePresented`	no_return_description	Records that you presented your Badge (verification_token) to a merchant, linking the event to the trip_id from kya_getAgentIdentity; call immediately after merging the checkoutPatch into a checkout payload. Accepts the merchant name or URL, the checkout context (arrival, addtocart, checkout, other), and an optional checkoutSessionId. Returns confirmation that the trip event was recorded; when Extended Auth is enabled, kyaLabs automatically checks back in 7 seconds to determine the outcome, otherwise call kya_reportBadgeOutcome once you know the result.
`kya_reportBadgeOutcome`	no_return_description	[DEPRECATED — outcomes are now tracked automatically via the verify endpoint; this tool will be removed in a future version.] Reports how the merchant responded (not_denied, denied, or unparseable) after presenting your Badge (verification_token) at a merchant, linked via trip_id. Returns confirmation that the outcome was recorded.
`kya_reportBadgeNotPresented`	no_return_description	[DEPRECATED — this event is no longer needed; this tool will be removed in a future version.] Reports that you did not present your Badge (verification_token) at a merchant, along with the reason (abandoned, merchant_didnt_ask, other), linked via trip_id. Returns confirmation that the event was recorded.
`kya_getCard`	no_return_description	Requests a single-use virtual Visa card for a purchase, after identifying yourself with kya_getAgentIdentity. Declare the merchant, estimated_amount (max $500), and a description of what's being purchased; the user approves via MFA before the card is issued. Returns an intent_id and the single-use card details locked to this purchase amount and merchant; the card self-destructs after use. Call kya_reportPurchase after the transaction completes.
`kya_reportPurchase`	no_return_description	Closes the audit trail for a purchase made with a kyaLabs virtual card by reporting its outcome; must be called after every purchase attempt. Takes the intent_id from kya_getCard, whether the purchase succeeded, and optional actual_amount, merchant_name, items, and order_confirmation details from the receipt. Returns confirmation that the purchase outcome was recorded.

Selection evidence

Confusable tool pairs.

6 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A	Tool B	Confidence	Why they collide
`kya_reportBadgePresented`	`kya_reportBadgeNotPresented`	medium	Both fire after a merchant interaction to record whether the Badge was shown; an agent unsure of the exact presentation state (e.g., ambiguous merchant challenge) could pick the wrong polarity, though the enum/required fields differ.
`kya_reportBadgePresented`	`kya_reportBadgeOutcome`	medium	reportBadgeOutcome (deprecated) and reportBadgePresented both concern the result of showing the Badge; an agent following older instructions or unsure which lifecycle event to log after a checkout could call either.
`kya_reportBadgeOutcome`	`kya_reportBadgeNotPresented`	medium	Both deprecated tools report a negative/ambiguous badge event (denied/unparseable vs. not presented); an agent trying to log 'the merchant didn't accept/see the badge' could plausibly choose either.
`kya_web_fetch`	`kya_getHeaders`	medium	Both attach the agent's identity to outbound requests to a merchant; a task like 'authenticate my request to this site' could be served by web_fetch (direct fetch) or getHeaders (headers for an external HTTP client), and the agent may not know which execution path it's supposed to use.
`kya_getAgentIdentity`	`kya_getHeaders`	low	Both are 'get identity'-flavored calls, but getAgentIdentity is clearly the mandatory first step and getHeaders explicitly depends on it, making misselection less likely.
`kya_getCard`	`kya_getHeaders`	low	Share 'get' verb but serve unrelated purposes (payment card vs. HTTP headers), so a natural-language purchase or browsing task is unlikely to conflate them.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard