Shinobi MCP server

Read from the package source without running it. The installed server may list more.

• add_note

  Add a free-form note. Used for things that do not fit decision/dead_end/task. Body is fulltext-searched by recall(), and embedded for semantic recall when SHINOBI_EMBED_PROVIDER is configured.

• agent_bootstrap

  Start an agent work session for a project. Returns project context, latest plan, selected/next task, open decisions, relevant dead ends, recent activity, and file-specific decisions. Optionally claims the task.

• archive_project

  Mark a project as archived (sets archived_at timestamp).

• bulk_create_taskswrite action

  Create multiple subtasks in a single transaction. Useful when seeding a project plan.

• check_dead_ends

  Preventive search BEFORE implementing an approach. Pass a description and optional file paths. Uses semantic similarity when SHINOBI_EMBED_PROVIDER is configured; otherwise FTS5 + filename overlap. Returns matching past failures.

• claim_task

  Mark a subtask as in_progress and link the current session. Call BEFORE starting work so resume knows where you left off.

• complete_task

  Mark a subtask as done. Optionally pass a summary that will be attached to the linked session. Set notify:true to fire a "task done" mobile push (best-effort, never fails the completion) — meant for headless / dispatch-loop agents; leave false for interactive completes so you do not buzz your own phone.

• compress_session_summary

  Compress a project's recent activity + decisions + dead ends into a terse 3-paragraph markdown summary via LLM (Groq Llama 3.3 by default, free tier). When persist=true (default), stores on projects.recent_summary_md so next agent_bootstrap surfaces it as signal instead of raw 270-row noise. Requires SHINOBI_LLM_PROVIDER + GROQ_API_KEY (or OPENAI_API_KEY).

• create_projectwrite action

  Create a new project. Tag with workspace (e.g. shinobi / shinobiapps / sitesnap) so cross-codebase work stays organised.

• create_taskwrite action

  Create a subtask. project_id is optional (null = unrouted inbox task). Title+description are embedded for semantic recall when SHINOBI_EMBED_PROVIDER is configured.

• decisions_for_file

  Return every decision whose files_touched contains the given path. Useful when opening a file you have not touched in months.

• delete_projectwrite action

  Permanently delete a project (cascades to subtasks, decisions, plans, etc.).

• delete_subtaskwrite action

  Permanently delete a subtask.

• extract_decisions

  Extract decision drafts from a conversation transcript via LLM (Groq Llama 3.3 by default, free tier). Drafts land in the decision_drafts table with status=pending — the user reviews them in the dashboard and approves to create real decisions via log_decision. Use at session boundaries when you want auto-capture of decisions you may have forgotten to log explicitly. Requires SHINOBI_LLM_PROVIDER +

• file_context

  Return guardrail context for files an agent is about to inspect or edit: project context annotations, decisions for each file, relevant dead ends, and recent activity.

• get_context

  Get a project living context: conventions, dont_touch, test_patterns, deploy_notes, file_annotations. Returns null when no context row exists yet.

• get_plan

  Return the latest plan for a project, or a specific version. Optionally include version history.

• get_project

  Get a single project by id, including its summary fields.

• get_task

  Get a single subtask by id.

• history

  Return activity timeline (claim/complete/log_decision/log_dead_end/save_plan/...) ordered newest-first. Optionally scoped to a project, entity, or session.

• ingest_findings

  Turn a list of audit / linter / code-review findings into a subtask graph the swarm can drain. Severity maps to priority (critical→urgent, high→high, medium→medium, low/info→low). Findings on the same file are chained (depends_on) so they run sequentially — agents never edit one file in parallel — while different files stay independent and fan out. Closes the loop: an AI review generates findings,

• link_commit

  Link a git commit to a subtask (when commit message contains [SHI-N] tag) or attribute to projects via target_path match. Records to the activity timeline so 'history' shows commits next to claims/completions.

• list_notes

  List notes ordered newest-first, optionally scoped to a project.

