How do I use Igniral MCP Server?

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., "@Igniral MCP Server Build a REST API for a gym management system" 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.

Igniral MCP Server

Official

by Igniral

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Igniral MCP Server

Igniral — Production-Ready Backends with AI Speed

Model Context Protocol (MCP) server that bridges AI agents (Claude, Cursor, Antigravity, etc.) with Igniral's backend platform. Describe your API in plain English — Igniral generates the schema, CRUD endpoints, authentication, Swagger docs, and antivirus-protected file storage automatically.

What is Igniral?

Igniral lets you generate 100% of your API infrastructure with a simple prompt, or build manually using a Visual Schema Builder. Everything is production-ready from the start:

🤖 AI-Powered Generation — Describe your data model, get a complete REST API instantly
🔐 Built-in Auth & RBAC — JWT authentication with role-based access control, no auth code needed
📄 Always-Sync Swagger — OpenAPI docs update automatically with every change
🛡️ Antivirus File Storage — Every uploaded file is scanned by ClamAV before reaching your infrastructure
📊 Real-time Analytics — Monitor API usage, error rates, and traffic from your dashboard
🗄️ Managed Database — Automatic backups and replication, zero DBA required

Get started for free at igniral.com → Start Now

Related MCP server: agnt

Prerequisites

Create an Igniral account at igniral.com (free tier available)
Generate Agent API Keys from the Igniral Dashboard → Agent API Keys
Have Node.js ≥ 18 installed on your machine

Important: This is an MCP server — it runs inside your AI-powered IDE (Claude Desktop, Cursor, Antigravity, etc.), not directly from the terminal. You configure it once in your IDE settings, and the IDE handles starting and stopping it automatically.

Quick Start

Choose your IDE and add the following configuration. Replace agent-xxxxxxxxxxxx and your-client-secret with your actual Agent API Key credentials.

Claude Desktop

Edit your claude_desktop_config.json:

{
  "mcpServers": {
    "igniral": {
      "command": "npx",
      "args": ["-y", "igniral-mcp-server"],
      "env": {
        "IGNIRAL_CLIENT_ID": "agent-xxxxxxxxxxxx",
        "IGNIRAL_CLIENT_SECRET": "your-client-secret"
      }
    }
  }
}

Cursor

Edit your .cursor/mcp.json:

{
  "mcpServers": {
    "igniral": {
      "command": "npx",
      "args": ["-y", "igniral-mcp-server"],
      "env": {
        "IGNIRAL_CLIENT_ID": "agent-xxxxxxxxxxxx",
        "IGNIRAL_CLIENT_SECRET": "your-client-secret"
      }
    }
  }
}

Antigravity (Google)

Edit ~/.gemini/antigravity/mcp_config.json:

{
  "mcpServers": {
    "igniral": {
      "command": "npx",
      "args": ["-y", "igniral-mcp-server"],
      "env": {
        "IGNIRAL_CLIENT_ID": "agent-xxxxxxxxxxxx",
        "IGNIRAL_CLIENT_SECRET": "your-client-secret"
      }
    }
  }
}

Note: Antigravity may not inherit your shell's PATH. Use the absolute path to node (e.g., /opt/homebrew/Cellar/node/25.9.0_2/bin/node) if you get "executable not found" errors.

That's it! After saving the configuration and restarting your IDE, you can ask your AI agent things like:

"Build me a gym management API"
"Create a REST API for a pet store with products, orders, and users"
"List my existing Igniral applications"

Tools

Once configured, the following tools are available to your AI agent:

Tool	Description
`igniral_generate_schema_from_prompt`	Auto-generate a complete app from a natural language description
`igniral_create_application`	Create an empty application shell manually
`igniral_create_dynamic_endpoint`	Add API endpoints to an existing application
`igniral_list_applications`	List the user's existing applications

Architecture

AI Agent (Claude/Cursor)
    │
    ▼ (MCP Protocol - stdio)
