Server Quality Checklist

Tool Scores

• read_objectA
  3.9/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  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 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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• search_objectsA
  3.9/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description 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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• world_summaryA
  3.9/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines4/5

  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.

• search_propertiesA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/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 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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• base_ratesA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• world_statusA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no parameters and no output schema, the description 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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• list_worldsA
  4.6/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  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 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.

  Purpose5/5

  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.

  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 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.

• rankingsA
  4.6/5.0
  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 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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  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 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.

  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 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.

  Usage Guidelines5/5

  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.

• search_eventsA
  4.6/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• load_worldA
  4.7/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  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: '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.

  Usage Guidelines4/5

  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.