Server Quality Checklist

Tool Scores

• check_psn_statusC
  2.9/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 full burden. It mentions 'progress' implying interim state reporting, but fails to disclose if the operation is read-only, blocking vs. polling, error behaviors, or return structure.

  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?

  Single sentence with no filler words. Front-loaded with verb and resource. However, given the lack of annotations and output schema, the description may be overly terse rather than efficiently concise.

  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 single-parameter status tool, the description covers the 'what' adequately. However, with no output schema and no annotations, gaps remain regarding return value semantics (possible states like running/failed) and operational safety.

  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% (job_id described as 'PsN job ID'), establishing baseline 3. The description implicitly validates the parameter context by mentioning 'PsN VPC or bootstrap job', but does not elaborate on ID format or constraints beyond the schema.

  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 uses specific verbs ('Check status and progress') and identifies the resource ('PsN VPC or bootstrap job'). It distinguishes from execution siblings (execute_psn_bootstrap/vpc) by scope, though it could clarify distinction from check_run_status.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this versus the sibling check_run_status tool, or prerequisites like needing to submit a job first. The scope (VPC/bootstrap) is implied but not framed as a selection criterion.

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

• check_run_statusB
  3.1/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 of behavioral disclosure. It identifies the read-only nature of 'checking' but fails to disclose what status values mean, whether results are real-time or cached, error conditions (e.g., invalid job_id), or 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?

  The description is a single, efficient sentence that front-loads the verb ('Check') and contains no redundant or wasted words. 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.

  Completeness3/5

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

  For a single-parameter tool with no output schema, the description adequately covers the basic invocation pattern. However, it misses opportunities to add value given the lack of annotations—specifically, it omits what status states to expect (running, completed, failed) or polling recommendations.

  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?

  With 100% schema description coverage, the schema fully documents the single 'job_id' parameter including its provenance from 'submit_run'. The description adds minimal semantic value beyond the schema ('by job ID'), meeting the baseline for high-coverage schemas.

  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 specific action ('Check'), resource ('status and progress'), and scope ('submitted NONMEM run'). It implies distinction from sibling 'get_run_results' by emphasizing status/progress rather than final results, though it doesn't explicitly contrast with alternatives.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives like 'get_run_results' or 'list_runs'. While the schema notes the job_id comes from 'submit_run', the description lacks workflow context such as 'use this to monitor execution before retrieving final results'.

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

• summarize_runB
  3.1/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 of behavioral disclosure. It mentions 'combining' files but fails to state whether this is a read-only operation, whether it creates output files on disk, what the return format is, or if it requires specific permissions. This leaves significant behavioral gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the action ('Generate') and immediately qualifies the scope ('comprehensive summary') and methodology ('by combining...'). Every word serves a purpose with no redundancy.

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

  Completeness2/5

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

  Despite complete parameter documentation in the schema, the description omits critical context given the lack of annotations and output schema. It does not describe the return value format, structure of the summary, or side effects, which are essential for a tool that aggregates multiple file types.

  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?

  With 100% schema coverage, the baseline is 3. The description adds valuable domain context by specifying the exact file extensions processed (.ext, .lst), which helps clarify how the 'run_name' parameter is used to locate specific NONMEM output files, exceeding the basic schema definitions.

  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 generates a comprehensive summary and identifies the specific resource (NONMEM run) and constituent files processed (control stream, .ext, .lst). However, it does not explicitly differentiate from siblings like 'get_run_results' or clarify why one would choose this over individual file parsers.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives such as 'read_ext_file', 'read_lst_file', or 'get_run_results'. While the mention of 'combining' files implies a comprehensive use case, there are no when/when-not statements or alternatives named.

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