┌──────────────────────────┐
│   Igniral MCP Server     │
│   ├─ TokenManager        │  ← OAuth2 client_credentials
│   ├─ Zod Validation      │
│   ├─ SSE Client          │
│   └─ HTTP Client         │
└────────────┬─────────────┘
             │ (HTTP + JWT with sub=userId)
     ┌───────┼───────┐
     ▼       ▼       ▼
auth-     ai-schema-  json-elements
server    builder     microservice
(token)   (auto-gen)  (CRUD)

Environment Variables

Variable	Required	Description
`IGNIRAL_CLIENT_ID`	✅	Agent API Key client ID (from Dashboard)
`IGNIRAL_CLIENT_SECRET`	✅	Agent API Key client secret (shown once at creation)
`IGNIRAL_AUTH_URL`	❌	Auth server URL (default: `https://auth.igniral.com`)
`IGNIRAL_API_URL`	❌	API URL (default: `https://api.igniral.io`)
`IGNIRAL_AI_API_URL`	❌	AI API URL (default: `https://ai.igniral.com`)

Development (from source)

Only needed if you want to contribute or modify the server:

git clone https://github.com/igniral/igniral-mcp-server.git
cd igniral-mcp-server
npm install
cp .env.example .env   # Edit with your credentials
npm run dev             # Start in development mode
npm run inspect         # Test with MCP Inspector

License

MIT

Available Tools

5 tools

igniral_create_applicationA

Creates an empty application shell (without endpoints). Use this when the user wants to manually build an application step by step, providing a specific name, description, and settings.

After creating the application, use igniral_create_dynamic_endpoint to add API endpoints one by one. Returns the applicationId needed for creating endpoints.

Do NOT use this after igniral_generate_schema_from_prompt — that tool already creates the application automatically.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Name of the application (e.g., 'GymApp', 'Pet Store API')
`description`	Yes	Description of what the application does
`version`	No	API version (default: 'v1')
`subdomain`	No	Custom subdomain for the API (lowercase, hyphens allowed). If not provided, one is generated automatically.
`aiGeneratedContext`	No	AI-generated context/documentation for the application
`isPrivate`	No	Whether the app is private (default: true). Private apps require authentication for all endpoints. Public apps can have some endpoints visible without auth.

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses creation of empty shell, return of applicationId, and inability to create endpoints. Lacks details on safety (creation is typically non-destructive) and authentication requirements.

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?

Concise multiple sentences, each adding value. Front-loaded with key purpose, no wasted words.

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

Completeness4/5

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

Despite lack of output schema, description explains return of applicationId. Context of workflow is provided. 6 parameters with full schema descriptions, but no details on output format beyond applicationId.

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

Parameters3/5

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

Schema coverage is 100%, so parameters are well-documented in schema. Description mentions name, description, and settings but adds no extra semantic value beyond 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?

Description clearly states it creates an empty application shell without endpoints. It distinguishes from siblings by explicitly mentioning the workflow: use after this tool for endpoints, and do not use after schema generation.

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?

Provides explicit when-to-use: manual step-by-step building. Gives clear exclusions: do not use after igniral_generate_schema_from_prompt. Directs to sibling tool for adding endpoints.

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

igniral_create_dynamic_endpointA

Creates a dynamic API endpoint within an existing application. Requires an applicationId from a previous igniral_create_application call.

Use this iteratively to add all needed endpoints to the application. Each endpoint defines its data schema (JSON Schema format), HTTP methods, visibility (PUBLIC/PRIVATE), and security policy.

Security policies:

NONE: Anyone with role permissions sees all data
OWNER_ONLY: Users only see data they created (most common for personal data)
CLAIM_FILTER: Filter data based on JWT claims (requires securityConfig)

ParametersJSON Schema

