GodPrompt MCP Server
Use the GodPrompt MCP server to access AI software-development workflow guidance and deterministic task routing through seven read-only tools.
Retrieve the full GodPrompt payload in one call.
Load the core GodPrompt skill for lean progressive disclosure.
Retrieve detailed protocols for 9 task types.
Retrieve verification gates/checklists before claiming completion.
Retrieve anti-patterns, red flags, and recovery guidance.
Classify a software-development task into one of 9 task types or
UNCLASSIFIED, with deterministic confidence and routing metadata.Get GodPrompt content version, MCP server version, bundled file metadata, and protocol catalog.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@GodPrompt MCP Serverget the core skill for AI software development"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
GodPrompt MCP Server
A Model Context Protocol (MCP) server for GodPrompt — AI software-development workflow guidance with task routing, TDD, debugging protocols, verification gates, and progressive disclosure.
Agent Harness Review — US$49
GodPrompt offers a bounded Agent Harness Review for developers and small teams whose coding agents lose context, overstep scope, skip verification, or repeat mistakes.
GodPrompt Agent Harness Review — US$49 one-time. For one repository, send up to three agent-control artifacts (AGENTS.md, CLAUDE.md, project rules, or equivalent) plus one short failure example. The review returns five priority risks, one proposed revised instruction block or patch, and a next-task verification checklist, with a target of 24 hours after payment and usable inputs.
To buy the review, use the US$49 one-time GitHub Sponsors tier. GitHub sign-in is required. After sponsoring, email info@tomiseregi.si with subject [GP-RS1] Agent Harness Review and include the GitHub username used for the sponsorship plus the review inputs. Delivery begins after the US$49 sponsorship is independently verified for this review. The free MIT GodPrompt MCP remains unchanged and free. See a transparent sample deliverable before deciding; it is illustrative, not a client result or benchmark. Full frozen experiment terms.
Related MCP server: prompts-mcp-server
Tools
Tool | Description |
| Full GodPrompt.md single-file payload (~40KB) |
|
|
|
|
|
|
|
|
| Deterministically route a task to one of 9 GodPrompt task types, or |
| Version info and server metadata |
Progressive Disclosure
For minimum context usage, start with get_core_skill, then load get_protocols, get_gates, or get_anti_patterns only when the task requires deeper guidance. Use get_god_prompt when you want everything in one shot.
Example queries
"Classify this refactor and tell me which GodPrompt workflow applies."
"Show me the verification gates I should satisfy before I claim this bug fix is complete."
"Load the debugging protocol for a failing integration test without loading the full GodPrompt."
Evaluation
GodPrompt's benchmark methodology, deterministic task corpus, evaluator logic, and reproducible run/export tooling live in the source project: GodPrompt Bench. No frozen reference-model run or raw benchmark artifacts have been published yet.
The MCP server does not run the benchmark or claim model-level superiority itself; it distributes the GodPrompt content evaluated by that suite.
Connect
Hosted remote (no Node.js required)
Use the public Streamable HTTP endpoint directly in MCP clients that support remote servers:
https://god-prompt-mcp.tomi-seregi99.workers.dev/mcpThe hosted endpoint exposes the same seven read-only GodPrompt tools as the local server and requires no API key or local Node.js runtime. It accepts both the deployed initialize flow and the current MCP 2026-07-28 server/discover flow so clients can connect while the ecosystem transitions between protocol eras. It is also published as a remote option in the Official MCP Registry alongside the installable stdio packages.
Agent Skills over MCP (SEP-2640)
On MCP 2026-07-28, both the hosted and stdio servers advertise the Final io.modelcontextprotocol/skills extension from SEP-2640. Supporting clients can discover the same relevance-scoped god-prompt Agent Skill with skills/list / skills/get, then fetch SKILL.md and its three reference files through resources/read. The skill manifest includes SHA-256 digests and exact byte sizes so clients can verify what they import. Clients that do not implement this extension continue to use the seven existing GodPrompt tools normally.
This transports GodPrompt's existing skill package; it does not force the skill into every request or change the host's own approval, verification, or activation policy. See the MCP Skills extension specification.
ChatGPT Plugin Directory (skill-only)
For the lowest-friction ChatGPT path, install GodPrompt from the first-party Plugin Directory. That published plugin carries the scoped god-prompt Agent Skill; use the custom MCP app setup below when you specifically want the seven callable GodPrompt tools.
ChatGPT (hosted remote MCP)
On ChatGPT web, supported Business and Enterprise/Edu workspaces can connect the hosted endpoint as a custom MCP app in Developer Mode:
Enable Developer Mode, then open Settings > Apps > Create (workspace controls may require an admin or authorized developer).
Use
https://god-prompt-mcp.tomi-seregi99.workers.dev/mcpas the MCP endpoint and select no authentication.Choose Scan Tools, confirm the seven read-only GodPrompt tools, then create and enable the app for the intended workspace users.
ChatGPT connects to remote MCP servers rather than local stdio servers. See OpenAI's Developer mode and MCP apps in ChatGPT documentation for current availability and workspace controls.
npm / npx (recommended)
npx -y god-prompt-mcpThe public npm package runs the local stdio server directly. It requires Node.js 22+ and no API key or account.
Windows custom stdio clients: If a client reports spawn npx ENOENT or spawn npx.cmd EINVAL, it may be trying to execute npm's Windows batch shim without a compatible launcher. Prefer the hosted endpoint, or, for an affected client that accepts a custom stdio command, use:
{
"command": "C:\\Windows\\System32\\cmd.exe",
"args": ["/d", "/s", "/c", "npx -y god-prompt-mcp"]
}This is a client-launcher workaround, not a GodPrompt MCP server change. Keep existing working cross-platform npx configurations unchanged.
Docker / GHCR (local stdio; no host Node.js)
For MCP clients that can launch a local process, the public GHCR image runs the same seven read-only tools without requiring Node.js on the host. Docker with Linux-container support is required; no API key is needed.
{
"command": "docker",
"args": ["run", "--rm", "-i", "ghcr.io/akzar1el/god-prompt-mcp:1.0.44"]
}Keep -i so the MCP client can exchange JSON-RPC over standard input/output; do not add -t (a TTY changes the stdio stream). The version tag selects the verified v1.0.44 image; update it deliberately for future releases rather than silently following the moving latest tag. The image is Linux/amd64 and runs as non-root user 10001:10001. If Docker is unavailable, use the hosted remote endpoint instead.
Glama
GodPrompt MCP is published on Glama. Use the server page to inspect the tools and connect it to a supported MCP client.
Kiro
Install this repository as a native Kiro Power to get the portable GodPrompt Agent Skill and MCP server together. In Kiro, open Powers → Add Custom Power → Import power from GitHub, enter:
https://github.com/AKzar1el/god-prompt-mcpKiro reads the repository's Agent Plugins 1.0 plugin.json, skills/, and mcp.json; the bundled MCP server activates with the Power instead of requiring a separate user-level MCP entry.
If you only want the MCP server, use the direct install button:
Both paths ultimately launch the published npm package through npx. Node.js 22+ is required for the MCP server.
Visual Studio Code
VS Code supports Agent Plugins 1.0 packages directly, so the lowest-friction path installs GodPrompt's portable Agent Skill and bundled MCP server together:
Run Chat: Install Plugin From Source from the Command Palette.
Enter
https://github.com/AKzar1el/god-prompt-mcp.Review the repository source before confirming the install. VS Code discovers the root
plugin.json,skills/god-prompt, andmcp.jsonfrom the same package.
If you only want the Agent Skill, install it at user scope so VS Code discovers it from ~/.copilot/skills:
gh skill install AKzar1el/god-prompt-mcp skills/god-prompt --agent github-copilot --scope userIf you only want the seven callable MCP tools, use the native MCP install button:
The plugin and MCP-only paths both launch the published local stdio server through npx. Node.js 22+ is required; no API key is needed.
Amazon Q Developer
Amazon Q Developer supports both local process MCP servers and remote HTTP MCP servers. For the no-Node path, add GodPrompt to the mcpServers object in the Q CLI or Q Developer IDE agent configuration:
{
"mcpServers": {
"god-prompt": {
"type": "http",
"url": "https://god-prompt-mcp.tomi-seregi99.workers.dev/mcp"
}
}
}The hosted endpoint is open and requires no API key. If you prefer local stdio, use the same Amazon Q MCP configuration shape with "command": "npx" and "args": ["-y", "god-prompt-mcp"]; that path requires Node.js 22+. See Amazon Q Developer's MCP guide and agent configuration format for the current CLI/IDE configuration locations and scope rules.
OpenAI Codex
GodPrompt can be used in Codex as either a portable Agent Skill or a native local MCP server.
Install the standards-compatible Agent Skill directly from this repository with Codex's built-in $skill-installer:
$skill-installer install https://github.com/AKzar1el/god-prompt-mcp/tree/main/skills/god-promptOr register the published stdio server with Codex's native MCP CLI:
codex mcp add god-prompt -- npx -y god-prompt-mcpRun codex mcp list to verify the registration. The Agent Skill gives Codex the reusable workflow directly; MCP adds GodPrompt's progressive-disclosure tools. Node.js 22+ is required for the MCP server.
Gemini CLI
Install the repository as a native Gemini CLI extension to get both the portable GodPrompt Agent Skill and the MCP server in one step:
gemini extensions install https://github.com/AKzar1el/god-prompt-mcpOr register only the published local stdio server with Gemini CLI's native MCP command:
gemini mcp add --scope user god-prompt npx -- -y god-prompt-mcpThe explicit user scope keeps this direct registration out of the project's .gemini/settings.json. Run gemini extensions list to verify the extension or gemini mcp list to verify the direct MCP registration. Node.js 22+ is required for the MCP server; GodPrompt itself needs no API key.
Google Antigravity CLI
Antigravity CLI supports Agent Plugins that bundle Agent Skills and MCP servers. Install the existing GodPrompt plugin directly from GitHub:
agy plugin install https://github.com/AKzar1el/god-prompt-mcpRun agy plugin list to verify the installation. The repository's Agent Plugins 1.0 package supplies both skills/god-prompt and the pinned local stdio MCP server, so no separate skill or MCP registration is needed. Node.js 22+ is required for the MCP server.
GitHub CLI Agent Skills (preview)
GitHub CLI 2.100+ can install the same portable Agent Skill directly into supported coding agents without cloning the repository:
gh skill install AKzar1el/god-prompt-mcp skills/god-prompt --agent codex --scope userReplace codex with another supported host such as github-copilot, claude-code, or cursor. The explicit skills/god-prompt path intentionally selects the portable skill rather than another distribution-specific package in this repository.
Vercel Skills CLI
The open skills CLI can install the same portable Agent Skill into Codex, Claude Code, Cursor, and many other supported coding agents:
npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent codex --copy -yReplace codex with another supported agent when needed. The current CLI discovers the repository's portable god-prompt skill directly and installs SKILL.md plus its referenced protocol files; the MCP server remains separately available through npx -y god-prompt-mcp.
AllAgents
For a project that uses several coding agents, AllAgents can consume this repository once and synchronize GodPrompt to the selected clients. This verified example installs the portable skill for Claude Code, Codex, and Cursor while reusing the repository's bundled MCP configuration:
npx -y allagents@latest skill add AKzar1el/god-prompt-mcp --skill god-prompt --scope project --client claude,codex,cursor --yesAllAgents resolves the repository as the source of truth, copies the god-prompt skill into each selected client, and materializes the existing local MCP server configuration with the package version already pinned by this repository. Use a different supported client set when your workspace requires it; no separate GodPrompt wrapper or package is needed.
Cline
Cline SDK / Hub 0.0.83+ can load GodPrompt's existing Agent Plugins 1.0 package directly. Cline discovers user-installed plugin packages under ~/.agents/plugins/*, validates the root plugin.json, exposes valid skills/ entries, and starts valid servers from the root mcp.json without writing them into cline_mcp_settings.json.
Install the repository into Cline's user plugin directory:
mkdir -p ~/.agents/plugins
git clone --depth 1 https://github.com/AKzar1el/god-prompt-mcp ~/.agents/plugins/god-prompt-mcpOn the next settings refresh or session build, Cline can expose the god-prompt Agent Skill and launch the bundled local stdio server, whose root mcp.json pins the published GodPrompt MCP package version. Cline intentionally does not auto-scan workspace .agents/plugins directories, so merely opening a repository cannot activate repository-controlled MCP servers; SDK hosts that deliberately trust another package root can opt in through agentPluginPaths.
Amp
Amp can load GodPrompt as an Agent Skill and expose the MCP tools only when that skill is relevant. Install the portable skill with:
npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent amp --copy -yThe skill includes Amp's sibling mcp.json configuration, pinned to the current GodPrompt MCP package. Amp keeps those seven MCP tool definitions hidden until the skill loads, avoiding a permanently expanded tool context while preserving the full progressive-disclosure surface. Node.js 22+ is required for the MCP server.
Factory Droid
Factory Droid can use GodPrompt as both an Agent Skill and a local MCP server. Install the complete portable skill with the current Skills CLI target for Droid:
npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent droid --copy -yDroid discovers compatible project skills under .agents/skills/. To add the callable GodPrompt tools as a local stdio MCP server, use Droid's native MCP command with the published version pinned:
droid mcp add god-prompt "npx -y god-prompt-mcp@1.0.44"Open /mcp in Droid to verify the server and available tools. The Agent Skill supplies the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.
Warp
Warp can use GodPrompt as both an Agent Skill and a local MCP server. Install the complete portable skill into Warp with:
npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent warp --copy -yWarp discovers project skills from .agents/skills/ and .warp/skills/. For MCP tools, add a CLI-based MCP server in Warp with command npx and arguments -y, god-prompt-mcp; Warp's Oz CLI can also receive MCP configuration through oz agent run --mcp. The skill supplies the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.
Goose
Goose can use GodPrompt as both an Agent Skill and a local MCP extension. Install the complete portable skill into Goose with:
npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent goose --copy -yGoose discovers the copied skill under .goose/skills/god-prompt/. To expose GodPrompt's callable tools for a session, start Goose with the published MCP package as an external stdio extension:
goose session --with-extension "npx -y god-prompt-mcp@1.0.44"Goose currently treats Agent Skills and MCP extensions as separate native surfaces, so this path does not depend on Agent Plugins support. The skill supplies the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.
Zed
Zed can use GodPrompt as both a native Agent Skill and a local MCP context server. Install the complete portable skill, including its referenced protocol files, with:
npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent zed --copy -yFor MCP tools, open Settings → AI → MCP Servers → Add Server → Add Local Server, set the command to npx, and pass -y and god-prompt-mcp as arguments. Zed loads project skills from .agents/skills/ and can forward configured MCP servers to supported external agents. Node.js 22+ is required for the MCP server.
OpenCode
OpenCode v2 natively discovers Agent Skills from .agents/skills/ and supports local MCP servers. Install the same portable GodPrompt skill with:
npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent opencode --copy -yTo expose GodPrompt's MCP tools as well, register the published local server with OpenCode's native v2 command, then verify the connection:
opencode mcp add god-prompt -- npx -y god-prompt-mcp
opencode mcp listThe add command writes the project MCP configuration for you. If you prefer to configure it by hand, use opencode.json or opencode.jsonc:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"servers": {
"god-prompt": {
"type": "local",
"command": ["npx", "-y", "god-prompt-mcp"]
}
}
}
}OpenCode 1.x used the same server entry directly under mcp; the v2 schema shown above nests named servers under mcp.servers.
The Agent Skill provides the reusable workflow; MCP adds the seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.
TraeCode
TraeCode can use GodPrompt as both a native project skill and a project-level local MCP server. Install the complete portable skill with the current Skills CLI target for Trae:
npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent trae --copy -yThe Trae target installs the skill under .trae/skills/god-prompt/, where TraeCode can load it when the task matches its description. To expose GodPrompt's callable tools for the project as well, add .trae/mcp.json:
{
"mcpServers": {
"god-prompt": {
"command": "npx",
"args": ["-y", "god-prompt-mcp@1.0.44"]
}
}
}TraeCode also supports the portable .agents/skills/ convention when Enable .agents Skills Directory is turned on in its import settings. Treat project MCP configuration as executable workspace configuration and enable it only in repositories you trust. The Agent Skill supplies the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.
OpenClaw
OpenClaw can use GodPrompt as both a project Agent Skill and a locally registered MCP server. Install the complete portable skill with the current Skills CLI target for OpenClaw:
npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent openclaw --copy -yThe copied skill lands under .agents/skills/god-prompt/, one of OpenClaw's documented project skill roots. To expose GodPrompt's callable tools to OpenClaw-managed agent runtimes as well, register the published stdio server:
openclaw mcp add god-prompt --command npx --arg -y --arg god-prompt-mcp@1.0.44
openclaw mcp probe god-promptmcp probe opens a live MCP connection and reports the discovered capabilities, making it a direct verification step after registration. The Agent Skill supplies the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.
Qoder
Qoder can use GodPrompt as both a native project Skill and a project-level local MCP server. Install the portable skill with Qoder's supported Skills CLI target:
npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent qoder --copy -yThe Qoder target installs the skill under .qoder/skills/god-prompt/, where Qoder can load it automatically when the task matches the skill description. To expose GodPrompt's callable tools to the project as well, add .mcp.json at the project root:
{
"mcpServers": {
"god-prompt": {
"command": "npx",
"args": ["-y", "god-prompt-mcp@1.0.44"]
}
}
}Qoder requires approval before using project-level MCP servers by default. After adding or changing the server, start a new session or run /mcp reload, then use /mcp to verify the connection. The Agent Skill supplies the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.
Qwen Code
Qwen Code can use GodPrompt through both of its native extension surfaces: Agent Skills and local MCP servers. Install the complete portable skill with the current Skills CLI target for Qwen Code:
npx -y skills@latest add AKzar1el/god-prompt-mcp --skill god-prompt --agent qwen-code --copy -yThis installs GodPrompt under .qwen/skills/god-prompt/, where Qwen Code can discover and load the skill when the task matches its description. To add the callable GodPrompt tools as a project-local stdio MCP server, add this to .qwen/settings.json:
{
"mcpServers": {
"god-prompt": {
"command": "npx",
"args": ["-y", "god-prompt-mcp"]
}
}
}Restart Qwen Code after changing MCP configuration, then open /mcp to verify the server. The Agent Skill provides the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.
Kimi Code
Kimi Code CLI can install GodPrompt as one native custom plugin containing the existing Agent Skill and local MCP server. Install the current repository branch explicitly:
/plugins install https://github.com/AKzar1el/god-prompt-mcp/tree/main
/reloadThe Kimi manifest points at skills/, so the god-prompt skill remains available through Kimi's normal relevance-based skill loading instead of being forced into every session. The same manifest exposes god-prompt-mcp@1.0.44 as a local stdio MCP server, preserving the seven progressive-disclosure tools. The explicit tree/main URL matters because Kimi's bare GitHub-repository install form prefers the latest GitHub release; using main makes the current plugin manifest available without forcing a documentation-only npm/MCP Registry release. Node.js 22+ is required for the MCP server.
JetBrains AI Assistant
JetBrains AI Assistant 2026.2 can use GodPrompt through both supported agent surfaces:
Agent Skill: in Settings → Tools → AI Assistant → Skills, open Manage External Registries and add
https://github.com/AKzar1el/god-prompt-mcp. The existingskills/god-promptpackage can then be installed for supported skill-aware agents such as Codex or Claude Agent.MCP tools: in Settings → Tools → AI Assistant → Model Context Protocol (MCP), add a stdio server with command
npxand arguments-y,god-prompt-mcp. Enable Pass custom MCP servers for the coding agent that should receive GodPrompt's progressive-disclosure tools.
The Agent Skill supplies the reusable workflow; the MCP server supplies GodPrompt's callable tools. Node.js 22+ is required for the MCP server.
JetBrains Junie CLI
Junie CLI can install GodPrompt as one extension by reusing this repository's existing Claude-compatible marketplace manifest. In Junie, register the repository and install the listed extension:
/extensions marketplace add AKzar1el/god-prompt-mcp
/extensions install god-prompt-mcpJunie supports .claude-plugin/marketplace.json as a marketplace format, so no Junie-specific duplicate manifest is required. The installed extension reuses GodPrompt's existing portable Agent Skill and MCP configuration; Junie can also discover the same skill from .agents/skills/ and supports local npx MCP servers. Node.js 22+ is required for the MCP server. Junie CLI is not installed in this repository's qualification environment, so these commands are documented from JetBrains' current extension contract rather than claimed as a local end-to-end runtime smoke.
Devin Desktop / Windsurf
Devin Desktop (formerly Windsurf) and Devin CLI can load GodPrompt's existing Agent Plugins 1.0 package directly from GitHub. After signing in to Devin, install the plugin with:
devin plugins install AKzar1el/god-prompt-mcpThe plugin supplies both skills/god-prompt and the published local stdio MCP server. Run devin plugins list to verify the installation.
If you only want the portable skill, place the complete skill directory at .agents/skills/god-prompt/; Devin also discovers project skills under .devin/skills/ and .windsurf/skills/. If you only want the MCP server, register it directly:
devin mcp add god-prompt -- npx -y god-prompt-mcpRun devin mcp list to verify the direct server registration. The Agent Skill provides the reusable workflow while MCP exposes GodPrompt's seven progressive-disclosure tools. Node.js 22+ is required for the MCP server.
Cursor
The repository includes a native Cursor plugin manifest plus a portable Agent Plugins 1.0 manifest. Cursor Marketplace can use .cursor-plugin/plugin.json with cursor-mcp.json; Agent Plugins-compatible clients can use root plugin.json with mcp.json. Both launch the same local stdio server through npx -y god-prompt-mcp.
GitHub Copilot
GitHub Copilot CLI supports the portable Agent Plugins 1.0 package at the repository root. Install it through the repository marketplace:
copilot plugin marketplace add AKzar1el/god-prompt-mcp
copilot plugin install god-prompt-mcp@god-promptThe plugin includes both the GodPrompt MCP server and a standards-compatible god-prompt Agent Skill under skills/god-prompt/. Copilot can load the skill automatically when relevant or invoke it explicitly as /god-prompt, while MCP remains available for progressive-disclosure tool access.
This keeps the marketplace entry, portable plugin, skill, and MCP server in one versioned repository and works for individual, team, and cloud-agent distribution. Direct repository installs (copilot plugin install AKzar1el/god-prompt-mcp) still work in current Copilot CLI releases, but the CLI marks them deprecated in favor of plugin@marketplace installs.
GitLab Duo CLI
GitLab Duo CLI 9.15+ supports Agent Plugins and Git-backed plugin marketplaces. Register this repository once, then install the same portable plugin:
duo plugin marketplace add https://github.com/AKzar1el/god-prompt-mcp.git
duo plugin install god-prompt-mcp@god-promptThe installed plugin bundles the existing god-prompt Agent Skill and pinned local MCP server, so GitLab Duo users get both workflow guidance and callable tools from the same versioned repository.
Claude Code
The repository includes a Claude Code marketplace catalog alongside the existing plugin and MCP manifests, so users can install the same versioned plugin directly from this GitHub repository without waiting for community-directory review. In Claude Code, run:
/plugin marketplace add AKzar1el/god-prompt-mcp
/plugin install god-prompt-mcp@god-promptThe plugin bundles the portable god-prompt Agent Skill and the pinned local MCP server. The same package remains structurally ready for Anthropic's reviewed community directory without maintaining a separate implementation.
Claude Code custom-gateway troubleshooting: In Claude Code 2.1.304+ with a third-party Anthropic-compatible gateway configured through ANTHROPIC_BASE_URL, an upstream tool-discovery regression can leave subagents without Read or headless claude -p without Agent/Bash. This is a Claude Code host issue, not a GodPrompt MCP server failure. Confirm the tools actually exposed in the affected session before applying a workaround.
Affected users report that merging "ENABLE_TOOL_SEARCH": "false" into the env section of their existing Claude Code settings restores core tools. This disables deferred tool discovery and can increase context-token usage; remove the workaround after an upstream fix. No change is needed for installations that already expose the expected tools.
Claude Desktop extension
GitHub releases include a .mcpb bundle for one-click local installation in MCPB-compatible clients such as Claude Desktop. The bundle runs the same local stdio server and does not require an API key or account.
Current GitHub releases are immutable and include a release attestation. With GitHub CLI installed, verify the release and your downloaded MCPB before installing it:
gh release verify <release-tag> --repo AKzar1el/god-prompt-mcp
gh release verify-asset <release-tag> <downloaded-mcpb> --repo AKzar1el/god-prompt-mcpThe asset check verifies that the local MCPB exactly matches the file recorded in the published release attestation.
Local stdio
npm install
npm run build
node dist/stdio.jsExample client configuration:
{
"mcpServers": {
"god-prompt": {
"command": "node",
"args": ["/absolute/path/to/god-prompt-mcp/dist/stdio.js"]
}
}
}Privacy Policy
GodPrompt MCP can run either as a local stdio server or through the public Streamable HTTP Worker. Its content tools return static GodPrompt material bundled with the server, and classify_task is deterministic; neither mode calls a model or third-party content API.
Data collection and use: GodPrompt application code has no telemetry or analytics and does not request account data. Local stdio tool input stays in the local Node.js process. Hosted remote tool input is sent over HTTPS to the Cloudflare-hosted Worker so it can produce the MCP response.
Storage and retention: the MCP request handlers are stateless and have no application database or request-retention path; they do not intentionally persist tool inputs after a request completes. Hosting/provider infrastructure may process connection or request metadata under its own policies.
Third-party sharing: local stdio does not transmit tool inputs or bundled GodPrompt content to an external API. The hosted remote necessarily passes the request through Cloudflare infrastructure, but GodPrompt application code does not forward tool inputs to another API or service. The MCP host or AI client may process conversation and tool data under its own policies independently of this server.
Contact and policy: see tomiseregi.si/privacy for the current privacy policy and contact information. For support or bug reports, use GitHub Issues.
Development
npm install
npm run build
npm testnpm test builds the stdio server, performs the MCP initialization handshake, and verifies the expected tool list.
Repository discovery metadata is kept in server.json for MCP Registry-compatible consumers and glama.json for Glama.
Updating Content
To update the embedded GodPrompt content:
Pull the latest content from the GodPrompt repository.
Run
npm run generate-content.Run
npm testbefore publishing a new server release.
The generator reads the current source layout: GodPrompt.md, SKILL.md, and the three files under references/.
License
Project & related MCP servers
Project page: GodPrompt — AI software-development system prompt · GodPrompt source
Related MCP servers: Google Search Console · GEO Tracker · Web Validator · Google News & Trends
Available Tools
7 toolsclassify_taskClassify software-development taskARead-onlyIdempotentInspect
Classify one concrete software-development task into one of GodPrompt's 9 task types (BUILD, DEBUG, REFACTOR, CONTENT, DESIGN, SHIP, ANALYZE, AUTOMATE, PLAN), or UNCLASSIFIED when no reliable route is detected. Returns JSON with task_type, deterministic confidence, protocol, matched_signals, alternative_task_types, ambiguous, and recommendation; use it for routing before loading detailed workflow text.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | The task description to classify, e.g. 'fix the login bug' or 'build a REST API for user auth' |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive hints, so the description's job is to add context. It does so by listing the exact return JSON fields (task_type, deterministic confidence, protocol, matched_signals, alternative_task_types, ambiguous, recommendation), noting that confidence is deterministic, and describing the UNCLASSIFIED fallback when no reliable route is detected. This adds meaningful behavioral transparency beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero redundancy. The verb and resource are front-loaded, the output contract is complete, and the usage guidance is placed at the end as a natural conclusion. Every sentence earns its place; nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter classifier with no output schema, the description is fully complete. It enumerates the classification types, the fallback, and all return fields, and it tells the agent exactly when to invoke it (routing before loading workflow text). An agent has everything needed to call this tool correctly without further research.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description and examples, so the baseline is 3. The description adds a subtle but useful nuance by specifying that the input should be 'one concrete' task, which rules out abstract or multi-part descriptions. This is more than pure repetition of the schema and helps the agent choose appropriate input formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool classifies a software-development task into one of nine enumerated types (BUILD, DEBUG, etc.) or UNCLASSIFIED. The specific verb 'classify' plus the named resource and the explicit output categories distinguish it from sibling getter tools like get_anti_patterns and get_god_prompt, which retrieve data rather than classify. This is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'use it for routing before loading detailed workflow text.' This tells the agent when to call this tool in a workflow. It does not explicitly name alternatives or state when not to use it, but the sibling tools are all getters with distinct purposes, so there is no real overlapping scenario. The guidance is clear but lacks an explicit 'when-not' clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_anti_patternsGet GodPrompt anti-patternsARead-onlyIdempotentInspect
Returns references/03-ANTI-PATTERNS.md — red flags, rationalizations, and recovery patterns. Covers the 10 most dangerous anti-patterns that lead to broken code, scope creep, and false confidence. Load when you catch yourself rationalizing. ~9KB.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and a non-destructive profile, so the description only needs to add behavioral context. It adds the exact source path, the approximate size (~9KB), and the kind of content returned, which gives the agent useful expectations beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no wasted words. The most important information (what is returned and from where) is front-loaded, and the usage cue and file size each earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only reference tool with no output schema, the description is complete: it names the file, summarizes its contents, gives a usage trigger, and even notes the file size. Nothing an agent needs to decide whether to call it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there is no parameter burden for the description to carry. The baseline of 4 applies because the description cannot add parameter-level meaning where no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns') and a precise resource ('references/03-ANTI-PATTERNS.md'), then clarifies content with concrete examples: red flags, rationalizations, and recovery patterns. It is clearly distinct from sibling tools like get_god_prompt or get_core_skill because it names the anti-pattern file and its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger condition: 'Load when you catch yourself rationalizing.' This tells the agent when the tool is appropriate, but it does not name when not to use it or compare it to sibling alternatives, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_core_skillGet core GodPrompt skillARead-onlyIdempotentInspect
Returns SKILL.md — the lean core protocol (~32KB) covering the universal 6-phase protocol, Three Iron Laws, and task auto-classification. Load it at the start of a task or after a context reset, then reuse that context instead of reloading it on every message. Start here for progressive disclosure.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuine value beyond them — the ~32KB size hint (token cost) and the instruction to reuse loaded context rather than reloading. It says nothing about rate limits, error behavior, or versioning, but those are secondary for a static-document read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all load-bearing: the first defines the payload and its contents, the second gives the load/reuse policy, the third establishes the progressive-disclosure entry point. The returning-payload information is front-loaded before the operational advice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the burden of describing the return value — and it does, naming the file and its major sections plus approximate size. Combined with the caching guidance, an agent has enough to call it correctly; only the ordering relative to specific sibling documents remains implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. Schema coverage is 100% and required count is 0, confirming no parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource ('Returns SKILL.md') and enumerates its contents — the 6-phase protocol, Three Iron Laws, auto-classification — so the agent knows exactly what payload arrives. It signals entry-point status via 'Start here for progressive disclosure,' which differentiates it from siblings like get_protocols or get_gates, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear timing guidance ('at the start of a task or after a context reset') and an explicit do-not-reload rule, which is actionable. It lacks explicit exclusions or named alternatives ('use get_gates when you need X'), leaving the agent to infer the ordering among the other get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_gatesGet GodPrompt verification gatesARead-onlyIdempotentInspect
Returns references/02-GATES.md — verification checklists, THE GATE (pre-completion verification), and structured report templates for every deliverable type. Load when you need to verify work before claiming completion. ~9KB.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is read-only, idempotent, and non-destructiveikuha. The description adds meaningful context about the returned file's contents and its size (~9KB), which goes beyond what annotations alone convey. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences front-load the core return value and follow with a practical usage trigger and size estimate. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent tool with no output schema, the description fully covers what an agent needs to know to invoke it correctly and understand what to expect. The annotations handle safety, and the description handles content and purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters)Skip, so there is no parameter schema to supplement. The description appropriately focuses on what the tool returns rather than any parameter details, matching the baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Returns') and a specific resource (references/02-GATES.md), and further describes what it contains: verification checklists, THE GATE, and structured report templates. This is distinct from sibling tools like get_protocols or get_anti_patterns, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance on when to use it: 'Load when you need to verify work before claiming completion.' It does not explicitly name excluded alternatives, but the context is clear enough for selection among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_god_promptGet full GodPromptARead-onlyIdempotentInspect
Returns the complete GodPrompt.md — a single-file universal system prompt for AI software development (63KB, ~1145 lines). Use this when you want the full payload in one shot. For progressive disclosure (smaller context), use get_core_skill and the reference tools instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered. The description adds the detail annotations cannot convey: the payload is large (63KB, ~1145 lines), which is exactly the context-cost signal an agent needs before pulling it. It stops short of saying what file/content type comes back, but the cost disclosure is the substantive addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The identity and size come first, the routing advice second, which is the right order for an agent deciding whether to invoke.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param getter with no output schema, the description covers identity, magnitude and alternatives — enough to call it correctly. A small residual gap is that it doesn't confirm the return is raw markdown text versus a file reference, though this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is nothing to disambiguate and the baseline applies. The description correctly spends no words on inputs and instead invests them in payload size and alternative tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (returns) and resource (the complete GodPrompt.md), and characterizes it as a single-file universal system prompt with concrete size (63KB, ~1145 lines). It also names the scenario in which a caller would want it, which separates it from the smaller-skill siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when you want the full payload in one shot" gives the selecting condition, and "For progressive disclosure (smaller context), use get_core_skill and the reference tools instead" names the alternatives and their trade-off. Both the when and the when-not are explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_protocolsGet GodPrompt protocolsARead-onlyIdempotentInspect
Returns references/01-PROTOCOLS.md — deep execution guides for each task type (BUILD, DEBUG, REFACTOR, CONTENT, DESIGN, SHIP, ANALYZE, AUTOMATE, PLAN). Load this when the task requires detailed protocol steps beyond the core skill. ~13KB.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld false, idempotent, and non-destructive, so less is required from the description. The description adds meaningful context by identifying the returned file, its purpose, task coverage, and approximate size (~13KB), going beyond what the schema or annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the resource being returned, and every sentence contributes: return target, content scope, trigger condition, and size. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent retrieval tool, this description is complete: an agent knows what it returns, when to use it, and what content to expect. The sibling context and annotations cover the remaining selection cues.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema description coverage is 100%, so the description has no parameter burden. It still clarifies that the returned artifact is a protocol reference and which task types it covers, which is the only relevant context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns references/01-PROTOCOLS.md — deep execution guides for each task type'. It unpacks the document's scope by enumerating the task types and frames it as distinct from the core skill, so an agent can tell it apart from sibling retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit when-to-use cue: 'Load this when the task requires detailed protocol steps beyond the core skill.' It does not explicitly name exclusionary alternatives like get_gates or get_anti_patterns, but the guidance is clear enough for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_versionGet GodPrompt versionsARead-onlyIdempotentInspect
Returns JSON with the GodPrompt content version, MCP server version, repository, bundled file sizes and purposes, and task-type/protocol catalog. Use it to verify which GodPrompt content/server version a client is connected to; use the content retrieval tools when you need the actual workflow text.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by specifying the JSON return format and the categories of information it contains. No contradictions; it simply could not mention potential caching or latency behavior, which is minor for a no-parameter version probe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the full output shape, and the second sentence provides usage routing. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description explicitly enumerates the major payload components and gives usage context. For a simple, no-parameter metadata tool, no critical information needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is vacuously 100% and the description does not need to explain parameter semantics. This is the baseline case for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Returns JSON with the GodPrompt content version, MCP server version, repository, bundled file sizes...') and enumerates exactly what the tool provides. This makes it clearly distinguishable from siblings like get_god_prompt and get_protocols, which return actual workflow content rather than metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'to verify which GodPrompt content/server version a client is connected to.' It also tells the agent when not to use it by directing it to 'the content retrieval tools' when actual workflow text is needed, effectively naming the alternative category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.22- Changed
classify_task3 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / description / patternAdded value: +"[\\p{L}\\p{N}]"
6 tool updates
v1.0.4- Changed
get_anti_patterns1 field changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"
- Changed
get_core_skill1 field changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"
- Changed
get_gates1 field changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"
- Changed
get_god_prompt1 field changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"
- Changed
get_protocols1 field changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"
- Changed
get_version1 field changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"
7 tool updates
v1.0.0- First observed
classify_task - First observed
get_anti_patterns - First observed
get_core_skill - First observed
get_gates - First observed
get_god_prompt - First observed
get_protocols - First observed
get_version
TDQS
Scored across 7 tools
Each tool targets a clearly distinct artifact or operation: full prompt, core skill, anti-patterns, gates, protocols, task classification, and version metadata. The only apparent overlap—get_god_prompt versus progressive-disclosure tools—is explicitly distinguished by payload size and intended use.
All names use a consistent verb_noun snake_case convention: get_god_prompt, get_core_skill, get_anti_patterns, get_gates, get_protocols, get_version, and classify_task. The classify_task deviation is still a clear verb_noun pattern and matches its operation.
Seven tools are well scoped for a progressive-disclosure prompt-content server. Each tool earns its place by covering a distinct file or routing/metadata function without overwhelming the caller.
The surface covers the full payload, lean core skill, all referenced operational documents, task classification, and version/catalog metadata. An agent can start lean, route tasks, load detailed guidance, verify work, and recover from anti-patterns without obvious dead ends.
Maintenance
Related MCP Connectors
Generate contextual prompts and reusable agent skills, evaluate prompts with the 16-dimension Prompt Score, and manage saved work in PromptDrive. Twelve MCP tools also provide authorized access to private Memory for source-grounded answers. Connect over Streamable HTTP using OAuth 2.1 and PKCE. Generation consumes account quota and automatically saves successful results; Memory access follows account permissions and plan limits.
Contextual prompts and agent skills for 140+ AI platforms.
Your prompt library inside your AI: 1,000+ pro templates, frameworks, vocab & pipelines.
Your prompt library in any MCP client: list, fetch, save and version prompt templates.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceProvides AI-powered selection and generation of specialized system prompts from a database of over 66 templates for Claude Code. It uses semantic search to find the best matching template and can adapt it to fit specific user tasks and contexts.-
- AlicenseAqualityDmaintenanceAutomatically generates and manages a prompts system for software projects, enabling persistent context for AI coding assistants through project scanning, requirement clarification, and module tracking.85 npmMIT
- AlicenseAqualityAmaintenanceAI visibility tracker MCP server. Track brand citations across ChatGPT, Claude, Perplexity, Gemini & Google AI Overviews. Self-host on Cloudflare Workers. GEO/AEO.121,817 npm39MIT
- AlicenseAqualityDmaintenanceProvides specialist context for AI agents, enabling them to work as different roles (UI, DE, SRE, etc.) through MCP prompts and tools.710 npm1MIT