Which integrations are available for this server?

Allows OpenAI clients (e.g., ChatGPT) to discover business needs, generate websites, manage sites, and publish sites via Template Vault.

How do I use Template Vault 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., "@Template Vault MCP Build me a bilingual website for my pool cleaning business." 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.

Template Vault MCP

by julioMeif

Overview Schema Related Servers Score Discussions

JavaScript

Local

Template Vault MCP

License

Connect Claude Desktop, ChatGPT, Cursor, Windsurf — or any MCP-speaking AI client — to Template Vault, an AI website builder for small businesses.

What it does

This package is the thin client-side adapter for the Template Vault MCP server. It bridges stdio-based MCP clients (Claude Desktop, Cursor) to our hosted HTTP+OAuth server.

Once connected, your AI can:

Tool	Purpose
`discover_business_needs`	Interview the user about their business with niche-tailored follow-ups (always called first).
`list_personalities`	List the visual styles (classic, minimal, gradient, zen, immersive, glass).
`generate_site`	Generate a full website from a populated business profile. Returns a job id.
`get_generation_status`	Poll the build status (`pending` → `processing` → `completed`).
`list_user_sites`	List the user's existing sites.
`publish_site`	Deploy a site to production at `slug.the-template-vault.com`.

End-to-end, a one-page Spanish-and-English bilingual site for a Miami pool builder takes ~60 seconds from "build me a website" to a real running URL.

Related MCP server: essetech-ai-readiness-mcp

Install

Claude Desktop

Open your claude_desktop_config.json (Settings → Developer → Edit Config) and add:

{
  "mcpServers": {
    "template-vault": {
      "command": "npx",
      "args": ["-y", "template-vault-mcp"]
    }
  }
}

Restart Claude Desktop. The first time you ask it to use a Template Vault tool, your browser will open for OAuth — log in (or sign up) at the-template-vault.com, click Allow, done.

Claude.ai (web)

Claude.ai speaks HTTP MCP natively — you don't need this adapter. Just add a custom connector:

Settings → Connectors → Add custom connector
URL: https://www.the-template-vault.com/api/mcp
Click Connect → OAuth flow → Allow

Cursor

In ~/.cursor/mcp.json:

{
  "mcpServers": {
    "template-vault": {
      "command": "npx",
      "args": ["-y", "template-vault-mcp"]
    }
  }
}

ChatGPT (Developer Mode)

OpenAI's MCP support uses an HTTP endpoint directly. Add the connector URL https://www.the-template-vault.com/api/mcp in ChatGPT's developer settings.

Auth & data

OAuth 2.1 + PKCE with refresh tokens — authorize once, stay connected for 90 days.
No credentials are stored in this repo. Tokens live in mcp-remote's per-user cache (~/.mcp-remote-auth/ by default).
Quota — each generate_site call counts against your monthly Template Vault plan (5 free / month on the free tier).
Per-user isolation — your AI can only see and act on YOUR sites.

Pricing

Free — 1 site, 5 generations/month
Pro — $15/mo, 5 sites, 25 generations, custom domains
Business / Agency — for multi-site / agency use

See pricing.

Content policy

We decline generation requests for content categories listed in CONTENT_POLICY.md — including adult content, hate speech, scams, illegal goods, CSAM, and impersonation/phishing sites. Requests that match these categories return an explicit error message rather than silently generating.

The Template Vault generator itself (Anthropic Sonnet) applies its own content safety on top — so a borderline request that gets past our pre-filter will typically be refused by the model. Multiple layers, defense in depth.

How it works

┌──────────────────────┐         stdio        ┌─────────────────────────┐
│  Claude Desktop /    │ ─────────────────▶  │ template-vault-mcp     │
│  Cursor / Windsurf   │ ◀───────────────── │ (this package)          │
└──────────────────────┘                     └────────────┬────────────┘
                                                          │ HTTPS + OAuth
                                                          ▼
                                             ┌─────────────────────────┐
                                             │  Template Vault         │
                                             │  api/mcp (hosted)       │
                                             └────────────┬────────────┘
                                                          │
                                                          ▼
                                                Site generation
                                                + Vercel deploy

The adapter has no business logic — it forwards stdio messages to the hosted MCP server and forwards responses back. All tool descriptions, schemas, and workflows live server-side; you always get the latest version without updating the package.

Open source