Name	Required	Description
`applicationId`	Yes	ID of the application to add the endpoint to
`endpointPath`	Yes	URL path for the endpoint (e.g., '/products', '/users', '/orders'). Must start with / and use lowercase letters, numbers, and hyphens.
`allowedMethods`	Yes	HTTP methods to enable: ['GET', 'POST', 'PUT', 'DELETE']. Include all methods the endpoint should support.
`schemaDefinition`	Yes	JSON Schema defining the data structure for this endpoint. Must include "$schema", "type": "object", and "properties". Each property needs a type (string, number, integer, boolean, array, object).
`type`	No	Endpoint type: 'JSON' for data APIs (default), 'FILE' for file uploads
`visibility`	No	Endpoint visibility: 'PRIVATE' (default, requires auth) or 'PUBLIC' (accessible without auth, only for public apps)
`securityPolicy`	No	Data access control: 'NONE' (shared data), 'OWNER_ONLY' (users see only their data), 'CLAIM_FILTER' (filter by JWT claims, requires securityConfig)
`securityConfig`	No	Required when securityPolicy is 'CLAIM_FILTER'. Defines which JWT claim maps to which data field for filtering.
`endpointDocumentation`	No	Human-readable documentation for this endpoint

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses the creation action, required parameters, and explains security policies with their implications. It does not describe failure modes, rate limits, or detailed auth flows, but the iterative use and policy explanations add substantial behavioral context.

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 well-structured: purpose first, then prerequisites, usage pattern, and options. It is concise without being overly terse, and each sentence adds meaningful context. A slight improvement could be more front-loaded with security policy overview.

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

Completeness4/5

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

Given 9 parameters (4 required), no output schema, and no annotations, the description provides adequate context: how to use iteratively, what to provide, and policy details. It omits return values and error conditions, but the core workflow is clearly explained.

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%, so baseline is 3. The description adds value by explaining how parameters interact, e.g., 'securityPolicy' with 'securityConfig', and provides high-level context for 'schemaDefinition' (JSON Schema format). This goes beyond the schema's individual parameter descriptions.

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-resource ('Creates a dynamic API endpoint') and explicitly ties it to an existing application, distinguishing it from siblings like 'igniral_update_dynamic_endpoint' and 'igniral_create_application'.

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?

The description specifies the prerequisite ('Requires an applicationId from a previous igniral_create_application call') and recommends iterative use ('Use this iteratively to add all needed endpoints'). It lacks explicit when-not-to-use guidance but provides sufficient operational context.

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

igniral_generate_schema_from_promptA

Generates a complete application from a natural language description. This tool creates the application, ALL endpoints with their JSON schemas, roles, and permissions automatically.

Use this when the user gives a general or ambiguous instruction like "build me a gym management app" or "create an API for a restaurant".

You do NOT need to call igniral_create_application or igniral_create_dynamic_endpoint after this — everything is created automatically. This may take 30-90 seconds to complete.

Returns the applicationId and a summary of what was created.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes	Natural language description of the application to generate. Be as detailed as possible about what the app should do and what data it should manage. Minimum 10 characters.

TDQS

A4.9/5.0

Behavior5/5

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

Despite no annotations, the description discloses behavioral traits: it creates everything automatically, takes 30-90 seconds, and returns applicationId and summary. This informs the agent of side effects and performance.

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 with three short paragraphs. Each sentence serves a purpose: stating the core function, providing usage context, and detailing outcomes. No unnecessary 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?

Given the single parameter and no output schema, the description covers all necessary context: what the tool does, when to use it, what not to do, timing, and return value. It is fully 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%, so baseline is 3. The description adds value by advising to be as detailed as possible and mentioning the 10-character minimum, enhancing 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 states 'Generates a complete application from a natural language description' with a clear verb and resource. It distinguishes from siblings by noting that igniral_create_application and igniral_create_dynamic_endpoint are unnecessary after this tool.

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 'Use this when the user gives a general or ambiguous instruction' and advises against calling other tools afterward, providing clear when-to-use and when-not-to-use guidance.

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

