GodPrompt MCP Server

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.

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.

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.

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.

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.

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.

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.