MIT licensed. The platform itself (the generator, the editor, the deployer) is closed source; this adapter is the open-source layer customers and contributors can inspect, fork, and build on.

PRs welcome for the adapter — bug fixes, additional client integrations, Docker improvements. Tool changes happen server-side; for those, open an issue or contact us at contact@the-template-vault.com.

Available Tools

6 tools

discover_business_needsA

Read-onlyIdempotent

REQUIRED FIRST STEP. Returns the question script you MUST ask the user before calling generate_site. Why: Template Vault's value is integration discovery — the generator detects what each business needs (WhatsApp button, Instagram block, booking, online ordering, etc.) based on these answers. Skipping discovery produces minimal text-only sites and embarrasses the user. ALWAYS call this tool first when a user asks to build/generate a website. After receiving the questions, ask them ONE AT A TIME in conversation — do not dump the whole list. Note answers, then build a complete businessProfile object for generate_site.

ParametersJSON Schema

Name	Required	Description	Default
`businessHint`	No	Optional 1-line user-supplied hint (e.g. 'pool builder in Miami', 'wedding photographer'). Lets the tool tailor follow-up questions to the niche.

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already indicate readOnly and idempotent. The description adds behavioral context: the tool returns a question script, must be called first, and the user must ask questions sequentially. No contradictions with annotations.

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?

Description is front-loaded with 'REQUIRED FIRST STEP' and uses formatting for emphasis. Every sentence adds value, though slightly lengthy. Could be tightened slightly but remains effective.

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?

Given the simplicity (1 optional param, no output schema), the description is complete. It explains the purpose, usage sequence, behavioral guidelines, and consequences of skipping. No 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?

Schema coverage is 100% and describes the optional businessHint parameter. The description adds meaning by explaining that the hint lets the tool tailor follow-up questions to the niche, beyond the schema's description.

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 clearly states the tool returns a question script and is the required first step before calling generate_site. It specifies the verb (returns), resource (question script), and context (business needs discovery). It distinguishes from siblings by mandating this tool before generate_site.

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

Usage Guidelines5/5

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

Explicitly says 'REQUIRED FIRST STEP' and 'ALWAYS call this tool first when a user asks to build/generate a website.' It provides when-not to skip: 'Skipping discovery produces minimal text-only sites.' Also instructs to ask questions one at a time.

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

generate_siteA

Destructive

Generate a new website for a business. Returns a jobId immediately — the build runs asynchronously (~30-90s). Poll get_generation_status to find the site_id + preview URL once it's done.

PREREQUISITE: You MUST have called discover_business_needs first and asked the user the resulting questions. Calling generate_site without a populated businessProfile produces a poor site missing integrations — WhatsApp buttons, Instagram embeds, booking widgets — and that embarrasses both the user and Template Vault.

A populated businessProfile should include AT LEAST: a phone or whatsapp number, hasPhysicalLocation (+ address if true), hasSocialMedia (+ handles if true), and languages. If the user truly refuses discovery, pass { skippedDiscovery: true } so the backend can warn in the admin log.

Content policy: Template Vault declines categories listed at https://www.the-template-vault.com/docs/mcp/content-policy (adult content, hate speech, scams, illegal goods, CSAM, impersonation/phishing). Obvious matches are rejected synchronously with a clear error; subtler cases are caught by the underlying Anthropic model.

Counts against the user's monthly generation quota.

ParametersJSON Schema

Name	Required	Description
`businessName`	Yes	Customer-facing business name. Will be shown in the navbar.
`businessDescription`	Yes	2-3 sentences from the discovery conversation — what they do, who for, vibe. Pull directly from the user's own words; do not invent.
`industry`	Yes	Industry category — e.g. 'wellness', 'restaurant', 'photography', 'pool builder', 'fitness'. Used for SEO + integration detection + personality picking. Be specific (prefer 'pool builder' over 'construction').
`personality`	No	Optional visual personality id (call list_personalities first to see options). If omitted, the AI picks one based on industry + description. NEVER pick `minimal` for a service contractor (pool/electric/plumb/handyman) or restaurant — those need `classic`. NEVER pick `glass` for a service contractor — too cold.
`pageCount`	No	Number of pages to generate (1-4). One-page sites convert best for small businesses.
`locales`	No	Locale codes — e.g. ['en'] or ['en','es'] or ['en','fr']. Max 3. For South Florida businesses always include 'es' alongside 'en' — most customers are bilingual. Each adds ~5s of latency.
`businessProfile`	Yes	REQUIRED for a good result. Drives all integrations + smart-block selection. An empty profile gives a sparse, text-only site.