igniral_list_applicationsA

Lists all applications owned by the current user. Use this to check what applications already exist before creating new ones, or to get the applicationId of an existing application.

Takes no parameters — the user is identified by the configured service token.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that no parameters are needed and that the user is identified via a service token, indicating authentication context. It does not mention any destructive or side effects, which is appropriate for a listing tool.

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 consists of three short, front-loaded sentences. The first sentence states the purpose, the second explains usage, and the third clarifies parameters. Every sentence is necessary and concise, with no wasted words.

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

Completeness4/5

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

The tool has no output schema, but the description covers purpose, usage, and authentication. For a simple listing tool, it is adequately complete. It does not specify return format or pagination, but given the simplicity, the information provided is sufficient for an agent to decide and invoke correctly.

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?

There are 0 parameters, and the schema coverage is 100% (empty schema). The description adds value by confirming 'Takes no parameters — the user is identified by the configured service token,' which clarifies the lack of input. Baseline for 0 parameters is 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 'Lists all applications owned by the current user.' This is a specific verb+resource, and it distinguishes itself from sibling tools like igniral_create_application (create) and igniral_update_dynamic_endpoint (update).

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?

The description provides explicit usage context: 'Use this to check what applications already exist before creating new ones, or to get the applicationId of an existing application.' It implies when to use (before creation) and what to extract, though it does not explicitly list alternatives.

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

igniral_update_dynamic_endpointA

Updates a dynamic API endpoint within an existing application. Requires an endpointId from a previous list_applications call.

Use this to modify the schema or configuration of an already existing endpoint.

ParametersJSON Schema

Name	Required	Description
`endpointId`	Yes	ID of the endpoint to update
`applicationId`	Yes	ID of the application the endpoint belongs to
`endpointPath`	Yes	URL path for the endpoint (e.g., '/products', '/users', '/orders'). Must start with / and use lowercase letters, numbers, and hyphens.
`allowedMethods`	Yes	HTTP methods to enable: ['GET', 'POST', 'PUT', 'DELETE']. Include all methods the endpoint should support.
`schemaDefinition`	Yes	JSON Schema defining the data structure for this endpoint. Must include "$schema", "type": "object", and "properties". Each property needs a type (string, number, integer, boolean, array, object).
`type`	No	Endpoint type: 'JSON' for data APIs (default), 'FILE' for file uploads
`visibility`	No	Endpoint visibility: 'PRIVATE' (default, requires auth) or 'PUBLIC' (accessible without auth, only for public apps)
`securityPolicy`	No	Data access control: 'NONE' (shared data), 'OWNER_ONLY' (users see only their data), 'CLAIM_FILTER' (filter by JWT claims, requires securityConfig)
`securityConfig`	No	Required when securityPolicy is 'CLAIM_FILTER'. Defines which JWT claim maps to which data field for filtering.
`endpointDocumentation`	No	Human-readable documentation for this endpoint

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only states it 'updates' and 'modifies the schema or configuration' without detailing whether it performs a partial patch or full replacement, any side effects, authorization needs, or response format. This lack of behavioral context is a significant gap for an update operation.

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 two concise sentences, front-loading the primary action and a key prerequisite. There is no redundancy or filler, and it efficiently conveys the core purpose. However, it could be slightly more structured with separate usage notes.

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?

Given the tool has 10 parameters and no output schema or annotations, the description is too sparse. It fails to explain important aspects like idempotency, partial update behavior, response structure, or error conditions. The description leaves the agent with insufficient behavioral and operational context for a complex update tool.

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 description coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema, merely echoing that it modifies schema or configuration. It does not explain how parameters relate to each other or provide usage examples, leaving the schema to carry the full burden.

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 'Updates' and the resource 'dynamic API endpoint', specifying it operates within an existing application. It distinguishes from sibling tools like 'create_dynamic_endpoint' by focusing on modification of an already existing endpoint, and explicitly mentions the prerequisite of an endpointId from list_applications.

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?

