GodPrompt workflows for TDD, debugging, verification, task routing, and progressive disclosure.
Scored across 7 tools
Each tool targets a distinct piece of content or action: classify_task performs routing while all get_* tools return specific reference documents. The descriptions clearly differentiate between the lean core skill, full prompt, protocols, anti-patterns, gates, and version info, so an agent is unlikely to confuse them.
Tool names follow a consistent verb_noun pattern with snake_case: classify_task for the classification action and get_* for every retrieval tool. This uniformity makes the tool surface predictable and easy to navigate.
Seven tools is well-scoped for a server that serves a reference/prompt library. Each tool covers a distinct aspect of the GodPrompt system—classification, core skill, protocols, anti-patterns, gates, full prompt, and version—with no redundancy or bloat.
The tool surface fully covers the expected operations for this domain: classify a task, retrieve the core protocol, get deep per-task-type guides, access anti-pattern warnings, retrieve verification gates, obtain the full prompt, and check versions. No obvious gaps exist for the server's stated purpose of providing progressive disclosure of a development protocol.
Classify a task description 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. Confidence is deterministic routing confidence, not a statistical probability.
| 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' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable nuance by clarifying that confidence is deterministic routing confidence (not statistical) and that UNCLASSIFIED is returned when no reliable route is detected, which goes beyond the annotation hints.
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 wasted words. The primary action and categories are front-loaded, and the confidence nuance is placed at the end for clarity. Perfectly sized for the information conveyed.
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 classification tool with annotations covering safety, the description is nearly complete. It enumerates output categories and explains confidence semantics, but it does not explicitly define the return structure (e.g., does it return just a string or an object with type and confidence?). Given no output schema, this small gap leaves some ambiguity.
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 schema description for the 'description' parameter is complete (100% coverage) and includes examples. The tool description only reuses 'task description' without adding new semantic meaning, so it meets the baseline but adds no extra value.
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 ('Classify') and a precise resource ('task description'), enumerates all nine task types plus the UNCLASSIFIED fallback. It clearly distinguishes this tool from the sibling 'get_*' tools by its classification 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 implies usage for classifying task descriptions, and the sibling names are all 'get_*' retrieval tools, making the differentiator obvious. However, it does not explicitly state when not to use this tool or how it relates to the alternatives, leaving no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | |||
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.
Returns SKILL.md — the lean core protocol (~11KB) 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent behavior. The description adds value by specifying the ~11KB size, the content scope, and the recommended usage pattern (load once, reuse). 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?
Two sentences, no fluff. The first sentence states the resource and content, the second gives usage guidance. Well front-loaded and efficient.
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, no-output-schema tool with safety annotations, the description fully explains what it returns, when to use it, and how to manage context. Nothing missing for an agent to call 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 the baseline is 4. The description appropriately doesn't attempt to explain parameters that don't 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 clearly states the tool returns SKILL.md, a specific resource, and enumerates its contents (6-phase protocol, Three Iron Laws, auto-classification). It positions it as the 'lean core protocol' and says 'Start here,' distinguishing it from siblings like get_protocols or get_gates.
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 when-to-use guidance: load at start of task or after context reset, and reuse context rather than reloading. It also says 'Start here for progressive disclosure,' implying it's the entry point. It doesn't name specific alternatives but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | |||
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.
Returns the complete GodPrompt.md — a single-file universal system prompt for AI software development (42KB, ~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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the payload size (42KB, ~1145 lines), which is useful context for context-window management. However, it doesn't describe the return format or whether the content is returned as a single string or file attachment, which would be useful behavioral detail.
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 with no waste. The core purpose is front-loaded, the payload size is given as a concrete detail, and the alternative routing is stated in the final sentence. Every sentence earns its 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 zero-parameter read-only tool, the description is nearly complete. It states what is returned, the size, and when to use it versus alternatives. The only minor gap is the exact return format (e.g., raw markdown string vs. structured wrapper), but with no output schema and no parameters, the description covers the essential decision-making context.
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 there is no parameter semantics burden on the description. The schema coverage is 100% (vacuously, since there are no properties). The description correctly focuses on what the tool returns rather than parameters. Baseline 4 for zero-param tools is appropriate.
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 the tool returns the complete GodPrompt.md, a single-file universal system prompt for AI software development, and specifies its size (42KB, ~1145 lines). This is a specific verb-resource pair that distinguishes it from sibling tools like get_core_skill or get_gates.
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 says to use this tool when you want the full payload in one shot, and names the alternative approach (get_core_skill and reference tools) for progressive disclosure with smaller context. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | |||
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.
Returns GodPrompt content and MCP server versions with a summary of what's included.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds the detail that a summary of what's included is returned, which is useful context beyond annotations. However, it does not describe the return structure or any limitations, which is acceptable given the simple nature of the tool.
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 a single concise sentence, front-loaded with the action and resource, and contains no filler or redundant phrasing. It is appropriately short for a zero-parameter tool.
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 tool with no parameters and no output schema, the description is minimal but adequate. It identifies the resource (versions) and the summary aspect. However, it could clarify what 'GodPrompt content' refers to, and there is no mention of how versions are presented (e.g., plain text, JSON). Given the simplicity, it is reasonably complete but not exhaustive.
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 fully covers parameter documentation. The baseline for zero parameters is 4, and the description correctly does not attempt to explain parameters since there are none. It adds no parameter-specific meaning, which is appropriate.
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 resource ('GodPrompt content and MCP server versions') and clearly differentiates from sibling getter tools by focusing on version information. The title 'Get GodPrompt versions' reinforces this, making the purpose 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 provides no guidance on when to use this tool versus the sibling getter tools (e.g., get_god_prompt, get_protocols). It does not state conditions, exclusions, or alternatives, leaving the agent to infer that this is for version checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
classify_taskget_anti_patternsget_core_skillget_gatesget_god_promptget_protocolsget_versionAdaptive plan/build/review cycles for AI coding assistants, persisted across sessions.
AI-powered spec-to-task decomposition and execution orchestration for coding agents.
Shared debugging memory for AI coding agents
Goal and task planning MCP for Codex and AI agents, with evidence-backed completion.
Add one secure layer between your agents and this server.