• get_run_resultsB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. While 'parsed' indicates structured data (distinguishing from raw file readers), the description omits critical details: return format, payload size considerations, idempotency, error behavior for invalid job IDs or failed runs, and whether it blocks for incomplete jobs.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with no redundant words. Key qualifiers ('full', 'parsed', 'completed') are front-loaded to immediately convey scope and distinguish the tool's output from alternatives.

  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 single-parameter retrieval tool, the description is minimally viable. However, given the lack of output schema and the likelihood that 'full results' represent a complex pharmacometric object, the description should indicate the return structure or content type (e.g., estimates, diagnostics, tables) to aid agent decision-making.

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

  Parameters3/5

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

  The input schema has 100% description coverage ('Job ID from submit_run'), establishing a baseline of 3. The description mentions 'by job ID' but adds no additional semantics regarding the parameter format, validation rules, or source constraints beyond what the schema already provides.

  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 identifies the action ('Get'), resource ('full parsed results'), and scope ('completed NONMEM run'). It implicitly distinguishes from siblings like 'check_run_status' (results vs status) and 'summarize_run' (full vs summary), though it doesn't explicitly contrast with 'parse_psn_results' which may cause confusion.

  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 includes the constraint 'completed' which implies when to use it, but lacks explicit guidance on workflow (e.g., 'use check_run_status first to verify completion') or error handling if the run is still active. No alternative tools are mentioned for incomplete runs.

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

• read_nm_tablesB
  3.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 full burden of behavioral disclosure. It mentions computing summary statistics and identifies specific columns processed, but does not specify the output format, whether the operation is read-only, or error handling behavior since no output schema exists to document the return 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?

  The description is a single, information-dense sentence with no filler. It front-loads the action ('Parse') and efficiently combines file type examples, operation details, and specific column targets without redundancy.

  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 single-parameter tool, the description adequately covers the input domain but leaves a gap regarding the return value structure since no output schema is present. It mentions 'summary statistics' but does not describe their format, granularity, or what happens when key columns are 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?

  While the schema has 100% coverage for the single file_path parameter, the description adds valuable semantic context by listing example file types (SDTAB, PATAB) and column names (CWRES, PRED, etc.), helping the agent understand what constitutes a valid NONMEM table file beyond the generic schema description.

  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 parses NONMEM table output files and computes summary statistics, using specific domain terminology (SDTAB, PATAB, CWRES, PRED, IPRED, ETAs) that identifies the exact resource type and distinguishes it from siblings like read_ext_file or read_nm_dataset which handle different file formats.

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

  Usage Guidelines2/5

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

  There is no explicit guidance on when to use this tool versus alternatives like parse_psn_results or read_nm_dataset, nor are there any stated prerequisites or exclusions. The specific file type examples provide implicit context but no direct usage instructions.

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

• cancel_runA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry full disclosure burden. It fails to explain behavioral traits such as whether cancellation is graceful or forceful, whether partial results are preserved, if the operation is reversible, or required permissions.

  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 single sentence is perfectly front-loaded with the action verb and contains no wasted words. 'Running' and 'NONMEM' each provide essential qualifying context that distinguishes this tool's scope.

  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 single-parameter mutation tool with no output schema, the description provides the minimum viable context to identify the tool's function. However, it lacks important contextual details about the consequences of cancellation (data retention, side effects) that would aid an agent in making informed invocation decisions.

  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?

  With 100% schema description coverage for the single 'job_id' parameter, the schema already documents the input adequately. The description does not add syntax details, format specifications, or guidance on how to obtain valid job IDs, meriting the baseline score.

  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 ('Cancel') with a clear resource ('NONMEM job') and state ('running'), distinguishing it from siblings like submit_run, check_run_status, or list_runs. It precisely identifies the domain and action.

  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 word 'running' implicitly indicates this is for active jobs only, providing minimal context. However, it lacks explicit guidance on when to use this versus letting jobs complete naturally, and does not mention prerequisites (e.g., job ownership requirements) or alternatives.

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

