Provides access to Laravel-specific documentation, coding rules, CRUD templates, and validation checklists to assist in Laravel application development and architectural decision-making.
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., "@Laravel AI MCP Server search the docs for database transactions and show me the CRUD templates"
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.
MCP (Model Context Protocol) server for providing Laravel AI documentation to Claude Code and other AI assistants.
# Clone or navigate to the project directory
cd laravel-ai
npm installnpm startDocumentation is expected to be in: ./docs (relative to project root)
Related MCP server: directory-indexer
Add to your Claude Code settings (~/.config/claude-code/config.json):
{
"mcpServers": {
"laravel-ai": {
"command": "node",
"args": ["path/to/laravel-ai/index.js"]
}
}
}If your documentation is in a different location:
{
"mcpServers": {
"laravel-ai": {
"command": "node",
"args": ["path/to/laravel-ai/index.js"],
"env": {
"DOCS_PATH": "/path/to/your/docs"
}
}
}
}Tool | Description |
| Get all documentation files structure |
| Read a specific documentation file |
| Search across all documentation |
| Get all coding rules (quick-reference.md) |
| Get CRUD templates (specific or all) |
| Get validation checklist (specific layer or all) |
| Get domain-specific examples |
| Get design system documentation |
laravel-ai/
├── docs/ # Documentation folder
│ ├── ai/
│ │ ├── quick-reference.md # All coding rules
│ │ ├── templates.md # Implementation templates
│ │ └── checklist.md # Validation checklist
│ ├── domains/
│ │ ├── ecommerce/ # E-commerce examples
│ │ ├── hr/ # HR examples
│ │ └── tourism/ # Tourism examples
│ ├── patterns/ # Pattern documentation
│ └── design-system.md # Design system (configurable)
├── index.js # MCP server
├── package.json # Dependencies
└── README.md # This fileWhen user says "pelajari docs", AI should:
// 1. Get quick reference
mcp.call_tool('get_quick_reference')
// 2. Get templates
mcp.call_tool('get_templates', { template_type: 'all' })
// 3. Get checklist
mcp.call_tool('get_checklist', { layer: 'all' })
// 4. Confirm ready// Search for "transaction"
mcp.call_tool('search_docs', { query: 'transaction' })// Get e-commerce examples
mcp.call_tool('get_domain_examples', { domain: 'ecommerce' })
// Get all domains overview
mcp.call_tool('get_domain_examples', { domain: 'all' })npm run devTest the MCP server manually:
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node index.jsThis server uses stdio transport for communication
All documentation is read from the file system
No caching - always reads latest documentation
Supports incremental updates to documentation
When documentation is updated, just restart the MCP server:
# Stop current server (Ctrl+C)
npm startVersion: 1.0.0 Last Updated: 2026-02-23
Get code validation checklist
| Name | Required | Description | Default |
|---|---|---|---|
| layer | No | Layer to get checklist for, or "all" for everything |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Get' implies a read operation, but the description doesn't specify whether this requires authentication, what format the checklist returns in, whether there are rate limits, or if it's a cached/real-time operation. For a tool with zero annotation coverage, this is insufficient.
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 'Get code validation checklist' is extremely concise - just four words that communicate the core purpose. There's zero wasted language, and the most important information (what the tool does) is front-loaded.
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 tool with no annotations and no output schema, the description is too minimal. It doesn't explain what a 'code validation checklist' contains, what format it returns, or how it differs from related tools. The agent would need to guess about the output format and behavioral characteristics.
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 schema description coverage is 100%, with the single parameter 'layer' fully documented in the schema including its enum values. The description adds no additional parameter information beyond what's already in the structured schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get code validation checklist' clearly states the action (get) and resource (code validation checklist), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings like 'get_design_system' or 'get_templates' - all appear to be retrieval operations for different types of content.
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. While the parameter description mentions 'all' for everything, there's no explicit when/when-not guidance or mention of sibling tools that might serve related purposes like 'get_templates' or 'search_docs'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get design system documentation
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Get') without detailing traits such as whether it's read-only, requires authentication, has rate limits, or what the output format might be. For a tool with no annotations, this is a significant gap in describing how it behaves beyond the basic purpose.
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 'Get design system documentation' is a single, efficient sentence that front-loads the core purpose with zero waste. It's appropriately sized for a simple tool with no parameters, making it easy to parse and understand quickly.
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 annotations, no output schema, and 0 parameters, the description is minimal. While it states the purpose, it lacks context on behavior, output format, or differentiation from siblings. For a tool in a set with multiple documentation-related siblings, this leaves the agent with incomplete information to use it effectively.
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 input schema has 0 parameters with 100% coverage, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it appropriately avoids unnecessary details. Baseline is 4 for zero parameters, as the description doesn't mislead or omit parameter information.
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 'Get design system documentation' states a clear verb ('Get') and resource ('design system documentation'), making the purpose understandable. However, it's somewhat vague about what 'design system documentation' entails and doesn't distinguish it from sibling tools like 'get_doc_structure' or 'read_doc', which might have overlapping functions. It avoids being a tautology of the name but lacks specificity.
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. With siblings like 'get_doc_structure', 'get_domain_examples', and 'read_doc', there's no indication of context, prerequisites, or exclusions. This leaves the agent without direction on selecting the appropriate tool for retrieving documentation-related information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the structure of all available documentation files
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't describe what 'structure' means (e.g., hierarchical layout, metadata), whether it's a read-only operation, potential rate limits, or the response format. This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
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 0 parameters, no annotations, and no output schema, the description is minimally adequate but lacks depth. It doesn't explain what 'structure' entails or provide behavioral context, which could be important for documentation retrieval. However, the simplicity of the tool (no inputs) reduces the need for extensive detail.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but that's appropriate given the schema's completeness. A baseline of 4 is applied as it adequately handles the lack of parameters.
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 'structure of all available documentation files', making the purpose understandable. However, it doesn't specifically differentiate this tool from sibling tools like 'get_design_system' or 'read_doc', which might also relate to documentation access.
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 like 'search_docs' or 'read_doc'. It lacks any context about prerequisites, timing, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get domain-specific implementation examples
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain to get examples for, or "all" for overview |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'gets' examples, implying a read operation, but doesn't disclose behavioral traits such as whether it returns structured data, text, or code; if there are rate limits; authentication needs; or what happens with invalid domains. This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence with no wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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, the description is incomplete. It doesn't explain what the examples include (e.g., code snippets, best practices), the format of the return value, or error handling. For a tool that fetches domain-specific content, more context is needed to guide effective 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?
The input schema has 100% description coverage, clearly documenting the 'domain' parameter with an enum. The description adds no additional meaning beyond the schema, as it doesn't explain what 'examples' entail or how the 'all' option differs from specific domains. With high schema coverage, the baseline is 3.
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 'Get domain-specific implementation examples' states a clear verb ('Get') and resource ('domain-specific implementation examples'), but it's vague about what these examples actually are or contain. It doesn't distinguish this tool from siblings like 'get_templates' or 'get_design_system', which might also provide examples or resources.
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 guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, and with siblings like 'get_templates' and 'get_design_system', there's no indication of how this tool differs or when it's preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the quick reference documentation (all coding rules)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't describe how the documentation is returned (e.g., format, structure, or pagination), whether it requires authentication, or any rate limits. This is a significant gap for a tool with zero annotation coverage.
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, efficient sentence with zero waste. It front-loads the purpose ('Get the quick reference documentation') and adds clarifying scope ('all coding rules') without unnecessary details, making it easy to parse.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'quick reference documentation' entails (e.g., format, content structure) or the return behavior, leaving the agent uncertain about the tool's output. For a tool with rich context (siblings like 'search_docs'), more guidance is needed.
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 input schema has 0 parameters with 100% description coverage, so the schema fully documents the lack of parameters. The description adds no parameter information, which is appropriate here. Baseline is 4 for 0 parameters, as no compensation is needed.
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 resource ('quick reference documentation') with a specific scope ('all coding rules'). It distinguishes from siblings like 'get_checklist' or 'get_templates' by focusing on coding rules documentation. However, it doesn't explicitly differentiate from 'read_doc' or 'search_docs' which might also retrieve documentation.
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 like 'read_doc' or 'search_docs' for documentation retrieval. It doesn't mention prerequisites, exclusions, or specific contexts where this tool is preferred, leaving 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.
Get implementation templates for CRUD operations
| Name | Required | Description | Default |
|---|---|---|---|
| template_type | No | Template type to get, or "all" for everything |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get implementation templates', implying a read-only operation, but doesn't specify if it's safe, requires authentication, has rate limits, or what the return format looks like (e.g., code snippets, files). This leaves significant gaps in understanding the tool's 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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse and understand quickly.
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, the description is incomplete. It doesn't explain what the tool returns (e.g., templates as text, files, or structured data), potential errors, or usage constraints. For a tool with no structured behavioral data, more detail is needed to ensure the agent can use it effectively.
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 input schema has 100% description coverage, with a clear parameter 'template_type' and an enum list. The description mentions 'CRUD operations', which adds context about the templates' purpose, but doesn't provide additional semantics beyond what the schema already documents, such as default behavior or examples. With high schema coverage, a baseline score of 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?
The description clearly states the verb 'Get' and the resource 'implementation templates for CRUD operations', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_design_system' or 'get_domain_examples', which might also provide templates or examples, so it doesn't reach the highest score.
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 like 'get_domain_examples' or 'get_quick_reference'. It lacks context on prerequisites, such as whether it's for specific frameworks or languages, and doesn't mention any exclusions or best practices for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a specific documentation file
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the documentation file relative to docs root |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool reads a file but doesn't disclose behavioral traits such as what happens if the file doesn't exist (e.g., error handling), whether it requires authentication, rate limits, or the format of the returned content (e.g., plain text, structured data). This leaves significant gaps for a tool that interacts with files.
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, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to scan. Every word earns its place by conveying essential information without 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?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It lacks details on error handling, return format, or operational context (e.g., file system access, permissions). For a read operation, this minimal description leaves too many unknowns for effective use by an AI agent.
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 input schema has 100% description coverage, with the parameter 'file_path' documented as 'Path to the documentation file relative to docs root'. The description adds no additional meaning beyond this, such as examples of valid paths or constraints. With high schema coverage, the baseline is 3, as the schema does the heavy lifting.
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 'Read a specific documentation file' clearly states the action (read) and resource (documentation file). It distinguishes from siblings like 'search_docs' (searching) and 'get_doc_structure' (structural overview), but doesn't explicitly contrast with 'get_domain_examples' or 'get_templates' which might also read files. The purpose is specific but could be more precise about what distinguishes it from all siblings.
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. It doesn't mention prerequisites (e.g., needing a valid file path), exclusions (e.g., not for searching or listing), or comparisons to siblings like 'search_docs' for broader queries or 'get_doc_structure' for metadata. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for content across all documentation files
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical details: it doesn't specify the search scope (e.g., full-text, metadata), result format, pagination, or any limitations (e.g., rate limits, authentication needs). This leaves significant gaps for an agent to understand how the tool behaves.
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 zero wasted words. It's front-loaded with the core action ('search') and resource, making it highly efficient and easy to parse at a glance.
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, the description is incomplete for a search tool. It doesn't explain what the search returns (e.g., list of documents, snippets), how results are ordered, or any behavioral traits like error handling. This makes it inadequate for an agent to fully understand the tool's context and usage.
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 100%, with the single parameter 'query' fully documented in the schema. The description adds no additional meaning beyond implying a search operation, which aligns with the schema but doesn't provide extra context like query syntax or examples. This meets the baseline for high schema coverage.
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 ('search') and resource ('content across all documentation files'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'read_doc' or 'get_doc_structure' beyond the general search functionality, which prevents a perfect score.
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. With sibling tools like 'read_doc' (likely for reading specific documents) and 'get_doc_structure' (likely for structural information), there's no indication of when searching is preferred over direct retrieval or structural queries.
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.
v1.0.0get_checklistget_design_systemget_doc_structureget_domain_examplesget_quick_referenceget_templatesread_docsearch_docsEvery tool has a clearly distinct purpose with no ambiguity. The tools target different aspects of documentation retrieval: checklists, design systems, structures, examples, references, templates, specific files, and search. There is no overlap in functionality.
All tools follow a consistent verb_noun pattern using snake_case. Each name starts with 'get_' or a similar verb ('read_', 'search_') followed by a descriptive noun, making the set predictable and readable.
With 8 tools, the server is well-scoped for its purpose of providing Laravel documentation and resources. Each tool earns its place by covering a specific aspect of documentation retrieval, avoiding bloat or thinness.
The tool surface is complete for the domain of documentation access, covering all key operations: retrieving specific files, searching, getting structured overviews, examples, templates, and references. There are no obvious gaps that would hinder an agent's workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Versioned documentation registry and semantic search for AI tools and coding assistants.
Serves your design system and coding standards to coding agents, so they stop guessing.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pujandan/mcp-laravel'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
