Skip to main content
Glama

thinkhard.si prompt tools

by si.thinkhard
OverviewDiscussionsAdmin

Server Details

Search 300+ expert prompt templates for work, grade a prompt out of 10, and price AI models.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct role: search for prompts, retrieve one by slug/title, list collections, grade a prompt, and estimate model cost. The only plausible overlap is search_prompts vs list_collections, but one finds by task while the other browses collection metadata, so an agent can easily choose correctly.

Naming Consistency5/5

All tool names use a consistent snake_case verb_noun pattern: estimate_ai_cost, get_prompt, grade_prompt, list_collections, search_prompts. There are no mixed casing styles or vague standalone verbs.

Tool Count5/5

Five tools is well-scoped for a prompt repository utility: search, retrieve, browse, evaluate, and cost-estimate. Each tool has a clear purpose and none feels redundant or missing for the stated scope.

Completeness4/5

The core read/use workflow is covered: discover prompts, retrieve their text and blanks, grade quality, and estimate cost. Minor gaps remain around saving/creating custom prompts or a dedicated prompt-improvement operation, but agents can work around these with the existing tools.

Available Tools

5 tools
estimate_ai_costEstimate what an AI feature costsA
Read-onlyIdempotent
Inspect

Estimate the monthly cost of running a prompt on current AI models (Claude, GPT, Gemini, DeepSeek, Qwen and others), from thinkhard.si's price catalog, which is checked against each provider's pricing page. Give token counts, or paste the prompt text to estimate them.

NameRequiredDescriptionDefault
modelsNoOptional: model names or ids to include, such as "Claude Sonnet 5.5". Default: every current model.
prompt_textNoOptional: the prompt, to estimate input tokens (about 4 characters a token).
input_tokensNoInput tokens per call. Omit to estimate from prompt_text.
output_tokensNoOutput tokens per call.
calls_per_monthNo

Output Schema

NameRequiredDescription
modelsYesCheapest first.
checkedYesWhen the prices were last checked against each provider.
input_tokensYes
output_tokensYes
calls_per_monthYes

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description still earns credit for disclosing data provenance and freshness posture — a curated catalog verified against each provider's pricing page — which tells the agent how much to trust the numbers. It does not state currency, whether prices are per-1M tokens, or that results are approximations that drift as pricing changes.

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?

Two sentences with zero waste: the first delivers purpose, model coverage, and data source; the second delivers the input-mode rule. Purpose is front-loaded before caveats, and every clause carries information.

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?

An output schema exists, so return-value shape need not be explained, and the description covers model scope, input flexibility, and data provenance for a zero-required-parameter tool. The gap is the cost basis — currency, per-token vs. per-1M normalization, and whether the result assumes uniform calls_per_month — which an agent may need to present results correctly.

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

Parameters3/5

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

Schema description coverage is 80%, so the schema already documents models, prompt_text, input_tokens, output_tokens, and calls_per_month in detail. The description's "give token counts, or paste the prompt text" restates the prompt_text/input_tokens relationship the schema already spells out ("Omit to estimate from prompt_text"). It adds nothing about calls_per_month or the default 500 output tokens, so the baseline 3 applies.

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?