The description indicates when to use the tool (to modify an existing endpoint) and mentions a prerequisite (endpointId from list_applications). However, it does not explicitly exclude alternative tools for different scenarios, such as creating a new endpoint, which is left implicit given the sibling tool names.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv1.0.6Jun 18, 2026
- First observedigniral_create_application
- First observedigniral_create_dynamic_endpoint
- First observedigniral_generate_schema_from_prompt
- First observedigniral_list_applications
- First observedigniral_update_dynamic_endpoint

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct action: creating an empty app, adding endpoints, generating full app from prompt, listing apps, and updating endpoints. The descriptions explicitly warn against using create_application after generate_schema_from_prompt, reducing ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with the prefix 'igniral_': create_application, create_dynamic_endpoint, generate_schema_from_prompt, list_applications, update_dynamic_endpoint. Minor length variation does not break consistency.

Tool Count5/5

5 tools is well-scoped for the domain of application and dynamic endpoint management. It covers creation (two modes), listing, and updating without being overly numerous or sparse.

Completeness3/5

The set covers creation, listing, and update operations but lacks any delete functionality (e.g., delete endpoint or delete application). This is a notable gap that could hinder agent workflows requiring removal.

Maintenance

ActivityInactive

ResponsivenessSyncing

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

gjallaOAuth
io.gjalla
Production-readiness for your AI coding agents.
Coding Agents Agent Orchestration
22
Eyevinn Open Source CloudOAuth
io.osaas.mcp
Your AI Agent's Infrastructure Layer. Connect Claude, Copilot, Codex, or ChatGPT to 200+ managed open source services. Start databases, pipelines, and applications through natural language.
Cloud Platforms Agent Orchestration Developer Tools
2
mcpOAuth
io.github.seldonframe
Build, deploy, and sell AI agents for local-service businesses - from your IDE.
Agent Orchestration Autonomous Agents
24
Orchard — Agentic Cloud BackendOAuth
io.github.Nicha404
Managed database, auth, file storage, email, analytics, and deployment for coding agents.
Cloud Platforms Developer Tools
2

Related MCP Servers

Neptune MCP Server
Cloud Platforms CI/CD & DevOps Autonomous Agents
shuttle-hq
A
license
B
quality
C
maintenance
Enables AI agents to deploy applications to AWS with DevOps capabilities by automatically inferring infrastructure needs from code and generating inspectable Infrastructure as Code specifications.
Updated 8 months ago (2026-01-08 12:07 UTC)
15
15
Apache 2.0
agnt
Developer Tools Browser Automation Code Execution
standardbeagle
A
license
Not graded
quality
A
maintenance
Bridges AI coding agents with the browser to provide visual debugging, real-time error capture, screenshot capabilities, DOM inspection, and interactive wireframing through a reverse proxy with injected developer tools.
Updated a day ago (2026-09-05 05:35 UTC)
58
19
Apache 2.0
golive-mcp
CI/CD & DevOps Version Control
abbylester1
A
license
Not graded
quality
A
maintenance
Enables AI agents to deploy code to any hosting provider by creating PRs, building, and verifying health checks, all from a single natural language command.
Updated 9 days ago (2026-08-28 13:40 UTC)
1
MIT
Jerrycan MCP
Coding Agents Autonomous Agents Developer Tools
backant-io
A
license
Not graded
quality
A
maintenance
The AI-native Rust backend framework + generation platform. Help agents design, generate, verify and package complete backends.
Updated a month ago (2026-08-10 22:16 UTC)
9
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/Igniral/igniral-mcp-server'

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

Igniral MCP Server

What is Igniral?

Prerequisites

Quick Start

Claude Desktop

Cursor

Antigravity (Google)

Tools

Architecture

Environment Variables

Development (from source)

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API