thinkhard.si prompt tools

Get a prompt template

get_prompt

Read-onlyIdempotent

Get the full text of one prompt from the thinkhard.si repository by its slug, registry number (such as CAR-001) or exact title, with its {{blanks}}, what goes in each, and why it works. If the name does not match exactly, it answers with the closest matches instead. Pass values to fill blanks with the user's details; blanks left without a value are listed in open_blanks.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>"
    },
    "name": "get_prompt"
  }
}

Input Schema

Name	Required	Description	Default
`prompt`	Yes	The slug, registry number or exact title from search_prompts.
`values`	No	Optional: blank name → the user's text, for example {"job_posting": "..."}.

Output Schema

Name	Required	Description
`id`	Yes	Registry number.
`url`	Yes
`slug`	Yes
`title`	Yes
`prompt`	Yes	The user message, with the given values filled in.
`system`	Yes	The system prompt, with the given values filled in. Empty when the template has none.
`open_blanks`	Yes	Blanks still to fill, for the user to supply.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

changedOutput schema / properties / open_blanks / description

Previous value: -"Blanks still to fill. Ask the user for these."New value: +"Blanks still to fill, for the user to supply."

Changed2 schema fields changedOct 23, 2026

changedInput schema / properties / prompt / description

Previous value: -"The slug, registry number or title from search_prompts."New value: +"The slug, registry number or exact title from search_prompts."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "id": {
+      "description": "Registry number.",
+      "type": "string"
+    },
+    "open_blanks": {
+      "description": "Blanks still to fill. Ask the user for these.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "prompt": {
+      "description": "The user message, with the given values filled in.",
+      "type": "string"
+    },
+    "slug": {
+      "type": "string"
+    },
+    "system": {
+      "description": "The system prompt, with the given values filled in. Empty when the template has none.",
+      "type": "string"
+    },
+    "title": {
+      "type": "string"
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "slug",
+    "title",
+    "system",
+    "prompt",
+    "open_blanks",
+    "url"
+  ],
+  "type": "object"
+}

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the description adds the non-obvious parts: fuzzy fallback on non-exact names, and that unfilled blanks surface in open_blanks. It does not mention what happens when a supplied values key matches no blank, or any failure/limit behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with what is retrieved and how it is identified, then the fallback behavior, then the values convention. No filler; each sentence carries distinct information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return format need not be explained, and the description still covers identification forms, fallback matching, and blank filling. The one gap is the true no-match case, which 'answers with the closest matches instead' leaves ambiguous for a tool whose whole job is exact lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description goes slightly beyond by restating that prompt accepts slug/registry number/title and by explaining the consequence of values (unprovided blanks are reported in open_blanks). It does not clarify whether extra keys in the values object are tolerated or how nested values are validated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (get the full text of one prompt) plus the exact identifier forms accepted (slug, registry number like CAR-001, exact title) and what comes back (the text with its {{blanks}}, what goes in each, why it works). This clearly separates a single-record retrieval from the sibling search_prompts lookup-by-query tool referenced in the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The invocation context is clear: you come here once you have an exact identifier, and the schema ties it back to search_prompts for discovery. It also explains the mismatch path (closest matches returned instead of an error). It stops short of naming explicit exclusions, e.g. when to prefer get_prompt_pattern or to fall back to search_prompts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All thinkhard.si prompt tools tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?