The description names a specific verb (estimate), the resource (monthly cost of running a prompt), and the scope (current models across Claude, GPT, Gemini, DeepSeek, Qwen, and others). The data source (thinkhard.si's catalog, cross-checked against provider pricing pages) further anchors it, and nothing about it overlaps with get_prompt, grade_prompt, list_collections, or search_prompts.

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?

"Give token counts, or paste the prompt text to estimate them" tells the agent the two valid input modes and when to prefer each, which is exactly the decision an agent faces. It stops short of naming exclusions or stating that this is an estimate-only tool with no live billing lookup, so it is clear context rather than fully explicit routing.

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

get_promptGet a prompt templateA
Read-onlyIdempotent
Inspect

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. Ask the user for any blank you cannot fill from the conversation instead of inventing it.

NameRequiredDescriptionDefault
promptYesThe slug, registry number or exact title from search_prompts.
valuesNoOptional: blank name → the user's text, for example {"job_posting": "..."}.

Output Schema

NameRequiredDescription
idYesRegistry number.
urlYes
slugYes
titleYes
promptYesThe user message, with the given values filled in.
systemYesThe system prompt, with the given values filled in. Empty when the template has none.
open_blanksYesBlanks still to fill. Ask the user for these.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare a safe, idempotent, closed-world read, so the bar is lower; the description still adds real behavior: the response includes blanks, what goes in each, and why the prompt works, and a non-matching lookup returns nearest matches instead of failing. The one gap is that it does not say what an empty match set looks like.

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 tight sentences, front-loaded with the retrieval action, then the identifier options and fallback, then the blank-filling rule. No redundant restatement of schema or annotations.

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

Completeness5/5

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

Covers retrieval key formats, near-miss behavior, the blank-filling contract, and the anti-hallucination instruction, which is everything needed to call it correctly. An output schema exists, so return-value structure need not be described.

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, but the description clarifies that `prompt` accepts a slug, registry number, or exact title, and that `values` are the user's details used to fill the {{blanks}}. It also adds the important constraint that unfulfillable blanks should be asked about, not fabricated.

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 distinct lookup keys (slug, registry number like CAR-001, exact title). It is clearly differentiated from the sibling search_prompts, which returns multiple results, while this returns a single prompt with its blanks and rationale.

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?

Explains the three acceptable identifiers, the near-miss fallback ("answers with the closest matches instead"), and instructs the agent to ask the user rather than invent blank values. It does not explicitly name search_prompts as the prerequisite discovery step in the description itself, leaving that to the schema text.

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

grade_promptGrade a prompt out of 10A
Read-onlyIdempotent
Inspect

Score a prompt out of 10 on the ten checks thinkhard.si uses (what to make, who it is for, background facts, length, format, what to avoid, what good looks like, an example, what to do if unsure, layout for the model). Returns which checks pass and a plain question for each one that fails. Rule-based and instant; use it to see what a prompt is missing before improving it.

NameRequiredDescriptionDefault
promptYesThe prompt to grade (the user message).
systemNoOptional system prompt, graded together with the prompt.
targetNoThe model it is for. Layout is judged for this model.any

Output Schema

NameRequiredDescription
bandYesThe score in a word.
scoreYesOut of 10.
checksYesThe ten checks, in order.
targetYesThe model it was read for.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond annotations by noting it is rule-based and instant, and by describing that failures come back as plain questions.

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?

The description is front-loaded with the core action and stays compact. The parenthetical list of checks is long but directly relevant to understanding what the score means.

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

Completeness5/5

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

With an output schema present and full parameter descriptions, the description does not need to explain return values in detail. It covers purpose, usage context, speed, and failure behavior, leaving no major gap for an agent calling this tool.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters are already documented in the input schema. The description does not add parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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?

The description states a specific verb and resource: it scores a prompt out of 10 against ten named checks. It also explains the result shape (pass/fail plus failure questions), so the tool is immediately distinguishable from siblings like get_prompt or search_prompts.

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?

It gives clear guidance on when to use it: before improving a prompt, to see what is missing. It does not explicitly state when not to use it or name alternatives, but the intended context is unambiguous.

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

list_collectionsList the prompt collectionsA
Read-onlyIdempotent
Inspect

List the collections in the thinkhard.si prompt repository, with how many prompts each has.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
collectionsYes

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that each collection reports a prompt count; it says nothing about ordering, pagination, or empty-repository 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?

One sentence, front-loaded with the action and the resource, with the return detail appended. No filler or redundancy.

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?

For a zero-parameter read tool with full annotation coverage and an output schema, the description covers what is needed to invoke it correctly. Only the routing rationale relative to sibling tools is missing.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies no filtering or input is accepted.

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

Purpose4/5

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

States a specific verb ('List') and resource ('collections in the thinkhard.si prompt repository') plus the payload each entry carries ('how many prompts each has'). It is clearly a different resource from the prompt-level siblings, though it never names or contrasts them explicitly.

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

Usage Guidelines3/5

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

Usage is only implied: an agent can infer this is the discovery step before get_prompt/search_prompts, but the description never says when to use it versus those siblings or what to do next with the result.

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

search_promptsSearch the prompt repositoryA
Read-onlyIdempotent
Inspect

Find ready-made, expert prompt templates for a work task in the thinkhard.si repository (300+ prompts for email, meetings, presentations, job search, marketing, sales, support, HR, finance, legal, spreadsheets, research and more). Use it whenever the user wants to write, plan, summarize, analyze or draft something at work, before writing a prompt from scratch. Then call get_prompt with the slug.

NameRequiredDescriptionDefault
limitNo
modelNoOptional: only prompts laid out for this kind of model.
queryYesWhat the user wants to do, in plain words, for example "cover letter" or "summarize a long contract".
collectionNoOptional: limit to one collection (see list_collections).

Output Schema

NameRequiredDescription
promptsYesBest match first. Empty when nothing matches.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real behavioral context beyond that: this is a curated repository of 300+ prompts and it is a search step in a two-call workflow whose output feeds get_prompt. It omits anything about result limits or ranking, which keeps it below 5.

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

Conciseness4/5

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

The core action and its scope are front-loaded, and the workflow instruction comes last where it belongs. The long parenthetical domain list is helpful for matching but costs some density.

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

Completeness5/5

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

An output schema exists, so return values need no explanation. The description supplies the missing workflow context (what populates the results, and that get_prompt should be called with the returned slug), which is exactly what an agent needs to chain the calls correctly.

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

Parameters3/5

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

Schema description coverage is 75% and both enums (model, collection) are documented in the schema itself, so the baseline is 3. The description adds no extra meaning for query, limit, or collection beyond what the schema already says.

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 ('Find ready-made, expert prompt templates') and scopes it concretely (the thinkhard.si repository, 300+ prompts, enumerated domains). This clearly separates it from get_prompt (retrieval by slug) and list_collections (browsing).

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?

Gives an explicit trigger ('whenever the user wants to write, plan, summarize, analyze or draft something at work') and an explicit alternative it beats ('before writing a prompt from scratch'), plus the follow-up step ('Then call get_prompt with the slug'). It does not say when to use list_collections instead or when this tool is a poor fit, so it falls 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updates
    • Changedestimate_ai_cost1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "calls_per_month": {
+      "type": "integer"
+    },
+    "checked": {
+      "description": "When the prices were last checked against each provider.",
+      "type": "string"
+    },
+    "input_tokens": {
+      "type": "integer"
+    },
+    "models": {
+      "description": "Cheapest first.",
+      "items": {
+        "properties": {
+          "input_per_million": {
+            "description": "US dollars per million input tokens.",
+            "type": "number"
+          },
+          "model": {
+            "type": "string"
+          },
+          "monthly_usd": {
+            "description": "US dollars a month.",
+            "type": "number"
+          },
+          "note": {
+            "description": "Empty unless something about the price needs saying.",
+            "type": "string"
+          },
+          "output_per_million": {
+            "description": "US dollars per million output tokens.",
+            "type": "number"
+          },
+          "per_call_usd": {
+            "description": "US dollars per call.",
+            "type": "number"
+          },
+          "ref": {
+            "description": "Provider and model id.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "model",
+          "ref",
+          "per_call_usd",
+          "monthly_usd",
+          "input_per_million",
+          "output_per_million",
+          "note"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "output_tokens": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "checked",
+    "calls_per_month",
+    "input_tokens",
+    "output_tokens",
+    "models"
+  ],
+  "type": "object"
+}
    • Changedget_prompt2 fields changed
      • 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"
+}
    • Changedgrade_prompt1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "band": {
+      "description": "The score in a word.",
+      "type": "string"
+    },
+    "checks": {
+      "description": "The ten checks, in order.",
+      "items": {
+        "properties": {
+          "check": {
+            "type": "string"
+          },
+          "pass": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "check",
+          "pass"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "score": {
+      "description": "Out of 10.",
+      "type": "integer"
+    },
+    "target": {
+      "description": "The model it was read for.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "score",
+    "band",
+    "target",
+    "checks"
+  ],
+  "type": "object"
+}
    • Changedlist_collections1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "collections": {
+      "items": {
+        "properties": {
+          "blurb": {
+            "type": "string"
+          },
+          "code": {
+            "description": "Registry prefix, such as CAR.",
+            "type": "string"
+          },
+          "count": {
+            "description": "Prompts in the collection.",
+            "type": "integer"
+          },
+          "id": {
+            "description": "Pass it to search_prompts as collection.",
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "code",
+          "name",
+          "blurb",
+          "count"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "collections"
+  ],
+  "type": "object"
+}
    • Changedsearch_prompts1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "prompts": {
+      "description": "Best match first. Empty when nothing matches.",
+      "items": {
+        "properties": {
+          "collection": {
+            "description": "The collection it belongs to.",
+            "type": "string"
+          },
+          "id": {
+            "description": "Registry number, such as CAR-002.",
+            "type": "string"
+          },
+          "laid_out_for": {
+            "description": "The kind of model it is laid out for.",
+            "type": "string"
+          },
+          "score": {
+            "description": "Its own grade out of 10.",
+            "type": "integer"
+          },
+          "slug": {
+            "description": "Pass it to get_prompt.",
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "description": "Its page on thinkhard.si.",
+            "type": "string"
+          },
+          "use": {
+            "description": "When to use it.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "slug",
+          "title",
+          "use",
+          "collection",
+          "laid_out_for",
+          "score",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "prompts"
+  ],
+  "type": "object"
+}
  2. 5 tool updates
    • First observedestimate_ai_cost
    • First observedget_prompt
    • First observedgrade_prompt
    • First observedlist_collections
    • First observedsearch_prompts

Related MCP Connectors

Related MCP Servers

Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources