io.github.cdonoyan/shuka
NPM · @SHUKASHAKE/AGENT
Universal trust attestation for AI agents: create, verify, and negotiate Shuka trust proofs.
Available components
Last scanned (5 hours ago)
Scores higher than 76% of npm servers
Category Security
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
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 9 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
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
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.
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 →
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 →
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
| Name | Type | Req | Description |
|---|---|---|---|
| brand | string | – | Filter by brand name |
| license_id | string | – | A specific license ID - returns full details plus validation instead of search results |
| page | number | – | Page number (default: 1) |
| per_page | number | – | Results per page (max 50) |
| search | string | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| handshake_id | string | – | Handshake ID (alternative to proof_token) |
| proof_token | string | – | Compact proof token (shk_v1....) — or use terms_id / handshake_id |
| purpose | string | – | Declared purpose of access (e.g. 'care_coordination') |
| record | boolean | – | Record a receipt + ledger event on allow (default true) |
| terms_id | string | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| description | string | yes | What you are attesting to. Be specific and clear; include industry and jurisdiction context in the text. |
| terms | object | – | 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).
| Name | Type | Req | Description |
|---|---|---|---|
| entity_data | object | yes | The data being attested - used to generate deterministic entity_id. Same data = same shake. |
| entity_type | string | yes | Category of entity being attested (e.g., 'medical_record', 'contract', 'license', 'compliance_check') |
| expires_in_days | number | – | Days until expiration (default: 365) |
| handshake_type | string | – | Type of attestation (default: 'attestation') |
| industry | string | – | Industry context (default: 'sdk') |
| purpose | string | yes | Human-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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | browse: list enterprise offerings. acquire: currently returns 501 not_implemented. |
| brand | string | – | (browse) Filter by brand |
| license_id | string | – | (acquire) The enterprise license ID |
| max_price | number | – | (browse) Maximum price |
| min_seats | number | – | (browse) Minimum seats needed |
| seats_needed | number | – | (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
| Name | Type | Req | Description |
|---|---|---|---|
| anchor_handshake_id | string | yes | The shake (handshake ID) that anchors this offering - must belong to you |
| brand | string | yes | Brand / title of the offering |
| buy_to_open_price | number | – | Price to purchase a grant |
| image_url | string | – | Offering image URL |
| max_grants | number | – | Maximum number of grants that can be sold |
| permitted_uses | array | – | What grant holders may do |
| platform_fee_percentage | number | – | Platform fee percent |
| prohibited_uses | array | – | What grant holders may not do |
| rights_holder | string | yes | Legal rights holder name |
| royalty_cap_usd | number | – | Royalty cap in USD |
| royalty_percentage | number | – | Royalty percent recorded in contract terms |
| valid_until | string | yes | Expiry 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.
| Name | Type | Req | Description |
|---|---|---|---|
| entity_data | object | yes | The entity data (used to derive entity_id) |
| entity_type | string | yes | Category 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
| Name | Type | Req | Description |
|---|---|---|---|
| access_config | object | – | (create) Access-type-specific config (e.g. valid_until, max_uses) |
| access_type | string | – | (create) How the data may be accessed |
| accessor_id | string | – | (record_access) Who accessed (defaults to this agent) |
| action | string | yes | The terms operation to perform |
| handshake_id | string | – | (create, by_handshake) The handshake the terms ride on |
| permitted_purposes | array | – | (create) Purposes the data may be used for |
| prohibited_purposes | array | – | (create) Purposes the data may NOT be used for |
| purpose | string | – | (record_access) Why the data was accessed |
| reason | string | – | (revoke) Why the terms are being revoked — REQUIRED for revoke |
| terms_id | string | – | (get, update, revoke, record_access, revisions, receipts) The terms ID |
| updates | object | – | (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.
| Name | Type | Req | Description |
|---|---|---|---|
| proof_token | string | yes | The proof token to verify |
| purpose | string | – | 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
| Name | Type | Req | Description |
|---|---|---|---|
| license_id | string | yes | The license/offering ID to acquire |
| payment_amount | number | yes | Payment 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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | The registry operation to perform |
| entity_id | string | – | (history, lookup, can_issue, will_accept) The entity ID |
| entity_type | string | – | (history) Ledger entity type (e.g. 'license', 'grant') |
| industry | string | – | (discover) Filter registries by industry |
| issuer_id | string | – | (will_accept, interop_check) The issuer entity ID |
| receiver_id | string | – | (interop_check) The receiver entity ID |
| shake_type | string | – | (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.
| Name | Type | Req | Description |
|---|---|---|---|
| grant_id | string | yes | The grant ID to revoke |
| reason | string | – | 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
| Name | Type | Req | Description |
|---|---|---|---|
| grant_id | string | yes | The 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
| Name | Type | Req | Description |
|---|---|---|---|
| proof_token | string | yes | The 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.
| Name | Type | Req | Description |
|---|---|---|---|
| shake_id | string | yes | The handshake ID to verify |
No output schema declared.
No examples provided.
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
claude mcp add cdonoyan-shuka -- npx -y @shukashake/agent
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.