• execute_psn_vpcA
  3.5/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 disclosure. It successfully communicates async execution, job ID return, and external dependencies, but omits side effects (file creation), error behavior, or reversibility considerations important for a simulation 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?

  Three efficient sentences front-loaded with purpose: method declaration, return value, and prerequisites. No redundant or filler text; every clause provides essential operational context.

  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?

  Adequate for a specialized tool with no output schema and no annotations, as it compensates by describing the return value (job ID). However, given the complexity of VPC analysis and nested parameters, it could benefit from mentioning typical use cases or linking to polling mechanisms.

  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%, providing detailed documentation for all parameters including nested options (predcorr, stratify_on, etc.). The description adds no parameter-specific guidance beyond the schema, meeting the baseline expectation.

  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?

  Clearly states the tool runs VPC (Visual Predictive Check) using PsN, with the async nature specified. Distinguishes from siblings like execute_psn_bootstrap by specifying the VPC method, though it could explicitly differentiate from generate_vpc_data.

  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?

  Mentions prerequisites (PsN + NONMEM) and implies polling is needed via 'Returns job ID for polling', but lacks explicit guidance on when to use this versus generate_vpc_data or which tool to use for polling (check_run_status).

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

• submit_runA
  3.5/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 full burden. It discloses async behavior and prerequisites (NONMEM installation) but omits critical behavioral details like file system side effects, error handling if the executable is missing, queue behavior, or whether operations are idempotent.

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

  Conciseness5/5

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

  Three sentences with zero waste. Front-loaded with the core action ('Submit'), followed by return value and prerequisites. Every clause 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?

  Given the lack of output schema and annotations, the description adequately covers the return value (job ID) but omits details about output artifacts, error formats, or lifecycle management that would help an agent handle the async operation robustly.

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

  Parameters3/5

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

  The input schema has 100% description coverage, documenting all four parameters (ctl_path, work_dir, nmfe_path, run_name) including defaults. The description adds no additional parameter semantics beyond the schema, meeting the baseline expectation for high-coverage schemas.

  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 submits a NONMEM run with specific async behavior. It distinguishes itself from sibling status-checking tools by mentioning it returns a job ID for polling. However, it doesn't explicitly differentiate from similar execution tools like 'execute_psn_bootstrap' or 'execute_psn_vpc'.

  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 a polling workflow by stating it returns a 'job ID for polling,' suggesting the use of 'check_run_status'. It also notes the NONMEM installation prerequisite. However, it lacks explicit guidance on when to use this versus PSN-based execution siblings or cancellation policies.

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

• read_lst_fileA
  3.6/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 of behavioral disclosure. While 'Parse' implies a read-only operation, the description does not confirm this, nor does it disclose error handling (missing files), performance characteristics, or the structure/format of the returned data.

  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?

  Single sentence with zero redundancy. Front-loaded with action and target, followed by a precise comma-separated list of extracted data points. Every word serves a specific purpose.

  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 single parameter and simple input structure, the description adequately covers inputs. For outputs (no output schema provided), it compensates by listing the specific data fields returned (termination status, warnings, etc.), giving the agent clear expectations of what information will be available.

  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?

  With 100% schema description coverage ('Path to the .lst file'), the schema fully documents the parameter. The description mentions '.lst file' which aligns with the schema but adds no additional semantics regarding path format (absolute/relative), file encoding, or existence requirements. Baseline score appropriate 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?

  Specific verb ('Parse') and resource ('NONMEM .lst file') clearly identified. The enumerated outputs (termination status, minimization success, shrinkage, condition number, warnings) precisely distinguish this from siblings like read_ext_file, read_nm_tables, or parse_control_stream by specifying the exact file type and data extracted.

  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 specific outputs listed imply usage for checking run completion and quality metrics, providing implicit context. However, it lacks explicit guidance on when to choose this over alternatives like get_run_results or parse_psn_results, and states no prerequisites (e.g., run completion status).

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

• check_nonmem_setupA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states what is checked, not behavioral traits like: whether it returns structured data or plain text, what happens when installations are missing (errors vs warnings), whether it validates executable functionality or just path existence, or if it's safe to run repeatedly.

  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?

  Single sentence, nine words, front-loaded with the action verb. No redundancy or filler. Every word earns its place in describing the tool's scope.

  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?

  Given the moderate complexity (validating four different software installations) and absence of both output schema and annotations, the description should specify the return format (e.g., report object, status list) and error behavior. It adequately covers the input side but leaves output behavior undocumented.

  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, which establishes a baseline score of 4 per the scoring rubric. The description correctly implies no configuration is needed for this diagnostic check.

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

  Purpose5/5

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

  The description uses specific verbs ('Check') and lists exactly which resources are verified (NONMEM, PsN, R, mrgsolve) and what aspects are checked ('installation status and paths'). It clearly distinguishes from siblings like check_psn_status and check_r_setup by covering the full environment rather than individual components.

  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?

  While the scope (checking four installations at once) implies this is for comprehensive environment validation versus the specific 'check_*' siblings, there is no explicit guidance on when to prefer this over check_r_setup or check_psn_status, or whether this should be run before other operations.

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

