A pasteable skeleton generated from the repository name. Check the project README for the exact package and arguments.
Star count
1 ★ · getnahook/nahook-mcp · read from the GitHub search API · (checked 2026-10-16 20:00:20)
Source
collected from the punkpeye/awesome-mcp-servers list · type: MCP server
Harvest history
first seen 2026-10-09 · last seen 2026-10-16 · seen 32× · listed by 7 sources
Score
score 703 · 1 ★ · 7 sources · mcp
FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: MCP 服务. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository getnahook/nahook-mcp;first catalogued 2026-10-09;last seen 2026-10-16。There is no official certification or quality rating here — we record sources and dates only.
The official **Model Context Protocol** server for Nahook — drive webhook deliveries, endpoints, and event triggers from Claude Desktop, Cursor, Cline, and any other MCP-compatible AI assistant. > The MCP server ships as a subcommand of the nahook CLI. One binary, one credentials file, one install path. What it does Once installed and authenticated, your AI assistant can: - **Inspect** endpoints, deliveries, and per-attempt logs to debug failed webhooks. - **Retry** failed or dead-lettered deliveries. - **Trigger** events and fan them out to every subscribed endpoint. - **Send** webhooks directly to a single endpoint. - **Manage** endpoints (create, update, pause, resume) — never delete, by design. Write operations are tagged with the MCP destructiveHint/readOnlyHint annotations so MCP clients surface a per-call human-approval prompt before anything mutates state. Security guardrails Webhook payloads are third-party data, so the server treats everything that flows back into the model's context as a potential prompt-injection channel: - **Untrusted content is fenced.** Every producer- or receiver-authored value that reaches the model — webhook payloads (get_delivery with include_payload), delivery idempotency keys, and receiver error messages (list_attempts) — is wrapped in explicit >> delimiters with embedded fence markers neutralized, and the server instructions tell the model to treat fenced content as inert data, never as instructions. - **Payloads are capped.** Bodies over 256 KB are truncated (flagged via payload_truncated) so a hostile producer can't stuff the model's context. Tune the cap with NAHOOK_MCP_PAYLOAD_CAP= in the MCP client's environment. - **No delete tools, by design.** Nothing in the tool surface can destroy data. - **update_endpoint is marked destructive.** It overwrites live endpoint config (repointing its URL is the primitive an injection would target), so its destructiveHint is true and clients surface a prominent approval prompt. - **Write tools rely on human approval.** Per the MCP spec, annotations are advisory hints, not access control — the security boundary is the client's per-call approval prompt, which applies to every non-read tool. The additive write tools (create_endpoint, send_to_endpoint, trigger_event) are annotated destructiveHint: false per their spec semantics; keep human-in-the-loop approval enabled in your MCP client and don't blanket-allow them. If you want a hard guarantee of no writes, run the server without an ingestion key (disables sending) and treat management tools as approval-gated. - **Secrets never reach the model.** Endpoint signing secrets and auth tokens are omitted from every tool output; whoami returns only the token's public id. - **Split credentials.** Sending (trigger_event, send_to_endpoint) requires a separate ingestion key — omit it and the server is management/read-only for ingestion. Client-side measures can't make prompt injection impossible — pair them with your MCP client's tool-approval prompts. Install The MCP server is a subcommand of the nahook CLI. Install the CLI, then add it to your AI client.