TDQS

A4.9/5.0

Behavior5/5

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

Discloses async execution (~30-90s), quota consumption, and content policy rejections. Annotations indicate destructiveHint=true and readOnlyHint=false; description aligns with and adds detail about the destructive creation process. No contradiction.

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 description is long but well-structured with sections (prerequisite, content policy). Information is front-loaded, but some redundancy exists (e.g., mentioning async twice). Still efficient for the complexity.

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?

Given the complexity (7 parameters, nested object, async, prerequisites, content policy, quota), the description covers all necessary aspects: return value, polling, prerequisites, edge cases, and restrictions. No output schema, but the polling mechanism is explained.

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

Parameters5/5

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

Schema coverage is 100% with descriptions. The tool description adds extra context: businessProfile is emphasized as required for good results, skippedDiscovery only when user refuses, and specific advice for businessDescription and personality. This significantly enhances understanding.

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 clearly states the tool's purpose: generating a new website. It specifies the async nature and return of a jobId. It distinguishes itself from sibling tools like discover_business_needs and get_generation_status by explaining prerequisites and subsequent polling.

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

Usage Guidelines5/5

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

Explicit prerequisites are given: must call discover_business_needs first. Provides guidance on when to use skippedDiscovery if user refuses. Mentions content policy restrictions. Clearly sets context for tool usage.

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

get_generation_statusA

Read-onlyIdempotent

Check the status of a generation job. Returns status (pending|processing|completed|failed), siteId (when completed), and an estimated progressPercent. Recommended polling interval: 5 seconds. The job typically takes 30-90 seconds total.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes	The jobId returned by generate_site.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate readOnly and idempotent. Description adds context: return fields, timing expectations, and polling behavior, which goes beyond annotations and helps the agent understand usage.

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 concise sentences: purpose, return fields, timing. No redundant information; front-loaded with key action and result.

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?

Given no output schema, the description covers all relevant return fields and timing. For a simple polling tool with one parameter and no nested objects, it is complete.

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% with a clear description for jobId. The description adds value by linking jobId to the output of sibling tool 'generate_site', improving semantic understanding.

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 clearly states the verb 'Check' and resource 'status of a generation job', listing specific return fields (status, siteId, progressPercent). It is distinct from sibling 'generate_site' which creates the job.

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?

Provides explicit polling guidance: recommended interval of 5 seconds and typical job duration of 30-90 seconds. Does not explicitly mention when not to use, but the purpose is well-scoped.

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

list_personalitiesA

Read-onlyIdempotent

List the visual personalities (styles) Template Vault can generate. Use to pick a style that fits the business before calling generate_site.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint. Description adds minimal behavioral context beyond listing styles, no mention of output format.

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 concise sentences, front-loaded with action and resource, no wasted words.

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?

For a simple listing tool with no parameters and no output schema, the description covers necessary info and usage context.

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?

No parameters; schema coverage is 100%. Description adds no param info, which 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?

Clearly states 'List the visual personalities (styles)' with specific verb and resource. Distinguishes from siblings by linking to generate_site.

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?

Explicitly says 'Use to pick a style that fits the business before calling generate_site', providing clear context and prerequisite guidance.

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

list_user_sitesA

Read-onlyIdempotent

List sites owned by the authenticated user. Use to find a siteId before calling publish_site.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint. The description adds no new behavioral traits beyond what annotations provide, but it does not contradict them.

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, no fluff. The first sentence states purpose, the second provides a usage hint. Highly efficient and front-loaded.

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?

Complete for a parameterless tool with no output schema. The description covers purpose and a key usage scenario, leaving no 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?

No parameters exist, and schema coverage is 100%. The description correctly requires no parameter explanation, earning the baseline of 4.

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 clearly states 'List sites owned by the authenticated user', specifying the verb and resource. It also distinguishes this tool from siblings by linking its use to obtaining a siteId for publish_site.

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?

Explicitly says 'Use to find a siteId before calling publish_site', providing a clear use case. However, it does not mention when not to use or compare to other listing tools.

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

publish_siteA