• generate_vpc_dataA
  3.7/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. Fails to disclose critical behavioral traits: whether output is returned or written to disk (despite 'output_dir' parameter implying file I/O), side effects, or computational intensity. Only discloses input requirements.

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

  Conciseness5/5

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

  Three concise sentences with zero waste. Front-loaded with core function, followed by key differentiator (No NONMEM), then prerequisites. Every clause provides essential selection or usage information.

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

  Completeness3/5

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

  Given 8 parameters and no output schema/annotations, description covers the essential domain context (R packages used) and input requirements. Missing disclosure of output behavior (file generation vs return values) and error conditions, leaving gaps for a tool of this complexity.

  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%, providing comprehensive parameter documentation. Description adds minimal semantic value beyond schema, though it correctly notes that a 'model' is required (semantic constraint) even though the JSON schema only marks 'observed_data_path' as required. Baseline 3 appropriate given schema quality.

  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 specific verb ('Generate'), resource ('VPC data'), and implementation method ('mrgsolve + vpc R package'). The phrase 'No NONMEM needed' effectively distinguishes it from sibling tool 'execute_psn_vpc' and signals the alternative technology stack.

  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 clear prerequisites ('Requires observed data and model') and differentiates from NONMEM-based alternatives ('No NONMEM needed'). Lacks explicit 'when to use X instead' guidance, but the technology constraint provides implicit selection criteria.

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

• run_diagnosticsA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden and successfully discloses the diagnostic suite performed and NONMEM independence. However, it lacks critical safety disclosure (read-only vs. destructive) and omits output format details (returns data vs. writes report files).

  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 dense sentences with zero waste: the first front-loads the comprehensive diagnostic scope with specific metrics, the second delivers a critical prerequisite constraint. Every word 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?

  Adequate for basic invocation given the simple 2-parameter schema, but incomplete regarding execution outcomes. Without annotations or output schema, the description should disclose whether results are returned as structured data, written to disk, or displayed, and whether the tool modifies the run directory.

  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 clear descriptions for both run_dir and run_name (including auto-detection behavior). The description adds no parameter-specific semantics beyond what the schema already provides, warranting the baseline score.

  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') and resource ('post-run diagnostics'), enumerates exact diagnostic checks performed (boundary checks, condition number, shrinkage, precision/RSE, convergence warnings), and distinguishes from NONMEM-dependent siblings via 'No NONMEM needed'—critical context in this pharmacometrics toolset.

  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?

  Provides timing context ('post-run') and environment constraint ('No NONMEM needed'), but fails to explicitly differentiate from sibling analysis tools like summarize_run, check_run_status, or get_run_results which also operate on completed runs.

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

• translate_to_mrgsolveA
  3.7/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 full burden. It adds valuable scope limitations (supports ADVAN1-13 specifically, handles $PK/$DES/$ERROR sections) but omits critical behavioral details: whether output_path overwrites existing files, what is returned when output_path is omitted, or dependency requirements. The capability disclosure is helpful but incomplete for safe invocation.

  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 efficient sentences with zero redundancy. The first sentence front-loads the core transformation purpose; the second immediately qualifies supported subsystems. Every word serves to define scope or capability.

  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 file-conversion tool with complete parameter schema documentation, the description adequately covers the transformation logic. However, given the lack of output schema and annotations, it should clarify the return behavior (e.g., 'returns file path or model code') and file system side effects to be fully 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?

  Input schema has 100% description coverage, establishing a baseline of 3. The description adds domain context by mentioning THETAs and OMEGAs, which semantically links to the parameter_values parameter (used for overriding these specific estimates), but does not elaborate on syntax requirements or validation rules 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?

  Description explicitly states the transformation ('Translate'), source format ('NONMEM control stream'), and target format ('mrgsolve model code'). The mention of specific pharmacometric components (ADVAN1-13, THETAs, OMEGAs) clearly distinguishes this from sibling parse_control_stream (which only parses) and simulate_mrgsolve (which executes simulations).

  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?

  While the domain specificity (NONMEM-to-mrgsolve conversion) implies usage context, there is no explicit guidance on when to choose this over parse_control_stream for analysis, nor warnings about prerequisites (e.g., mrgsolve availability). The description relies on the tool name to convey intent without explicit when/when-not rules.

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

