How do I use prompte-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@prompte-mcp enhance my prompt for debugging a memory leak" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

prompte-mcp

by AlanRoybal

Overview Schema Related Servers Score Discussions

JavaScript

Local

prompte-mcp

An MCP server that enhances your prompts before Claude processes them — automatically applying chain-of-thought, few-shot, tree-of-thought, and other prompt engineering techniques based on what you're asking.

you type:   "fix this null pointer crash"

claude sees: "Work through this using the ReAct pattern — alternate between
              Thought (reasoning) and Action (what you would do), then give
              a final Answer.

              fix this null pointer crash"

Setup

No API key needed. Prompte runs entirely on your existing Claude Code or Codex session.

git clone https://github.com/AlanRoybal/prompte-mcp
cd prompte-mcp
node bin/setup.js

The setup script handles everything:

Registers the MCP server in ~/.claude/settings.json
Installs the UserPromptSubmit hook (automatic enhancement on every prompt)
Creates ~/.prompte/config.json with defaults

Then restart Claude Code.

Flags

node bin/setup.js --yes       # accept all defaults, no prompts
node bin/setup.js --dry-run   # preview changes without writing anything

Manual setup

If you prefer to edit ~/.claude/settings.json directly:

{
  "mcpServers": {
    "prompte": {
      "command": "node",
      "args": ["/path/to/prompte-mcp/bin/prompte-mcp.js"]
    }
  },
  "hooks": {
    "UserPromptSubmit": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "python3 /path/to/prompte-mcp/hooks/user-prompt-submit.py"
          }
        ]
      }
    ]
  }
}

Related MCP server: MCP Prompt Optimizer

How it works

The MCP server handles classification and technique selection. Claude Code (your existing session) does the actual enhancement — no separate API calls, no extra costs.

your prompt
    │
    ▼
┌─────────────┐
│  Classifier │  keyword heuristics (no API call)
│             │  → intent: debugging / reasoning / generation / ...
└──────┬──────┘
       │  technique affinity scores
       ▼
┌─────────────┐
│   Scorer    │  affinity × your learned acceptance rate
│             │  → selects best technique
└──────┬──────┘
       │  techniqueInstruction
       ▼
  Claude Code  ←── applies the technique using its own intelligence
       │
       ▼
    response

The scorer learns from you. Acceptance rates per technique are tracked in ~/.prompte/ — techniques you skip get demoted over time.

Two modes

Automatic (hook)

The UserPromptSubmit hook fires on every prompt silently — no tool call, no interruption. Claude receives the enhanced version without you doing anything.

Prefix a prompt with * to bypass:

* just answer this exactly as asked

Interactive (MCP tools)

When Claude calls enhance_prompt, it shows you the enhancement and waits for your decision before answering:

I've selected the Chain of Thought technique for this (debugging).

Original: why does my function crash when the list is empty?

Enhanced: Think through this step-by-step before giving your final
          answer. Show your reasoning explicitly.

          why does my function crash when the list is empty?

[A] Accept   [E] Edit   [S] Skip   [Q] Quit

Reply with a / e / s / q (or just say "accept", "skip", etc.):

Reply	What happens
`a` / accept	Claude answers using the enhanced prompt
`e` / edit	Paste your revised version, Claude uses that
`s` / skip	Claude answers your original prompt, no technique
`q` / quit	Claude stops, does nothing

Set autoAccept: true in ~/.prompte/config.json to skip the confirmation and apply silently.

Claude Code can also call these tools directly during a session:

Tool	What it does
`enhance_prompt`	Classify intent, select best technique, return `techniqueInstruction` for Claude to apply
`list_techniques`	All 8 techniques with your acceptance stats
`get_stats`	Session totals + current config
`record_feedback`	Mark an enhancement helpful/not (trains technique weights)
`get_config`	Read `~/.prompte/config.json`
`set_config`	Write a config value

The CLAUDE.md in this repo tells Claude when to call enhance_prompt automatically — on debugging, reasoning, generation, architecture, and review prompts.

The 8 techniques

