worldanvil-mcp-server

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation5/5
Each tool has a clearly distinct purpose: identity, worlds, articles, categories, assets, search (metadata vs full-text), backlinks, and export. The descriptions are explicit about when to use each, with cross-references to avoid ambiguity. No two tools appear to do the same thing.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case: get_identity, list_worlds, create_article, update_category, search_content, etc. Actions are limited to get, list, search, find, create, update, delete, and export, applied uniformly across resources.
Tool Count4/5
18 tools is slightly above the typical well-scoped range, but each tool earns its place given the complexity of World Anvil (articles, categories, assets, search, export). The count feels reasonable for a rich domain, though it edges toward heavy.
Completeness4/5
The tool set provides full CRUD for articles and categories, plus read access to all asset types, search capabilities, backlink lookup, and world export. Minor gaps exist: no create/update/delete for assets and no world-level editing, but these are likely outside the server's intended scope.
Average 4.4/5 across 18 of 18 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on August 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
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

Behavior2/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 states 'create' which implies mutation, but does not mention permissions, side effects, reversibility, error behavior, or what the API returns. This leaves significant gaps for a write operation.
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 that front-loads the core action and then adds the key optional nuance. No filler or redundant content.
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?
With no output schema and no annotations, the description should cover more context. It clearly states the purpose and optional nesting, but does not explain return values, error conditions, or prerequisites (e.g., world existence). This is adequate for a simple tool but leaves notable gaps for an agent to fully predict 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?
Schema description coverage is 100%, with each parameter having a clear description. The tool description adds marginal value by clarifying 'folder' and optional nesting, but does not enhance understanding of parameter formats, constraints, or the purpose of extra_fields beyond what the schema already provides.
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 uses the specific verb 'create' with the resource 'category (folder)' and clarifies it operates 'in a world' with optional nesting under a parent. This clearly distinguishes it from sibling tools like list_categories, update_category, and delete_category.
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 the tool is for creating categories but does not explicitly state when to use it over alternatives or any prerequisites. It mentions optional nesting but provides no guidance on when to use create_category vs other category-related tools or what to check beforehand.
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. The verb 'List' implies a read-only operation, and 'all categories' clarifies the scope, but it does not explicitly disclose side effects, permissions, or return format beyond what is implied. It adds useful context about how categories relate to articles, but stops short of full behavioral disclosure.
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; the first gets straight to the purpose, and the second explains how the output is used. Every word earns its place, with no fluff or repetition.
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 list tool with a single parameter and no output schema, the description provides enough context. It explains what the tool returns (categories), how they are identified (ids), and how the output feeds into related operations. It could mention the exact structure of the response, but that is not critical for this 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% because the world_id parameter is described in the schema. The description adds no additional parameter-level detail, but the schema fully documents the required parameter, so the baseline score of 3 applies.
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 (List), the resource (categories), and the scope (all categories of a world). It also distinguishes the tool from siblings like list_articles and list_worlds, and explains the role of categories.
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 gives clear context for when to use the tool: to retrieve category IDs, which then filter list_articles or file new articles. It does not explicitly state when not to use it, but the context is sufficient for an AI agent to choose it correctly among siblings.
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 of behavioral disclosure. It adds value by stating partial update semantics ('Only provided fields change') and specifying the two primary operations. However, it does not disclose side effects of moving a category (e.g., impact on child categories), permissions, or error handling, leaving minor 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, front-loaded with the primary actions. 'Only provided fields change' adds critical behavioral info without redundancy. Every word earns its place, making it highly efficient.
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 4-parameter tool with no output schema, the description covers the core purpose and update semantics. It lacks explicit details about extra_fields and return values, but given the schema provides some parameter descriptions, it is sufficient for most use cases. The absence of annotations is offset by the clarity of the described 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 description maps 'rename' to the title parameter and 'move' to the parent_id parameter, adding meaning beyond the schema's minimal descriptions. It also clarifies partial update behavior. However, it does not mention extra_fields, and schema coverage is only 50%, so it only partially compensates for the missing parameter explanations.
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's function with specific actions ('Rename a category or move it under a different parent'), distinguishing it from sibling tools like create_category and delete_category. The resource (category) and scope are explicit, leaving no ambiguity about what the tool does.
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 context for when to use this tool (when renaming or moving a category) and implies partial update behavior ('Only provided fields change'). It does not explicitly name alternatives or exclusion criteria, but the use cases are specific enough for an agent to select it appropriately.
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 discloses the critical non-obvious behavior that content is replaced wholesale, not patched, and instructs to send the full body. It also states partial-update semantics for other fields. However, it does not mention the return value or pass-through behavior of extra_fields.
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-loaded with the primary action, and the crucial content-replacement warning is set off with NOTE. There is no filler or redundant 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?
For a 9-parameter update tool with no output schema, the description covers the essential workflow and the main content-replacement hazard. It omits the response/return shape and does not explain advanced fields like extra_fields or interactions among state, is_wip, and is_draft, leaving some gaps.
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 schema already covers 5 of 9 parameters with descriptions, including content and category behavior. The description adds the general partial-update rule for all fields and reinforces the content replacement caveat. It does not elaborate on undocumented parameters like title, state, is_wip, or is_draft beyond that general rule.
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 uses specific action 'Update an existing article' and clarifies scope with 'Only the fields you provide are changed.' It clearly distinguishes itself from sibling tools like create_article and delete_article by focusing on existing articles.
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?
It provides an explicit editing workflow: 'to edit, get_article first, modify, send back the full body.' This tells the agent when to fetch before updating. It does not explicitly contrast with create_article for new articles, but 'existing article' implies that distinction.
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 transparency burden. It discloses that results are scoped to the authenticated user and include ids, which is useful. However, it does not describe the response format, ordering, or whether full world objects are returned, leaving some behavioral ambiguity for a zero-parameter read-only 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 exactly two sentences, front-loaded with the primary purpose ('List all worlds...') followed by a succinct usage callout. Every sentence earns its place with 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?
For a simple zero-parameter list tool, the description is complete enough. It mentions that the output contains ids and that this tool is the entry point for other tools needing a world_id. While no output schema exists, the description gives a reasonable expectation of return content without over-specifying.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline is 4. The description correctly implies the tool takes no input and focuses on the output, which adds minimal but sufficient contextual meaning.
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 a specific verb and resource: 'List all worlds owned by (or shared with) the authenticated user' and specifies that the result includes their ids. This clearly distinguishes it from sibling tools like get_world (single world) and list_articles (articles within a world).
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 identifies when to use the tool: 'Usually the first call in a session — most other tools need a world_id from here.' It does not explicitly mention when not to use it or name alternative tools, but the chaining purpose is clearly conveyed.
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 for behavioral disclosure. It adds context by mentioning 'authenticated' and 'verify credentials', implying auth-dependency, but it does not explain behavior on invalid credentials or other failure modes. For a simple read operation this is acceptable but not rich.
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 short sentences, front-loaded with the core purpose and followed by a direct usage hint. Every word adds value; there is no fluff or redundancy.
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?
For a parameterless tool with no output schema, the description sufficiently covers what the tool returns (id + username) and its intended use case (credential verification). Given the tool's simplicity, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information because none are needed. It does clarify the return value (id + username), which is arguably more relevant for a parameterless tool.
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 returns the authenticated user's id and username, using a specific verb ('Return') and resource ('authenticated World Anvil user'). This distinguishes it from sibling tools that operate on worlds, articles, or assets.
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 'Use to verify credentials are working', providing a clear when-to-use context. It doesn't mention exclusions or alternatives, but given the tool's unique identity-checking purpose, no alternatives are needed.
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 the burden and is effective. It discloses that content is World Anvil BBCode with examples and that new articles default to private+draft, with a way to publish immediately. It does not cover auth or return values, but the core creation behavior is transparent.
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 with no filler. The first states the action, the second packs content format and default behavior, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no annotations or output schema, the description covers the main behavior, content format, and visibility defaults. It leaves advanced params like extra_fields and template_type to the schema, which is acceptable, though return behavior is not mentioned.
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 high at 78%, so the baseline is near 3, but the description adds value by combining state='public' and is_draft=false for immediate publishing and showing BBCode examples. This supplements the schema without redundant repetition.
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 'Create a new article in a world,' specifying the verb, resource, and scope. It distinguishes from siblings by emphasizing 'new' and touches on content format, making it stand apart from update/delete tools.
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?
It provides clear context by noting articles default to private+draft and gives instructions to publish immediately. However, it does not explicitly mention when to use a specific alternative like update_article, though the 'new' wording makes this implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does excellent work: discloses permanence, irreversibility, absence of a trash bin, and provides a user-safety confirmation directive. This goes beyond basic safety information.
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, front-loaded with the critical warning, and zero unnecessary words. Every clause earns its place.
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?
For a simple one-parameter destructive tool, the description covers the key context: irreversible deletion and user confirmation. No output schema is needed for a delete operation, and the warnings sufficiently prepare the agent.
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% with a clear description for article_id (UUID), so baseline 3 applies. The tool description adds no extra parameter meaning, which is acceptable given the schema already documents it fully.
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?
States the exact action (delete) and resource (article), emphasizes permanent deletion, and clearly distinguishes it from create/update/read siblings like update_article or get_article.
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?
Implies usage for article removal and explicitly instructs user confirmation for non-explicit deletions. However, it does not contrast with other tools or mention alternatives, leaving when-to-use vs siblings implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behavioral traits: permanent deletion, non-deletion of articles, and the need for user confirmation. This goes beyond minimal disclosure and is highly transparent about 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences each add essential value: the action, the side effect, and the safety instruction. No fluff, and the most critical information (permanence) is front-loaded.
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?
For a simple single-parameter delete tool with no output schema, the description covers purpose, irreversibility, side effects on articles, and user confirmation. It is fully complete for an agent to invoke 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 describes the only parameter (category_id as UUID) with 100% coverage. The description adds no additional parameter semantics, but the schema is sufficient, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'PERMANENTLY delete a category'. It distinguishes from siblings like delete_article by specifying the resource and emphasizing irreversibility. The behavior on articles is also clarified, making the purpose unambiguous.
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 context for use: it's irreversible and articles become uncategorized. It also instructs to 'Confirm with the user first', which is a safety guideline. However, it does not explicitly mention when not to use or list alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 that the search is on cached text, uses exact UUID matching (no false positives), and that the first call builds the cache which can take a minute. This is substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences pack the essential information: purpose, mechanism, use cases, and a performance caveat. The most important fact is front-loaded, and every sentence earns its place with no redundancy.
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?
The description covers what the tool does, how it operates, when to use it, and a key cache performance characteristic. Given the absence of annotations and output schema, this is sufficient for an agent to select and invoke the tool 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?
Schema coverage is 100%, so the schema already fully documents both required parameters. The description does not add parameter-specific detail beyond the schema, so the baseline score applies.
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 leads with a specific verb+resource: 'Find every article, secret or note that LINKS TO a given article.' It further distinguishes from sibling search tools by emphasizing exact UUID-based matching for backlinks, with no false positives.
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 use cases: 'where is this NPC mentioned?' or 'before deleting an article.' This gives an agent explicit context for when to use the tool, though it does not explicitly name alternative tools or exclusions.
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 the full burden. It discloses the content format (World Anvil BBCode), the link syntax as @[Title](type:uuid), and that template-specific fields vary by article type. It doesn't mention permissions or error behavior, but this is a straightforward read tool and the disclosed details are meaningful.
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, both necessary. The first is front-loaded with the core action and deliverables; the second adds valuable format details without redundancy. No fluff.
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 there is no output schema, the description fully specifies what the response contains (content fields, relations, template-specific fields) and the BBCode/link behavior. For a single-parameter read tool, this is complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says 'UUID of the article', but the description adds practical context: uuids can be obtained from link mentions in other articles, making it clear how to source the article_id. This goes beyond the structural definition.
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 opens with 'Read one article in full' which is a specific verb+resource, then enumerates the returned fields (content, sidebar, tags, category, relations, template-specific fields). This clearly distinguishes it from sibling tools like list_articles or search_articles, which operate at the list level.
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 a clear use case: 'this makes this the way to walk the world's knowledge graph for context' by following @[Title](type:uuid) mentions. It implicitly contrasts with listing/searching tools but does not explicitly mention when not to use it.
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 behavioral disclosure. It discloses auto-pagination ('auto-paginates; nothing is hidden') and the output format ('shown as [type] on each line'), which is valuable. It doesn't cover auth or rate limits, but for a listing tool it is reasonably transparent.
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 compact and front-loaded with the core action. Every sentence serves a purpose: stating scope, clarifying entity types, explaining output, and pointing to the sibling alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description conveys what to expect: all articles, auto-pagination, and type shown per line. It could mention ordering or other return fields, but the absence is not critical for a list tool with good parameter schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that every World Anvil entity is an article with a template type, which clarifies the 'type' parameter and its significance. It also reinforces the category and type filtering options beyond the schema's brief 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 'List ALL articles in a world' with a specific verb and resource scope, and it distinguishes itself from sibling tools by explicitly directing keyword lookups to search_articles and implying a comprehensive listing.
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?
It provides explicit guidance on when to use this tool versus search_articles: 'For keyword lookups prefer search_articles.' It also notes optional filters by category or template type, giving clear use cases.
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 the full burden of behavioral disclosure. It discloses auto-pagination and the output format ('one line per asset with its id'), which are useful beyond the schema. However, it does not explicitly state that this is a read-only operation or mention error/edge-case behavior (e.g., empty list), leaving a small gap.
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 tight three sentences: purpose, behavior/output, and usage guidance. It is front-loaded with the main action, includes the most important extra details, and contains no filler or redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 2 parameters and no output schema. The description covers the resource types, pagination, and return format, and points to sibling tools for related operations. It is mostly complete, though a note about what happens with no assets or error conditions would make it fully robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds semantic value by explaining the enum options (e.g., 'secrets (GM-only notes)', 'subscribergroups (player visibility groups)'), which the schema enum lacks. This enriches the meaning of the 'kind' parameter without repeating the schema verbatim.
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 opens with a specific verb and resource: 'List a world's non-article resources', then enumerates the resource types (secrets, maps, timelines, etc.). It clearly distinguishes from related tools by pointing to 'list_articles' for articles and 'get_asset' for reading a single asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use get_asset to read one in full' and 'For articles use list_articles instead', providing clear when-to-use vs alternatives. Also mentions 'Auto-paginates' to set expectations for large results.
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 provided, the description carries the disclosure burden. It reveals case-insensitive matching, multiple-word matching semantics, and metadata-only performance characteristics. Though it omits details like pagination or result format, it provides meaningful behavioral context beyond a bare operation.
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 compact and front-loaded with the primary function. Each sentence earns its place: the first states the action, the second details matching semantics, the third clarifies multi-word behavior, and the last two provide performance and alternative navigation. No filler 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?
For a search tool without annotations or output schema, the description is quite complete: it covers scope, matching rules, performance, and redirects to appropriate sibling tools. It lacks explicit mention of result structure or pagination, but given the simplicity and the presence of get_article for content, it provides sufficient context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that the query performs case-insensitive matching against title, slug, and tags, and that multiple words must all match. This enriches the meaning of the 'query' parameter beyond its schema description, while world_id and type are already well-specified in 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 tool's action: 'Find articles in a world by keyword' with specificity on matching fields (title, slug, tags). It distinguishes itself from sibling tools by explicitly naming search_content for body text and get_article for reading content, making the purpose unambiguous.
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 usage guidance: it notes the tool is 'Fast (metadata only)' and directs users to 'search_content instead' for body text, and to 'get_article on a result id' for content. This clearly states 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job: it discloses that the tool makes hundreds of API calls, takes minutes, returns only a summary, writes data to disk rather than context, refuses to write into non-empty non-export directories, and requires an absolute output path. This is thorough behavioral disclosure.
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 somewhat long with a large list of included entities, but every sentence provides valuable information. It is front-loaded with the core purpose and structured logically (what, how long, return behavior, constraints). A slight trimming could improve conciseness, but it remains efficient for the tool's complexity.
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?
For a complex tool with no output schema and no annotations, the description covers all critical aspects: full content list, side effects (disk writes, downloads), performance (minutes), return behavior, and special conditions (empty dir, absolute path). The user/agent has enough to invoke and handle the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaningful parameter context beyond the schema: output_dir must be absolute, is created if missing, and must be empty or a previous export. It also clarifies world_id is a UUID. This enriches the schema definitions.
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 clones a COMPLETE world to a local directory as raw full-granularity JSON, listing all included data types (articles, categories, secrets, etc.). It uses a specific verb ('Clone'/export) and resource ('world'), and it is clearly distinct from sibling tools like get_world or list_articles. No ambiguity.
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 context for when to use the tool (full migration, rewriting @mention links) and includes important usage caveats (data goes to disk, not into context; read specific exported files afterwards). However, it does not explicitly mention alternatives or when NOT to use this tool, though no sibling tool serves the same purpose.
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 the behavioral disclosure burden. It states exactly what the tool returns (description, settings, counts, links). While it does not explicitly say it's read-only or mention error behavior, the 'get' verb and content list make the behavior reasonably transparent.
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 with no fluff. The first sentence front-loads the purpose and return contents; the second provides a concise, useful prerequisite. Every word earns its place.
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?
For a simple one-parameter getter without an output schema, the description fully covers what the tool does, what it returns, and how to use it. No critical information is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes world_id as a UUID, so baseline is 3. The description adds value by explaining how to obtain the world_id (via list_worlds), enriching the parameter 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 identifies the tool as retrieving full details for a single world, listing specific content categories (description, settings, counts, links). It distinguishes from list_worlds by focusing on a single world, and from other siblings by its resource specificity.
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 explicitly instructs to use list_worlds first to obtain the required world_id, providing clear sequencing and an alternative when the ID is unknown. This is direct, actionable guidance for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full disclosure. It reveals that kind=map triggers several API calls to assemble a hierarchy, which is an important behavioral trait. It also transparently explains what is returned for each kind, giving the agent a complete picture of 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core statement, but the second sentence is long and information-dense. However, every detail is valuable and not redundant with the schema. It is concise overall, but slightly dense.
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?
For a read tool with no output schema and no annotations, the description fully explains what will be returned for each kind, notes the cost of map assembly, and provides an alternative for articles. This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage, but the description adds significant meaning to the 'kind' parameter by explaining the specific return shape for each enum value (map, notebook, other). This goes beyond the schema's simple 'Asset type' label, though it adds nothing for 'id'.
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 'Read a single asset in full' with a specific verb and resource. It then details what 'full' means for each kind, distinguishing map and notebook from other asset types, and explicitly contrasts with get_article, so the purpose is unambiguous and differentiated from siblings.
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?
It provides explicit usage context: for maps and notebooks, you get the full hierarchy; for other kinds, just the entity. It also directly tells the agent to use get_article for articles, which is an explicit alternative. This is clear guidance on when to use this tool vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 matching semantics (all words in same entity, case-insensitive), cache behavior (self-refreshes, first call builds cache), and performance warning (first call can take a minute). This is rich, honest behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the tool's purpose, followed by critical constraints and performance notes. Every sentence earns its place with no filler.
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 no output schema and no annotations, the description adequately covers what the tool does, its return format (context snippets), matching constraints, and performance caveats. This is complete for an agent to confidently invoke the 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 description coverage is 100% and each parameter is clearly described. The description adds extra query semantics not found in schema: 'All words must appear in the same entity' and case-insensitive matching, which enriches understanding of the query 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 the tool performs full-text search inside world's text, specifying article bodies, GM secrets, and notes, and returns context snippets. It distinguishes itself from sibling search_articles by noting its broader scope.
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 states when to use this tool vs alternatives: 'For title/tag lookups search_articles is faster.' This provides clear guidance on selecting the appropriate sibling tool.
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:

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

Score Badge

Copy to your README.md:

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

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/daireb/worldanvil-mcp'

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