This MCP server lets AI assistants deploy, inspect, edit, and manage live static websites via the Krexel hosting platform. Key capabilities include:
Deploy a site (ship_site): Upload a local build folder to a custom domain. Supports framework hints (Next.js, Astro, Vite, static) and returns a deploy_id and preview URL.
List deployments (list_deploys): View recent deploys from local state, optionally filtered by domain.
Rollback (rollback): Mark a previous deploy as the current good version for a domain.
Inspect deploy logs (get_logs): Retrieve build logs for a specific deploy.
List files (list_files): Get metadata (paths, sizes, SHA256 hashes) for all files in a deployed site.
Read a file (read_file): Fetch the full content of a specific file from a deployed site.
Edit a file (edit_file): Patch a live site using create, replace, replace_all, or delete operations. Changes go live in ~8 seconds as a lightweight patch deploy.
Set environment variables (set_env): Encrypt and persist env vars for a domain using AES-256-GCM encryption.
Check account status (get_status): View account info, deploy count, plan, platform, and state directory.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@krexel-mcp Deploy my new site from the ./dist folder"
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.
Ship AND edit static sites from any AI assistant that speaks the Model Context Protocol.
krexel-mcp is the official MCP server for
Krexel — a "your AI ships and edits your live site"
API. Point any MCP-compatible client (Claude Desktop, Cursor, Windsurf,
VS Code) at this server and your assistant can deploy, list, edit,
rollback, and inspect sites just by talking.
Add krexel-mcp to your MCP client configuration:
{
"mcpServers": {
"krexel": {
"command": "npx",
"args": ["-y", "krexel-mcp"],
"env": {
"KREXEL_API_URL": "https://api.krexel.com",
"KREXEL_API_KEY": "krx_live_••••••••••••••••",
"KREXEL_MASTER_KEY": "<your-32-byte-hex-key>"
}
}
}
}Restart your client. The assistant now sees nine Krexel tools.
Related MCP server: Vercel MCP Server
Tool | What it does |
| Upload a built site folder. Returns a |
| Patch a deployed site (create / replace / replace_all / delete). 0.1 deploy. |
| List the files in a deployed site (path + size + sha256). |
| Read one file's content from a deployed site. |
| List recent deploys from local state. Optional domain filter. |
| Fetch build logs for a deploy. |
| Mark a previous deploy as the current good version. |
| Encrypt and persist an env var for a domain (AES-256-GCM). |
| Return account, deploy count, plan, and state directory. |
AI calls list_files(deploy_id) to see what files exist on the site.
AI calls read_file(deploy_id, path) to read the file it wants to change.
AI generates the new content itself, then calls
edit_file(deploy_id, op: "replace", file, find, value, message).
Krexel ships the patch as a new deploy — live in ~8 seconds, 0.1 deploy
against the customer's quota. The new deploy_id and parent_deploy_id
are returned so the AI can chain further edits on top.
The AI is the brain. Krexel is the hands.
All tools take plain JSON arguments and return JSON. Tool schemas are
discoverable via the standard MCP tools/list request.
Env var | Required | Default | Notes |
| no |
| Base URL of the Krexel orchestrator API. |
| no* |
| Account API key. Forwarded as |
| yes* | — | 32-byte hex string for env-var encryption. *Required for |
State files are written under $KREXEL_HOME (default ~/.krexel/).
MIT © Syfer
Patch a file on a live deployed site and ship a new patch deploy. The AI decides what to change; the MCP ships the patch. Returns the new deploy_id + preview_url.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | create = new file (requires value/content); replace = first match (requires find + value); replace_all = every match (requires find + value); delete = remove file. | |
| file | Yes | Path of the file to create/replace/delete. | |
| find | No | For replace/replace_all: the exact substring to find inside the file's current content. | |
| value | No | For create/replace/replace_all: the new text. | |
| content | No | Alias for value (kept for ergonomics on create). If both given, value wins. | |
| message | No | Optional human-readable note stored with the patch deploy. | |
| deploy_id | Yes | The BASE deploy to patch on top of. The new patch deploy will have this as its parent_deploy_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses key behaviors: applying a patch and deploying, returning deploy_id and preview_url. However, it omits details like failure handling or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words, front-loading the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description mentions return values and overall purpose, but lacks details on error states or side effects of the patch deploy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter well. The description adds minimal additional meaning beyond contextualizing the operations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it patches a file on a live site and ships a patch deploy, distinguishing it from read-only (read_file) or full deploy (ship_site) tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for modifying files and deploying, but no explicit when-not-to-use or alternatives listed among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get build logs for a deploy. In Phase 1 these are mocked from the local manifest; Phase 2 will stream from the orchestrator.
| Name | Required | Description | Default |
|---|---|---|---|
| deploy_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden; it discloses that logs are currently mocked from the local manifest and will stream in Phase 2, which is useful transparency beyond a simple 'get logs'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core function, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the purpose and current behavior (mocked logs). Slightly better than minimal due to the phase context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the deploy_id parameter beyond what the schema provides (type and pattern). The description must compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'build logs for a deploy', distinguishing it from sibling tools like get_status or list_deploys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning Phase 1 and Phase 2, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return current account, deploy count, platform, and state directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it 'Return[s]' data, indicating a read-only operation. With no annotations, the description carries the burden, but it does not disclose potential side effects, authorization needs, or rate limits. For a simple read tool, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and lists the return fields. Every word contributes to understanding the tool's purpose and output, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and a simple function, the description adequately covers what it returns. However, it lacks details such as the format of the output or any limitations. Still, it is sufficient for a straightforward status retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter information. The schema coverage is 100% (by default), and the description adds value by listing the returned fields. For zero-parameter tools, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns account, deploy count, platform, and state directory. It uses a specific verb ('Return') and resource ('status'), making the purpose understandable. However, it does not distinguish itself from siblings like 'get_logs' or 'list_deploys', but given it's a status retrieval, the context implies it's a general overview tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The purpose is implied (e.g., when you need an overview), but there are no exclusions or mentions of when not to use it. This leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent deploys from the local Krexel state file. Optionally filter by domain.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| domain | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions reading from a local file, implying a safe read operation, but omits details such as default limit, ordering, recency definition, and whether network access or auth is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is appropriately brief for a simple tool, though additional details could improve completeness without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and two optional parameters, the description lacks critical context such as default behavior, the meaning of 'recent', and the effect of the limit parameter. It feels incomplete for a tool with these features.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only mentions the 'domain' filter, leaving the 'limit' parameter unexplained. The description does not specify that 'limit' controls the number of results returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (deploys from local Krexel state file), and an optional filter (by domain). It distinguishes from siblings like list_files or get_logs by specifying the source and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing recent deploys but does not provide explicit guidance on when to use this tool versus alternatives such as get_status or rollback. No when-not or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the files in a deployed site (paths, sizes, sha256). Returns metadata only — use read_file to fetch content.
| Name | Required | Description | Default |
|---|---|---|---|
| deploy_id | Yes | The deploy_id returned from ship_site (or any patch deploy). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return type (metadata) and what it does not do (fetch content). Missing details on pagination, error handling, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and result, then key distinction. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and no output schema. Description provides essential purpose and return type, but could detail the structure of the returned objects more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with a description of deploy_id. Tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists files in a deployed site with specific metadata (paths, sizes, sha256). It distinguishes from read_file by noting it returns metadata only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage via mention of read_file for content, but no explicit when-to-use vs other siblings like list_deploys or get_status. Lacks guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a single file's contents from a deployed site. Path is relative to the site root (e.g. 'index.html', 'assets/logo.svg').
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path inside the deploy. No leading slash, no '..'. Examples: 'index.html', 'css/main.css'. | |
| deploy_id | Yes | The deploy_id that contains the file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as that it is a safe read-only operation, authentication requirements, or rate limits. 'Read' implies non-destructive but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences with no wasted words. Front-loaded verb 'Read' immediately conveys purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description adequately states what it does but omits output format (e.g., plain text) and error conditions. With no output schema, these would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds examples for path and clarifies relativity to site root, but does not significantly add beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a single file's contents from a deployed site, using a path relative to the site root with examples. This distinguishes it from siblings like edit_file (modify) and list_files (list names).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (reading file contents) but does not explicitly provide when-not-to-use or mention alternatives. However, the context is clear enough for an AI agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a previous deploy as the current 'last_good' for a domain. Phase 2 will actually push the rollback; Phase 1 just records intent.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | deploy_id to roll back to | |
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals important behavioral details: phase 1 only records intent, not actual rollback. However, it lacks other behavioral context such as required permissions or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no wasted words. Perfectly concise for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and no annotations, the description is fairly complete for a simple tool. It explains the two-phase process, but could benefit from mentioning expected outcome or effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (domain description missing). The description adds no extra meaning beyond the schema: 'to' is described as 'deploy_id to roll back to' which is already in the schema. Domain remains vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('mark a previous deploy as the current 'last_good' for a domain') and distinguishes between phases, indicating a specific verb and resource. It differentiates from sibling tools like 'ship_site' by noting it's phase 1 of a rollback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through phase mention but does not explicitly state when to use this tool versus alternatives like 'ship_site'. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encrypt and persist an environment variable for a domain. Stored at $KREXEL_HOME/env/.enc with AES-256-GCM using KREXEL_MASTER_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes | ||
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses encryption method (AES-256-GCM), storage location (KREXEL_HOME/env/<domain>.enc), and key usage (KREXEL_MASTER_KEY), which is thorough for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Front-loaded purpose in first sentence, technical detail in second. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks parameter semantics, return value info, and potential side effects (e.g., overwriting). With 3 required params and no output schema, more detail is needed for full comprehension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the meaning of 'key', 'value', or 'domain' parameters. It adds no clarification beyond the schema's field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it encrypts and persists an environment variable for a domain, using specific verb+resource. It distinguishes from siblings like edit_file or read_file, which are unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or side effects. It only explains the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a built site folder to Krexel. Zips the folder, stages it locally, and POSTs to the Krexel orchestrator API. Returns a deploy_id (always) and preview_url. If the orchestrator is unreachable the response carries an api_ok: false flag with the upstream error — never fakes success.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Custom domain to attach (e.g. shop.example.com). | |
| folder | Yes | Absolute or ~-relative path to the built site directory. | |
| framework | No | Build framework hint. Default 'auto' detects from package.json. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses error handling (api_ok: false, never fakes success) and return values (deploy_id, preview_url). No annotations exist, so description carries burden. Could mention permissions or idempotency, but sufficient for core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences, front-loaded with purpose, then returns, then error behavior. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main actions, error handling, and returns. Could mention preconditions (folder must exist, domain valid) or duration, but adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Overall description does not add meaning beyond schema for individual params; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb (upload), resource (built site folder to Krexel), and process (zips, stages, POSTs). Distinguishes from sibling tools like edit_file or rollback by its deploy-focused action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for deploying a built folder, but no explicit when-not-to-use or alternatives. Sibling context helps, but description lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.1edit_fileget_logsget_statuslist_deployslist_filesread_filerollbackset_envship_siteEach tool serves a distinct purpose: editing files, getting logs, status, listing deploys, listing files, reading files, rolling back, setting env vars, and shipping sites. No two tools have overlapping responsibilities, making it easy for an agent to select the correct one.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., edit_file, get_logs, list_deploys). Even 'rollback' is a clear single verb. No mixing of conventions or styles.
With 9 tools, the server covers the core deployment lifecycle without being overwhelming. The count is well-scoped for a focused platform like Krexel, allowing efficient agent interaction.
The tool set covers primary deployment operations: create (ship_site, edit_file), read (list_deploys, get_logs, get_status, list_files, read_file), update (edit_file, set_env), and delete (implied via rollback). Minor gaps like explicit env variable listing or deploy deletion are absent but not critical for basic workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deploy a GitHub repo to a live HTTPS URL from your AI tool; read logs, set variables, resize apps.
Deploy files, sites, and Dockerfile apps to live URLs + private drives for agent memory.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
Deploy and manage your apps, databases, storage, and scheduled jobs from your AI agent
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Syfer-web/krexel-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
