Skip to main content
Glama

The Daily Workflow — AI Tools & Free Alternatives

search_prompts

Read-onlyIdempotent

Search 1700+ user-submitted AI prompts for ChatGPT, Claude, Midjourney, DALL-E, Cursor, Gemini and more. Each prompt is a copy-paste-ready template for a specific task (writing, coding, marketing, design, business, etc).

Args:
    query: Free-text search over title and prompt body. Example: "blog post outline",
           "code refactor", "logo design", "cold email".
    ai_tool: Filter by target AI. Values: ChatGPT, Claude, Midjourney, DALL-E 3,
             Gemini, Cursor, Copilot.
    category: Filter by category. Values: Writing, Coding, Marketing, Design,
              Business, Education, Creative, Productivity.
    limit: Max results (1-25, default 10).

Returns:
    Dict with `count` and `results`. Each result: id, title, category, ai_tool,
    preview (first 200 chars of prompt), page_url.

Use this when the user asks "give me a prompt for X" or "find a prompt to do Y".
The full content is at the page_url.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_prompts"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of results to return (1-25; values outside the range are clamped). Default: 10.
queryNoFree-text search query matched against prompt title and prompt text. Example: "blog post outline", "code refactor", "logo design", "cold email". Empty string returns unfiltered results.
ai_toolNoFilter by the AI the prompt is written for. One of: "ChatGPT", "Claude", "Midjourney", "DALL-E 3", "Gemini", "Cursor", "Copilot". Empty string means any AI.
categoryNoFilter by prompt category. One of: "Writing", "Coding", "Marketing", "Design", "Business", "Education", "Creative", "Productivity". Empty string means any category.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

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/openWorld, so safety is covered. The description adds real behavioral value beyond them: results are trimmed to a 200-char `preview`, the full content lives at `page_url`, and the return shape (`count` + `results`) is described. Missing only retrieval-adjacent detail such as relevance ranking or empty-result behavior.

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?

Front-loaded with the purpose sentence, then Args and Returns in a scannable structure; no filler prose. It loses a point for duplicating the enum lists and default values that already appear verbatim in the schema, plus a minor inconsistency between 'DALL-E' in the intro and 'DALL-E 3' in the Args.

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?

There is no output schema, and the description fully compensates by describing the return structure and per-result fields. For a zero-required-parameter, read-only search tool, an agent has everything needed to call it and to know what it will not get back (full prompt text).

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 coverage is 100%, so the schema already documents all four parameters including defaults, the 1-25 range, clamping, and the empty-string-means-any behavior. The description's Args block largely restates those same enum values and examples rather than adding new meaning, 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?

Specific verb+resource ('Search 1700+ user-submitted AI prompts') with concrete scope: which AI tools are covered and that each result is a copy-paste-ready template. An agent can distinguish this from search_ai_tools, search_mcp_servers, and search_pipelines purely from the description because the resource (prompts) and its domains are named explicitly.

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?

Explicit trigger phrase: 'Use this when the user asks "give me a prompt for X" or "find a prompt to do Y".' That is a clear usage condition an agent can pattern-match on. It stops short of naming alternatives or exclusions (e.g. 'for AI tool metadata use search_ai_tools instead'), so it is clear context without full routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.