• compare_modelsA
  3.8/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 full burden. It successfully discloses what calculations are performed (delta-OFV, AIC), but fails to state whether the operation is read-only, requires completed runs, or describe the return format.

  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 well-structured sentences with zero waste: the first states purpose and metrics, the second specifies input requirements. Information is front-loaded with the action verb.

  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 single-parameter comparison tool with full schema coverage, the description is nearly complete. It could be improved by noting the read-only nature or output structure, but adequately describes the core functionality without requiring verbosity.

  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%, establishing a baseline of 3. The description adds semantic context that the inputs represent model runs and file paths, though it loosely mentions 'run directories' while the schema strictly specifies '.ext' file 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 uses specific verbs ('Compare') and resources ('NONMEM runs'), and explicitly lists comparison metrics (OFV, delta-OFV, parameter counts, AIC). This clearly distinguishes it from single-run siblings like 'summarize_run' or 'get_run_results'.

  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 usage context through the specific statistical metrics mentioned (suggesting use for model selection/comparison), but provides no explicit 'when to use' guidance or contrasts with alternatives like 'read_ext_file' for individual file inspection.

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

• list_runsA
  3.8/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 full burden of behavioral disclosure. It adds valuable specificity by enumerating the possible status values (completed/failed/running), but omits safety characteristics (read-only status), performance implications for large directories, or whether the operation is atomic.

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

  Conciseness5/5

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

  The description is a single, efficient sentence of 13 words with no redundancy. The parenthetical status enumeration adds precise value without verbosity. Information is front-loaded with the action and target.

  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 absence of an output schema, the description compensates by specifying what information is returned (status categories). For a simple 2-parameter listing tool, this is nearly complete, though explicitly stating the return format (e.g., 'returns an array') would provide full clarity.

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

  Parameters3/5

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

  The input schema has 100% description coverage, documenting both project_dir and recursive parameters completely. The description focuses on the operation rather than repeating parameter details, which is appropriate when the schema is self-documenting. Baseline score applies.

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

  Purpose5/5

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

  The description provides a specific verb (scan), target resource (NONMEM run files), and output detail (status categories: completed/failed/running). The scope 'project directory' clearly distinguishes this from sibling tools like check_run_status or get_run_results which likely operate on individual runs.

  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?

  While the description establishes the context (scanning a project directory), it lacks explicit guidance on when to prefer this over check_run_status for single-run checks or get_run_results for detailed results. Usage is implied by the directory-scanning scope but not explicitly contrasted with alternatives.

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

• parse_control_streamA
  3.8/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It discloses what gets extracted (structural components) but omits safety characteristics (read-only vs. destructive), error handling for malformed files, or validation behavior. 'Parse' implies non-destructive reading but this isn't explicitly stated.

  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?

  Single dense sentence with zero waste. Front-loaded with action ('Parse'), immediately identifies resource ('NONMEM control stream'), qualifies with extensions, and uses colon-delimited list for output specifics. Every clause 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?

  Given no output schema exists, the description effectively compensates by listing specific extracted components ($THETA, $OMEGA, etc.), giving users clear expectations of return value structure. Slight gap regarding whether it returns JSON, nested objects, or flat structure.

  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 has 100% coverage with clear description ('Path to the .ctl or .mod file'). The description reinforces the file type context but doesn't add additional semantics like path format requirements (absolute vs. relative) or file encoding expectations. Baseline 3 appropriate 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?

  Excellent specificity: 'Parse' (clear verb), 'NONMEM control stream' (specific resource), file extensions (.ctl/.mod), and enumerated components ($THETA, $OMEGA, etc.) clearly distinguish it from sibling tools like read_lst_file or parse_psn_results which handle outputs rather than input control files.

  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?

  Provides implied usage through the specific components listed (parameter structures vs. execution/results), but lacks explicit guidance such as 'use this to inspect model structure before running' or contrasts with siblings like read_nm_dataset which reads data files rather than control files.

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

