MCP for Flarum

Server Quality Checklist

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

Latest release: v0.7.2
Disambiguation4/5
Most tools have distinct purposes (CRUD, search, docs), though flarum_search and flarum_list overlap slightly for searching discussions. Descriptions clarify differences, making confusion unlikely.
Naming Consistency4/5
All tools start with 'flarum_' and use verb or verb_noun patterns (e.g., docs_get, create_discussion). Minor inconsistency with verbs like create vs create_discussion, but overall predictable.
Tool Count5/5
13 tools cover core forum operations (CRUD, search, docs) without bloat. Each tool serves a clear purpose, and the count is well-scoped for the domain.
Completeness4/5
Covers CRUD for all resources, search, and docs. Includes an escape hatch for custom endpoints. Minor gaps like explicit moderation tools are mitigated by flarum_update.
Average 4/5 across 13 of 13 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 48 commits in the last 12 weeks
- Last stable release on July 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the tool performs a write operation (posting a reply), but fails to mention any behavioral traits such as authentication requirements, side effects (e.g., bumping the discussion), or error conditions.
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 sentence that conveys the essential action and resource. It is front-loaded and contains no wasted words, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 required parameters, no output schema, no nested objects), the description provides the core action. However, it lacks completeness in areas like success/error responses and usage context, which would help an agent use it correctly.
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 already provides descriptions for both parameters with 100% coverage. The description adds marginal value by reinforcing the purpose of discussionId ('by its id'), but does not add significant new meaning beyond the 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 it posts a reply to an existing discussion, using a specific verb and resource. It distinguishes from the sibling tool flarum_create_discussion which creates a new discussion, but does not explicitly differentiate from other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is for replying to an existing discussion, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the JSON:API format and permission requirement, but does not detail side effects, return values, error handling, or behavior on resource creation.
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?
Two sentences plus an example, front-loaded with purpose. Every sentence adds value, though the example could be integrated more concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a creation tool with 3 parameters and no output schema. Covers resource type, attributes, relationships, and permission, but missing details on response format and error states.
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 baseline is 3. The description adds an example for relationships and clarifies the structure of attributes, but does not provide additional semantics beyond the 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?
The description clearly states the verb 'Create' and the resource 'any Flarum resource via JSON:API', which distinguishes it from sibling tools like flarum_create_discussion. The example solidifies the purpose.
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 mentions the requirement for an API key with permission, but provides no guidance on when to use this general tool versus the specialized sibling flarum_create_discussion, nor any conditions or exclusions.
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 provided, so description carries full burden. It implies creation but does not disclose permissions, rate limits, or consequences. Minimal behavioral insight beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with main purpose, then optional detail. Efficient and clear.
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?
For a simple creation tool with 3 parameters and no output schema, the description covers essential purpose and parameter usage. Could mention return value or errors, but not required. Adequate.
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%, but description adds useful context: tagIds may be required by forums with Tags extension. This goes beyond the schema's description of 'Tag ids to attach.'
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 starts a new discussion with title and content, distinguishing it from sibling tools like flarum_reply. However, it does not explicitly differentiate from flarum_create, which might be a generic create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional tagIds and that they may be required by some forums, but lacks guidance on when not to use the tool or alternatives. No prerequisites or when-to-use context provided.
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 full burden. It discloses that 'Long fields are truncated by default' (behavioral detail) and gives an example, but does not explicitly state read-only nature, permissions required, or side effects. The description is minimal regarding behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with an example, front-loaded with purpose. No wasted words. Efficiently communicates the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 1 required, no output schema, and no annotations, the description is adequate but leaves gaps. It covers the main purpose and a key behavior (truncation), but does not describe return format, pagination, or other common search behaviors. Could be more complete for a search tool.
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 80% (4 of 5 parameters have descriptions). The description adds context by explaining 'using Flarum's gambit/search (filter[q])' for the query parameter and 'Long fields are truncated by default' relating to maxFieldChars. This adds meaning beyond the schema's 'Search query string' and truncation 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 'Full-text search across discussions' and specifies use of Flarum's gambit/search mechanism. It provides an example, making the purpose unmistakable. The tool is differentiated from siblings like flarum_list which likely list without searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the search mechanism and gives an example, implying it is for search queries. However, it does not explicitly state when to prefer this over alternatives like flarum_list or flarum_get. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 mentions that 'Returns full field values by default (no truncation)', which is a useful behavioral note. However, it does not explicitly state that the operation is read-only, nor does it disclose any side effects, permission requirements, or rate limits. The word 'Fetch' implies a safe operation, but more explicit disclosure would improve clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus an example. Every sentence adds value: first sentence states the core function, second sentence notes default behavior, and the example illustrates common usage. No fluff or redundancy.
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 description covers the essential aspects for a single-resource fetch tool: how to specify type and id, optional includes and field narrowing, and default truncation behavior. No output schema exists, but the description's note on 'full field values' provides adequate expectation. Missing aspects like error responses or relationship to other tools are minor given the tool's simplicity.
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 an example (type='discussions', id='42', include='posts,user') which provides concrete usage context but does not add substantial meaning beyond what the schema already provides for each parameter.
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 'Fetch a single Flarum resource by type and id', with a specific verb ('Fetch'), resource ('Flarum resource'), and scope ('single'), which distinguishes it from sibling tools like flarum_list (list multiple) and flarum_search (search across resources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (need a single resource by ID) but does not explicitly state when not to use or mention alternatives. It lacks exclusions or context for choosing between this and sibling tools like flarum_search or flarum_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 non-GET methods are refused in read-only mode, but does not explain what read-only mode means, how it is determined, or any other behavioral aspects like authentication or rate limits. This partial disclosure is useful but incomplete.
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, consisting of two short sentences that front-load the purpose and quickly follow with key usage detail. Every word earns its place, and the structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, including nested object for body) and no output schema, the description could be more complete. It explains the path relative to API root and hints at custom endpoints, but lacks details on response format, error handling, or the implications of read-only mode. The description is adequate for an escape hatch but not fully comprehensive.
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 already provides 100% description coverage for all parameters, including path, method, query, and body. The description adds no new parameter-level meaning beyond examples like '/discussions' or '/fof/gamification/ranks', which is borderline but does not elevate the score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is an escape hatch for making arbitrary requests to any Flarum API endpoint, for anything not covered by typed tools. It explicitly mentions custom extension routes and non-JSON:API endpoints, distinguishing it from sibling tools like flarum_get, flarum_create, etc.
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 when to use this tool (for any endpoint not covered by typed tools) and highlights a key constraint: in read-only mode, non-GET methods are refused. However, it does not explicitly mention when not to use it or suggest alternatives, though the sibling tools list implies preference for typed tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses the HTTP method (PATCH) and examples of side effects (lock, sticky, hide). However, it does not mention required permissions, idempotency, rate limits, or error behavior, leaving gaps.
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 two sentences plus an example, immediately stating the core action and purpose. Every sentence adds unique value; no filler.
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 the tool has 4 parameters with nested objects, no output schema, and 9 siblings, the description adequately covers purpose, parameter usage via example, and typical use cases. It lacks details on return values or error conditions but is sufficient for typical 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?
Schema coverage is 100% with parameter descriptions. The description adds value beyond schema with a concrete example showing how 'attributes' and 'type'/'id' are used together, and enumerates possible moderation actions.
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 explicitly states 'Update (PATCH) any Flarum resource by type and id' and provides concrete examples of use (editing posts, moderation actions). It clearly distinguishes from sibling tools like flarum_create, flarum_delete, flarum_get, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives examples of when to use the tool (editing, moderation) but does not explicitly state when not to use it or compare it to alternatives. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool returns info and user, implying a read-only operation. It does not discuss side effects, rate limits, or authentication details, but for a simple read-only tool this is minimally adequate.
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 at two sentences with no redundant information. Every word serves a purpose.
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 the tool has no parameters and no output schema, the description is reasonably complete. It explains the return value and a primary use case. It could mention the output format but is not necessary.
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 no parameters (100% coverage), so the schema already fully describes the input. The description adds no parameter-specific information, earning a baseline score of 3.
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 exactly what the tool returns (forum basic info and the user the API key acts as) and provides a use case (verify connectivity and permissions). It clearly distinguishes itself from sibling tools that perform CRUD operations.
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 explicitly says 'Useful to verify connectivity and permissions', giving a clear when-to-use. It does not mention when not to use, but the context is sufficient to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It transparently describes the tool as a guide covering safe fixes, commands, error interpretation, and report writing, with no hidden side effects. It does not mention limitations (e.g., if forum is inaccessible), but overall disclosure is good.
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 roughly three sentences but packs in audience, purpose, distinguishment, coverage, and usage pairing. It is front-loaded with key information. Could be slightly tighter but remains efficient and clear.
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?
With no output schema, the description must explain what the guide covers. It does so thoroughly (first-aid, info, logs, common errors, how to write a support request) and mentions pairing with another tool. For a guide tool, this is adequately complete.
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?
There is only one parameter (topic) with enum values, and the schema already provides clear descriptions (100% coverage). The description adds minimal but useful context ('Section to return... or omit for full guide'), so it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a plain-language guide for forum admins to diagnose broken Flarum forums and prepare support requests. It explicitly distinguishes itself from the sibling tool flarum_dev, which is for building extensions, ensuring no confusion.
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 advises using the tool 'whenever a user describes a forum problem or asks how to get help' and suggests pairing with a related prompt. It implicitly excludes use for extension development via the sibling distinction, though it does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States irreversibility and permission requirements, but does not detail behavior on success/error or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words. Front-loaded with action and resource scope.
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?
Covers purpose, irreversibility, and permissions. Lacks details on error behavior or response, but adequate for a simple delete tool with no output schema.
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 already documented. Description adds no additional meaning beyond examples of type values.
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 deletes any Flarum resource by type and id with examples (post, discussion, user). Distinguishes from sibling tools like flarum_create, flarum_get, etc.
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?
Mentions irreversibility and permission requirements, providing clear guidance on when to use. Lacks explicit exclusion of alternatives, but the delete purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It indicates the tool fetches from the live sitemap, implying a read-only operation. It does not detail return format or potential side effects, but the behavior is straightforward for a list 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 two sentences long, front-loading the purpose and then providing usage guidance. Every sentence is meaningful and without redundancy.
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 the absence of an output schema, the description mentions paths and URLs as return elements, which is adequate for a list tool. However, it could be improved by specifying whether URLs are absolute or relative, but overall it provides enough context for the agent to understand the tool's output.
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 100% coverage for the single parameter 'filter'. The description adds value beyond the schema by providing a concrete example (e.g., filter='extend'), which helps the agent understand usage.
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 explicitly states what the tool does: listing available Flarum 2.0 documentation pages (paths and URLs) from the live sitemap. It uses specific verbs and resources, and distinguishes itself from sibling tools like flarum_docs_get by indicating it is a preliminary discovery step.
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 clear guidance on when to use the tool: before reading a page with flarum_docs_get. It also mentions the optional filter parameter. However, it does not explicitly state when not to use it or contrast with other sibling tools like flarum_docs_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses truncation of long text fields and how to override (maxFieldChars, fields, flarum_get). No annotations provided, so description carries this burden well. Could mention pagination behavior more explicitly but it's covered by 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?
Concise and front-loaded. Every sentence adds value. Includes example usage and important notes about truncation.
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 8 parameters and no output schema, description covers key behaviors (truncation, JSON:API features). Could mention return format but list tools typically return JSON:API collections. Adequate.
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 has 100% coverage, baseline 3. Description adds value by explaining truncation, providing example usage (type, filter, include), and contextualizing parameters like maxFieldChars.
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 explicitly states the tool lists or searches any Flarum resource collection, with examples (discussions, posts, users, etc.). It distinguishes from sibling tools like flarum_get (for full content) and flarum_search (which may be more specific).
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?
Clearly indicates when to use (for listing/searching collections). Implicitly contrasts with flarum_get for reading full content. Could explicitly state not to use for single resource retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'Reads the live docs, so results reflect the current docs.' No annotations provided, but description covers read-only nature. Could mention that it is non-destructive and doesn't require authentication, but overall clear.
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?
Four sentences, front-loaded with purpose, efficient and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return format (ranked results with page path and snippet) and how to use results (call flarum_docs_get). Sufficient for a search 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 coverage is 100%, so schema already documents parameters. Description adds a bit (e.g., 'natural language or keywords') but does not significantly enhance meaning 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?
Clearly states the tool searches official Flarum 2.0 docs and returns ranked results with page path and snippet. Distinguishes from sibling tools like flarum_docs_get (reads full page) and flarum_search (forum search).
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 when to use: 'look up how something works... before acting on a forum.' Provides an example query and instructs to call flarum_docs_get with a result's 'page' for full content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full behavioral burden. It discloses that it returns Markdown source (preserving code blocks and headings) and ignores URL anchors. No mention of error handling or rate limits, but the safe read nature is evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Key information is front-loaded: the purpose and input flexibility, then behavioral notes, then sibling pairing advice. Every sentence adds value.
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?
No output schema, but description implies return value (Markdown content). Two parameters are both well-explained. Could mention error behavior for invalid pages, but adequate for a simple read tool. Contextual completeness is high given the tool's simplicity.
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%, but description adds value by explaining acceptable page formats (slug, path, URL, anchor ignored) and clarifying that maxChars=0 returns the whole page. These details go beyond the schema's generic 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 tool fetches the full Markdown of one Flarum documentation page, specifying accepted input formats (slug, path, URL). It distinguishes itself from the sibling tool flarum_docs_search by recommending pairing to find the right page first.
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 advises pairing with flarum_docs_search for discovery, and provides concrete examples of acceptable inputs (page slug, site path, URL). This gives clear context for when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly indicates the tool returns reference content and has no side effects. While it doesn't explicitly state 'read-only' or 'no destructive actions', the context of 'development reference' and 'omit topic for full reference' implies passive retrieval. This is sufficiently transparent for a reference 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?
Despite its length, the description is well-structured and front-loaded with the core purpose and topics. Every sentence adds value (usage guidance, pairing, parameter behavior). It is as concise as possible given the complexity of the tool's reference topics.
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 tool is a simple reference with one optional parameter and no output schema, the description is fully complete. It covers purpose, usage, parameter options, and relationships to sibling tools, leaving no ambiguities.
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 schema covers 100% of the parameter with enum values and description. The description adds value by explaining that omitting the topic returns the full reference and listing the topic values, reinforcing and clarifying the parameter's effect. This goes beyond the schema baseline of 3.
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 explicitly defines the tool as a development reference for building/reviewing Flarum extensions, listing specific topics (scaffolding, frontend, backend, etc.) and distinguishing it from siblings like flarum_docs_search by stating the pairing. The verb 'Consult' and resource 'Flarum extension development reference' make the purpose very clear.
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?
The description provides explicit guidance: 'Consult it before scaffolding, when adding a feature, or when reviewing extension code.' It also explains how to narrow output with the 'topic' parameter and mentions pairing with flarum_docs_search/flarum_docs_get for alternative tools. This covers when, why, and how to use the tool effectively.
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:

[![mcp-for-flarum MCP server](https://glama.ai/mcp/servers/linkrobins/mcp-for-flarum/badges/card.svg)](https://glama.ai/mcp/servers/linkrobins/mcp-for-flarum)

Score Badge

Copy to your README.md:

[![mcp-for-flarum MCP server](https://glama.ai/mcp/servers/linkrobins/mcp-for-flarum/badges/score.svg)](https://glama.ai/mcp/servers/linkrobins/mcp-for-flarum)

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/linkrobins/mcp-for-flarum'

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