# io.github.cdonoyan/shuka (npm · @shukashake/agent)

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

- Trust score: 83/100 (high trust)
- Change this week: +1
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- npm · `@shukashake/agent`: 83/100 (this document), [markdown](https://verifymcp.io/servers/cdonoyan-shuka/shukashake-agent.md), [page](https://verifymcp.io/servers/cdonoyan-shuka/shukashake-agent)

## Channel facts

- Registry: `npm`
- Package: `@shukashake/agent`
- Version: `2.2.0`
- Transport: `stdio`

## Trust breakdown

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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 30 of 92 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 9 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 80/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - 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.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 100/100
  - No destabilizing schema changes in the last 30 days.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 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.
  - An AI judge read all 16 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## 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.

### Claude

```bash
claude mcp add cdonoyan-shuka -- npx -y @shukashake/agent
```

### Cursor

```json
{
  "mcpServers": {
    "cdonoyan-shuka": {
      "command": "npx",
      "args": [
        "-y",
        "@shukashake/agent"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "cdonoyan-shuka": {
      "command": "npx",
      "args": [
        "-y",
        "@shukashake/agent"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add cdonoyan-shuka -- npx -y @shukashake/agent
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "cdonoyan-shuka": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@shukashake/agent"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add cdonoyan-shuka --command npx --arg -y --arg @shukashake/agent
```

### Hermes

```yaml
mcp_servers:
  cdonoyan-shuka:
    command: "npx"
    args: ["-y", "@shukashake/agent"]
```

### Netclaw

```json
{
  "McpServers": {
    "cdonoyan-shuka": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@shukashake/agent"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add cdonoyan-shuka -t stdio -c npx -a -y @shukashake/agent
```

### Other

```json
{
  "mcpServers": {
    "cdonoyan-shuka": {
      "command": "npx",
      "args": [
        "-y",
        "@shukashake/agent"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-01 (score 83, 0)

- [security] Stability: 0.97 → pass

### 2026-10-31 (score 83, +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.

### 2026-10-29 (score 82, +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.

### 2026-10-27 (score 81, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-10-26 (score 66, −16)

- [security regression] Malware scan: pass → unverified
- [functional regression] Schema quality: 2726 → 3017
- [functional] Destructive annotations: pass → 0
- [functional] Package version: 2.1.2 → 2.2.0

### 2026-10-25 (score 82, +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.

### 2026-10-23 (score 81, +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.

### 2026-10-21 (score 80, +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.

## MCP tools (15)

### `create_idempotent_shake` (~298 tokens)

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).

Input parameters:

- `entity_data` (object, required): The data being attested - used to generate deterministic entity_id. Same data = same shake.
- `entity_type` (string, required): 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, required): Human-readable purpose of this shake

### `lookup_shake` (~85 tokens)

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.

Input parameters:

- `entity_data` (object, required): The entity data (used to derive entity_id)
- `entity_type` (string, required): Category of entity

### `verify_shake` (~54 tokens)

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.

Input parameters:

- `shake_id` (string, required): The handshake ID to verify

### `create_attestation` (~192 tokens)

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.

Input parameters:

- `description` (string, required): 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

### `verify_proof` (~124 tokens)

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

Input parameters:

- `proof_token` (string, required): The Shuka proof token to verify (shk_v1.xxx.yyy or ENV-xxx format)

### `negotiate_trust` (~157 tokens)

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.

Input parameters:

- `proof_token` (string, required): The proof token to verify
- `purpose` (string): Why you need to verify this (provides context for the trust decision)

### `browse_marketplace` (~171 tokens)

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

Input parameters:

- `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

### `issue_license` (~325 tokens)

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

Input parameters:

- `anchor_handshake_id` (string, required): The shake (handshake ID) that anchors this offering - must belong to you
- `brand` (string, required): 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, required): Legal rights holder name
- `royalty_cap_usd` (number): Royalty cap in USD
- `royalty_percentage` (number): Royalty percent recorded in contract terms
- `valid_until` (string, required): Expiry date (ISO format, e.g. 2027-12-31)

### `purchase_license` (~177 tokens)

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

Input parameters:

- `license_id` (string, required): The license/offering ID to acquire
- `payment_amount` (number, required): Payment amount (must match the offering price)

### `verify_grant` (~112 tokens)

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

Input parameters:

- `grant_id` (string, required): The grant ID to verify (GRANT-...)

### `enterprise_licenses` (~172 tokens)

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.

Input parameters:

- `action` (string, required): 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

### `manage_terms` (~482 tokens)

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

Input parameters:

- `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, required): 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)

### `registry` (~300 tokens)

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.

Input parameters:

- `action` (string, required): 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

### `check_access` (~213 tokens)

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.

Input parameters:

- `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)

### `revoke_grant` (~78 tokens)

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.

Input parameters:

- `grant_id` (string, required): The grant ID to revoke
- `reason` (string): Revocation reason (audit trail)

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/cdonoyan-shuka/shukashake-agent#diagnostics

## Score history

- 2026-11-05: 83
- 2026-11-04: 83
- 2026-11-03: 83
- 2026-11-02: 83
- 2026-11-01: 83
- 2026-10-31: 83
- 2026-10-30: 82
- 2026-10-29: 82
- 2026-10-28: 81
- 2026-10-27: 81
- 2026-10-26: 66
- 2026-10-25: 82
- 2026-10-24: 81
- 2026-10-23: 81
- 2026-10-22: 80
- 2026-10-21: 80
- 2026-10-20: 79
- 2026-10-19: 79
- 2026-10-18: 78
- 2026-10-17: 78
- 2026-10-16: 77
- 2026-10-15: 38
- 2026-10-14: 38
- 2026-10-13: 66
- 2026-10-12: 66
- 2026-10-11: 66
- 2026-10-04: 66
- 2026-10-03: 66
- 2026-10-02: 51

## 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.

## Links

- npm package: https://www.npmjs.com/package/@shukashake/agent
- Socket report: https://socket.dev/npm/package/@shukashake/agent
- Repository: https://github.com/cdonoyan/shuka-agent
- Changelog RSS feed: https://verifymcp.io/servers/cdonoyan-shuka/shukashake-agent.xml
- Changelog JSON feed: https://verifymcp.io/servers/cdonoyan-shuka/shukashake-agent.json
- HTML version of this page: https://verifymcp.io/servers/cdonoyan-shuka/shukashake-agent