DestructiveIdempotent

Publish a site to production at slug.the-template-vault.com. First publish wires up the GitHub repo + Vercel project; subsequent calls just trigger a Vercel rebuild that picks up the latest config from Supabase.

ParametersJSON Schema

Name	Required	Description	Default
`siteId`	Yes	Site id from list_user_sites or get_generation_status.

TDQS

A3.9/5.0

Behavior4/5

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

Annotations set destructiveHint: true and idempotentHint: true. The description adds behavioral details by explaining the first publish sets up external infrastructure (GitHub, Vercel) and subsequent calls are rebuilds, adding context beyond the annotations. However, it doesn't elaborate on what destruction entails.

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, no redundancy, directly front-loads the core purpose. Every clause adds value, making it highly concise and well-structured.

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?

Given the simple single parameter, no output schema, and annotations covering key hints, the description adequately covers behavioral nuances (first vs subsequent call behavior) and external dependencies, completing the context.

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 sole parameter siteId has a schema description indicating its source ('from list_user_sites or get_generation_status'), providing full schema coverage. The tool description does not add further parameter meaning, so 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 clearly states the tool's action: 'Publish a site to production at slug.the-template-vault.com.' It distinguishes between first publish (wires up GitHub repo + Vercel project) and subsequent calls (triggers Vercel rebuild), differentiating from siblings like generate_site and get_generation_status.

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?

The description implies when to use the tool (to publish a site) but provides no explicit guidance on prerequisites, such as requiring a generated site first, or when not to use it. It does not mention alternatives like generate_site vs publish_site.

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

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: discovery, generation, status polling, style listing, site listing, and publishing. No two tools overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., discover_business_needs, generate_site, list_personalities), making them predictable and easy to understand.

Tool Count5/5

With 6 tools, the set is well-scoped for a website generation server. Each tool serves a necessary step in the workflow without being excessive or insufficient.

Completeness5/5

The tool set covers the entire lifecycle: discovery of business needs, generation, status tracking, style selection, site listing, and publishing. No obvious gaps for the intended domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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 BOAuth
ai.websitepublisher
Build and publish websites through AI conversation.
App Automation Content Management Systems Developer Tools
444
SitesPlaced
com.sitesplaced
Build, edit, and publish real websites and online stores by chatting with your AI assistant.
Content Management Systems E-commerce & Retail
3
website-mcp
one.socialai
Build, edit, stock, and publish Social AI websites and storefronts via AI chat.
Content Management Systems E-commerce & Retail
2
MCPVillage
com.mcpvillage
Build & edit your own website by talking to your LLM: pages, forms, SEO, analytics. Free to start.
Content Management Systems Marketing
2

Related MCP Servers

YesHelloofficial
Marketing Web Scraping Design Tools
yeshello-app
A
license
A
quality
D
maintenance
Digital business cards, lead capture forms, and service listings - built and managed by AI. 63 tools with live browser editing, stock photos, web scraping, and guided tours.
Updated 3 months ago (2026-05-28 05:12 UTC)
6
MIT
essetech-ai-readiness-mcp
AI & Machine Learning
seppez89
A
license
A
quality
D
maintenance
Enables AI assistants to assess a small business's AI readiness (0–100 score), suggest tailored AI use cases, describe Essetech's services, and book a free consultation.
Updated 3 months ago (2026-06-12 07:01 UTC)
4
19
MIT
warpweb-mcp
Content Management Systems Marketing AI & Machine Learning
northbeamsoftware
A
license
A
quality
D
maintenance
Enables building, revising, and deploying AI-generated websites for local service businesses via the Warpweb API, with support for domain management and form webhooks.
Updated 3 months ago (2026-05-22 03:00 UTC)
10
51
1
MIT
founden-mcp
Autonomous Agents Developer Tools
O-mega-Enterprise
A
license
A
quality
C
maintenance
Enables building and iterating on a software company through natural language, returning live preview URLs, without needing a browser.
Updated a month ago (2026-07-25 05:53 UTC)
4
65
MIT

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/julioMeif/template-vault-mcp'

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

Template Vault MCP

What it does

Install

Claude Desktop

Claude.ai (web)

Cursor

ChatGPT (Developer Mode)

Auth & data

Pricing

Content policy

How it works

Open source

Links

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

YesHelloofficial

Latest Blog Posts

MCP directory API