GodPrompt MCP + Agent Skill for coding agents with TDD, debugging, verification, and task routing.
Scored across 7 tools
Each tool has a distinct role: classification, version introspection, and retrieval of specific content files. The only real overlap is get_god_prompt vs get_core_skill/get_protocols, but the descriptions clearly frame them as full-payload vs progressive-disclosure paths, so an agent can choose correctly.
Six of seven tools follow a clean get_<resource> pattern. classify_task is a verb_noun deviation but is still readable and semantically appropriate for its action-oriented behavior.
Seven tools is well-scoped for a prompt-content server with progressive disclosure. Each tool maps to a distinct bundled artifact or a routing/version utility, and no tool feels redundant.
The surface covers the full lifecycle: classification, core skill, deep protocols, verification gates, anti-patterns, full one-shot payload, and version/catalog introspection. Minor gap: no way to search or list individual reference files beyond what get_version reports, but core workflows are fully served.
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' |
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.
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 (~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 | |||
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.
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 (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 | |||
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.
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 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 | |||
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.
LLM Orchestration Agent (Mcp)
LLM Orchestration MCP Agent
MCP-Native LLM Orchestration Agent
Goal and task planning MCP for Codex and AI agents, with evidence-backed completion.
Add one secure layer between your agents and this server.