Technique	Best for	What it adds
Chain of Thought	Debugging, reasoning	Step-by-step reasoning before answering
Few-Shot	Generation, review	Concrete example to anchor output
Tree of Thought	Decisions, architecture	3 approaches with pros/cons, then a recommendation
Meta-Prompting	Architecture, generation	Restate understanding of the goal before answering
Role Prompting	Review, generation	Senior software engineer framing
Self-Consistency	Reasoning, debugging	Verify from a different angle, correct if wrong
Step-Back	Explanation, reasoning	Consider broader context and first principles first
ReAct	Debugging, multi-step	Interleaved Thought / Action / Observation steps

Configuration

~/.prompte/config.json:

{
  "enabled": true,
  "autoAccept": false,
  "bypassPrefix": "*",
  "preferredTechniques": [],
  "disabledTechniques": [],
  "llmClassifier": true,
  "maxPromptLength": 4000
}

Key	Default	Description
`enabled`	`true`	Master switch
`bypassPrefix`	`"*"`	Prompt prefix to skip enhancement
`preferredTechniques`	`[]`	Boost these techniques
`disabledTechniques`	`[]`	Never use these techniques
`maxPromptLength`	`4000`	Skip enhancement above this length

Per-project overrides: drop a .prompte file anywhere in your project tree (or a parent directory). Values override the global config.

Project structure

prompte-mcp/
├── bin/
│   ├── prompte-mcp.js      MCP server
│   └── setup.js            setup script
├── src/
│   ├── classifier/         intent classification (LLM + keyword fallback)
│   ├── techniques/         8 technique definitions
│   ├── engine/             classify → score → select → rewrite
│   └── config/             ~/.prompte/ storage and acceptance rate learning
├── hooks/
│   └── user-prompt-submit.py   UserPromptSubmit hook
└── CLAUDE.md               tells Claude when to call enhance_prompt

Available Tools

6 tools

enhance_promptB

Enhance a prompt with the best prompt engineering technique for its intent.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes	The raw prompt to enhance
`technique`	No	Force a specific technique ID (optional)

TDQS

B3.2/5.0

Behavior3/5

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

Without annotations, the description carries full burden. It reveals intelligent selection logic ('best... for its intent') but fails to disclose return format, whether this is a pure function, or what occurs when intent classification is ambiguous.

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?

Single efficient sentence with no redundancy. However, given zero annotations and no output schema, it is under-specified rather than appropriately concise.

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?

Covers the primary transformation intent but omits critical context for a utility tool: return value structure, relationship to list_techniques for discovering technique IDs, and behavior when explicit technique parameter conflicts with auto-selected intent.

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% with clear descriptions. The description adds context that 'technique' relates to 'prompt engineering' and implies optional automatic selection, but does not detail parameter interaction patterns or valid technique ID formats.

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?

Clear action verb 'Enhance' with specific resource 'prompt' and domain context 'prompt engineering technique'. Mentions automatic selection based on 'intent', distinguishing it from generic prompt processing. However, lacks specificity about output format.

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

Usage Guidelines2/5

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

Provides no guidance on when to use the optional 'technique' parameter versus automatic selection, nor does it reference sibling tool 'list_techniques' which users might need to call first to discover available technique IDs.

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

get_configA

Read the current ~/.prompte/config.json

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

Annotations are absent so description carries full burden. 'Read' correctly implies non-destructive file access, and the specific path discloses scope. However, lacks details on error behavior (file missing), return format structure, or whether content is parsed or raw.

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?

Perfectly concise. Front-loaded imperative verb, zero redundancy. Every word earns its place in describing the operation and target file.

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?

Adequate but incomplete for a data retrieval tool with no output schema or annotations. While the file path provides context, missing description of return value structure (parsed JSON vs string) or error cases leaves gaps.

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?

Zero parameters present, establishing baseline of 4. Description compensates appropriately by specifying the implicit target resource (config file path), adding context beyond the empty schema.

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?

Excellent clarity. Specific verb 'Read' + exact resource path '~/.prompte/config.json'. Clearly distinguishes from sibling 'set_config' (implied write operation) and other tools like 'get_stats' or 'list_techniques'.

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

Usage Guidelines2/5

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

No explicit guidance on when to use vs alternatives. Lacks mention of sibling 'set_config' for modification scenarios or prerequisites like file existence. Agent must infer usage from verb alone.

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

