Server Quality Checklist

Tool Scores

• run_fileA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It states the action and that output is summarised, but it does not disclose side effects of running Mplus (e.g., generated output files), execution duration risks, or what the summary contains. This is a significant gap for an execution 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?

  Two concise sentences with no redundancy. The core operation is stated first, and the intended use case is front-loaded. Every sentence earns its place.

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

  Completeness3/5

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

  For a tool with 4 parameters, no output schema, and no annotations, the description is minimal. It covers the core use case and references the input file type, but it omits expected output summary details and behavioral expectations like timeout handling, though the schema does describe parameter constraints.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

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

  The schema covers 100% of parameters, so the description does not need to repeat them. It adds no new parameter-level meaning beyond referencing run_syntax for the 'include' option. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Run'), a specific resource ('Mplus input file that already exists on disk'), and adds differentiating context ('written by hand or by the Mplus editor') that separates it from siblings like run_syntax. It is clear and not a tautology.

  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 an explicit usage condition: 'Use this for .inp files written by hand or by the Mplus editor.' It clearly identifies when to use the tool, though it does not explicitly state when not to use it or name direct alternatives.

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

• compare_fitA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of disclosing behavior. It does disclose a meaningful statistical behavior: the optional chi-square difference test and its MLR scaling correction. However, it does not state that the tool is read-only, what happens on missing/invalid files, or any output/error behavior, leaving some behavioral ambiguity.

  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 compact and front-loaded with the core action, then expands with relevant use cases and the chisq_diff behavior. It earns every sentence, though it could be slightly more structured by separating the parameter-specific behavior from the general purpose.

  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 description is adequate for invoking the tool: it explains the core comparison task, the chisq_diff option, and MLR scaling. However, with no output schema, it does not describe the return format or what the side-by-side table looks like, and it does not mention the nested-models prerequisite for the chi-square difference test, which an agent would need for correct usage.

  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 value beyond the schema by explaining that chisq_diff runs a chi-square difference test between consecutive models and that MLR scaling is handled, which the schema's one-line description does not convey. It also confirms the side-by-side ordering implied by out_paths.

  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 ('Put ... side by side') and resource ('fit statistics of several .out files'), making the tool's core function unmistakable. It also lists concrete use cases (class enumeration, measurement invariance, nested model comparisons) and thereby distinguishes itself from single-file siblings like output_summary or output_section.

  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: whenever multiple .out files need their fit statistics compared. It does not explicitly name alternatives or say 'use only for multiple files,' so it falls short of a full when/when-not statement, but the multi-file framing is clear enough.

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

• build_syntaxA
  4.1/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 of behavioral disclosure. It clearly states the tool is non-executing and that the output is raw text, and it reveals template limitations by directing uncovered content to extra parameters. It could add failure behavior or caveats, but the core behavior is disclosed.

  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 concise, front-loaded with purpose, and contains no filler. Each sentence earns its place, and the whole definition is appropriately sized for the tool's complexity.

  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 40-parameter tool with no output schema and no annotations, the description still covers the essential workflow, the full model-family list, and a fallback policy for unsupported elements. The per-parameter context in the schema compensates for missing model-type-specific grouping.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

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

  The schema already provides 100% parameter descriptions, setting a baseline of 3. The description adds a useful routing rule for non-template content, but it references `model_extra` while the schema actually defines `model_lines`; following the description verbatim could lead an agent to pass a non-existent parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Write Mplus input syntax for a standard model family', then enumerates model types. It also distinguishes itself from run_syntax by explicitly stating 'Returns the syntax as text - it does not run it.'

  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 gives an explicit workflow: 'Read it, adjust it, then pass it to `run_syntax`', which tells the agent how to use this tool in relation to its execution sibling. However, it does not compare against other siblings like syntax_help or state conditions when build_syntax should be avoided.

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

