GodPrompt MCP Server
This server provides read-only GodPrompt workflow guidance, task routing, and verification material for AI software-development agents over MCP.
get_god_prompt— retrieve the complete GodPrompt.md single-file system prompt (~47KB).get_core_skill— load the lean SKILL.md core protocol to start with minimal context.get_protocols— fetch deep execution guides for all 9 GodPrompt task types.get_gates— get verification checklists and pre-completion gate templates.get_anti_patterns— access red flags and recovery patterns for common agent failures.classify_task— deterministically route a task to one of 9 task types or UNCLASSIFIED with confidence and matched signals.get_version— verify content/server version, bundled file sizes, and catalog metadata.Runs locally via stdio or as a hosted remote endpoint without an API key.
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.
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.33"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.33"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.33"]
}
}
}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.33
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.33"]
}
}
}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.33 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 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 (~16KB) 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description need not repeat that. It adds useful behavioral context beyond the schema: approximate response size (~16KB), that it is a lean protocol rather than the full prompt, and that its content is reusable across a context. No contradiction with 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 compact and front-loaded: the first sentence states exactly what is returned, the second gives actionable usage guidance, and the final phrase reinforces its role as the entry point. Every sentence contributes meaning without fluff.
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 tool with no output schema, the description is complete: it identifies the return value (SKILL.md), its size and contents, when to call it, and how to handle the returned context. An agent has everything needed to invoke it correctly.
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 trivially 100% and the description has no parameter burden. The baseline of 4 applies because the description instead clarifies what the returned resource contains and how to use it.
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 names a specific deliverable, 'SKILL.md', and states its contents: the universal 6-phase protocol, Three Iron Laws, and task auto-classification. It also positions it as 'the lean core protocol' and 'Start here', distinguishing it from siblings like get_god_prompt or get_protocols without needing to open their schemas.
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 timing cues: 'Load it at the start of a task or after a context reset'. It also tells the agent what not to do — reload it on every message — and directs agents to 'Start here for progressive disclosure', which effectively makes it the entry point among sibling 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 (47KB, ~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 readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavioral context by disclosing the large payload size (47KB, ~1145 lines) and that it returns the full single-file content in one shot. This helps the agent anticipate context usage, going beyond the structured 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?
Three concise sentences: the first front-loads the primary action and payload description, the second states the primary use case, and the third names the alternative for different needs. Every sentence earns its place with zero 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 tool with no output schema, the description provides everything an agent needs: what the tool returns, the size, and when to use it versus alternatives. The annotations cover the operational safety profile. Nothing essential 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 the schema is trivially complete. The baseline for 0 parameters is 4, and the description appropriately avoids inventing parameter details. No compensation needed.
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 the complete GodPrompt.md', and further identifies it as a single-file universal system prompt. It differentiates itself from siblings by naming get_core_skill and reference tools as alternatives for progressive disclosure. An agent can immediately understand what this tool provides and how it differs from its 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?
The description explicitly states when to use this tool ('when you want the full payload in one shot') and when not to ('For progressive disclosure (smaller context)'), naming the alternative tools. This is clear, actionable guidance with no ambiguity.
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 maps to a clearly distinct file or action: full prompt, core skill, individual reference docs, task classification, and version metadata. The descriptions explicitly prescribe when to use each (e.g., full file vs progressive disclosure), so an agent would rarely misselect. Even the overlapping full-prompt and core-skill tools are disambiguated by context size and start-here guidance.
All tools follow a consistent snake_case verb_noun pattern: get_* for content retrieval and metadata, plus classify_task for the single classification action. There are no stylistic clashes or vague names, and the function of each tool is predictable from its name alone.
Seven tools is well within the ideal range for a focused content-delivery and classification server. Each tool covers a distinct artifact or action—full prompt, core skill, three reference files, classification, and version check—and none feels redundant. The count is appropriate for the server's narrow purpose.
The set covers the complete documented workflow: core protocol loading, task-type classification, deeper per-type protocols, anti-patterns, gates/checklists, and version verification. Since this is a read-only content server, no CRUD operations are expected. It exposes every referenced file plus a classifier, leaving no 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.
Self-hosted AI prompt library: prompts, collections, tags, teams, chains. 29 MCP tools for agents.
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.822 npmMIT
- AlicenseAqualityAmaintenanceAI visibility tracker MCP server. Track brand citations across ChatGPT, Claude, Perplexity, Gemini & Google AI Overviews. Self-host on Cloudflare Workers. GEO/AEO.12807 npm46MIT
- AlicenseAqualityBmaintenanceProvides specialist context for AI agents, enabling them to work as different roles (UI, DE, SRE, etc.) through MCP prompts and tools.79 npm1MIT