get_statsB

Get session totals and current config snapshot.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

Zero annotations provided, so description carries full behavioral burden. Only states what is retrieved without disclosing side effects, caching behavior, cost/heaviness of the operation, or session scope definition. Merely implies read-only nature through 'Get'.

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?

Single efficient sentence of seven words with zero redundancy. Information is front-loaded and immediately actionable.

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?

Minimal viable completeness for a zero-parameter tool. Description identifies the two data domains (session stats, config) but lacks detail on what 'session totals' comprises or the snapshot format, which would help given no output schema exists.

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?

Input schema has zero parameters (confirmed by context signals), triggering baseline score of 4. Description does not need to compensate for missing parameter documentation.

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?

Uses specific verb 'Get' and identifies resources 'session totals' and 'current config snapshot'. Somewhat distinguishes from sibling get_config by including session metrics, though overlap with config retrieval isn't explicitly clarified.

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

Usage Guidelines2/5

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

Provides no guidance on when to prefer this over get_config or other siblings, nor any prerequisites or conditions for use. Agent must infer applicability from the resource names alone.

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

list_techniquesB

List all 8 available prompt engineering techniques with acceptance stats.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

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 disclosure burden. It adds valuable context by specifying the fixed count (8) and that acceptance statistics are included, but lacks details on data freshness, caching, authentication requirements, or the specific structure of the returned technique objects.

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 a single, efficient sentence of 9 words. It is front-loaded with the action and resource, and every clause earns its place by conveying scope ('all 8') and content ('acceptance stats').

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 no output schema exists, the description partially compensates by mentioning 'acceptance stats,' hinting at the return value structure. However, for a complete picture without annotations or output schema, it should ideally describe the technique object format (e.g., whether it includes IDs, names, descriptions) to enable proper parsing.

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?

With zero parameters, the baseline score applies per the rubric. The description implies why no parameters are needed (it returns all 8), which aligns with the empty schema. No additional parameter documentation is required or present.

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 provides a specific verb (List), resource (prompt engineering techniques), and scope (all 8 available with acceptance stats). However, it does not explicitly differentiate from sibling tools like 'get_stats' or 'enhance_prompt', which could cause confusion about when to list techniques versus getting general statistics or applying them.

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

Usage Guidelines2/5

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

No explicit guidance is provided on when to use this tool versus alternatives (e.g., 'get_stats' which might return aggregate data, or 'enhance_prompt' which consumes these techniques). There are no 'when-not-to-use' exclusions or prerequisites mentioned.

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

record_feedbackC

Record whether an enhancement was helpful.

ParametersJSON Schema

Name	Required	Description
`technique`	Yes	Technique ID
`helpful`	Yes	Was it helpful?
`prompt`	No	The original prompt (for context)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. 'Record' implies write persistence but lacks disclosure of side effects, idempotency, overwrite behavior, or what happens to recorded data.

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?

Single sentence, front-loaded, no redundancy. Efficient but arguably too terse given missing workflow and behavioral context.

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

Completeness2/5

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

Omits critical context for a feedback tool: relationship to enhance_prompt workflow, whether feedback is anonymous/required, and data persistence. With siblings providing the 'enhancement' being rated, should explicitly state this closes the feedback loop.

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 has 100% description coverage, establishing baseline 3. Description adds semantic context ('enhancement was helpful') mapping to 'technique' and 'helpful' params but doesn't elaborate syntax or optional 'prompt' usage beyond schema.

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?

Clear verb ('Record') and resource ('feedback'/'whether helpful'). Mentions 'enhancement' which links to the 'enhance_prompt' sibling, distinguishing this as the feedback mechanism versus the enhancement generator.

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

Usage Guidelines2/5

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

No explicit guidance on when to use (e.g., 'call after enhance_prompt') or when not to use. Lacks workflow integration instructions despite clear relationship to sibling tools.

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

set_configA

Write a config value to ~/.prompte/config.json

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes	Config key
`value`	Yes	New value

TDQS

A3.5/5.0

Behavior3/5

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