• data_prepareA
  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 transparency burden, and it does so well: it discloses that output is numeric-only, has no header, flags missing values, truncates names to 8 characters, and returns specific artifacts plus rename/recode notes. It does not discuss source-file mutability or overwrite behavior, but the main behavioral traits are explicit.

  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 one dense sentence that front-loads the core action and then packs only high-value details: supported formats, transformation rules, and returned artifacts. There is no filler.

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

  Completeness4/5

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

  For a 12-parameter conversion tool with no annotations and no output schema, the description covers the essential context: input formats, output behavior, and return contents. It could mention file-writing behavior more explicitly, but the schema documents out_path, so the remaining gap is minor.

  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 tool description adds useful global context for parameters such as missing_flag, header, and encode_strings, but it does not add per-parameter semantics beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Convert') and a precise resource (data files into an Mplus .dat file), then enumerates the supported formats and key transformation rules. This clearly distinguishes data_prepare from sibling tools that handle syntax, execution, or output inspection.

  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 the tool's use case obvious: prepare a data file for Mplus analysis and get the blocks to paste into an input file. It does not explicitly state when not to use it or name alternatives, but the context is clear enough.

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

• output_summaryA
  4.2/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 full burden. It discloses that the file must already exist and that the tool re-reads rather than repeats a run, conveying a read-only, non-executing behavior. It does not detail error handling or response shape, but for a summarizer this is reasonably transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no filler. The purpose and content scope are front-loaded, and the usage context is delivered compactly in the second sentence. Every phrase 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?

  For a tool with no output schema, the description covers what it summarizes and when to use it, while the schema handles include values and max_rows. It does not describe the response format or truncation behavior, but these are minor gaps given the simple read-only purpose.

  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 references the `include` parameter but does not add meaning beyond the schema, which already documents all parameters, defaults, and value options. No additional parameter clarification is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Summarise an Mplus .out file that already exists.' It enumerates the content covered (status, warnings, fit, parameter estimates) and clarifies via 're-read ... without repeating it' that this is distinct from running or creating output.

  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 says when to use the tool: for output produced outside this server or for re-reading an existing run without re-running it. This implies it is not for new analyses and differentiates it from run_file/run_syntax, though it does not name sibling tools or state exclusions directly.

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

• run_syntaxA
  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 full behavioral burden and does well: it discloses line folding to 90 characters, that .inp and .out files persist on disk, and what default output is summarised. It does not cover error behavior or run side effects, but the essential traits are transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three focused sentences with no filler. The core action is front-loaded, and each additional sentence adds useful behavioral or usage detail.

  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 six-parameter execution tool with no output schema, the description explains the operation, persistence, defaults, and output extension mechanism. It is slightly incomplete on what exactly the 'summary' contains as a return value, but enough is provided for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining what the default output contains and how `include` extends it, which goes beyond the schema's raw list of allowed sections.

  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 a specific verb-resource chain: write Mplus syntax to a file, run it, and summarise output. This differentiates it from nearby siblings like run_file (running existing files) and output_summary (summarising already-produced output).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for submitting new/supplied Mplus syntax and receiving a summary, and it gives guidance on requesting more output with `include`. However, it never explicitly contrasts this with sibling tools like run_file or build_syntax, so an agent must infer when to use this tool versus alternatives.

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

• savedata_readA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description must carry the behavioral burden. It discloses what is read, where the column layout comes from, what data types are present, and the optional CSV side effect. It does not describe exact return formatting or error cases, but covers the essential behavior well.

  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 tightly written sentences with no filler. The core behavior and data contents are front-loaded, and the optional CSV export is a clear, secondary clause.

  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 three-parameter read tool with no output schema and no annotations, the description covers the source, contents, layout origin, and optional destination. Minor edge cases such as behavior when the .out file lacks SAVEDATA information are not covered, but the essential invocation context is complete.

  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 schema already documents out_path, rows, and to_csv. The description adds a little context by mentioning CSV for R/Excel, but adds no parameter-level syntax or formatting detail 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?

  States a specific verb ('Read'), a precise resource ('the file a SAVEDATA command wrote'), and the meaningful content (factor scores, class probabilities, class membership). It also explains the key mechanism of using the column layout Mplus recorded in the .out file, which clearly differentiates it from siblings like output_summary or output_section.

  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?

  Gives clear context: this tool is for reading SAVEDATA output associated with an Mplus .out file, and optionally exporting it as CSV for R or Excel. It does not explicitly list exclusions or alternatives, but the intended use case is unmistakable.

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

