Server Quality Checklist

Tool Scores

• lnm_list_guidanceA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already disclose read-only, idempotent, non-destructive behavior, so the bar for additional behavioral disclosure is lower. The description adds useful context about the documents being bundled with the server and the returned fields (id, title, coverage, resource URI), but does not mention pagination or ordering. No contradiction with annotations.

  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 front-loaded with the core list action and scope, then uses a compact paragraph to explain the document contents, filtering, and return fields. Every sentence earns its place, and the final pointer to lnm_get_guidance is a useful, minimal next-step instruction.

  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 read-only list tool with no output schema, the description adequately specifies what is returned and how to fetch a full document. It could more explicitly draw boundaries against sibling list tools, but the content areas and the mention of document IDs and URIs give an agent enough to operate 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 description coverage is 100%, so the parameters are already well documented. The description adds only the general 'Filter by design or topic' guidance, which mirrors the schema. Baseline 3 is appropriate because the schema carries the parameter-documentation load.

  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 a specific verb and resource: 'List the long-form guidance documents bundled with this server.' It clearly distinguishes itself from siblings by describing the document set as 'the prose references behind the other tools' and explicitly directs single-document retrieval to lnm_get_guidance.

  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?

  Provides useful context on when to use the tool: it lists the reference documents and says to 'Fetch one with lnm_get_guidance.' It also explains the documents are background prose for other tools and offers filtering by design or topic. It does not explicitly exclude sibling tools such as lnm_list_designs or lnm_methods_checklist, so selection guidance is strong but not exhaustive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lnm_phrasebookA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds useful context beyond that: results are recurring moves grouped by section/purpose, and the output is meant to inform register, not to be copied verbatim. This extra caveat helps the agent set correct expectations about the returned content.

  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 front-loaded with the main action and then gives a compact set of examples and a pragmatic warning. Every sentence adds useful context, and the Args note is minimal without being redundant. The length is appropriate for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

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

  With no output schema, the description does enough to convey what kind of output to expect: grouped sentence frames for common literature moves. It also communicates the practical limitation that frames should not be pasted verbatim. It does not enumerate all possible sections or describe the exact formatting, but those are minor gaps for a read-only lookup 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 description coverage is 100%, so the schema already documents both parameters. The description adds example values for the section parameter, which is helpful, but mostly repeats what the schema says and does not discuss response_format. This fits the baseline of 3 for high 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 opening line says exactly what the tool does: return sentence frames, grouped by section and purpose. The examples of recurring moves further specify the kind of content the agent can expect. This distinguishes it from sibling tools like lnm_get_guidance or lnm_limitations, which have different outputs.

  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 makes clear the tool is for matching the register of the literature and explicitly warns against pasting frames in unedited. It does not explicitly name sibling tools as alternatives or state when not to use it, so it stops short of a 5. The context is nevertheless clear 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.

