Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

io.github.cdonoyan/shuka

NPM · @SHUKASHAKE/AGENT

Universal trust attestation for AI agents: create, verify, and negotiate Shuka trust proofs.

Available components

+1 this week 83 Trust /100

Last scanned (5 hours ago)

Scores higher than 76% of npm servers

Category Security

Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security98
  • No malware found by supply-chain analysis.Pass
  • No known CVEs affecting this package version or its production dependencies.Pass
  • No install/post-install scripts declared.Pass
  • 30 of 92 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
Schema Quality & AI Usability80
  • 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 3017 tokens (~177/item across 17 items; 15 tools + 2 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
  • No destabilizing schema changes in the last 30 days.Pass
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
Tool Safety75
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "revoke_grant" implies "revoke" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
  • An AI judge read all 16 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 1 Nov 26 0
    • Stability: 0.97 → pass security
  • 31 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.

  • 29 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.

  • 27 Oct 26 +15
    • Malware scan: unverified → pass ▲ security
  • 26 Oct 26 −16
    • Malware scan: pass → unverified ▼ security
    • Schema quality: 2726 → 3017 ▼ functional
    • Destructive annotations: pass → 0 functional
    • Package version: 2.1.2 → 2.2.0 functional
  • 25 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 73 to 77. That category is still filling its 30-day observation window: 22 days of observed history at the previous scan, 23 at this one. The score rises as the window fills, whether or not the server changes.

  • 23 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 67 to 70. That category is still filling its 30-day observation window: 20 days of observed history at the previous scan, 21 at this one. The score rises as the window fills, whether or not the server changes.

  • 21 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 5 Nov 2026 · Analysed npm/@shukashake/agent@2.2.0

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem npm

Background: How many MCP packages publish verified provenance →

Dependencies 92 packages
Packages resolved 92
Stale 30
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 15 exposed · ~2,940 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
browse_marketplace ~171

Browse the shake-anchored license marketplace. Every offering in the marketplace is anchored to a Shuka shake that proves the underlying rights. Without a license_id this searches offerings; with a license_id it returns full details plus a validation check. Use this to: - Discover license offerings by keyword or brand - Inspect a specific offering before purchasing (purchase_license) - Confirm an offering is real, active, and in good standing

NameTypeReqDescription
brandstring–Filter by brand name
license_idstring–A specific license ID - returns full details plus validation instead of search results
pagenumber–Page number (default: 1)
per_pagenumber–Results per page (max 50)
searchstring–Free-text search across offerings

No output schema declared.

No examples provided.

check_access ~213

THE DECISION POINT: may this accessor use this data for this purpose right now? Evaluates the stored Terms Layer (status, validity window, remaining uses, purpose binding) AND the shake's revocation state, server-side. Returns a SIGNED verdict. Allowed crossings are receipted and land as ACCESSED events on the hash-chained ledger; a revoked shake denies with consent_revoked. Call this BEFORE acting on data protected by a Shuka proof — it is the same check shuka.guard performs at enterprise enforcement points.

NameTypeReqDescription
handshake_idstring–Handshake ID (alternative to proof_token)
proof_tokenstring–Compact proof token (shk_v1....) — or use terms_id / handshake_id
purposestring–Declared purpose of access (e.g. 'care_coordination')
recordboolean–Record a receipt + ledger event on allow (default true)
terms_idstring–Terms ID (alternative to proof_token)

No output schema declared.

No examples provided.

create_attestation ~192

Create a verifiable Shuka attestation for any claim or data. Use this when you need to: - Prove a claim is true with cryptographic certainty - Create an audit trail for data being shared - Attest to compliance, consent, or authorization - Generate a portable proof that other agents can verify Returns a proof token (shk_v1.xxx.yyy) that anyone can verify. Include industry/jurisdiction context directly in the description text — the attestation records the text and optional terms.

NameTypeReqDescription
descriptionstringyesWhat you are attesting to. Be specific and clear; include industry and jurisdiction context in the text.
termsobject–Optional access terms: access_type (single_use|time_limited|use_limited|perpetual|session_bound|windowed), validity_days, require_receipt, permitted_purposes, prohibited_purposes

No output schema declared.

No examples provided.

create_idempotent_shake ~298

Create or retrieve an idempotent Shuka shake. RECOMMENDED for most use cases. The One Ring: Same entity_data always returns the same shake. This is the magic that enables AI agents to repeatedly attest to the same data without creating duplicates - critical for enterprise integrations. This shake is the anchor for EVERYTHING else in the united flow: attach terms (manage_terms), issue a marketplace offering from it (issue_license), and its lifecycle is recorded in the registry (registry). Use this when you need to: - Attest to data that may be referenced multiple times - Create portable proofs that persist across sessions - Ensure billing accuracy (only charged on first creation) - Build reliable audit trails without duplicate entries Returns the shake with was_created=true (new) or was_created=false (existing).

NameTypeReqDescription
entity_dataobjectyesThe data being attested - used to generate deterministic entity_id. Same data = same shake.
entity_typestringyesCategory of entity being attested (e.g., 'medical_record', 'contract', 'license', 'compliance_check')
expires_in_daysnumber–Days until expiration (default: 365)
handshake_typestring–Type of attestation (default: 'attestation')
industrystring–Industry context (default: 'sdk')
purposestringyesHuman-readable purpose of this shake

No output schema declared.

No examples provided.

enterprise_licenses ~172

Browse enterprise (multi-seat) license offerings. action="browse": list enterprise offerings (filter by brand, min_seats, max_price). action="acquire": NOT CURRENTLY AVAILABLE — the enterprise seat model is not built yet and the backend returns 501 not_implemented. Use purchase_license for single-grant acquisitions.

NameTypeReqDescription
actionstringyesbrowse: list enterprise offerings. acquire: currently returns 501 not_implemented.
brandstring–(browse) Filter by brand
license_idstring–(acquire) The enterprise license ID
max_pricenumber–(browse) Maximum price
min_seatsnumber–(browse) Minimum seats needed
seats_needednumber–(acquire) Number of seats to acquire

No output schema declared.

No examples provided.

issue_license ~325

Issue a license offering anchored to one of YOUR handshakes (shakes). The united flow: your shake proves the underlying rights; the offering is issued FROM that shake; buyers purchase grants against it; every event is recorded in the append-only registry. Requires an SDK key with license:write permission and an issuer-capable account (Partner/Admin). Get keys at https://shuka.app/dashboard/api-keys Use this to: - Turn an attested asset (voice likeness, IP, dataset rights) into a sellable offering - Set pricing, permitted/prohibited uses, royalties, and grant caps

NameTypeReqDescription
anchor_handshake_idstringyesThe shake (handshake ID) that anchors this offering - must belong to you
brandstringyesBrand / title of the offering
buy_to_open_pricenumber–Price to purchase a grant
image_urlstring–Offering image URL
max_grantsnumber–Maximum number of grants that can be sold
permitted_usesarray–What grant holders may do
platform_fee_percentagenumber–Platform fee percent
prohibited_usesarray–What grant holders may not do
rights_holderstringyesLegal rights holder name
royalty_cap_usdnumber–Royalty cap in USD
royalty_percentagenumber–Royalty percent recorded in contract terms
valid_untilstringyesExpiry date (ISO format, e.g. 2027-12-31)

No output schema declared.

No examples provided.

lookup_shake ~85

Look up an existing shake by entity identifiers. Use this to check if a shake already exists before creating a new one, or to retrieve shake details for data you've previously attested. Returns the shake if found, or null if not found.

NameTypeReqDescription
entity_dataobjectyesThe entity data (used to derive entity_id)
entity_typestringyesCategory of entity

No output schema declared.

No examples provided.

manage_terms ~482

Manage the rules layer: modifiable terms riding on immutable handshakes. The shake never changes; the terms on it can be amended, re-priced, or revoked WITHOUT re-attesting. This is how user IP stays under the owner's control after attestation. Actions (all require an SDK key assigned to a user; most are billable): - create: attach terms to a handshake (requires handshake_id; access_type defaults to perpetual; 409 terms_exist if the handshake already has terms; needs license:write, $0.05) - get: fetch terms by terms_id - update: amend terms (updates MUST include change_reason or the backend 400s; new revision recorded; needs license:write, $0.03) - revoke: revoke terms (reason is REQUIRED; needs license:write, $0.02) - record_access: log an access under the terms (creates a receipt; purpose must be in permitted_purposes when those are set; needs license:read, $0.01) - revisions: amendment history for terms - receipts: access receipts (audit trail) for terms - by_handshake: get the current terms attached to a handshake

NameTypeReqDescription
access_configobject–(create) Access-type-specific config (e.g. valid_until, max_uses)
access_typestring–(create) How the data may be accessed
accessor_idstring–(record_access) Who accessed (defaults to this agent)
actionstringyesThe terms operation to perform
handshake_idstring–(create, by_handshake) The handshake the terms ride on
permitted_purposesarray–(create) Purposes the data may be used for
prohibited_purposesarray–(create) Purposes the data may NOT be used for
purposestring–(record_access) Why the data was accessed
reasonstring–(revoke) Why the terms are being revoked — REQUIRED for revoke
terms_idstring–(get, update, revoke, record_access, revisions, receipts) The terms ID
updatesobject–(update) Fields to change — MUST include change_reason (backend rejects without it)

No output schema declared.

No examples provided.

negotiate_trust ~157

Perform agent-to-agent trust negotiation with Shuka as the arbiter. Use this when: - Another agent presents a proof and you need Shuka to vouch for it - You need a recommendation on whether to proceed with a data exchange - You want detailed validation evidence before trusting external data Returns a recommendation: safe_to_proceed, proceed_with_caution, additional_verification_recommended, or do_not_proceed. NOTE: negotiation is a billable operation (standard shake rate). An invalid proof is rejected by a free pre-check before any charge.

NameTypeReqDescription
proof_tokenstringyesThe proof token to verify
purposestring–Why you need to verify this (provides context for the trust decision)

No output schema declared.

No examples provided.

purchase_license ~177

Purchase a license from the marketplace (creates a grant). Returns the transaction, portfolio entry, and the attestation (handshake + proof_token) anchoring the grant to the registry ledger. The proof_token is portable - any agent can verify it with verify_proof. Acquisition is idempotent per buyer+license: a replay returns 409 with no double charge; a license you already own returns 409 already_owned; a payment_amount that doesn't match the current list price returns 400 carrying license_price. Use this to: - Acquire usage rights for an offering found via browse_marketplace - Get a cryptographic proof of your grant for downstream agents

NameTypeReqDescription
license_idstringyesThe license/offering ID to acquire
payment_amountnumberyesPayment amount (must match the offering price)

No output schema declared.

No examples provided.

registry ~300

Query the Shuka registry: the append-only ledger and interoperability layer. Actions: - history: full chronological ledger history for an entity (requires entity_type + entity_id) - discover: find registries by industry / shake_type - lookup: look up a registry entity by entity_id - can_issue: check whether an entity can issue a shake type (requires entity_id + shake_type) - will_accept: check whether an entity accepts a shake type from an issuer (requires entity_id + shake_type + issuer_id) - interop_check: full issuer-to-receiver interoperability check (requires issuer_id + receiver_id + shake_type) Use this to trace provenance (every license and grant event is in the ledger) and to confirm two parties can exchange a given shake type BEFORE attempting it.

NameTypeReqDescription
actionstringyesThe registry operation to perform
entity_idstring–(history, lookup, can_issue, will_accept) The entity ID
entity_typestring–(history) Ledger entity type (e.g. 'license', 'grant')
industrystring–(discover) Filter registries by industry
issuer_idstring–(will_accept, interop_check) The issuer entity ID
receiver_idstring–(interop_check) The receiver entity ID
shake_typestring–(discover, can_issue, will_accept, interop_check) The shake type in question

No output schema declared.

No examples provided.

revoke_grant ~78

Revoke a license grant (issuer or admin only). Writes the transactional GRANT_REVOKED event on the grant's ledger chain and revokes the grant's proof token — verify_grant reports it immediately.

NameTypeReqDescription
grant_idstringyesThe grant ID to revoke
reasonstring–Revocation reason (audit trail)

No output schema declared.

No examples provided.

verify_grant ~112

Verify a marketplace grant against the append-only registry ledger. Returns the grant status, the anchoring license offering, the attestation, and the integrity of the ledger chain. This is how any agent confirms a grant is real, active, and unrevoked - without trusting the grant holder. Use this when: - Another party claims to hold a license grant - You need to confirm a grant before honoring its permitted uses

NameTypeReqDescription
grant_idstringyesThe grant ID to verify (GRANT-...)

No output schema declared.

No examples provided.

verify_proof ~124

Verify a Shuka proof token and get details about the attestation. Use this when you: - Receive a proof token and need to confirm it's valid - Want to check the trust score before proceeding - Need to see what was attested and when - Want to verify claims before acting on data Proof tokens look like: shk_v1.YWJjMTIz.a1b2c3 or ENV-xxx

NameTypeReqDescription
proof_tokenstringyesThe Shuka proof token to verify (shk_v1.xxx.yyy or ENV-xxx format)

No output schema declared.

No examples provided.

verify_shake ~54

Verify a shake by its ID and get trust information. Use this to confirm a shake is valid and check its trust score before proceeding with a data exchange.

NameTypeReqDescription
shake_idstringyesThe handshake ID to verify

No output schema declared.

No examples provided.

Install

How do I install the io.github.cdonoyan/shuka MCP server?

io.github.cdonoyan/shuka runs locally as an npm package, launched with npx -y @shukashake/agent. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

npm · @shukashake/agent

# add to Claude Code
claude mcp add cdonoyan-shuka -- npx -y @shukashake/agent
Common questions

What is the io.github.cdonoyan/shuka MCP server?

io.github.cdonoyan/shuka is an MCP server listed in the public MCP registry as io.github.cdonoyan/shuka. Universal trust attestation for AI agents: create, verify, and negotiate Shuka trust proofs. This page covers its npm package (@shukashake/agent).

Is the io.github.cdonoyan/shuka MCP server safe to use?

io.github.cdonoyan/shuka scores 83 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the io.github.cdonoyan/shuka MCP server expose?

io.github.cdonoyan/shuka exposes 15 tools: create_idempotent_shake, lookup_shake, verify_shake, create_attestation, verify_proof, and 10 more. Their descriptions and schemas cost roughly 2,940 tokens of context every time the server is loaded.

Is the io.github.cdonoyan/shuka MCP server still maintained?

io.github.cdonoyan/shuka is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What licence is the io.github.cdonoyan/shuka MCP server under?

io.github.cdonoyan/shuka declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.