• output_sectionA
  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 behavioral burden. It discloses verbatim return behavior and the list-sections mode. It omits edge behaviors like what happens when a section is not found or how max_chars truncates output, but the core behavior is clearly transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no filler. The primary action and purpose are front-loaded, and the secondary usage instruction is packed efficiently into the second sentence.

  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?

  There is no output schema, so the description appropriately explains the return value ('verbatim' section). It covers the main usage modes and lists example sections. Missing failure-mode details are minor for a straightforward read 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 baseline of 3 applies. The description reinforces `section` usage ('Call without section to list') but adds no real meaning beyond what the input schema already documents for `out_path`, `section`, and `max_chars`.

  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?

  Description uses a precise verb and resource: 'Return one section of an .out file verbatim.' It also states scope ('for anything the summary does not parse') and gives concrete examples (TECH1, TECH4, residuals), making it clearly distinguishable from output_summary and compare_fit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says when to use: for content the summary does not parse, and instructs how to discover sections by omitting `section`. This gives clear decision rules relative to the companion summary tool, though it does not name alternative tools directly.

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

• syntax_helpA
  4.4/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 disclosure burden. It effectively conveys that this is a non-destructive read-only lookup, discloses the no-argument listing behavior, and enumerates the exact valid topics. This is sufficient behavioral context for a reference 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?

  Two sentences with zero filler. The topic list is front-loaded, followed by the no-topic call convention and the usage timing in a logical, compact order.

  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?

  Complete for a simple one-parameter reference tool with no output schema. It covers topics, calling conventions, and when to use it. It could mention the shape of the returned content, but that is a minor gap given how self-contained the purpose is.

  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% and the schema already documents the topic parameter. The description adds genuine value beyond the schema by enumerating all valid topic values (mixture, cfa, growth, etc.), which the schema does not list. This goes beyond the baseline for high-coverage schemas.

  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+resource ('Mplus syntax reference') and enumerates the topics covered. It is clearly distinguished from its operational siblings (build_syntax, run_syntax, output_summary, compare_fit), which all execute or analyze rather than provide reference material.

  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?

  Gives an explicit usage condition: 'Use it before writing syntax for a model family you have not written recently.' It also discloses the no-topic listing behavior. It does not name exclusion cases or alternatives, but for a help tool the guidance is clear and actionable.

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

• mplus_statusA
  4.5/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 of signaling behavior. 'Report' plus the listed outputs implies a read-only diagnostic operation, and the note about installation-related failures gives useful execution context. It does not detail output formatting or authorization needs, but for a zero-argument status tool this is a minor gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no filler: the first states what the tool reports, the second states when to call it. The most decision-relevant information 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 zero-argument diagnostic tool with no output schema, the description is sufficient: it names the return categories (executable, version, demo limits) and the recommended invocation context. Nothing needed to call it correctly is 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 input schema has zero parameters, so there is no parameter semantics for the description to clarify. Baseline 4 applies because the absence of parameters makes schema coverage complete by vacuity.

  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 ('Report'), a clear resource ('Mplus executable'), and the exact aspects reported (version, demo-version limits). It is clearly distinct from all siblings, which are about syntax, running, output parsing, and savedata — none overlap with environment/status inspection.

  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 gives an explicit trigger condition and ordering: 'Call this first when a run fails for reasons that look like the installation rather than the model.' It does not list when not to use it or name alternative tools, so it stops short of a 5.

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