• lnm_audit_manuscriptA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish read-only, idempotent, non-destructive behavior; the description adds substantial context beyond that by explaining severity grades, finding contents, quoted overstatement triggers, and the limitation that a clean audit is not a quality endorsement. No contradiction with annotations.

  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 well structured and front-loaded, but the Args section largely duplicates the input schema. Each paragraph still earns its place: grades, limitations, and return shape are distinct pieces of useful information.

  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?

  With no output schema, the description adequately explains the return value: counts followed by findings grouped by severity, with each finding containing section, problem, and fix. It also specifies input minimums and the optional design parameter, so an agent has enough context to call 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 description coverage is 100%, so the baseline is 3. The description mostly restates the schema, with minor additions like the 120+ word minimum and the effect of supplying a design id, but it does not materially deepen parameter understanding 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 names a specific verb and resource: it searches a draft for required reporting elements and for overstating phrasings. It also distinguishes itself from a review, making its scope clear relative to sibling checklist/guidance 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?

  The description gives clear context for when to use the tool: supply a manuscript or complete section, optionally a design id, and expect a text search rather than a quality verdict. It explicitly states what the tool cannot do, but it does not name sibling alternatives or provide direct when-not-to-use comparisons.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lnm_list_designsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful behavioral context beyond annotations: it returns a table of id, name, and what the design establishes, and explains that the id is passed to other tools. No contradiction exists.

  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 front-loaded with the primary purpose, then covers when to use it, what designs are included, what is returned, and when not to use it. Every sentence adds useful information and nothing is redundant or 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?

  For a simple read-only listing tool with only one optional parameter, the description is complete: it states the purpose, usage timing, scope, return format, and routing alternative. The annotations cover safety and idempotency, so nothing an agent needs to invoke correctly is missing.

  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 single parameter, response_format, is fully described in the schema with an enum and a clear explanation of markdown vs json. Since schema description coverage is 100%, the description does not need to add parameter details; the baseline 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 opens with a specific verb and resource: 'List every study design this server can plan, check, and audit.' It also names the exact design types covered and explicitly differentiates this tool from lnm_outline_paper by saying not to use it when the design id is already known.

  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?

  Usage guidance is explicit: 'Use this first when you do not yet know which design a study is, or to show a user the options.' It also provides a clear exclusion and alternative: 'Don't use when: you already know the design id — call lnm_outline_paper directly.' This fully routes an agent to the correct tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lnm_classify_designA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds significant behavioral detail: it scores every design, returns matched signals, lists reviewer-expected analyses, and explicitly refuses to guess when no design matches, instead requesting more facts. This is valuable transparency beyond the annotations.

  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 front-loaded with the core purpose, followed by instructions, an example, return values, and error handling. Every section earns its place, and the format is scannable for a complex classification tool.

  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?

  Despite lacking an output schema, the description covers the return contract: best match, confidence flag, ranked table, mandatory analyses, and error-handling behavior. Input requirements are explicit, so an agent has everything needed to 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 both parameters are already documented. The description adds value by specifying exactly what the free-text description should include (cohorts, provenance, outcome variable, validation cohort) and by providing a concrete example input. This exceeds the baseline but is not fully transformative.

  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: 'Decide which lesion/stimulation mapping design a described study belongs to.' It clearly distinguishes itself from siblings like lnm_list_designs by stating the tool classifies rather than lists, and it explains what is returned: a ranked list, confidence flag, and mandatory analyses.

  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 when-to-use guidance: pass a free-text description containing cohorts, origins, outcome variable, and validation cohort. It provides an example and explains error-handling behavior when nothing matches. It does not explicitly name alternative sibling tools or state when not to use it, but the context is strong 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.

• lnm_get_guidanceA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the readOnly/idempotent annotations by disclosing the 25,000-character truncation behavior, the 'section' retrieval semantics, and detailed error handling for unknown ids and unmatched headings. An agent can predict important edge-case behavior before calling the 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 compact and well-structured: a one-sentence purpose, a behavior paragraph, an Args list, and an Error handling line. Every sentence adds information and there is no repetition of schema content.

  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 two-parameter read-only tool, the description is complete: it explains source of ids, optional section behavior, truncation, and error responses. Even without an output schema, an agent has enough information 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 already documents both parameters clearly, but the description adds useful nuance: 'section' is a substring, it retrieves the heading plus subheadings, and omitting it returns the whole truncated document. The examples 'specificity' and 'permutation' help clarify acceptable inputs.

  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 first sentence states the exact operation: 'Fetch one guidance document, or one heading within it.' This clearly conveys the verb, resource, and optional narrower scope, and it is easily distinguished from sibling tools like lnm_list_guidance.

  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 concrete guidance on when to use the 'section' parameter: pass part of a heading to get one section, or omit it for the full document. It also points to lnm_list_guidance as the source for valid ids, though it does not explicitly name alternatives or state when not 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.

