Filament MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.0.1-beta
Disambiguation4/5
Most tools have distinct purposes, such as discovering docs, generating plans, getting commands, and fetching components. However, there is some overlap between filament_discover_docs, filament_get_docs, filament_list_docs, and filament_search_docs, which all relate to documentation access and could cause confusion about which to use for specific queries.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with the prefix 'filament_' and a clear verb_noun structure, such as filament_get_component and filament_list_components. This predictability makes it easy for agents to understand and select tools based on their naming conventions.
Tool Count5/5
With 10 tools, the server is well-scoped for assisting with Filament PHP development, covering key areas like documentation, components, commands, and planning. Each tool appears to serve a specific function without redundancy, making the count appropriate for the domain.
Completeness4/5
The tool set provides comprehensive coverage for Filament development tasks, including documentation retrieval, component management, and implementation planning. A minor gap is the lack of tools for creating or modifying Filament resources, such as generating code or updating components, which might limit full lifecycle support.
Average 2.7/5 across 10 of 10 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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 'Generate' implies a write or creation operation, but doesn't specify if this is read-only, destructive, requires authentication, has rate limits, or what the output entails (e.g., a plan document, code snippets). This is inadequate 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.
Conciseness5/5
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 and appropriately sized for the tool's name, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters with nested objects), lack of annotations, no output schema, and low schema coverage, the description is severely incomplete. It doesn't address behavioral traits, parameter meanings beyond the schema, or what the tool returns, making it inadequate for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 33%, with only the 'description' parameter documented. The description adds no information about parameters like 'version' or 'models', failing to compensate for the coverage gap. It doesn't explain what 'models' represent or how they influence the plan, leaving key inputs ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate a Filament implementation plan' restates the tool name 'filament_generate_plan' almost verbatim, making it tautological. It doesn't specify what constitutes an 'implementation plan' or what resources it generates, nor does it differentiate from siblings like filament_get_commands or filament_list_components, which might provide related functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 (e.g., during development setup), or exclusions, leaving the agent to guess based on the name alone among multiple sibling tools focused on documentation and components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 without details on permissions, rate limits, output format, pagination, or side effects. For a list operation with zero annotation coverage, this is inadequate and fails to inform the agent about 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core action, making it easy to parse quickly, though it lacks depth.
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's complexity (2 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, error handling, or how parameters interact, leaving significant gaps for the agent to infer behavior, which reduces effectiveness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'category' but doesn't explain what it means or list the enum values. It omits the 'version' parameter entirely. This adds minimal semantic value beyond the bare schema, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('List') and target ('components in a category'), which clarifies the basic purpose. However, it's vague about what 'components' are (e.g., UI components, code modules) and doesn't distinguish this from sibling tools like 'filament_get_component' or 'filament_list_docs', missing specificity for a 4-5 score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (e.g., 'filament_get_component' for details or 'filament_search_docs' for broader searches) or any context like prerequisites, making it minimally helpful for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action ('fetch') without disclosing behavioral traits like rate limits, authentication needs, response format, or error handling. This is inadequate for a tool with parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, though this conciseness comes at the cost of detail.
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 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how parameters interact, or behavioral context, making it insufficient for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it adds no meaning beyond the schema. Parameters 'category', 'section', and 'version' are undocumented in both schema and description, leaving their semantics unclear (e.g., what categories or sections exist).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch documentation from filamentphp.com' states a clear verb ('fetch') and resource ('documentation'), but it's vague about scope and doesn't differentiate from sibling tools like 'filament_list_docs' or 'filament_search_docs'. It lacks specificity about what exactly is fetched.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'filament_list_docs' and 'filament_search_docs', the description offers no context for choosing between them, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions returning 'exact section matches' which gives some context about result precision, but lacks details on permissions, rate limits, error handling, or what constitutes a 'section'. More behavioral traits would be helpful for a search 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 is extremely concise—just 7 words—and front-loaded with the core purpose. Every word earns its place with no wasted text, making it easy to scan and understand quickly.
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 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain parameter usage, result format, or behavioral constraints. For a search tool with multiple parameters, this leaves significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'query' should contain, what 'version' selection means for results, or how 'maxResults' affects output. The description adds no meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and target resource ('Filament docs'), and specifies the type of results ('exact section matches'). However, it doesn't explicitly differentiate from sibling tools like 'filament_get_docs' or 'filament_discover_docs', which likely have different search or retrieval approaches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or specific contexts where this search method is preferred over others like 'filament_get_docs' for direct retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'discover live documentation routes' but fails to explain what 'live' entails (e.g., real-time updates, online sources), potential side effects, or response format. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse and front-loaded with the core purpose. It earns its place by succinctly conveying the tool's function.
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 lack of annotations and output schema, the description is incomplete. It doesn't address behavioral traits, return values, or how it differs from sibling tools, leaving the agent with insufficient context for effective use in a complex environment with multiple documentation-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond the input schema, which has 0% description coverage but includes an enum for 'version' (4.x, 5.x). Since schema coverage is low, the description doesn't compensate, but the single parameter is simple with clear options, so 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('discover') and resource ('live documentation routes from filamentphp.com'), making the purpose evident. However, it doesn't differentiate from siblings like 'filament_get_docs' or 'filament_list_docs', which likely serve similar documentation-related functions, preventing 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.
Usage Guidelines2/5
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 such as 'filament_get_docs' or 'filament_list_docs'. The description lacks context about prerequisites, timing, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 this is a 'get' operation, implying it's read-only, but doesn't specify what 'detailed information' includes (e.g., properties, usage examples, dependencies), whether there are rate limits, authentication requirements, or error conditions. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and efficiently communicates the core function, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with 2 parameters, one with an enum), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what 'detailed information' entails, how results are structured, or address potential issues like invalid component names. For a tool that likely returns structured data about components, more context is needed to guide an agent effectively.
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 50% (only the 'component' parameter has a description), and the description adds no additional parameter information beyond what's in the schema. It doesn't explain what 'component' refers to (e.g., is it case-sensitive, what format?), nor does it clarify the 'version' parameter's purpose or default behavior. With partial schema coverage, the description fails to compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('about a Filament component'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'filament_list_components' or 'filament_get_docs', which might provide related information about Filament components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'filament_list_components' (likely listing components) and 'filament_get_docs' (likely getting documentation), there's clear potential for overlap, but the description offers no comparison or context for choosing this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 tool retrieves a namespace but does not explain what the output looks like (e.g., a string, an object), whether it involves external API calls, or any error conditions. The description is minimal and lacks details on how the namespace is determined or validated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is front-loaded and efficiently conveys the core purpose without redundancy or fluff, making it easy to parse quickly.
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 lack of annotations and output schema, the description is insufficient for a tool with 2 parameters (one required) and no behavioral context. It does not explain the return value, error handling, or how the namespace is derived, leaving significant gaps for an AI agent to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the parameters are well-defined with enums for 'classType' and 'version'. The description does not add any semantic details beyond the schema, such as explaining what each class type represents or why the version matters. However, since the schema provides clear constraints, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('correct namespace for a Filament class'), making the purpose understandable. It distinguishes itself from siblings by focusing on namespace retrieval rather than discovery, generation, or listing of other Filament elements. However, it could be more specific about what 'correct' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing to know the class type beforehand, or differentiate from sibling tools like 'filament_get_component' or 'filament_list_components'. Usage is implied 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.
Behavior2/5
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. 'List documentation sections' implies a read-only operation but doesn't specify what 'sections' means, whether there's pagination, rate limits, authentication requirements, or how results are structured. This leaves significant gaps for an agent to understand 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just three words—and front-loaded with the core action. There's no wasted text, making it easy to parse, though this brevity comes at the cost of detail.
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 complexity (a listing tool with one parameter but no output schema or annotations), the description is incomplete. It doesn't cover what 'sections' entails, how results are returned, or the role of the 'version' parameter. With no annotations to fill gaps, this leaves the agent with insufficient context for reliable use.
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?
The input schema has one parameter ('version') with an enum and default value, but schema description coverage is 0%, meaning the schema itself provides no descriptive context. The description doesn't mention parameters at all, but since there's only one optional parameter with clear enum values, the baseline is high. However, it doesn't explain what 'version' refers to (e.g., Filament framework version) or how it affects the listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List documentation sections' clearly states the verb ('List') and resource ('documentation sections'), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'filament_get_docs' or 'filament_search_docs', leaving ambiguity about what distinguishes this listing operation from other documentation-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools related to documentation (e.g., 'filament_get_docs', 'filament_search_docs'), there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 ('Get') but doesn't describe what 'Get' entails—whether it lists, retrieves details, or executes commands, nor does it cover permissions, rate limits, or output format. This lack of detail is a significant gap for a tool with no annotation coverage, making it hard to predict behavior.
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 extremely concise—a single phrase 'Get Filament artisan commands'—with zero wasted words. It's front-loaded and directly states the purpose without unnecessary elaboration, making it efficient for quick understanding. This is ideal for conciseness in tool descriptions.
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's complexity (low, with 1 parameter) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'artisan commands' are, how results are returned, or any behavioral traits. For a tool in a set with many siblings, more context is needed to ensure the agent can use it correctly without trial and error.
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?
The description adds no parameter semantics beyond the input schema, which has 1 parameter ('version') with 0% schema description coverage. However, since there's only 1 parameter and it has an enum (['4.x', '5.x']) with a default ('5.x'), the schema itself provides clear constraints. The description doesn't need to compensate heavily, but it also doesn't explain what 'version' means in context (e.g., Filament framework version). Baseline is high due to low parameter count and schema clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get Filament artisan commands' specifies both the verb ('Get') and resource ('Filament artisan commands'). It distinguishes from siblings like 'filament_get_docs' or 'filament_list_components' by focusing on commands rather than documentation or components. However, it doesn't explicitly differentiate from all siblings (e.g., 'filament_discover_docs' might also involve commands), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., Laravel/Filament environment), or comparisons to siblings like 'filament_generate_plan' or 'filament_search_docs'. Without any usage instructions, it leaves the agent to infer applicability, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 tool retrieves relationship types but doesn't explain what that entails—whether it returns all types, requires authentication, has rate limits, or what format the output takes. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose ('Get Laravel relationship types'), making it easy to parse quickly. Every word earns its place, achieving optimal conciseness.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'relationship types' means in Laravel context, what the return format is, or any behavioral traits like error handling. For a tool with no structured support, this leaves the agent with insufficient information to use it effectively.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details beyond the schema, but since there are no parameters, this is acceptable. A baseline of 4 is appropriate as the schema fully handles the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('Laravel relationship types'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings like 'filament_get_commands' or 'filament_get_component'—it's clear what it does but not how it differs from other 'get' tools in the server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no explicit instructions on context, prerequisites, or comparisons to sibling tools like 'filament_discover_docs' or 'filament_search_docs', 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![filament-mcp-server MCP server](https://glama.ai/mcp/servers/serbansorin/filament-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/serbansorin/filament-mcp-server)

Score Badge

Copy to your README.md:

[![filament-mcp-server MCP server](https://glama.ai/mcp/servers/serbansorin/filament-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/serbansorin/filament-mcp-server)

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/serbansorin/filament-mcp-server'

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