This server provides MCP tools to query and analyze Dwarf Fortress world history. Key capabilities include:
World management: Check backend status, list previously opened worlds, load a world from XML, and get a high-level summary (civilizations, eras, wars, eventful figures).
Object exploration: Read detailed or condensed histories of figures, civilizations, sites, etc. (read_object); search objects by name substring (search_objects); and search by structured properties like goals, race, positions, or affiliations (search_properties).
Event search: Full-text search over event prose to find specific deeds, with optional filters for year range and event types; also retrieve all events within a timeframe without a keyword.
Statistical analysis: Compute base rates of property values to understand commonality (base_rates); rank objects by numeric measures like events, kills, or deaths (rankings); and cross-tabulate two properties with aggregates (breakdown).
Flexible controls: Most tools support result limits and filters (object type, detail level, year range) to refine queries and improve performance.
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., "@legendsviewer-mcp How common is the goal 'immortality' among necromancers?"
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 a language model read and query the history of a Dwarf Fortress world: search the deeds recorded in the legends, read the biography of a figure or the history of a civilization, and check whether what looks remarkable actually is.
It is a thin client over the analysis API added by LegendsViewer-AIPowered, a fork of Kromtec/LegendsViewer-Next.
LegendsViewer-AIPowered must be running. This server owns no world state: parsing a large export takes about 30 seconds and 800 MB, which is fine once per application run and unacceptable per MCP session. It therefore queries a long-lived backend rather than loading anything itself.
# in the LegendsViewer-AIPowered checkout
dotnet run --project LegendsViewer.BackendA stock LegendsViewer-Next will not work: it has no /api/Analysis routes. world_status says so
explicitly if you point this at one.
Related MCP server: genskill-mcp
npm install
npm run buildThen register it with your MCP client. For Claude Code:
{
"mcpServers": {
"legendsviewer": {
"command": "node",
"args": ["/absolute/path/to/legendsviewer-mcp/dist/index.js"]
}
}
}Set LEGENDSVIEWER_URL if the backend does not listen on http://localhost:15421.
Tool | Purpose |
| is the backend reachable, is a world loaded, which object types exist |
| worlds opened before, with the XML path each loads from |
| parse an export into memory (~30 s) |
| overview: civilizations, eras, wars, most eventful figures |
| one object's history, |
| find by name |
| find by goal, race, position, affiliation |
| full text search over the prose of every event |
| how common a property value is |
| who holds the maximum of a numeric measure |
| one property grouped by another, with aggregates |
Two of these deserve emphasis, because they cover what the others cannot. Only search_events
finds deeds, which appear in no property; only search_properties finds goals and
affiliations, which appear in no event.
And base_rates is the one to reach for before concluding anything. A trait shared by three
notable figures looks like a pattern until you learn that half the world shares it — most properties
are recorded for only part of the objects, so the tool reports both denominators rather than letting
you assume one.
breakdown is the one to reach for when the question has two halves — age at death by caste,
casualties by attacker race. The other tools each read a single property, so such a question used
to be answered by pulling the objects and joining them by hand, which for the classic API means
recovering ids from HTML anchors. Do not do that: if a property needed for the join is missing, add
it as a facet in the backend instead.
Arguments are validated strictly: an unknown parameter is an error, not a silently dropped key. The
tool's cap is maxEvents for both detail levels, whereas the backend route behind the digest calls
it maxNotableEvents — passing the backend's name used to look like it worked while the server
default applied instead.
Ask for the digest first. read_object defaults to it. The full dossier of a large civilization
can exceed 600 KB, most of it recurring festivals; the digest is around 17 KB and keeps the events
that are rare for that object.
Filter event searches when you can. There is no index — the text only exists once the prose has
been rendered — so an unfiltered search on a large world renders every event and takes a few
seconds. Passing eventTypes brings it to milliseconds.
Drop q to read history rather than search it. search_events with only fromYear/toYear
returns everything that happened then, which is the one question no keyword can express. It is also
the fastest call in the set: with no text to match, nothing is rendered at all — a full year of a
494,436 event world comes back in 9 ms.
npm test # unit tests, plus an in-memory MCP client exercising every tool
npm run watch # recompile on changeThe tests use no network: the HTTP client is stubbed, and the MCP surface is driven through the SDK's in-memory transport.
MIT.
How common each value of a property is. Call it before concluding that a shared trait is meaningful: most properties are recorded for only part of the objects, so the answer reports both the objects carrying the field and the whole scope, and divides by the former. Omit field to list the queryable fields.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Restrict to one object type. | |
| field | No | Property key. Omit to list the available fields. | |
| limit | No | Maximum values returned, default 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that the tool reports both the objects carrying the field and the whole scope, and divides by the former—an important detail about how results are computed. It also mentions the listing behavior when field is omitted. However, it doesn't explicitly state whether the output is a percentage, count, or other format, though the described division implies proportions.
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 two sentences long and front-loads the core purpose. Every clause serves a purpose: defining the tool, giving when-to-use guidance, explaining the calculation, and noting the field-omission behavior. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately explains what the answer reports (both scopes and the division). It also covers the alternative use of omitting field. It doesn't mention the default limit (in schema) or return format details, but given the tool's simplicity and high schema coverage, this is sufficient 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters described in the schema. The description adds limited new parameter-specific meaning; it reinforces the 'omit field' behavior already in the schema. It does not elaborate on the type or limit parameters beyond what the schema provides, so it meets the baseline for high schema coverage without adding significant extra value.
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 immediately states the tool's function: 'How common each value of a property is.' This is a specific statistical/resource-scoped purpose that clearly differentiates it from sibling tools like search_objects or rankings. It also explains the nuanced behavior of dividing by the number of objects carrying the field, making the purpose unmistakable.
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 instructs when to call the tool: 'Call it before concluding that a shared trait is meaningful.' It explains why by noting that 'most properties are recorded for only part of the objects' and how the answer handles this. It also clarifies the alternative usage of omitting field to list queryable fields, giving clear context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Worlds LegendsViewer has opened before, with the XML path each one loads from. Use it to find the argument for load_world.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the list is based on worlds previously opened by LegendsViewer and includes the XML path, which is meaningful behavioral context beyond the title.
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, front-loaded with purpose and immediate guidance. Every word earns its place.
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?
The description is adequate for a simple zero-parameter list tool, providing both the list content and the reason to use it. It could mention persistence across sessions, but it's not critical for the stated use case.
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 tool has zero parameters, so the baseline is 4. The description adds context about the output (XML path) that complements the empty schema.
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 'known worlds' and specifies it includes the XML path each world loads from. It uses a specific verb+resource and distinguishes from siblings like load_world and world_status.
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 instructs to use this tool to find the argument for load_world, making the intended use case and relationship to the sibling tool clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parses a legends export into memory, replacing whatever world was loaded. Takes about 30 seconds and 800 MB for a large world, so call it once and query afterwards. Point it at the -legends.xml file; the _plus.xml beside it is picked up automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Full path to the <world>-legends.xml file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description discloses significant behavioral traits: it replaces any prior loaded world (side effect), takes about 30 seconds and 800 MB for a large world (performance/resource usage), and automatically picks up the _plus.xml file (implicit behavior). This goes well beyond a generic statement and helps the agent anticipate consequences.
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 three sentences, each with a distinct purpose: function, performance/side effect, and file-specific guidance. No wasted words, and the most important information (what it does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is remarkably complete. It covers the action, side effects, resource requirements, and file-handling details. The agent knows to call it once before querying and what to expect, so no critical information seems missing.
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 only says 'Full path to the <world>-legends.xml file.' The description adds that the _plus.xml beside it is picked up automatically, meaning the path should point only to the -legends.xml file and not the _plus.xml. This enriches the parameter's meaning beyond the schema definition, so the description adds value even with 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Parses a legends export into memory, replacing whatever world was loaded.' The verb 'parses' and the resource 'legends export' are specific, and the mention of replacing the currently loaded world distinguishes it from sibling tools like world_status or world_summary, which clearly operate on an already loaded world.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'call it once and query afterwards' indicates this is the initial setup step before using other query tools. It also gives file-specific guidance ('Point it at the -legends.xml file'). However, it does not explicitly name alternative tools or state when not to use it, so a small deduction from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who holds the maximum of a measure — events, kills, worshippers, deaths and so on. Complements base_rates, which orders by how many objects share a value rather than by the value itself. Returns total, min, median and max beside the leaders, so a first place can be read against the spread. Omit by to list the available measures.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | Measure name. Omit to list the available measures. | |
| type | No | Restrict to one object type. | |
| limit | No | Maximum entries, default 20. | |
| order | No | Descending by default; asc for minima. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses return structure ('Returns total, min, median and max beside the leaders') and behavior of omitting 'by'. However, it does not mention default order/limit or potential error conditions, which are partially covered by schema defaults.
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 three concise sentences: purpose, differentiation, return behavior, and a usage tip. Every sentence adds unique value, with no redundancy or fluff.
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 or output schema, the description provides a solid overview of purpose, differentiation, and return content. It lacks explicit mention of default ordering/limit, but these are in the schema. The tool's complexity is well-handled.
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 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the 'by' parameter behavior (omit to list measures) and providing examples of valid measure names. Other parameters (type, limit, order) are not expanded, but schema already covers them.
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's purpose: 'Who holds the maximum of a measure' with concrete examples (events, kills, worshippers, deaths). It also distinguishes itself from sibling base_rates by contrasting value-based ranking vs. count-based ordering.
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?
Explicit guidance is provided: 'Complements base_rates, which orders by how many objects share a value rather than by the value itself' tells when to use this tool instead. Also instructs 'Omit by to list the available measures,' which is a clear usage directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The history of a single world object as prose. detail='digest' condenses it to the event type breakdown, an activity histogram and only the events whose type is rare for that object — use it for civilizations and other large objects, whose full dossier can exceed 600 KB. detail='full' returns everything.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Object id. | |
| type | Yes | Object type, for example "HistoricalFigure", "Entity", "Site", "War". | |
| detail | No | How much to return. | digest |
| toYear | No | Latest year, inclusive. | |
| fromYear | No | Earliest year, inclusive. | |
| maxEvents | No | Cap on events (full) or on notable events (digest). 0 means no limit. | |
| eventTypes | No | Comma separated raw event type names, exactly as printed in brackets on each event line (for example "hf died,created site"). Narrowing here also makes event search far faster. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses meaningful behavioral details: the digest mode returns an event type breakdown, activity histogram, and only rare events, and warns that full dossiers can exceed 600 KB. This goes beyond a basic read operation, though it does not mention all limits or output structure.
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 tight sentences: the first states the core purpose, the second explains the detail modes and use cases. No waste, no redundancy, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema, the description explains the primary behavior and the digest/full distinction well. It does not illustrate how filtering parameters (toYear, fromYear, maxEvents, eventTypes) combine, but the schema covers their meanings, so this is adequate.
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 100%, so the baseline is 3. The description adds semantic value to the 'detail' parameter by explaining what digest vs full actually produce and when to use each, exceeding baseline.
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 reads the history of a single world object as prose, with a specific verb and resource. It implicitly contrasts with siblings like search_objects (which searches), but does not explicitly name alternatives.
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?
It gives clear guidance on when to use 'digest' vs 'full' based on object size, which is useful context. However, it does not explain when to choose this tool over siblings like search_objects or world_summary, nor does it provide any exclusions or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full text search over the prose of every event in the world — the only way to find deeds, as opposed to names or properties. There is no index, so an unfiltered query on a large world takes a few seconds; passing eventTypes cuts that to milliseconds because excluded events are never rendered. Omit q to read a span of history instead of searching it: with fromYear/toYear alone it returns everything that happened then, and being free of any text to match it is the fastest query here. Give q or a filter — neither would mean every event in the world.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Substring of the event prose, case-insensitive. Omit to take everything the filters admit. | |
| limit | No | Maximum events shown, default 25. | |
| toYear | No | Latest year, inclusive. | |
| fromYear | No | Earliest year, inclusive. | |
| eventTypes | No | Comma separated raw event type names, exactly as printed in brackets on each event line (for example "hf died,created site"). Narrowing here also makes event search far faster. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of disclosure. It reveals significant behavioral traits: absence of an index (making unfiltered queries slow), eventTypes filtering for speed, and how omitting q changes the operation to a history read. However, it doesn't mention return format or error handling, so it's not fully exhaustive.
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?
Three succinct sentences front-load the core purpose, then efficiently expand on behavior and parameter use. Every sentence contributes new information with no 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?
For a tool with no output schema and all parameters optional, the description covers purpose, parameter interaction, and performance considerations effectively. It lacks explicit return-format details, but the tool's behavior is well-scoped and the description is adequate for selection and 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 underlying schema already describes each parameter (100% coverage), so baseline is 3. The description adds valuable meaning by explaining how parameters interact—e.g., 'Give q or a filter—neither would mean every event in the world'—and the performance implications of using eventTypes, going beyond the raw schema descriptions.
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 that this tool performs full text search over event prose, using the specific verb 'search' and resource 'events,' and distinguishes itself as 'the only way to find deeds' versus names or properties, differentiating it from sibling tools like search_objects and search_properties.
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?
It explicitly tells users when to use this tool (to find deeds/event text) and when alternatives for names/properties are needed. It also explains variants like omitting q to read history spans and the performance trade-offs, offering clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds world objects whose name contains the query. Exact matches rank first, then prefixes, then event count.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Substring of the name, case-insensitive. | |
| type | No | Restrict to one object type. | |
| limit | No | Maximum hits, default 25. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses useful behavioral details like ranking order (exact matches first, then prefixes, then event count), which goes beyond the schema. However, it does not state whether the tool is read-only or describe any side effects, though this is less critical for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that delivers the core purpose and ranking behavior without any fluff. Every phrase earns its place, making it highly concise and well-structured.
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?
The tool is relatively simple, and the description covers the essential search behavior. However, with no output schema and no annotations, it does not hint at the return format or pagination. It also does not clarify how this search relates to search_properties or search_events, leaving the context incomplete for an agent deciding between tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add semantic meaning to the parameters (q, type, limit) beyond what the schema already provides. The only implicit hint is that 'name contains the query' maps to q, but this is already in the schema.
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 finds world objects by name substring, with a specific verb 'finds' and resource 'world objects'. It distinguishes from siblings like search_properties and search_events by focusing on name. The ranking detail (exact, prefix, event count) further clarifies its purpose.
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 title 'Search by name' and description imply the tool is for name-based searches, but no explicit when-to-use guidance is given. It does not mention alternatives or conditions that would favor another search tool, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the structured properties of objects — goal, race, positions, affiliations, worshipped deities — rather than names or event text. These never appear in any event, so this is the only tool that finds them. Each hit reports which field and value matched.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Substring of the property value, case-insensitive. | |
| type | No | Restrict to one object type. | |
| field | No | Restrict to one property, using the key printed in brackets in a dossier, for example "goal" or "position". | |
| limit | No | Maximum hits, default 25. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds value by stating that each hit reports which field and value matched, and that the tool only searches structured properties, not event text. While it does not explicitly state read-only behavior, it is a search tool with no side effects implied, and the behavioral detail is sufficient.
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 three sentences, front-loaded with the core action, and each sentence adds distinct value: what it searches, when to use it, and what the result reports. No wasted words.
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 moderate complexity, 100% schema coverage, and no output schema, the description is largely complete. It explains purpose, usage guidance, and hit structure. It could be more explicit about the overall return shape, but it sufficiently covers the key aspects for an agent to use it 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?
Schema coverage is 100%, so the baseline is 3. The description adds context with property examples and hit reporting, but does not go beyond the schema's parameter descriptions. It reinforces field restrictions but does not add new parameter 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 the tool searches structured properties of objects, listing specific examples like goal, race, positions, affiliations, and worshipped deities. It explicitly contrasts with name or event text searches, distinguishing it from sibling tools like search_objects and search_events.
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?
It explicitly states that property values never appear in events and that this is the only tool that finds them, giving a clear when-to-use context. It implies alternatives for names or event text but does not name the sibling tools directly, so the guidance is strong but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether LegendsViewer is reachable, whether it exposes the analysis layer, and which world is loaded. Also lists the object type names accepted by the other tools. Start here when anything fails.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It clearly discloses the three checks (reachability, analysis layer, world loaded) and the additional function of listing accepted object type names. It does not state return format or error behavior, but for a status tool the described behavior is reasonably transparent and not contradicted by any annotation.
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 two sentences, front-loaded with the core purpose. Every sentence adds value: the first describes the status checks, the second mentions the object type names and provides usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides a sufficient overview of its role and the kind of information it returns. It explains usefulness ('Start here when anything fails') and lists a key output (object type names). It could be even more explicit about the exact structure of the status response, but overall it is complete for operational context.
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 zero parameters, so the baseline for this dimension is 4. The description does not need to explain parameters; it instead focuses on what the tool reports, which is appropriate. There is no parameter-related information missing.
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 that the tool checks reachability of LegendsViewer, the availability of the analysis layer, and the currently loaded world. It also mentions listing object type names, which distinguishes it from sibling tools that load or summarize worlds or search objects. The verb is implied but the resource and scope are specific.
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 gives explicit when-to-use guidance with 'Start here when anything fails', positioning the tool as a first diagnostic step. It does not explicitly list when not to use it or compare it to alternatives, but the phrase 'Start here' strongly implies it is the entry point before using other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Overview of the loaded world: totals per type, main civilizations, eras, largest wars, most eventful figures and the most common event types. About 4 KB. The intended starting point before drilling into anything.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries behavioral disclosure. It adds useful context like approximate size ('About 4 KB') and the kind of content included, but does not explicitly state return format, read-only nature, 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?
Two sentences front-load the core concept, then efficiently list the included content, size, and intended use. No filler or repetition.
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 zero-parameter, no-output-schema overview tool, the description is mostly complete. It covers content, scale, and usage, but stops short of describing the exact return structure or distinguishing itself from similar sibling tools by name.
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 tool has zero parameters, so the schema fully covers inputs. Per the rubric, 0 parameters earns a baseline 4; the description adds no parameter-specific detail because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the resource ('loaded world') and scope ('overview', with totals, civilizations, eras, wars, figures, event types). It lacks an explicit verb, and while 'intended starting point' hints at differentiation from siblings, no sibling is named.
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?
Explicitly positioned as 'the intended starting point before drilling into anything', providing clear usage context. Does not name alternatives or state when not to use, but the guidance is unambiguous.
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 function: world management (list/load), overview (summary/status), object access (read/search), property search, event search, and statistical analysis (rates/rankings). No two tools overlap in purpose, and the descriptions make the boundaries clear.
Most tools follow a verb_noun pattern (list_worlds, load_world, read_object, search_*), but a few use noun-only names (world_status, world_summary, base_rates, rankings). This is a minor deviation; the names are still readable and self-explanatory, but not fully consistent.
10 tools is well within the ideal 3-15 range and matches the complexity of the domain. Each tool earns its place, covering distinct workflows without redundancy.
The toolset covers the full workflow: locating worlds, loading them, getting summaries, drilling into objects, searching by name/property/event, and performing statistical analysis. There are no obvious missing operations for typical analysis tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
An MCP server that gives your AI access to the source code and docs of all public github repos
MCP server for AI dialogue using various LLM models via AceDataCloud
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hadows/legendsviewer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