• lnm_limitationsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnly/idempotent annotations, the description discloses the tool's core behavior: entries are filtered by study_features, concessions are paired with counters, and already-answered entries are moved into a separate 'retired' set. This gives the agent a clear model of what the tool will and will not return.

  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 front-loaded with the main action and immediate purpose, then explains the concession-counter rationale, then lists args and returns. Every sentence earns its place and there is no redundant 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?

  With no output schema, the description compensates by stating the return shape ('ordered list to write as one Discussion paragraph, plus the retired set'). All three parameters are meaningfully contextualized, including a concrete example for study_features, making the tool fully actionable.

  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, but the description adds meaning beyond the schema: it explains that design can be omitted for limitations common to every design and that study_features 'both trigger and retire entries.' The example feature list clarifies the expected granularity and format.

  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: 'Return the limitations a reviewer of this design will raise, filtered to the ones that are actually yours.' It also clarifies what the output is for ('to write as one Discussion paragraph') and distinguishes itself from a generic guidance tool by emphasizing study-specific filtering and concession-counter pairs.

  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 clearly explains how to use the tool: provide design and study_features, and it explains the 'retired' concept so the user knows to report those points as strengths in the Methods rather than concessions in the Discussion. It does not explicitly list when-not-to-use or alternatives, but the guidance given is strong and contextual.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lnm_methods_checklistA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so no contradiction exists. The description adds meaningful behavioral context beyond those hints: items are graded 'required', 'expected', or 'optional', each item carries its rationale, and the checklist is meant for drafting rather than exhaustive auditing.

  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 well-structured and front-loaded: a one-line purpose, a compact explanation of grading semantics, explicit usage timing, a sibling alternative, and a clearly formatted Args list. Every sentence adds value without padding.

  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 is complete for a read-only checklist tool: it explains what is returned, how items are graded, when to use it, when not to use it, and what each parameter does. Although there is no output schema, the 'tickable table' and item-grading description cover the key output expectations.

  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, but the description adds useful meaning: it explains that omitting design returns items common to every design, that section restricts to a section, and that include_optional controls optional-item inclusion. The only minor gap is that response_format is not mentioned in the Args list, though the schema 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?

  The description opens with a specific verb and resource: 'Return the reporting checklist for a design as a tickable table.' It clearly distinguishes the tool from its sibling lnm_audit_manuscript by contrasting a working list with a check against finished text, so an agent can tell them apart.

  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 states when to use the tool ('Use while drafting the Methods, and again before submission') and names the alternative for a different task ('For a check against finished text instead of a list to work from, use lnm_audit_manuscript'). This gives the agent actionable routing guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lnm_outline_paperA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations by detailing what the tool produces, including per-section subsections, word budgets, reporting elements, sentence frames, and a gap analysis. It also honestly notes what it does not cover: analyses that the design must defend but the study does not mention. This is strong behavioral disclosure for a read-only planning tool.

  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 purpose and uses a clear Args list that is easy to scan. The Returns line partially restates the earlier output description, which is a small redundancy, but overall the length is justified for a tool with seven parameters.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

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

  Given the complexity of producing a section-by-section paper plan, the description is remarkably complete. It explains the shape of the output, the prerequisite step, parameter meanings, and the target_journal constraint, so an agent has enough context to invoke the tool correctly without an output schema.

  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 the schema already covers all parameters, the description adds concrete examples for design, topic, cohorts, connectome, and analyses_done, and clarifies that target_journal is 'used only to remind you to check word and figure limits.' This provides real selection guidance beyond the schema's property 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 opens with 'Produce a section-by-section plan for a paper of a given design', which clearly names a specific verb and deliverable. It also distinguishes itself from sibling tools like lnm_classify_design by describing its own output: a plan with subsections, word budgets, obligations, and sentence frames.

  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 guidance to call lnm_classify_design first when the design id is unknown, and clarifies the limited role of target_journal and the role of analyses_done in gap detection. It does not explicitly contrast with checklist or audit siblings, but the sequencing note and purpose make the intended usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.