Discloses the specific file path (~/.prompte/config.json) which is crucial context absent from annotations. However, with no annotations provided, fails to disclose mutation semantics: whether it overwrites existing keys, creates the file if missing, or validates values. Carries partial burden for a destructive operation.

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?

Single efficient sentence with zero waste. Front-loaded with action verb and fully qualified path. Appropriate length for a simple 2-parameter tool.

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?

Adequate for a flat 2-parameter mutation tool: identifies the operation, target file, and required inputs. However, with no output schema and no annotations, the description should ideally disclose overwrite behavior and file auto-creation policy to be complete.

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% with 'Config key' and 'New value' descriptions. Description adds no additional parameter semantics beyond what the schema provides, meeting the baseline score for high-coverage schemas.

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?

Clear specific verb 'Write', resource 'config value', and precise location '~/.prompte/config.json'. Implicitly distinguishes from sibling 'get_config' by indicating this is the write counterpart.

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

Usage Guidelines2/5

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

No explicit guidance on when to use vs alternatives, prerequisites (e.g., directory existence), or conditions (creates file vs requires existing file). Only states what it does, not when to choose it.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a distinct purpose with no overlap: enhance_prompt modifies prompts, get_config/set_config handle configuration, get_stats provides usage data, list_techniques enumerates methods, and record_feedback captures user responses. The descriptions clearly differentiate their functions.

Naming Consistency4/5

Most tools follow a verb_noun pattern (enhance_prompt, get_config, get_stats, set_config, record_feedback), but list_techniques uses a verb_object pattern which is slightly inconsistent. Overall, the naming is readable and predictable with only minor deviation.

Tool Count5/5

With 6 tools, this server is well-scoped for prompt engineering management. Each tool serves a clear role in the workflow: configuration, enhancement, technique listing, feedback, and statistics. The count is neither too sparse nor bloated.

Completeness5/5

The toolset fully covers the prompt engineering domain: it supports configuration management (get/set), enhancement with techniques (enhance_prompt, list_techniques), feedback collection (record_feedback), and monitoring (get_stats). There are no obvious gaps for core operations.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Artificial Wit AI
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
noteit-mcp
io.github.bahfahh
MCP server for AI agent profiles and smart notes. 60+ coding prompt packs with expert personas.
Note Taking Developer Tools Coding Agents
25
PlanExe A
io.github.PlanExeOrg
MCP server for generating rough-draft project plans from natural-language prompts.
Autonomous Agents Developer Tools Project Management
113398

Related MCP Servers

Prompt Auto-Optimizer MCP
Developer Tools Autonomous Agents Code Execution
sloth-wq
A
license
B
quality
D
maintenance
An MCP server that automatically optimizes AI prompts using evolutionary algorithms, helping improve prompt performance, creativity, and reliability through iterative testing and refinement.
Updated a year ago (2025-08-03 10:02 UTC)
12
3
MIT
MCP Prompt Optimizer
Developer Tools Autonomous Agents Research & Data
Bubobot-Team
A
license
Not graded
quality
D
maintenance
This MCP server provides research-backed prompt optimization tools and professional domain templates designed to improve AI performance through strategies like Tree of Thoughts and Medprompt. It enables users to analyze, auto-optimize, and refine prompts using advanced reasoning patterns and safety-critical alignment techniques.
Updated a year ago (2025-06-23 08:35 UTC)
24
MIT
Refine Prompt
Developer Tools Autonomous Agents
FelippeFarias
A
license
A
quality
D
maintenance
An MCP server that uses Claude 3.5 Sonnet to transform ordinary prompts into structured, professionally engineered instructions for any LLM. It enhances AI interactions by adding context, requirements, and structural clarity to raw user inputs.
Updated a year ago (2025-04-03 00:31 UTC)
1
3
MIT
prompt-plus-plus-mcp
AI & Machine Learning Developer Tools
bacoco
A
license
A
quality
D
maintenance
An advanced MCP server that intelligently enhances prompts using 44+ metaprompt strategies, with LLM-driven strategy selection and enterprise-grade features.
Updated a year ago (2025-06-13 07:11 UTC)
8
53
9
MIT

Appeared in Searches

Prop Amp (Proportional Amplifier) Information

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/AlanRoybal/prompte-mcp'

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