Manage a Wiki.js instance through its GraphQL admin API, including reading and writing pages, managing navigation and groups, and triggering Git storage syncs.
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., "@mcp-server-wikijs List all pages in the wiki"
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.
An MCP server that lets Claude (or any MCP client) manage a Wiki.js instance through its GraphQL admin API — read and write pages, manage navigation and groups, and trigger Git storage syncs.
Published on PyPI as
mcp-server-wikijs; the source repo ismargus/wikijs-mcp. The admin focus (navigation, groups, Git sync, raw GraphQL) sets it apart from content-authoring Wiki.js MCP servers.
How it works: MCP does not run inside Wiki.js. This is a small stdio server your MCP client launches locally; it talks to
https://<your-wiki>/graphql. If your Wiki.js is on a private network, the machine running this needs network reach to it.
Tool | What it does |
| Run any Wiki.js GraphQL query/mutation (escape hatch) |
| List pages (id, locale, path, title) |
| Get a page's content + metadata |
| Create a page |
| Update a page — only passed fields change |
| Delete a page |
| Current nav mode + tree |
|
|
| Groups + their permissions/page rules |
| Re-sync the Git storage target (re-import content repo) |
Related MCP server: Wiki.js MCP Server
A running Wiki.js 2.x instance.
An API key: Administration → API Access → enable the API → New API Key (full access; the 2.x API isn't finely scoped). Copy the token.
Run it on demand with uvx (no install) — set the two
environment variables and go:
export WIKIJS_URL="https://wiki.example.com"
export WIKIJS_TOKEN="your-api-key"
uvx mcp-server-wikijsOr install it:
pip install mcp-server-wikijs # or: uv tool install mcp-server-wikijs
mcp-server-wikijsThe server speaks MCP over stdio, so running it directly just waits for a client — that's expected. Wire it into a client below.
Variable | Required | Description |
| ✅ | Base URL of your Wiki.js instance (e.g. |
| ✅ | Wiki.js API key. Aliases also accepted: |
For standalone runs you can instead drop a .env next to where you launch it
(cp .env.example .env); it's loaded automatically.
claude mcp add wikijs --env WIKIJS_URL=https://wiki.example.com --env WIKIJS_TOKEN=your-api-key -- uvx mcp-server-wikijs…or add it to .mcp.json / your settings:
{
"mcpServers": {
"wikijs": {
"command": "uvx",
"args": ["mcp-server-wikijs"],
"env": {
"WIKIJS_URL": "https://wiki.example.com",
"WIKIJS_TOKEN": "your-api-key"
}
}
}
}Tip: keep secrets out of committed files — reference an env var that's already in your shell, e.g.
"WIKIJS_TOKEN": "${WIKIJS_TOKEN}", and start the client from a shell where it's set.
Add the same block to claude_desktop_config.json
(Settings → Developer → Edit Config), then restart Claude Desktop.
Once registered, ask your assistant things like:
"List every page under clients/ in the en locale."
"Create a page at guides/onboarding titled 'Onboarding' with this content: …"
"Update page 31 — append a 'Troubleshooting' section, leave everything else."
"Trigger a Git sync so the wiki re-imports the content repo."
The Wiki.js API key is full-admin — treat it as a privileged credential. Keep it in your secrets manager / environment, never commit it, and revoke or rotate it anytime from Wiki.js → API Access. Every write tool acts with that key's full authority, so review mutations before approving them.
git clone https://github.com/margus/wikijs-mcp
cd wikijs-mcp
uv sync # install runtime + dev deps
uv run pytest # run the test suite (no live wiki needed — httpx is mocked)
uv run ruff check . # lintThe Wiki.js logic lives in src/wikijs_mcp/client.py (WikiJSClient), unit-tested against
httpx.MockTransport. src/wikijs_mcp/server.py is a thin layer of MCP tool wrappers over
it. See CONTRIBUTING.md.
Create a new wiki page. path is locale-relative (e.g. 'guides/getting-started').
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| tags | No | ||
| title | Yes | ||
| editor | No | markdown | |
| locale | No | en | |
| content | Yes | ||
| description | No | ||
| is_published | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states creation, but does not mention what happens if the page already exists, required permissions, or any side effects.
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 short and front-loaded with the purpose. The second sentence adds specific value for 'path'. No wasted words, though it could include more detail in the same space.
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 8 parameters and no output schema, the description lacks essential context such as return value, validation rules, or constraints (e.g., path uniqueness). It is incomplete for an agent to use correctly.
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?
With 0% schema description coverage, the description only clarifies the 'path' parameter (locale-relative). The other 7 parameters (title, content, tags, editor, locale, description, is_published) receive no additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new wiki page, distinguishing it from sibling tools like get_page, update_page, delete_page, and list_pages. The example for 'path' adds 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 implies usage for creating a page but does not explicitly state when to use this tool versus alternatives like update_page for existing pages or list_pages for browsing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a page by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only states 'Delete a page by id' without disclosing whether deletion is permanent, any associated side effects, or required permissions. Critical behavioral context is absent.
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 concise at one sentence with no wasted words. However, it may be too sparse for a destructive tool, but brevity itself is not a flaw. It front-loads the purpose efficiently.
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, no output schema, and a single parameter, the description should cover more about the operation's impact, return behavior, or error conditions. It falls short, leaving an agent without sufficient context for safe invocation.
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 one parameter 'id' with no description. The tool description adds 'by id', which merely restates the parameter name. With 0% schema description coverage, the description should provide more meaning (e.g., data format, source) but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete a page by id.' It uses a specific verb and resource, distinguishing it from sibling tools like create, update, or get. However, it is minimal and does not describe any scope or context beyond the basic action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to delete, or provide any context about typical scenarios. For a destructive action, explicit usage advice is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an arbitrary Wiki.js GraphQL query or mutation. Use for operations not covered by
the typed tools. variables is an optional dict of GraphQL variables.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| variables | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions running queries or mutations, implying both read and write, but does not detail potential destructive effects, error handling, or authentication requirements. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Front-loaded with purpose and usage guidance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (arbitrary GraphQL) and lack of output schema or annotations, the description is minimal. It covers basic purpose and when to use but leaves gaps about error behavior, result format, and potential side effects. Adequate for a fallback tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It adds that `variables` is an optional dict of GraphQL variables, providing some meaning beyond the schema. However, it does not describe the `query` parameter beyond its name. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs arbitrary Wiki.js GraphQL queries/mutations and distinguishes from typed tools by specifying 'for operations not covered by the typed tools.' This provides a specific verb and resource with clear scope.
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 explicitly says to use this tool for operations not covered by typed tools, providing clear context for when to use it. It implies not to use when a typed tool exists, but does not include explicit exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single group with its permissions and page rules.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
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 the tool returns permissions and page rules, which is valuable behavioral context beyond the schema. However, it does not explicitly state that the operation is read-only or mention any side effects, though this is implied for a 'get' operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose without extraneous words. It is front-loaded with the main action and provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter, the description adequately covers the return value (permissions and page rules). However, it could be more explicit about the parameter's role, though the parameter name 'id' makes it clear. No output schema exists, so the description compensates reasonably.
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 coverage is 0%, and the description does not explain the 'id' parameter beyond the context of identifying a group. The parameter is required, but the description adds no additional meaning or guidance on its format or expected values.
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 'group', and specifies that it returns 'permissions and page rules', which distinguishes it from siblings like 'list_groups' (which returns a list) and 'get_page' (which gets a page).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single group's details, but does not explicitly state when to use this tool over 'list_groups' or other sibling tools, nor does it mention any prerequisites or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a page's content + metadata, by path+locale (default locale 'en') or by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| path | No | ||
| locale | No | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It indicates the operation is a read (get) with no side effects implied, which is good. However, it does not disclose potential behavioral traits such as idempotency, authentication requirements, rate limits, or what constitutes 'content + metadata' (e.g., whether it includes all fields or a summary). The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 18 words that is concise, front-loaded with the primary action ('Get a page's content + metadata'), and efficiently conveys the key usage methods. Every word contributes meaning 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 has 3 parameters, no output schema, and no annotations, the description is minimally adequate. It explains how to retrieve a page but omits details about the return structure, error handling (e.g., what if page not found?), and whether content is full or partial. For a getter tool, more detail on output would improve completeness.
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?
With 0% schema description coverage, the description adds significant meaning beyond the input schema. It explains that 'path' and 'locale' work together (with locale defaulting to 'en') and that 'id' is an alternative lookup method. This clarifies the relationship between parameters and usage. However, it does not specify behavior when both id and path are provided, or the priority between them, which would earn a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a page's content and metadata, with two distinct lookup methods (by path+locale or by id). It effectively distinguishes itself from sibling tools like create_page, delete_page, update_page (write operations) and list_pages (listing). This is a specific verb+resource combination with clear scope.
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 implicitly guides usage by specifying retrieval methods (path+locale or id), indicating when to use this tool (to fetch a single page's content). It does not explicitly state when not to use it or mention alternatives, but the context from sibling tools (e.g., list_pages for multiple pages) provides sufficient differentiation. The lack of explicit exclusions or when-to-use guidance prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List user groups (id, name).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist and the description does not disclose any behavioral traits such as sorting, pagination, or scope, leaving agent uninformed about 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 concise sentence with no wasted words, appropriate for a parameterless tool.
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 output schema and no annotations, the description is too minimal, lacking details on whether the list is comprehensive and any ordering, leaving it incomplete.
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?
With zero parameters, the schema is fully covered. The description adds minimal output info (id, name) but this is not parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists user groups and returns id and name, distinguishing it from get_group by implying plural results. However, it could more explicitly say it returns a list.
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 like get_group, leaving the agent to infer usage without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List wiki pages (id, locale, path, title). Optionally filter by locale (e.g. 'en').
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| locale | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It discloses read-only nature and returned fields. However, it doesn't mention pagination limits or ordering, leaving some gaps for a list operation with a limit parameter.
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?
Single sentence, front-loaded with the main purpose. No wasted words; efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no output schema, the description is adequate. It covers purpose and one filter. Could mention limit controls max results but not essential.
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 description adds meaning to the locale parameter (filter by locale) beyond the schema's type info. The limit parameter is only in schema with default, no additional context. With 0% schema coverage, the description should cover both but only addresses one.
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 (list), resource (wiki pages), and specifies the fields returned (id, locale, path, title). It distinguishes from sibling tools like get_page (single page) and create_page.
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 mentions optional filtering by locale, giving context for when to apply this parameter. It doesn't explicitly exclude alternatives but implies listing vs. single page retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a storage action — defaults to syncing the Git storage target, which re-imports the content repo.
| Name | Required | Description | Default |
|---|---|---|---|
| handler | No | sync | |
| target_key | No | git |
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 mentions triggering a sync and re-import but does not disclose whether the action is destructive, idempotent, or requires permissions. The behavior is partially transparent but 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 is a single concise sentence with front-loaded purpose. No redundancy, but could benefit from additional details without becoming verbose.
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?
With 0% schema description coverage, no annotations, and no output schema, the description leaves significant gaps. It does not explain possible parameter values, return values, side effects, or error conditions. For a triggering action, more context 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?
Schema description coverage is 0%, so the description must compensate. It explains that handler defaults to 'sync' and target_key defaults to 'git', implying possible other values, but does not elaborate on allowed values, effects, or syntax for these 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 'Trigger' and the resource 'storage action' with a specific default of syncing the Git storage target to re-import content repo. It distinguishes from sibling tools which focus on pages and groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The description implies default behavior but does not mention alternative tools or conditions. Among siblings, no direct alternative exists, but the description lacks usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing page by id. Only the fields you pass are changed; the rest are kept from the current page.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| tags | No | ||
| title | No | ||
| content | No | ||
| description | No | ||
| is_published | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses partial update behavior but lacks details on auth, rate limits, or error handling for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no fluff; front-loaded with the core action.
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 mutation tool with 6 parameters and no output schema or annotations, the description is too sparse; missing error handling, idempotency, and response details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description adds no parameter-specific details beyond property names, which are self-explanatory but lack constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing page by id, which distinguishes it from create_page and delete_page.
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 explicitly notes partial update behavior, implying when to use, but does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: page CRUD, group retrieval, navigation management, admin actions. Tools like get_page vs list_pages are clearly differentiated by scope. No overlapping purposes.
All tool names follow a consistent verb_noun pattern (e.g., create_page, get_navigation, list_groups) using underscores. No deviations or mixed conventions.
11 tools provide a well-scoped set covering page management, groups, navigation, and admin. The count is appropriate for the Wiki.js domain without being excessive or sparse.
Core page operations are complete (CRUD+list). Groups only have read operations, and user management is absent, but the GraphQL escape hatch covers missing operations. Minor gaps in group lifecycle.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared project wiki for AI agents: read and write pages, next actions, and activity logs over MCP.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Read and write your team's shared, AI-readable wiki from any MCP client.
MCP-native open-source Notion alternative: read & write pages, databases and kanban boards.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/margus/wikijs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