• list_projects

  List Shinobi projects with progress. Filter by status, workspace, or include archived. Pass brief=true for a token-light listing (truncated descriptions, no summary blobs) and use get_project for full detail.

• list_tasks

  List subtasks. Filter by project_id, status, or claude session id.

• log_dead_end

  Log an approach that demonstrably failed so future sessions do not re-try. Embeds approach+failure_reason for semantic match when SHINOBI_EMBED_PROVIDER is configured.

• log_decision

  Record a decision in the durable decision log. Architectural choices, library picks, tradeoffs, workarounds. Embeds summary+rationale for semantic recall when SHINOBI_EMBED_PROVIDER is configured.

• next_task

  Pick the highest-priority todo subtask whose dependencies are met. Optionally scoped to a project. Also returns matched dead-end warnings (semantic when SHINOBI_EMBED_PROVIDER is configured).

• notify

  Fire-and-forget mobile push to every subscribed device. Unlike request_approval, this does NOT block waiting for a response — use it from a headless / dispatch-loop agent to signal "done while you slept" (kind:"task_completed") or "I am stuck, come look" (kind:"blocked"). Returns a delivery summary; push failures never throw.

• plugin_hello

  List discovered plugins and their registered tools. Use this to verify the plugin system loaded correctly. Plugins are loaded from ~/.shinobi/plugins/*.{js,mjs} (user tier) and node_modules/@shinobi/plugin-* (npm tier).

• recall

  Search across decisions, dead ends, notes, and subtask titles/descriptions for a query string. Uses semantic similarity when SHINOBI_EMBED_PROVIDER is configured; otherwise FTS5-backed fulltext. Use this when you have lost the thread on an old project.

• request_approval

  Block waiting for the user to approve a decision via mobile push notification. Creates an approval row, fires web push to all subscribed devices with action buttons, and polls until the user responds (or timeout). Use when the agent hits a decision point that requires human judgment ("ship to prod?", "drop this feature?", "pick library X or Y?").

• save_plan

  Persist an approved plan as a new versioned snapshot. Auto-increments version per project.

• session_closeout

  Finish an agent work session in one call. Records summary, changed files, completed tasks, decisions, dead ends, optional plan snapshot, and follow-up tasks.

• unarchive_project

  Restore an archived project (clears archived_at).

• update_contextwrite action

  Patch a project's context. Only fields present in the patch are modified — others preserve their prior value.

• update_decision_statuswrite action

  Move a decision through its lifecycle (open / fix_now / fix_later / wontfix / fixed / false_positive). Stamps decided_at automatically on closing states.

• update_projectwrite action

  Patch a project. Only fields present in the patch are modified.

• update_subtaskwrite action

  Patch a subtask. Rejects circular dependencies. Use status="todo" to reset an in-progress task.

• Code scan199 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitylocal package, no credentials required12/15
• Maintenancelast push 58 days ago12/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Safety score

88/100

higher than 75% of 1,299 Productivity servers

Tools

39

the typical Productivity server has 7

Tools that change things

23%

typical: 0%. Fewer write tools means less an agent can break

GitHub stars

2

more than 60% of 854 Productivity servers

Downloads a week

53

more than 41% of 427 Productivity servers with a package

Shinobi: common questions

Is Shinobi MCP server safe?

Yes, by our scan: it is graded A (88/100). Read the Shinobi safety report

How do I install Shinobi?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does Shinobi need an API key?

Not as far as the registry entry and our scan can tell: no credentials are declared or required.

Is Shinobi maintained?

The last commit was 96 days ago (2026-07-31). The latest release is v0.3.1.

What can I use instead of Shinobi?

Servers from other publishers that do the same job: Argent MCP server, Agent-Native Dispatch MCP server and CLEO MCP Server.

How does Shinobi compare with other Productivity MCP servers?

safety score 88/100 (higher than 75% of 1,299 Productivity servers); tools 39 (the typical Productivity server has 7); tools that change things 23% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.