• read_ext_fileA
  3.8/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 full burden. It transparently discloses what data is extracted (parameter estimates, standard errors, OFV, eigenvalues, condition number), but omits safety profile (read-only status), error handling for malformed files, or performance characteristics.

  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?

  Single sentence with zero waste. Front-loaded with the action ('Parse'), immediately identifies the domain-specific file type ('NONMEM .ext file'), and efficiently lists the five categories of extracted data. Every clause 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?

  Given the lack of output schema, the description compensates well by enumerating the specific data elements returned (parameter estimates through condition number). For a single-parameter read tool, this is sufficient, though explicit mention of return structure format would elevate it further.

  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 the file_path parameter fully documented as 'Path to the .ext file'. The description reinforces the expected file type but adds no additional semantic details about valid path formats or constraints beyond the schema, warranting the baseline score.

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

  Purpose5/5

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

  The description uses specific action verbs ('Parse', 'extract') and identifies the exact resource ('NONMEM .ext file'). It clearly distinguishes from siblings like read_lst_file and read_nm_tables by specifying the .ext extension and listing unique outputs (parameter estimates, OFV, eigenvalues) typical of this file format.

  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 usage through the file extension '.ext' and lists specific extracted content, helping agents select this when needing parameter estimates or OFV values. However, it lacks explicit guidance on when to prefer this over siblings like read_lst_file or get_run_results, or prerequisites like file existence.

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

• read_nm_datasetA
  3.8/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 full burden. It successfully discloses what the tool produces (the five summary statistics listed), but fails to mention safety properties (read-only), performance characteristics on large datasets, or error handling behavior.

  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?

  Single sentence efficiently structured with action first ('Read and summarize'), followed by specific outputs after the colon. Zero redundancy; every element specifies either the operation or a specific summary component produced.

  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 output schema exists, the description compensates effectively by enumerating the five summary components returned (subject count through column overview). However, it lacks mention of error conditions or output format structure, and should ideally note the read-only nature given absent annotations.

  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 adds domain context by specifying 'NONMEM dataset' which clarifies the expected file format for file_path, but does not elaborate on parameter syntax or validation rules beyond what the schema provides.

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

  Purpose5/5

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

  Description provides specific verb ('Read and summarize') and resource ('NONMEM dataset'), clearly distinguishing it from siblings like read_ext_file, read_lst_file, and read_nm_tables which handle output files rather than input datasets. The scope is precisely defined.

  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?

  While the description implies exploratory data analysis use through the listed summary statistics (subject count, dose records, etc.), it lacks explicit guidance on when to use this versus read_nm_tables or parse_control_stream. No prerequisites or exclusions are stated.

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

