Skip to main content
Glama
jezweb

Smart Prompts MCP Server

prompts_help

Get guidance on using Smart Prompts tools effectively, including usage instructions, practical examples, and best practices for prompt management.

Instructions

Get help understanding how to use the Smart Prompts tools effectively. Returns guidance on tool usage, examples, and best practices.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicNoSpecific topic to get help on (e.g., "creating", "searching", "github", "examples"). Leave empty for general help.

Implementation Reference

  • The handleHelp private method implements the core logic of the 'prompts_help' tool. It selects from predefined help texts based on the optional 'topic' parameter (general, workflow, creating, searching, github, examples) and returns the corresponding markdown-formatted guidance as a CallToolResult.
      private handleHelp(args: EnhancedToolArguments): CallToolResult {
        const topic = args.topic?.toLowerCase() || 'general';
        
        const helpTexts: Record<string, string> = {
          general: `# 🚀 Smart Prompts MCP Server Help
    
    This server manages a library of reusable prompt templates stored in GitHub.
    
    ## 🎯 **RECOMMENDED WORKFLOW (Follow This Order):**
    
    ### 1. 🔍 **ALWAYS START WITH SEARCH**
       → Use **search_prompts** first to find existing prompts
       → Avoid creating duplicates and discover what's available
    
    ### 2. 📖 **GET DETAILS WHEN NEEDED** 
       → Use **get_prompt** with exact names from search results
       → See full content and template variables
    
    ### 3. ✨ **CREATE ONLY WHEN NECESSARY**
       → Use **create_github_prompt** after confirming nothing similar exists
       → Automatically saves to GitHub with proper organization
    
    ### 4. 🔗 **COMBINE FOR COMPLEX TASKS**
       → Use **compose_prompts** to build multi-step workflows
       → Reuse existing prompts in new combinations
    
    ## 📚 **Available Tools:**
    1. **prompts_help** - Get contextual help and guidance
    2. **search_prompts** - 🔍 START HERE - Find existing prompts
    3. **list_prompt_categories** - Browse all categories 
    4. **get_prompt** - Get full prompt details (use exact names from search)
    5. **create_github_prompt** - Create new prompts (search first!)
    6. **compose_prompts** - Combine multiple prompts
    7. **check_github_status** - Verify GitHub connection
    
    💡 **Pro Tip:** Search before you create! Most tasks already have prompts.
    
    Use 'prompts_help' with topic: "creating", "searching", "workflow", or "examples" for detailed guidance.`,
    
          workflow: `# 🔄 Recommended Workflow
    
    ## ✅ **STEP-BY-STEP PROCESS:**
    
    ### **DISCOVERY PHASE** 🔍
    1. **Start with search_prompts** 
       - Use keywords related to your task
       - Browse by category if unsure
       - Check multiple search terms
    
    2. **Explore categories with list_prompt_categories**
       - See what's available in each area
       - Get counts to understand library size
    
    ### **EVALUATION PHASE** 📖
    3. **Use get_prompt for promising results**
       - Get full content and metadata
       - Check template variables and examples
       - Evaluate if it meets your needs
    
    ### **ACTION PHASE** ⚡
    4a. **If perfect match found:**
       - Use the existing prompt directly
       - Note the template variables needed
    
    4b. **If close match found:**
       - Consider using compose_prompts to combine
       - Extend with additional instructions
    
    4c. **If no match found:**
       - Use create_github_prompt to build new one
       - Follow naming conventions
       - Add good metadata for future discovery
    
    ## 🎯 **EXAMPLE WORKFLOW:**
    
    \`\`\`
    User needs: "Help with code reviews"
    
    1. search_prompts with query: "code review"
       → Finds: "Code Review Assistant"
    
    2. get_prompt with name: "code_review_assistant" 
       → Perfect! Has template variables for {{code}} and {{focus_areas}}
    
    3. Use the existing prompt ✅
    \`\`\`
    
    ## ❌ **ANTI-PATTERNS TO AVOID:**
    - Creating prompts without searching first
    - Using get_prompt with guessed names  
    - Ignoring template variables and examples
    - Not checking categories for context`,
    
          creating: `# Creating Prompts
    
    ## Best Practices:
    1. **Search first** - Check if a similar prompt exists
    2. **Use clear names** - lowercase_with_underscores (e.g., api_documentation_generator)
    3. **Categorize properly** - Use existing categories when possible
    4. **Add good metadata** - Title, description, and tags help discoverability
    5. **Include examples** - Show how to use the prompt in the content
    
    ## Example:
    \`\`\`
    create_github_prompt with:
    - name: "code_reviewer"
    - title: "Automated Code Review Assistant"
    - description: "Reviews code for best practices and potential issues"
    - category: "development"
    - content: "Review the following code for:\\n1. Best practices\\n2. Potential bugs\\n3. Performance issues\\n\\nCode:\\n{{code}}"
    - tags: ["code-review", "quality", "development"]
    - arguments: [{"name": "code", "description": "The code to review", "required": true}]
    \`\`\`
    
    ## Template Variables:
    Use {{variable_name}} in content for dynamic placeholders.`,
    
          searching: `# Searching for Prompts
    
    ## Search Methods:
    
    ### 1. Keyword Search
    \`\`\`
    search_prompts with:
    - query: "api documentation"
    \`\`\`
    Searches in titles, descriptions, and content.
    
    ### 2. Category Filter
    \`\`\`
    search_prompts with:
    - category: "development"
    \`\`\`
    Shows all prompts in a specific category.
    
    ### 3. Tag Filter
    \`\`\`
    search_prompts with:
    - tags: ["api", "rest"]
    \`\`\`
    Find prompts with specific tags.
    
    ### 4. Combined Search
    \`\`\`
    search_prompts with:
    - query: "test"
    - category: "development"
    - tags: ["automation"]
    \`\`\`
    
    ## Tips:
    - Start broad, then narrow down
    - Check list_prompt_categories first
    - Use partial keywords (e.g., "doc" finds "documentation")`,
    
          github: `# GitHub Integration
    
    ## How it Works:
    1. Prompts are stored in GitHub repository: ${this.hasGitHubAccess ? 'Connected ✓' : 'Read-only (no write access)'}
    2. Changes are committed directly to the repository
    3. Other users see updates immediately
    
    ## Requirements:
    - GitHub token with repo access (currently ${this.hasGitHubAccess ? 'configured' : 'missing or read-only'})
    - Repository: Check with check_github_status
    
    ## Creating Prompts:
    - Use create_github_prompt to save directly to GitHub
    - Prompts are organized in category folders
    - Each prompt is a markdown file with YAML frontmatter
    
    ## Troubleshooting:
    - Run check_github_status to verify connection
    - Ensure GITHUB_TOKEN environment variable is set
    - Token needs 'repo' scope for write access`,
    
          examples: `# Example Prompts
    
    ## 1. Simple Prompt
    \`\`\`
    create_github_prompt with:
    - name: "explain_code"
    - title: "Code Explanation Generator"
    - description: "Explains code in simple terms"
    - category: "development"
    - content: "Explain this code in simple terms:\\n\\n{{code}}"
    - tags: ["explanation", "documentation"]
    \`\`\`
    
    ## 2. Complex Prompt with Multiple Arguments
    \`\`\`
    create_github_prompt with:
    - name: "api_endpoint_generator"
    - title: "REST API Endpoint Generator"
    - description: "Creates REST endpoints with documentation"
    - category: "development"
    - content: "Create a {{method}} endpoint for {{resource}} that {{description}}.\\n\\nInclude:\\n- Validation\\n- Error handling\\n- OpenAPI docs"
    - arguments: [
        {"name": "method", "description": "HTTP method", "required": true},
        {"name": "resource", "description": "Resource name", "required": true},
        {"name": "description", "description": "What the endpoint does", "required": true}
      ]
    \`\`\`
    
    ## 3. Composed Prompt
    \`\`\`
    compose_prompts with:
    - prompts: ["code_reviewer", "documentation_generator"]
    - separator: "\\n\\nNext Task:\\n\\n"
    \`\`\``,
        };
    
        const helpText = helpTexts[topic] || helpTexts.general;
        
        return {
          content: [
            {
              type: 'text',
              text: helpText,
            } as TextContent,
          ],
        };
      }
  • The tool definition in getToolDefinitions(), including name, description, and inputSchema specifying an optional 'topic' string parameter.
      name: 'prompts_help',
      description: 'Get help understanding how to use the Smart Prompts tools effectively. Returns guidance on tool usage, examples, and best practices.',
      inputSchema: {
        type: 'object',
        properties: {
          topic: {
            type: 'string',
            description: 'Specific topic to get help on (e.g., "creating", "searching", "github", "examples"). Leave empty for general help.',
          },
        },
      },
    },
  • src/index.ts:56-62 (registration)
    Registers the ListTools and CallTool request handlers on the MCP Server, delegating to EnhancedPromptTools.getToolDefinitions() (exposes prompts_help schema) and EnhancedPromptTools.handleToolCall() (executes prompts_help via internal switch). This effectively registers the tool with the MCP protocol.
    server.setRequestHandler(ListToolsRequestSchema, async () => {
      return enhancedTools.getToolDefinitions();
    });
    
    server.setRequestHandler(CallToolRequestSchema, async (request) => {
      return await enhancedTools.handleToolCall(request);
    });
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool 'Returns guidance on tool usage, examples, and best practices,' which gives some behavioral context about output content. However, it doesn't cover aspects like response format, potential errors, or performance characteristics (e.g., if it's a fast lookup or requires network calls).

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 concise and front-loaded, consisting of two clear sentences that directly state the purpose and output. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.

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

Completeness3/5

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

Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is moderately complete. It covers the core purpose and output type but lacks details on error handling, response structure, or integration with sibling tools. For a help tool, more context on when and how to use it would improve completeness.

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?

The input schema has 100% description coverage, with the 'topic' parameter well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what the schema provides (e.g., it doesn't elaborate on topic examples or constraints). With high schema coverage, the baseline score of 3 is appropriate.

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?

The description clearly states the tool's purpose: 'Get help understanding how to use the Smart Prompts tools effectively.' It specifies the verb ('Get help') and resource ('Smart Prompts tools'), but doesn't explicitly differentiate from siblings like 'check_github_status' or 'compose_prompts', which are action tools rather than help tools. The purpose is clear but lacks sibling distinction.

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?

The description implies usage context ('how to use the Smart Prompts tools effectively') but doesn't provide explicit guidance on when to use this tool versus alternatives. For example, it doesn't specify if this should be used before attempting other tools or as a fallback for errors. The guidance is implied rather than explicit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jezweb/smart-prompts-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server