• parse_psn_resultsA
  3.9/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 full burden. It successfully discloses the standalone nature (no installation required) and input constraints (VPC/bootstrap only). However, it fails to state whether the tool is read-only, what format it returns (JSON, tables, files?), or error conditions.

  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 waste: first states core purpose, second states the key deployment constraint. Information is front-loaded and appropriately sized for a single-parameter tool.

  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?

  Given no output schema exists, the description should ideally characterize the return value (parsed data structure, file content, etc.). It adequately covers input requirements but leaves a gap regarding output format and behavioral side effects.

  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% for the single parameter, establishing a baseline of 3. The description adds value by constraining 'results_dir' to contain 'VPC or bootstrap' results specifically, providing semantic context beyond the schema's generic 'Path to PsN output directory'.

  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 states specific verb ('Parse'), resource ('results from an existing PsN output directory'), and scope ('VPC or bootstrap'). The 'existing' qualifier and specific result types distinguish it from sibling execution tools like execute_psn_bootstrap.

  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 phrase 'No PsN/NONMEM installation needed' provides an implicit usage guideline (use when software isn't installed locally). However, it lacks explicit when-not-to-use guidance or named alternatives like get_run_results or read_lst_file for different parsing scenarios.

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

• simulate_mrgsolveA
  3.9/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 full burden. It fails to disclose what the tool returns (given no output_schema), whether it creates/modifies files via output_path, or computational intensity. The description only states what it does, not behavioral side effects.

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

  Conciseness5/5

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

  Three sentences with zero waste: purpose declaration first, sibling differentiation second, input requirement third. Appropriately front-loaded and compact for the complexity level.

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

  Completeness3/5

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

  With 10 parameters and no output schema, the description should disclose return behavior or file output characteristics. While the schema documents parameters well, the agent lacks guidance on what simulation results look like or how output_path behaves.

  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?

  With 100% schema coverage, baseline is 3. The description adds crucial semantic guidance that either model_code OR model_file must be provided—a logical requirement not enforced by the schema since both parameters are marked optional. This prevents invocation errors.

  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 specific action (Run a simulation) and resource (mrgsolve), and explicitly distinguishes from NONMEM-based siblings with 'No NONMEM needed.' The R context is also specified.

  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 'No NONMEM needed' phrase effectively signals when to use this tool versus NONMEM-based alternatives like submit_run or execute_psn_bootstrap. However, it lacks explicit guidance on when to use this versus translate_to_mrgsolve or prerequisites for the simulation.

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

• check_r_setupA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Discloses what gets checked (R installation + 4 specific packages) but omits critical behavioral details: whether it auto-installs missing packages, throws errors, or returns structured status data. Lists packages but not failure modes.

  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?

  Single efficient sentence with no wasted words. Action verb front-loaded, specific package enumeration in parentheses provides clarity without verbosity. Appropriate length for the tool's scope.

  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 zero parameters and simple check purpose, description adequately covers inputs. Missing output specification (what constitutes pass/fail, return format) but sufficient for agent to understand tool's verification scope given the complexity level.

  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?

  Input schema contains zero parameters (empty object). Per scoring rules, 0 parameters establishes baseline score of 4. Description appropriately requires no additional parameter explanation.

  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 specific verb 'Check' with clear resource 'R installation and required packages', explicitly listing the four packages (mrgsolve, vpc, dplyr, ggplot2). Effectively distinguishes from sibling check tools like check_nonmem_setup and check_psn_status by specifying R ecosystem.

  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?

  No explicit when-to-use or when-not-to-use guidance provided. However, context implies usage before R-dependent operations (e.g., simulate_mrgsolve, generate_vpc_data). Lacks explicit prerequisites or sequencing guidance.

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

• execute_psn_bootstrapA
  4.2/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 full burden and successfully discloses critical behavioral traits: the asynchronous nature ('async'), the polling-based return value ('job ID'), and external dependencies ('PsN + NONMEM'). It does not disclose potential side effects or cleanup behavior.

  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 consists of three dense, front-loaded sentences with zero waste: the action, the return value, and the prerequisites. Every clause earns its place by conveying distinct operational information.

  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 lack of output schema, the description appropriately compensates by documenting the return value ('job ID'). It adequately covers the tool's complexity (nested options, external dependencies) for an execution utility, though it could specify error conditions or polling intervals.

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

  Parameters3/5

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

  The input schema has 100% description coverage, establishing a baseline score of 3. The description adds no additional parameter semantics, examples, or syntax guidance beyond what the schema already provides for model_path, samples, and the nested options object.

  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') with a clear resource ('bootstrap using PsN'), explicitly distinguishing this tool from siblings like execute_psn_vpc. The parenthetical '(async)' further clarifies the execution model.

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

  Usage Guidelines4/5

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

  The description provides clear context by stating prerequisites ('Requires PsN + NONMEM') and the return value pattern ('Returns job ID for polling'), implying the async workflow. However, it lacks explicit guidance on when to choose this over similar execution tools or cancellation policies.

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