SCMCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific single-cell analysis tasks, but some overlap exists in visualization tools (e.g., pl_dotplot vs ccc_dot_plot) and clustering algorithms (leiden vs louvain) that could cause confusion. Descriptions generally help clarify differences, but the sheer number of tools increases potential for misselection.
Naming Consistency3/5
The naming follows mixed conventions: many use verb_noun patterns (filter_cells, calculate_qc_metrics), but others use abbreviations (ccc, pca, tsne) or prefix patterns (pl_ for plotting tools). While readable, the inconsistency between descriptive names and technical abbreviations creates a fragmented naming scheme.
Tool Count2/5
With 52 tools, this server is overloaded for a single-cell analysis domain. While comprehensive, the count far exceeds typical well-scoped servers (3-15 tools), making it difficult for agents to navigate and increasing cognitive load. A more modular approach would be more appropriate.
Completeness5/5
The tool set provides exceptionally complete coverage of single-cell analysis workflows, including data I/O (read_tool, write_tool), preprocessing (filtering, normalization), analysis (clustering, differential expression, cell-cell communication), and visualization. No obvious gaps exist for core single-cell analysis tasks.
Average 2.7/5 across 52 of 52 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 16, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under BSD 3-Clause.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/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 but fails completely. It doesn't indicate whether this is a read-only or destructive operation, what permissions might be required, what the output looks like, or any performance characteristics. The single phrase provides zero behavioral context beyond the basic action implied by the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (only three words), this represents under-specification rather than effective conciseness. The description fails to provide any meaningful information that would help an agent understand or use the tool. Every word should earn its place, but here the words don't provide sufficient value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 9 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what 'adata' refers to (AnnData objects), what the tool actually produces, when to use it, or any behavioral characteristics. The agent would struggle to use this tool correctly based solely on the description.
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 description coverage is 100%, meaning all 9 parameters are well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema descriptions. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'merge multiple adata' is a tautology that essentially restates the tool name 'merge_adata'. While it implies combining AnnData objects, it lacks specificity about what 'merge' means in this context (concatenation along specific axes) and doesn't distinguish this tool from potential sibling tools that might also manipulate AnnData objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of prerequisites, typical use cases, or comparison to other data manipulation tools in the sibling list. The agent must infer usage solely from the tool name and parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it only states 'Partition-based graph abstraction' without explaining what the tool does operationally (e.g., computes connectivity, generates abstracted graphs), what it returns, or any side effects like data modification. This is inadequate for a tool with parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with a single phrase, the description is under-specified and fails to convey essential information. Conciseness should not come at the cost of clarity; this is too brief to be useful, making it inefficient rather than well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by parameters like 'use_rna_velocity' and 'model', and the lack of annotations and output schema, the description is severely incomplete. It doesn't explain the tool's purpose, behavior, or output, leaving critical gaps for an AI agent to understand and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema, such as clarifying relationships between parameters or typical use cases. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Partition-based graph abstraction' is essentially a tautology that restates the tool name 'paga' (which appears to be an acronym for Partition-based Graph Abstraction). It doesn't specify what action the tool performs (e.g., compute, generate, analyze) or what resource it operates on, making it vague and unhelpful for distinguishing from sibling tools like 'leiden' or 'louvain' that also work with graph-based clustering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of context, prerequisites, or comparisons to sibling tools like 'leiden', 'louvain', or 'neighbors', which are related to graph-based analysis. This leaves the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description reveals nothing about what the tool actually does (generates a plot? returns data?), what happens when invoked (creates output file? displays visualization?), error conditions, or performance characteristics. It's completely inadequate for a tool with 24 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (one short sentence), this is under-specification rather than effective conciseness. The single sentence doesn't earn its place by providing meaningful information beyond the tool name. No structure or front-loading of key information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 24 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool produces (plot? image? data?), how results are returned, or provide any context for when and why to use it. The description fails to compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 24 parameters thoroughly. The description adds zero parameter information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Heatmap of the expression values of genes' restates the tool name 'pl_heatmap' in slightly different words (tautology). It doesn't specify what action the tool performs (e.g., 'generate', 'plot', 'create') or distinguish it from sibling plotting tools like pl_dotplot, pl_matrixplot, or pl_scatter. The purpose is vague beyond stating it's a heatmap visualization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling plotting tools (pl_dotplot, pl_matrixplot, pl_scatter, etc.) with no indication of when a heatmap is preferred. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but fails completely. It doesn't mention that this is a visualization/read-only operation (implied but not stated), doesn't describe what the output looks like (no output schema exists), doesn't mention performance characteristics, data requirements, or any side effects. For a complex 30-parameter visualization tool, this is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short phrases) but this brevity comes at the cost of being under-specified rather than efficient. While it's not verbose or repetitive, it fails to provide essential information that would help an AI agent understand and use the tool effectively. The structure is simple but inadequate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (30 parameters), lack of annotations, and absence of an output schema, the description is completely inadequate. It doesn't explain what PCA coordinates are being plotted, what data format is expected, what the visualization output contains, or how this tool relates to the data analysis workflow. For such a sophisticated visualization tool, this minimal description fails to provide necessary context.
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 description coverage is 100%, so all parameters are documented in the schema itself. The description adds no parameter information beyond what's already in the comprehensive schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scatter plot in PCA coordinates. default figure for PCA plot' is vague and tautological. It restates the tool name 'pl_pca' (plot PCA) without specifying what it actually does - it doesn't clarify that this visualizes principal component analysis results as a scatter plot, nor does it distinguish it from sibling tools like 'pl_scatter' or 'pl_embedding'. The phrase 'default figure for PCA plot' adds confusion rather than clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There are absolutely no usage guidelines provided. The description doesn't indicate when to use this tool versus alternatives like 'pl_scatter', 'pl_embedding', or 'pl_pca_variance_ratio' (all sibling tools). It offers no context about prerequisites, when this visualization is appropriate, or what data state is required before calling this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it only names the analysis without describing what the tool does operationally—whether it modifies data, returns results, requires preprocessed inputs, or has side effects. This leaves critical behavioral aspects undefined, failing to compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single phrase—which avoids waste. However, it is under-specified rather than efficiently informative. It is front-loaded but lacks substance, so it doesn't fully earn a top score for conciseness, as brevity here comes at the cost of clarity.
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?
Given the complexity implied by 5 parameters and no output schema, the description is incomplete. It fails to explain what DPT analysis entails, what it returns, or how it fits into a workflow. Without annotations or output schema, the description should provide more context to guide the agent, but it does not, leaving significant gaps in understanding the tool's role and results.
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, with each parameter well-documented in the schema itself. The tool description adds no additional meaning or context about the parameters, such as typical values or interactions. Since the schema does the heavy lifting, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Diffusion Pseudotime (DPT) analysis' is tautological, essentially restating the tool name with minimal elaboration. It lacks a specific verb or clear action, making the purpose vague. While it hints at a computational biology analysis, it doesn't distinguish this tool from siblings like 'diffmap' or 'paga' that might also involve trajectory or pseudotime analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context, prerequisites, or exclusions. Given the sibling tools include other analysis methods (e.g., 'diffmap', 'paga', 'tsne'), the lack of usage guidelines leaves the agent without direction on selecting this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but offers none. It doesn't indicate whether this is a read-only analysis tool or if it modifies data, what the computational requirements might be, whether it's reversible, or what the output format is. The description fails to provide any behavioral context beyond the bare name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this is under-specification rather than effective conciseness. The description doesn't earn its place by providing any useful information beyond the tool name. A truly concise description would still convey essential purpose and context in minimal words.
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?
For a complex statistical analysis tool with 8 parameters and no output schema, the description is completely inadequate. It doesn't explain what PCA does in this context, what data it operates on, what results to expect, or how it fits with other tools. The absence of annotations and output schema means the description should provide substantial context, which it fails to do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 8 parameters. The description adds no parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation purely through the schema, with no value added by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Principal component analysis' is a tautology that merely restates the tool name 'pca' without specifying what it actually does. It doesn't indicate what resource it operates on (e.g., gene expression data), what the output is, or how it differs from sibling tools like 'pl_pca' or 'pl_pca_variance_ratio'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple related PCA tools in the sibling list (pl_pca, pl_pca_variance_ratio), but the description doesn't explain when this computational PCA tool should be used versus visualization tools or what prerequisites might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but fails to do so. It does not explain what 'regress out' entails operationally—whether it modifies data in place, requires specific permissions, has side effects, or handles errors. The parenthetical '(mostly)' is ambiguous and unhelpful.
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 a single, brief sentence that is front-loaded and wastes no words. However, its extreme brevity leads to under-specification rather than true conciseness, as it omits necessary details for clarity and usage.
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?
Given the complexity implied by the tool name (a statistical regression operation), lack of annotations, and no output schema, the description is incomplete. It does not explain what data is affected, the output format, or how it integrates with other preprocessing tools in the sibling list, leaving significant gaps for an AI agent.
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 description coverage is 100%, so the input schema already documents all parameters ('keys', 'layer', 'n_jobs') with clear descriptions. The tool description adds no additional meaning or context about these parameters beyond what the schema provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Regress out (mostly) unwanted sources of variation' is vague and tautological—it essentially restates the tool name 'regress_out' without specifying what is being regressed or in what context. It does not clearly distinguish this tool from sibling tools like 'combat' or 'scale', which might also handle variation reduction in data preprocessing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any specific scenarios, prerequisites, or comparisons to sibling tools such as 'combat' or 'normalize_total', leaving the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. 'Annotate' implies a write/mutation operation that modifies data, but it doesn't specify whether this is destructive (e.g., adds annotations to existing objects, creates new objects, or filters datasets). It doesn't mention performance characteristics, error conditions, or what the output looks like (especially problematic since there's no output schema).
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 extremely concise at just three words, with zero wasted text. It's front-loaded with the core action ('Annotate') though lacking detail. For conciseness alone, it's optimal, but this comes at the cost of being under-specified.
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?
Given the complexity (12 parameters, statistical gene selection tool), absence of annotations, and no output schema, the description is severely incomplete. It doesn't explain what 'annotation' entails, what the tool returns, how it affects the data object, or its role in a typical analysis pipeline. For a tool with this many parameters and no structured output documentation, the description should provide much more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly with descriptions, defaults, and constraints. The description adds no parameter information beyond what's in the schema, not even high-level context about how parameters interact (e.g., that 'flavor' choice affects which other parameters are relevant). This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Annotate highly variable genes' is a tautology that essentially restates the tool name 'highly_variable_genes'. It provides the verb 'annotate' but doesn't specify what annotation means in this context (e.g., marking genes in a dataset, calculating statistical metrics, or filtering). While it distinguishes from some siblings like 'filter_genes' or 'score_genes', it doesn't clearly differentiate from 'pl_highly_variable_genes' which appears to be a visualization sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires normalized data), when it's appropriate in a workflow, or what alternatives exist among the many sibling tools (e.g., 'filter_genes', 'score_genes', 'pl_highly_variable_genes'). The agent must infer usage solely from the name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states what the tool does (plotting), but doesn't mention whether it creates a file, displays an image, requires specific data preprocessing, has side effects, or any performance considerations. For a complex tool with 24 parameters, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but not particularly well-structured. The first sentence states the purpose, while the second adds a vague note about defaults. However, the second sentence doesn't provide clear value and contains a typo ('Defualt'), reducing its effectiveness. It's concise but could be more polished and informative.
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?
Given the tool's complexity (24 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain what the tool returns (e.g., a plot object, file path, or visualization), how to interpret results, or any prerequisites. For a visualization tool with many configuration options, more context is needed to help an agent use it effectively.
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 description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds no parameter-specific information beyond what's already in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Plot ranking of genes(DEGs) using dotplot visualization', which provides a clear verb ('Plot') and resource ('ranking of genes'). However, it doesn't differentiate from sibling tools like 'pl_dotplot' or 'pl_matrixplot' that might also create dot plots, and the mention of 'rank_genes_groups tool' is vague without explaining what that tool does.
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 guidance on when to use this tool versus alternatives. It mentions 'Default plot DEGs for rank_genes_groups tool', but this is unclear without context on what that tool does or when this visualization is preferred over other plotting tools like 'pl_heatmap' or 'pl_violin' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 provides minimal behavioral information. It mentions 'batch effect correction' which implies data transformation, but doesn't disclose whether this is destructive (modifies input data), requires specific data formats, has computational requirements, or what the output looks like. Significant behavioral gaps remain.
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 extremely concise - a single sentence that directly states the tool's function. There's no wasted language or unnecessary elaboration. However, the brevity comes at the cost of completeness, making it more under-specified than optimally concise.
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?
For a data transformation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, what data format it expects, whether it modifies data in-place, or how it differs from other correction methods. Given the complexity of batch effect correction and lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, with high schema coverage (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs 'batch effect correction' using the 'ComBat function', which is a specific statistical method. However, it doesn't clearly distinguish this from sibling tools like 'regress_out' or 'scale' that might also address data normalization or correction. The purpose is clear but lacks sibling differentiation.
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 guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., requires normalized data), when batch correction is appropriate, or what alternatives exist among the many sibling tools for data processing and normalization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the tool creates a plot but doesn't disclose behavioral traits like whether it returns an image file, displays the plot, saves it, or modifies data. It also doesn't mention error conditions, performance implications, or dependencies. For a complex plotting tool with 42 parameters, this is a significant gap.
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 a single, efficient sentence that states the core purpose. It's appropriately sized and front-loaded with the main action. However, it could be more structured by including key usage notes, but it avoids unnecessary verbosity.
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?
Given the high complexity (42 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., a plot object, file path, or visualization), how to interpret results, or any side effects. For a plotting tool in a data analysis context, more guidance on output and behavior is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 42 parameters thoroughly. The description adds no parameter-specific information beyond implying the 'basis' parameter is for embedding types like UMAP or t-SNE. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with additional context like typical values or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates a scatter plot for embeddings, which is a clear purpose. However, it's vague about the specific resource (e.g., what data it plots from) and doesn't distinguish from sibling tools like 'pl_scatter' or 'pl_pca', which also create plots. It mentions 'embedding basis' but doesn't specify this is for AnnData objects or single-cell data.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing pre-computed embeddings), compare to sibling tools like 'pl_scatter' or 'pl_pca', or specify use cases. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It mentions the tool generates a plot but fails to describe key traits: it doesn't specify if this is a read-only operation, what data source it uses (e.g., from prior analysis like 'highly_variable_genes'), the output format (e.g., image file, display), or any side effects like saving files. This leaves significant gaps in understanding the tool's behavior.
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 concise and front-loaded, stating the purpose in a single sentence with no wasted words. It efficiently communicates the core action ('plot highly variable genes') and visualization type ('dispersions or normalized variance versus means'), making it easy to parse, though it could benefit from slightly more structure to enhance clarity.
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?
Given the complexity of a plotting tool with 12 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., output format, data dependencies), usage context, and how it integrates with sibling tools. While the schema covers parameters well, the description fails to compensate for other gaps, making it inadequate for full agent understanding.
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, providing clear details for all 12 parameters (e.g., 'figsize' for figure dimensions, 'log' for logarithmic axes). The description adds no additional parameter semantics beyond the schema, as it doesn't explain how parameters interact or their impact on the plot. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately documents parameters without extra help from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'plot[s] highly variable genes' and specifies 'Plot dispersions or normalized variance versus means for genes,' which clarifies the action and visualization type. However, it's somewhat vague about the exact statistical context (e.g., what data it operates on) and doesn't differentiate from sibling tools like 'pl_scatter' or 'pl_embedding' that might also plot gene data, leaving room for ambiguity.
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 guidance on when to use this tool versus alternatives, such as other plotting tools in the sibling list (e.g., 'pl_scatter' for general scatter plots or 'highly_variable_genes' for non-plotting analysis). It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 plotting but doesn't disclose behavioral traits such as whether it modifies data, requires specific data formats (e.g., AnnData), outputs a plot file or displays it, handles errors, or has performance considerations. The description is too minimal for a tool with 23 parameters.
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 concise with two short phrases, but it's not front-loaded with the most critical information (e.g., data source). It avoids redundancy, but could be more structured to highlight key aspects like input requirements.
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?
Given high complexity (23 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what the tool returns (e.g., a plot object, file path, or visualization), data dependencies, or integration with sibling tools. This leaves significant gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 23 parameters. The description adds no parameter-specific information beyond implying two variables are plotted, which is already clear from parameter names like 'x' and 'y'. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool plots a scatter plot of two variables, which is a clear purpose, but it's vague about what data it operates on (e.g., from an AnnData object common in single-cell analysis) and the phrase 'along observations or variables axes' is ambiguous. It doesn't distinguish from siblings like 'pl_embedding' or 'pl_pca' which might also produce scatter plots.
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 guidance is provided on when to use this tool versus alternatives like 'pl_embedding' for embeddings or 'pl_dotplot' for other visualizations. The description lacks context about prerequisites (e.g., requires preprocessed data) or typical use cases, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but only states what the tool does, not how it behaves. It lacks information on output format (e.g., image file, display), side effects, performance, or error handling, which is insufficient for a plotting tool with many parameters.
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 a single, efficient sentence with no wasted words. It's appropriately sized for a basic purpose statement, though it could be more informative given the tool's complexity.
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?
Given the tool's complexity (19 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain what the plot outputs, how to interpret it, or critical behavioral aspects, leaving significant gaps for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 19 parameters. The description adds no parameter-specific information beyond the schema, but the high coverage justifies a baseline score of 3, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates a 'compact plot of expression of a list of genes,' which provides a basic purpose but is vague about the specific type of plot and lacks differentiation from sibling tools like pl_dotplot or pl_heatmap. It doesn't specify what 'tracksplot' means or how it differs from other plotting tools in the server.
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 guidance is provided on when to use this tool versus alternatives like pl_dotplot or pl_matrixplot. The description doesn't mention prerequisites, context, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It mentions 'for visualization' which suggests a read/transform operation rather than destructive modification, but doesn't clarify computational requirements, memory usage, typical runtime, or what the output actually contains. For a complex tool with 13 parameters, this leaves significant behavioral unknowns.
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 extremely concise - a single phrase that identifies the algorithm and its purpose. There's no wasted language or redundancy. However, given the tool's complexity (13 parameters, no output schema), this brevity borders on under-specification rather than optimal conciseness.
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?
For a complex dimensionality reduction tool with 13 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (embeddings? plots? transformed data?), doesn't mention typical input data formats, and provides no context about how UMAP differs from other available methods. The agent would struggle to use this tool effectively based solely on this description.
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%, with all 13 parameters well-documented in the schema itself. The description adds no parameter-specific information beyond the generic mention of UMAP. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't provide any higher-level guidance about which parameters are most important or typical configurations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Uniform Manifold Approximation and Projection (UMAP) for visualization' which identifies the algorithm and its purpose (dimensionality reduction for visualization). However, it's somewhat vague about what the tool actually does - it doesn't specify whether it creates embeddings, transforms data, or generates plots. Among siblings like 'tsne', 'pca', and 'diffmap', it doesn't clearly differentiate UMAP's specific use cases or advantages.
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 guidance on when to use UMAP versus alternative dimensionality reduction methods like 'tsne', 'pca', or 'diffmap' that are available as sibling tools. There's no mention of typical use cases, prerequisites, or performance characteristics that would help an agent choose between these visualization/dimensionality reduction options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Hierarchical clustering dendrogram' implies a computation/visualization tool but doesn't disclose behavioral traits: whether it modifies data (e.g., adds to .uns), requires specific data formats, has performance considerations, or what the output looks like (plot vs data structure). For a tool with 9 parameters and no annotations, this is a significant gap in transparency.
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 extremely concise at two words with zero waste. It's front-loaded with the core concept. While it's under-specified, this dimension scores conciseness, not completeness, and it earns full marks for brevity.
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?
Given the tool's complexity (9 parameters, clustering operation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (plot, data structure, or modification to data object), typical use cases, or how it fits into analysis workflows. For a computational tool with many parameters, more context is needed.
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 parameters are well-documented in the schema itself. The description adds no parameter information beyond what's in the schema. It doesn't explain relationships between parameters (e.g., how var_names overrides use_rep and n_pcs) or provide usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hierarchical clustering dendrogram' states the tool's purpose but is vague. It identifies the output type (dendrogram) and method (hierarchical clustering) but doesn't specify what action the tool performs (e.g., computes, generates, plots) or what data it operates on. It doesn't distinguish from siblings like 'leiden' or 'louvain' which are also clustering methods.
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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'leiden' (community detection) or 'paga' (trajectory inference) that might be used for similar clustering or analysis tasks. There's no indication of prerequisites, typical workflows, or when hierarchical clustering is preferred over other methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It mentions 'force-directed graph drawing' which implies a computational process, but fails to describe what the tool actually does behaviorally: does it modify data structures, create visual output files, or update internal state? It doesn't address permissions, side effects, or output format, leaving significant gaps for a tool with 8 parameters.
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 phrase that's appropriately sized for its purpose. It's front-loaded with the core functionality and contains no wasted words. Every part of the description earns its place by conveying the essential concept without unnecessary elaboration.
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?
Given the complexity (8 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool actually produces (e.g., a visualization file, updated data structure, or plot object), what data it operates on, or how it integrates with the broader workflow. For a visualization tool with many parameters, this leaves too many unanswered questions for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Force-directed graph drawing for visualization' states the general purpose (graph drawing) and technique (force-directed), but it's vague about what specific resource it operates on and doesn't distinguish from sibling tools like 'paga', 'dendrogram', or 'embedding_density' which also create visualizations. It lacks the specificity needed for clear tool selection.
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 guidance on when to use this tool versus alternatives. With many sibling tools for visualization (e.g., 'paga', 'dendrogram', 'pl_embedding'), there's no indication of what makes 'draw_graph' distinct or appropriate for certain scenarios over others. This leaves the agent guessing about proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the tool does at a high level. It doesn't disclose behavioral traits such as whether it modifies data in-place, requires specific permissions, has side effects, or handles errors, which is inadequate for a tool with 8 parameters and no output schema.
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 zero waste, clearly stating the core action without unnecessary details. It's appropriately sized and front-loaded, making it easy to parse quickly.
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?
Given the tool's complexity (8 parameters, no output schema, and no annotations), the description is incomplete. It lacks context on what the tool returns, how it integrates with other tools (e.g., 'rank_genes_groups'), and behavioral details, making it insufficient for effective agent use without heavy reliance on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying fold change and fraction filtering, which aligns with parameters like 'min_fold_change' and 'min_in_group_fraction' but doesn't enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool filters genes based on fold change and fraction, which gives a basic purpose, but it's vague about what specific resource or dataset it operates on (e.g., 'rank_genes_groups' output from an 'adata' object). It doesn't distinguish from siblings like 'filter_genes' or 'rank_genes_groups', leaving ambiguity about scope.
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 guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing prior output from 'rank_genes_groups'), exclusions, or comparisons to siblings like 'filter_genes' or 'highly_variable_genes', leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 offers minimal behavioral context. It mentions the outcome ('same total count') but doesn't disclose that this is a destructive transformation of count data, doesn't explain what 'normalize' means mathematically (scaling factors), and omits critical details like whether it handles sparse matrices or preserves data structure. The description fails to compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core function without unnecessary words. It's appropriately sized for a tool with well-documented parameters in the schema, and every word earns its place by conveying the essential purpose.
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?
Given the complexity (8 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain the mathematical operation, doesn't mention typical inputs/outputs (e.g., operates on AnnData objects), and provides no context about the transformation's impact on downstream analysis. For a preprocessing tool with significant parameters, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose as 'Normalize counts per cell to the same total count', which is clear about the operation (normalize) and target (counts per cell). However, it lacks specificity about the domain (single-cell RNA-seq data) and doesn't differentiate from sibling tools like 'scale' or 'log1p' that also perform normalization-like operations.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires raw count data), typical workflow position (early preprocessing), or comparison to other normalization methods available in sibling tools. The agent must infer usage from parameter descriptions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the basic action. It doesn't disclose behavioral traits like whether it modifies data, requires specific data formats, has side effects, or what the output looks like (e.g., returns a plot object or displays it). This is inadequate for a tool with 25 parameters and no output schema.
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 directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.
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?
Given the high complexity (25 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain the tool's context (e.g., part of a data analysis pipeline), output behavior, or key usage constraints. For such a rich tool, more comprehensive guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 25 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema, such as explaining key parameters like 'groupby' or 'var_names' in more detail. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates a heatmap of mean expression values per group, which is a clear purpose. However, it's somewhat vague about the specific context (e.g., biological data analysis) and doesn't distinguish it from sibling tools like pl_heatmap or pl_dotplot, which might create similar visualizations.
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 guidance is provided on when to use this tool versus alternatives like pl_heatmap or pl_dotplot. The description only states what it does, not when it's appropriate or what prerequisites are needed (e.g., requires grouped data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 plotting but doesn't disclose behavioral traits like whether it modifies data, requires specific data formats (e.g., AnnData), outputs a plot vs. data, handles errors, or has performance considerations. The description is too minimal to inform the agent about how the tool behaves beyond basic functionality.
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 zero waste—it directly states the tool's purpose without fluff. It's appropriately sized for a plotting tool, though it could benefit from more detail given the complexity.
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?
Given the tool's complexity (26 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the data context (e.g., works with AnnData objects), output format (e.g., returns a plot image or modifies an object), or how to interpret results. The schema covers parameters, but the description fails to provide necessary operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 26 parameters. The description adds no meaning beyond the schema—it doesn't explain key parameters like 'keys' (required) or how parameters interact. Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Plot violin plot of one or more variables' clearly states the verb ('Plot') and resource ('violin plot'), but it's vague about what 'variables' refers to (e.g., genes, observations) and doesn't distinguish this tool from sibling visualization tools like pl_dotplot or pl_scatter. It specifies the plot type but lacks context about the data domain (e.g., single-cell RNA-seq).
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 guidance on when to use this tool versus alternatives like pl_stacked_violin or other plotting tools. It doesn't mention prerequisites (e.g., requires AnnData object), typical use cases, or exclusions. Usage is implied only by the tool name and generic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Predict doublets' implies a read-only analysis operation, but doesn't disclose whether this modifies input data, what output format to expect, whether it's computationally intensive, or what happens with the results. For a 15-parameter tool with complex statistical operations, this is a significant gap in behavioral context.
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 extremely concise at just 4 words, with zero wasted language. It's front-loaded with the core purpose. While it may be too brief for adequate completeness, it earns full marks for conciseness.
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?
For a complex 15-parameter statistical tool with no annotations and no output schema, the description is severely inadequate. It doesn't explain what doublets are, what Scrublet is, what domain this applies to, what the output looks like, or how results should be interpreted. The description fails to provide the necessary context for effective tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 15 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Predict doublets using Scrublet' states the action ('predict') and target ('doublets'), but is vague about what doublets are in this context and doesn't distinguish this tool from sibling tools like 'filter_cells' or 'score_genes' which might also involve cell quality assessment. It doesn't specify what Scrublet is or what domain this applies to (single-cell RNA-seq analysis).
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 guidance on when to use this tool versus alternatives. With many sibling tools for single-cell analysis (e.g., 'filter_cells', 'score_genes', 'calculate_qc_metrics'), there's no indication whether this should be used before/after other quality control steps, what data prerequisites exist, or what alternatives might be available for doublet detection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions analysis but doesn't describe what the tool actually does behaviorally - whether it modifies data in place (the 'inplace' parameter suggests it might), what kind of output it produces, computational requirements, or error conditions. The description is too vague about the actual analysis process and results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but under-specified rather than efficiently informative. While it doesn't waste words, it fails to provide essential context that would help an agent understand when and how to use this tool effectively. The single sentence doesn't earn its place by providing sufficient guidance.
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?
For a complex tool with 17 parameters, no annotations, and no output schema, the description is severely inadequate. It doesn't explain what the analysis produces, how results are stored/returned, what the 'inplace' parameter fundamentally means for data modification, or provide any context about the biological analysis being performed. The agent would struggle to use this tool correctly based solely on this description.
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 baseline is 3. The description adds no parameter-specific information beyond what's already in the comprehensive schema. It mentions 'one method' which aligns with the 'method' parameter but provides no additional context about method selection, parameter interactions, or practical usage considerations.
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 performs 'cell-cell communication analysis' with a specific method, providing a verb ('analysis') and resource ('cell-cell communication'). It distinguishes from some siblings like visualization tools (ccc_circle_plot, ccc_dot_plot) but doesn't explicitly differentiate from ccc_rank_aggregate or ls_ccc_method, which are related to communication analysis methods.
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 guidance on when to use this tool versus alternatives. It mentions 'one method' but doesn't explain when to choose this over other analysis tools like ccc_rank_aggregate or when to use specific methods listed. There's no mention of prerequisites, input data requirements, or typical workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 offers limited behavioral insight. It mentions that metrics are calculated for AnnData but doesn't describe what happens to the data (mutates AnnData? creates new object?), performance characteristics, or error conditions. The qc_vars parameter hint about calling mark_var first is useful but insufficient for full transparency.
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 appropriately concise - a single sentence that states the core purpose with examples. However, it could be more front-loaded with clearer usage context. The parameter descriptions in the schema are detailed but that's separate from the main description text.
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?
For a 7-parameter tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, how results are stored, whether it modifies the input AnnData, or provide context about when this tool fits in a workflow. The mention of calling mark_var first is helpful but doesn't compensate for major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal value beyond the schema - it mentions common metrics but doesn't explain how parameters relate to those metrics or provide additional semantic context. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: calculating quality control metrics for AnnData, with specific examples of metrics (total counts, gene number, percentage in ribosomal and mitochondrial). It distinguishes from siblings by focusing on QC metrics calculation, though it doesn't explicitly compare to alternatives like 'filter_cells' or 'filter_genes'.
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 minimal usage guidance. It mentions that 'mark_var tool should be called first when you want to calculate mt, ribo, hb' in the qc_vars parameter description, but this is buried in parameter details rather than clear when-to-use guidance. No explicit alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool creates a visualization (a circular plot), implying it's a read-only operation that generates output, but doesn't disclose critical behavioral traits: whether it modifies input data, returns a plot object or file, has performance characteristics, or requires specific data preprocessing. For a complex visualization tool with 26 parameters, this is a significant 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?
The description is a single, efficient sentence that states the core purpose without unnecessary elaboration. It's appropriately sized for a tool where detailed parameter semantics are handled by the schema. Every word earns its place, and the structure is front-loaded with the essential information.
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?
Given the tool's complexity (26 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain what the tool returns (plot object, file path, display?), how it integrates with the data pipeline, or typical workflow context. The agent must rely entirely on the schema for parameter understanding and guess about behavioral aspects and output.
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%, with detailed parameter documentation in the schema itself. The description adds no parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description. The description doesn't compensate but doesn't need to since the schema is comprehensive.
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's purpose: 'Visualize cell-cell communication network using a circular plot.' It specifies the verb ('visualize'), resource ('cell-cell communication network'), and visualization type ('circular plot'). However, it doesn't differentiate from sibling tools like 'ccc_dot_plot' or 'ccc_rank_aggregate', which likely serve similar visualization purposes for the same data domain.
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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing LIANA results in adata.uns), comparison to sibling visualization tools like 'ccc_dot_plot', or typical use cases. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the tool creates a visualization, implying a read-only operation, but doesn't cover critical aspects like whether it modifies the input data, requires specific data formats, has performance considerations, or what the output looks like (e.g., a plot object or file). For a complex tool with 17 parameters, this is a significant gap in transparency.
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: 'Visualize cell-cell communication interactions using a dotplot.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a tool where detailed information is handled by the schema. Every word earns its place.
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?
Given the tool's complexity (17 parameters, no annotations, no output schema), the description is incomplete. It lacks information on behavioral traits, usage context, output format, and dependencies. While the schema covers parameters well, the description fails to provide the broader context needed for effective tool selection and invocation, especially for a visualization tool where understanding the output is crucial.
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 description coverage is 100%, meaning all parameters are well-documented in the input schema itself. The description adds no additional parameter semantics beyond the schema, such as explaining how parameters interact or typical values. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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's purpose: 'Visualize cell-cell communication interactions using a dotplot.' It specifies the action ('visualize') and the resource ('cell-cell communication interactions'), and the dotplot method distinguishes it from other visualization tools like ccc_circle_plot or pl_heatmap. However, it doesn't explicitly differentiate from pl_dotplot, which might be a sibling tool for general dotplots, leaving some ambiguity.
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 guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites (e.g., requiring LIANA results in adata.uns), compare it to other visualization methods like ccc_circle_plot, or specify typical use cases. This lack of context makes it harder for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It mentions aggregation but doesn't explain what the tool actually does with the data (e.g., computational method, output format, whether it modifies input data, performance characteristics, or error conditions). For a tool with 13 parameters and complex functionality, this is inadequate.
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 a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for what it communicates, though it could be more informative. There's no wasted verbiage or redundant information.
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?
For a complex tool with 13 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the aggregation produces, how results are returned or stored, what computational methods are involved, or what the user should expect. The description leaves too many questions unanswered for effective tool selection and use.
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 description coverage is 100%, so the schema already fully documents all 13 parameters. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the 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 action ('Get an aggregate') and the target ('ligand-receptor scores from multiple Cell-cell communication methods'), making the purpose understandable. However, it doesn't differentiate this tool from its sibling 'ccc' tool, which appears to be a related cell-cell communication method, leaving some ambiguity about when to use one versus the other.
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 guidance on when to use this tool versus alternatives. With sibling tools like 'ccc' available, there's no indication of whether this is for aggregation of existing results, a different analysis approach, or specific use cases. The user must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but provides minimal information. It doesn't mention whether this is a read-only or destructive operation, what permissions might be needed, computational complexity, memory requirements, or what the output looks like. The description only states what the tool does, not how it behaves.
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 extremely concise at just 4 words, with zero wasted language. It's front-loaded with the core purpose and contains no unnecessary elaboration. This is an example of efficient communication where every word earns its place.
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?
Given this is a dimensionality reduction tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what diffusion maps are, what they're particularly good for, what the output format will be, or how results should be interpreted. For a complex statistical method, more contextual information would be helpful.
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 baseline is 3. The description adds no parameter information beyond what's already documented in the schema. All three parameters (n_comps, neighbors_key, random_state) are fully described in the input schema with clear explanations and defaults.
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's purpose as performing 'Diffusion Maps for dimensionality reduction', which is a specific verb+resource combination. However, it doesn't differentiate this from sibling tools like pca, tsne, or umap that also perform dimensionality reduction, which prevents a perfect score.
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 guidance on when to use this tool versus alternatives. With multiple dimensionality reduction methods available (pca, tsne, umap, etc.), the description offers no context about when diffusion maps are preferable, what data characteristics they work best with, or any prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool calculates density but doesn't explain what 'density' means in this context, how it's computed, whether it modifies data in place (e.g., adding results to `.obs`), or any performance considerations. This is inadequate for a tool with no annotation coverage.
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, clear sentence: 'Calculate the density of cells in an embedding.' It's front-loaded with the core purpose and wastes no words, making it highly efficient and easy to parse for an AI agent.
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?
Given the complexity of a density calculation tool with 4 parameters and no output schema, the description is incomplete. It doesn't explain the output format (e.g., where results are stored, like in `.obs` as hinted by the 'key_added' parameter), nor does it cover behavioral aspects like data mutation. This leaves significant gaps for an agent to understand the tool's full context.
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, so the schema already documents all parameters thoroughly. The description doesn't add any semantic details beyond what's in the schema, such as explaining interactions between parameters or typical use cases. This meets the baseline for high schema coverage but doesn't enhance understanding.
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's purpose: 'Calculate the density of cells in an embedding.' It specifies the verb ('calculate') and resource ('density of cells'), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'pl_embedding' or 'umap', which might also involve embeddings, so it doesn't reach a perfect score.
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 guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, such as needing an existing embedding from tools like 'umap' or 'tsne', nor does it compare to sibling tools like 'pl_embedding' for visualization purposes. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the filtering action but lacks details on behavioral traits: it does not specify if this is a destructive operation (e.g., removes cells from a dataset), what the output format is (e.g., returns filtered data or modifies in-place), or any performance considerations (e.g., handling of large datasets). This leaves significant gaps for an agent to understand the tool's 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 is a single, efficient sentence: 'Filter cells based on counts and numbers of genes expressed.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity. Every part of the sentence contributes essential information.
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?
Given the complexity (a filtering tool with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It does not explain what the tool returns (e.g., a filtered dataset, success status, or error messages), nor does it cover behavioral aspects like side effects or data handling. For a tool that likely modifies or subsets data, this leaves critical context gaps for an agent.
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, with clear documentation for all four parameters (min_counts, min_genes, max_counts, max_genes). The description adds no additional parameter semantics beyond what the schema provides, such as typical value ranges or interactions between parameters. Since schema coverage is high, the baseline score is 3, reflecting adequate but not enhanced parameter understanding.
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's purpose: 'Filter cells based on counts and numbers of genes expressed.' It specifies the verb ('filter') and resource ('cells'), and the criteria ('counts and numbers of genes expressed'). However, it does not explicitly differentiate from sibling tools like 'filter_genes' or 'filter_rank_genes_groups', which reduces the score from 5 to 4.
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 guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'filter_genes' (which filters genes, not cells) or 'calculate_qc_metrics' (which might compute metrics for filtering). There are no explicit when/when-not statements or prerequisites, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 filtering but doesn't specify whether this operation is destructive (e.g., modifies the dataset in place), what permissions are required, or what the output looks like (e.g., returns a filtered dataset or just a list). For a tool with potential data mutation implications, this lack of detail is a significant 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?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action ('filter genes'), making it easy to parse quickly, and every part of the sentence contributes essential information about the filtering criteria.
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?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely performs data filtering. It doesn't explain the behavioral implications (e.g., whether filtering is reversible or affects downstream analysis), output format, or error conditions. For a preprocessing tool in a data analysis context, this leaves critical gaps in understanding how to use it effectively.
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, with each parameter clearly documented (e.g., 'Minimum number of counts required for a gene to pass filtering'). The description adds minimal value beyond this, only hinting at the filtering criteria without providing additional context like default thresholds or interaction effects between parameters. This meets the baseline for high schema coverage.
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 action ('filter genes') and the criteria ('based on number of cells or counts'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'filter_cells' or 'filter_rank_genes_groups', which would require more specific context about what distinguishes gene filtering from cell filtering or other filtering operations.
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 guidance on when to use this tool versus alternatives. With sibling tools like 'filter_cells' and 'filter_rank_genes_groups' available, there's no indication of the specific scenarios or data preprocessing steps where gene filtering is appropriate, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 offers minimal behavioral insight. It mentions mapping operations but doesn't disclose whether this is read-only or mutating, what permissions are needed, how it handles errors, or what the output format looks like. For a data transformation tool with zero annotation coverage, this is inadequate.
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 directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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?
For a data mapping tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'reference data' and 'new data' refer to, what format the mapping produces, or how this tool fits within the broader data analysis workflow alongside siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter documentation.
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's purpose: 'Map labels and embeddings from reference data to new data.' It specifies the action ('map') and resources ('labels and embeddings'), but doesn't differentiate from siblings like 'merge_adata' or 'neighbors' which might have overlapping data integration functions.
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 guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or comparison to sibling tools like 'merge_adata' for data integration or 'neighbors' for similarity calculations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't mention whether this is a read-only or mutating operation, what data structure it operates on (though implied from parameters), performance characteristics, or what the output looks like. The description only names the algorithm without explaining its 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 is extremely concise at just 6 words, with zero wasted language. It's front-loaded with the essential information (algorithm name and purpose) in a single, efficient phrase.
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?
For a complex clustering algorithm with 10 parameters and no output schema, the description is inadequate. It doesn't explain what data structure it operates on (AnnData objects implied from parameters), what the output format is, typical use cases, or how results integrate with the analysis workflow. The description is too minimal given the tool's 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 description coverage is 100%, so the schema already fully documents all 10 parameters. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in 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's purpose as 'Leiden clustering algorithm for community detection', which identifies both the algorithm and its function. It distinguishes itself from siblings like 'louvain' (another clustering algorithm) by naming the specific algorithm, but doesn't explicitly differentiate when to use Leiden vs Louvain.
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 guidance on when to use this tool versus alternatives. With sibling tools like 'louvain' (another community detection algorithm) and 'paga' (graph abstraction), there's no indication of when Leiden clustering is preferred, what data prerequisites exist, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 transformation but doesn't disclose behavioral traits: whether it modifies data in-place or returns a copy, memory implications (beyond what 'chunked' parameter hints at), error handling for negative values, or typical output format. For a data transformation tool with zero annotation coverage, this leaves significant 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 extremely concise—a single sentence with the mathematical formula. It's front-loaded with the core purpose and wastes no words. Every part earns its place by precisely defining the transformation.
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?
Given the complexity (data transformation with 5 parameters) and lack of annotations/output schema, the description is incomplete. It doesn't cover behavioral aspects, usage context, or output expectations. For a tool in a bioinformatics preprocessing context with many siblings, more guidance is needed to help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond implying a data matrix input (not explicitly a parameter). It doesn't explain parameter interactions or provide examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 mathematical operation: 'Logarithmize the data matrix (X = log(X + 1))'. It specifies the verb ('logarithmize') and resource ('data matrix'), and the formula clarifies the exact transformation. However, it doesn't differentiate from sibling tools like 'normalize_total' or 'scale', which are also preprocessing operations.
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 guidance on when to use this tool versus alternatives. It doesn't mention typical use cases (e.g., for count data in single-cell analysis), prerequisites, or comparisons to sibling tools like 'normalize_total' or 'scale'. The agent must infer usage from the mathematical formula alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but only states what the algorithm is without explaining what it does operationally. It doesn't mention that this is a computational clustering operation, what kind of input data it expects (e.g., adjacency matrices), whether it modifies data in place, what outputs are generated, or any performance characteristics like computational intensity.
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 extremely concise at just 6 words, with zero wasted language. It's front-loaded with the essential information (algorithm name and purpose) in a single, clear phrase. Every word earns its place by identifying both the method and its application domain.
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?
For a complex clustering algorithm with 9 parameters and no output schema, the description is insufficient. It doesn't explain what the tool actually does operationally, what data structures it expects or produces, or how it integrates with the broader analysis workflow. The absence of annotations means the description must carry more weight, but it provides only minimal context.
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 description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline expectation but doesn't provide extra context about how parameters interact or typical usage patterns.
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's purpose as 'Louvain clustering algorithm for community detection', which specifies both the algorithm (Louvain) and its function (clustering for community detection). However, it doesn't differentiate from its sibling 'leiden', which appears to be another clustering algorithm in the same server, leaving room for confusion about when to choose one over the other.
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 guidance on when to use this tool versus alternatives like 'leiden' or other clustering methods available in the sibling tools. It doesn't mention prerequisites, typical use cases, or any context about what data or state is required before invoking this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but lacks critical behavioral context: it doesn't mention that this is a read-only analysis tool (implied by 'calculate'), doesn't describe output format or where results are stored (though parameters hint at '.uns'), and omits any error conditions or performance characteristics. The description is functional but insufficient for a tool with 6 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the core purpose without unnecessary elaboration. Every word earns its place, and the structure is front-loaded with the essential action. There's zero waste or redundancy in this concise formulation.
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?
For a tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (only mentioning calculation, not results), doesn't provide context about typical workflows, and offers no guidance on parameter interactions. The agent would need to rely heavily on the parameter schema to understand this tool's full behavior.
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 input schema already documents all 6 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema - it doesn't explain relationships between parameters (e.g., how 'method' interacts with 'normalize') or provide usage examples. The baseline score of 3 reflects adequate but minimal value addition.
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 action ('calculate overlap') and the resources involved ('data-derived marker genes and reference markers'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'rank_genes_groups' or 'score_genes', which also work with marker genes but perform different functions.
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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing 'rank_genes_groups' output first), nor does it differentiate from sibling tools that might handle similar data. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states what the tool does but lacks critical behavioral details: it doesn't specify if this is a read-only or mutating operation, what data structures it modifies (e.g., updates an AnnData object), performance characteristics, or error conditions. For a complex tool with 10 parameters, this is a significant 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?
The description is extremely concise and front-loaded: a single sentence that directly states the tool's function without any fluff. Every word earns its place, making it easy for an agent to parse quickly. This is an example of efficient communication.
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?
Given the tool's complexity (10 parameters, no output schema, and no annotations), the description is insufficient. It doesn't explain what the tool returns (e.g., modifies an AnnData object in place or returns a new object), how results are stored, or common pitfalls. For a tool that likely performs critical data analysis steps, more context is needed.
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%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., it doesn't explain how parameters interact or typical values). This meets the baseline of 3 when the schema does the heavy lifting, but no extra value is provided.
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's purpose: 'Compute nearest neighbors distance matrix and neighborhood graph.' It specifies the verb ('compute') and the resources ('distance matrix and neighborhood graph'), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'umap' or 'tsne' that might also involve neighbor computations, which prevents a perfect score.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., data preprocessing), typical use cases (e.g., for clustering or visualization), or how it relates to sibling tools like 'pca' or 'umap'. This lack of context leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. The description only states the plotting action without mentioning whether this creates a file, displays a plot, requires specific data structures, has side effects, or what the output format is. For a complex plotting tool with 29 parameters, this lack of behavioral context is a significant 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?
The description is extremely concise - a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's appropriately sized for a plotting tool description and front-loads the essential information.
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?
Given the tool's complexity (29 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain what the tool returns (plot object? file path? display?), what data structures it expects, or any prerequisites. For a visualization tool with many configuration options, the description should provide more context about the tool's behavior and output.
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%, meaning all 29 parameters are documented in the schema itself. The description adds no parameter information beyond what's already in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the 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's purpose: 'Plot dot plot of expression values per gene for each group.' It specifies the verb ('Plot'), resource ('dot plot'), and scope ('expression values per gene for each group'). However, it doesn't differentiate from sibling tools like 'pl_rank_genes_groups_dotplot' or 'ccc_dot_plot', which prevents a perfect score.
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 guidance on when to use this tool versus alternatives. With multiple plotting tools in the sibling list (pl_heatmap, pl_matrixplot, pl_rank_genes_groups_dotplot, etc.), there's no indication of when a dot plot is appropriate versus other visualization types. The description only states what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'plot' implies a read-only visualization operation, the description doesn't specify whether this creates a new plot, modifies existing data, requires specific preconditions (like having PCA already computed), or what the output format is. For a visualization tool with 12 parameters, this is inadequate behavioral context.
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 gets straight to the point: 'Plot the PCA variance ratio to visualize explained variance.' There's no wasted language or unnecessary elaboration.
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?
For a visualization tool with 12 parameters and no annotations or output schema, the description is insufficient. It doesn't explain what the tool actually produces (plot type, output format), what data it operates on, or any prerequisites. The context signals show this is a moderately complex tool (12 parameters) that needs more complete documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the 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's purpose: 'Plot the PCA variance ratio to visualize explained variance.' It specifies the action (plot), the statistical concept (PCA variance ratio), and the visualization goal (explained variance). However, it doesn't differentiate from sibling tools like 'pl_pca' or 'pca' that might also handle PCA-related visualizations.
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 guidance on when to use this tool versus alternatives. With sibling tools like 'pl_pca', 'pca', and various other plotting tools, there's no indication of when this specific variance ratio visualization is appropriate versus other PCA visualizations or analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool creates a plot image, implying a read-only visualization operation, but doesn't disclose critical behavioral traits: whether it modifies input data, requires specific data formats (e.g., AnnData), handles errors, or produces output (e.g., file path, display). For a complex plotting tool with 22 parameters, this lack of context is a significant 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?
The description is extremely concise and front-loaded: two sentences that directly state what the tool does and its key feature (compact stacking). Every word earns its place with zero redundancy. It efficiently communicates the core functionality without unnecessary elaboration.
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?
Given high complexity (22 parameters, no annotations, no output schema), the description is incomplete. It doesn't address what the tool returns (e.g., image file, plot object), data requirements, error conditions, or how it integrates with sibling tools. For a visualization tool in a data analysis context, more guidance on input data structure and output handling is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 22 parameters thoroughly. The description adds no parameter-specific information beyond the tool's general purpose. It doesn't explain key parameters like 'groupby' or 'var_names' in context, nor does it provide examples or typical usage patterns. Baseline 3 is appropriate when schema does all the work.
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's purpose: 'Plot stacked violin plots' specifies the verb and resource. It distinguishes from sibling 'pl_violin' by mentioning 'stacked on top of each other' and 'compact image', though not explicitly contrasting with other plotting tools. The purpose is specific but could better differentiate among multiple visualization siblings.
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 guidance on when to use this tool versus alternatives is provided. The description mentions 'compact image' which hints at a use case for space-efficient visualization, but it doesn't specify when stacked violins are preferable over regular violins ('pl_violin') or other plots like dot plots or heatmaps. No prerequisites, data requirements, or explicit alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'perform differentially expression analysis,' which implies statistical computation and potential data modification, but doesn't specify whether this tool mutates data, requires specific permissions, has performance considerations, or what the output entails. For a tool with 13 parameters and no annotations, this is a significant gap in transparency.
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 extremely concise—just one sentence with two clauses. It front-loads the core purpose without unnecessary elaboration. Every word earns its place, making it efficient and easy to parse, though this conciseness may contribute to gaps in other dimensions.
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?
Given the tool's complexity (13 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain the output format, how results are stored or accessed, or the implications of the analysis. For a differential expression tool with many parameters, more context is needed to guide effective use, especially without annotations or output schema.
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%, meaning all parameters are documented in the input schema. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain how parameters interact or provide usage examples. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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's purpose: 'Rank genes for characterizing groups, perform differentially expression analysis.' It specifies the action ('rank genes') and the goal ('characterizing groups' and 'differentially expression analysis'), which is more specific than just restating the name. However, it doesn't explicitly differentiate from sibling tools like 'filter_rank_genes_groups' or 'pl_rank_genes_groups_dotplot', which appear related but serve different purposes.
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 guidance on when to use this tool versus alternatives. With sibling tools like 'filter_rank_genes_groups' and 'pl_rank_genes_groups_dotplot' available, there's no indication of how this tool fits into a workflow or when it should be chosen over others. The description only states what it does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It only states what the tool does ('read data'), but lacks details on behavioral traits such as performance characteristics (e.g., memory usage with large files), error handling, or output format. The mention of 'backed' mode in the schema hints at memory behavior, but the description doesn't surface this, leaving gaps in transparency.
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 extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose. There is no wasted language or redundancy, making it efficient and easy to parse for an AI agent.
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?
Given the tool's complexity (15 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what the tool returns (e.g., data structure or format), how to handle errors, or provide context for the numerous parameters. For a data-reading tool with many options, more guidance is needed to ensure correct usage.
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 description adds minimal parameter semantics beyond the input schema, which has 100% coverage. It lists file formats (e.g., h5ad, 10x, text files) and mentions 'directory path,' but these are implied by the 'filename' parameter. No additional context or usage examples are provided for parameters, so it meets the baseline of 3 given the comprehensive schema descriptions.
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's purpose: 'Read data from various file formats (h5ad, 10x, text files, etc.) or directory path.' It specifies the verb ('read') and resource ('data from various file formats'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'write_tool' or 'list_obs', though the distinction is implied by the verb 'read'.
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 guidance on when to use this tool versus alternatives. It mentions file formats but doesn't specify scenarios, prerequisites, or exclusions. For example, it doesn't indicate if this is the primary tool for data ingestion or when to prefer it over other tools like 'ingest' or 'merge_adata' from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'scale' implies a transformation operation, the description doesn't mention whether this modifies data in-place, creates a new dataset, what permissions are required, error conditions, or performance characteristics. For a data transformation tool with zero annotation coverage, this is insufficient.
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, clear sentence with zero waste. It's appropriately sized and front-loaded with the essential information about what the tool does.
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?
Given this is a data transformation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what gets returned (transformed data object? success indicator?), what format the output takes, or how this integrates with the broader data processing workflow alongside sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. This meets the baseline of 3 when the schema does the heavy lifting, but no extra value is provided.
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's purpose: 'Scale data to unit variance and zero mean' - this specifies the verb ('scale') and the transformation outcome. However, it doesn't differentiate from potential sibling tools that might also transform data (like normalize_total or log1p), so it doesn't reach the highest score.
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 guidance on when to use this tool versus alternatives. With many sibling tools for data transformation and preprocessing (normalize_total, log1p, regress_out, etc.), there's no indication of when scaling is appropriate versus other normalization methods or when to combine them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 offers minimal behavioral information. It mentions 'average expression' but doesn't explain what the scoring output represents, whether it modifies data in place, what format results take, or any computational characteristics. For a tool with 6 parameters and no annotations, this is inadequate.
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 states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.
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?
For a tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the scoring output means, how results are returned, or the computational behavior. The description should provide more context about what 'scoring' accomplishes in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 where the schema does the heavy lifting.
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 verb 'score' and the resource 'genes', specifying it's based on average expression. However, it doesn't differentiate from sibling tools like 'score_genes_cell_cycle' or explain what scoring means in this context beyond the basic calculation.
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 guidance is provided about when to use this tool versus alternatives like 'score_genes_cell_cycle' or other scoring methods. The description only states what it does, not when it's appropriate or what prerequisites might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the tool 'scores' and 'assigns' phases, implying a computational analysis that likely modifies or adds data, but it doesn't specify whether this is a read-only operation, what data structures are affected (e.g., modifies an 'adata' object), or any side effects like performance considerations. For a tool with 7 parameters and no annotations, this is insufficient detail.
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 extremely concise with a single sentence: 'Score cell cycle genes and assign cell cycle phases.' It is front-loaded and wastes no words, making it easy to parse quickly. Every word contributes directly to stating the tool's purpose without 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?
Given the complexity of a 7-parameter tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., scores, phase assignments, or modified data), how results are structured, or any behavioral nuances. For a computational biology tool likely operating on complex data like 'adata', this leaves significant gaps in understanding.
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 description adds no parameter-specific information beyond what the input schema provides. Since schema description coverage is 100%, the schema already fully documents all 7 parameters with clear descriptions and defaults. The description doesn't compensate by explaining interactions between parameters or high-level usage patterns, so it meets the baseline for high schema coverage.
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's purpose: 'Score cell cycle genes and assign cell cycle phases.' It specifies the action ('score' and 'assign') and the domain ('cell cycle genes' and 'cell cycle phases'), making the intent unambiguous. However, it doesn't differentiate from sibling tools like 'score_genes' or 'ccc', which might have overlapping functionality, preventing a perfect score.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as requiring specific data formats or preprocessing steps, nor does it compare to sibling tools like 'score_genes' or 'ccc' that might handle similar tasks. This lack of context leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the algorithm purpose but doesn't describe what the tool actually does behaviorally - whether it modifies data in place, creates new embeddings, requires specific data formats, has computational intensity, or produces visual output versus coordinate data. The description is insufficient for a 9-parameter computational tool with no annotation coverage.
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 extremely concise - a single sentence that efficiently states both the algorithm name and its application domain. There's zero wasted verbiage, and it's front-loaded with the essential information.
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?
For a complex dimensionality reduction tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (embeddings? plots?), how results integrate with the data structure, computational requirements, or typical workflow context. The single sentence leaves too many open questions for effective agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in 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 performs 't-distributed stochastic neighborhood embedding (t-SNE)' and specifies its purpose 'for visualizing single-cell data.' This provides a specific verb (embedding) and resource (single-cell data), though it doesn't explicitly differentiate from sibling tools like umap or pca that also perform dimensionality reduction for visualization.
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 guidance on when to use this tool versus alternatives like umap, pca, or diffmap from the sibling list. It doesn't mention typical use cases, prerequisites, or comparisons with other dimensionality reduction methods available on the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the basic function. It doesn't disclose whether this is a destructive operation (overwrites existing files), what permissions are needed, error conditions, or what happens upon success. The description lacks behavioral context beyond the minimal action statement.
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, direct sentence with zero wasted words. It's perfectly front-loaded with the core action and immediately communicates the essential function without any fluff or unnecessary elaboration.
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?
For a write operation with 4 parameters and no annotations or output schema, the description is inadequate. It doesn't explain what AnnData objects are, what formats are supported beyond what's in the schema, whether the operation is atomic, what validation occurs, or what happens on failure. The context demands more complete guidance for a file-writing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no parameter information beyond what's in the schema, maintaining the baseline score of 3. It doesn't explain relationships between parameters (e.g., how 'ext' interacts with 'filename' extension).
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 action ('Write') and the resource ('AnnData objects to file'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'read_tool' beyond the obvious directionality, nor does it specify what AnnData objects are in this context.
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 guidance is provided about when to use this tool versus alternatives. While 'read_tool' is clearly the complementary operation, there's no mention of prerequisites (e.g., needing an AnnData object in memory), file format considerations, or when other tools might be more appropriate for data export.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'List' implies a read operation, but the description doesn't disclose what format the listing returns, whether it's paginated, if it requires specific permissions, or any rate limits. For a tool with zero annotation coverage, 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 with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple listing 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?
For a parameterless listing tool with no output schema, the description adequately states what it does but lacks crucial context about return format and behavioral constraints. Without annotations or output schema, the agent doesn't know what the listing looks like or any operational limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. The description doesn't need to explain parameters, and it correctly implies no inputs are required. A baseline of 4 is appropriate for parameterless tools with complete schema coverage.
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 verb ('List') and resource ('cell-cell communication method'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'ccc', 'ccc_circle_plot', or 'ccc_dot_plot' which likely handle CCC methods differently, so it falls short of a perfect score.
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 guidance on when to use this tool versus alternatives. With multiple CCC-related siblings (ccc, ccc_circle_plot, ccc_dot_plot, ccc_rank_aggregate), the agent receives no help distinguishing this listing function from other CCC operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the tool lists columns and should be called before other tools, but it doesn't describe what 'key columns' means, whether this is a read-only operation, if it has side effects, or details about output format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 is two concise sentences that efficiently state the purpose and usage guidelines without any wasted words. It's front-loaded with the core function and follows with practical advice, making it easy to parse and understand quickly.
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 tool has 0 parameters, no annotations, and no output schema, the description provides basic purpose and usage but lacks details on what 'key columns' are, the output format, or how it integrates with the broader context of sibling tools. It's minimally adequate but has clear gaps in explaining the tool's role and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though it's generic as 'ListObsModel'). The description doesn't need to add parameter details, so it appropriately focuses on usage. A baseline of 4 is given since no parameters are present, and the description doesn't attempt to explain non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'List key columns in adata.obs', which provides a specific verb ('List') and resource ('key columns in adata.obs'), but it's somewhat vague about what constitutes 'key columns' and doesn't clearly distinguish this from sibling tools like 'list_var' or 'read_tool' that might also list data. It avoids tautology by not just restating the name.
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 explicitly states 'It should be called before other tools need obs key column names input', providing clear context on when to use this tool (as a prerequisite for other operations). However, it doesn't specify when not to use it or name alternatives among siblings, such as how it differs from 'list_var' or other data inspection tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 explains the tool creates boolean values in adata.var and provides an example (mitochondrion genes startswith MT-), which adds useful context. However, it doesn't mention important behavioral aspects like whether this operation modifies data in-place, what happens to existing columns, error conditions, or performance characteristics. The description adds some value but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but has structural issues. The first sentence clearly states the purpose, but the second sentence has grammatical errors ('startswith' should be 'start with') and mixes example with usage guidance. The final clause 'or other qc_vars' is vague. While not excessively long, the structure could be cleaner with better separation of concepts.
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 4 parameters with 100% schema coverage but no annotations and no output schema, the description provides adequate context for the tool's purpose and primary use case. However, for a data mutation tool (adding columns to adata.var), the description should ideally mention more about the behavioral implications - whether this is reversible, what format the output takes, or how it interacts with other QC tools. The example helps but doesn't fully compensate for the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. It mentions 'mitochondrion genes startswith MT-' as an example, which relates to the pattern_type and patterns parameters, but doesn't provide additional syntax, format details, or usage patterns beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 states the tool's purpose clearly: 'Determine if each gene meets specific conditions and store results in adata.var as boolean values.' It specifies the verb (determine/mark), resource (genes), and output location (adata.var). However, it doesn't explicitly differentiate from sibling tools like 'filter_genes' or 'check_gene' that might have overlapping functionality.
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 for when to use this tool: 'the tool should be called first when calculate quality control metrics for mitochondrion, ribosomal, hemoglobin genes. or other qc_vars.' This gives explicit guidance about the primary use case (QC preprocessing) and timing (first step). However, it doesn't mention when NOT to use it or explicitly name alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. The description mentions it's for 'checking' and listing, which implies a read-only operation, but doesn't specify if it requires specific permissions, what the output format is, or any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps, though it's not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose and followed by usage guidance. Every sentence adds value without redundancy, making it efficient and well-structured for an AI agent to parse quickly.
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 tool has 0 parameters, no annotations, and no output schema, the description adequately covers the purpose and usage. However, it lacks details on behavioral aspects like output format or error handling, which could be important for a tool used as a prerequisite in workflows. It's minimally viable but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though the schema description 'ListVarModel' is minimal). With no parameters, the baseline score is 4, as there's nothing for the description to add beyond what's already covered. The description doesn't need to explain parameters, so it meets expectations.
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's purpose: 'list key columns in adata.var' with a specific verb ('list') and resource ('key columns in adata.var'). It distinguishes from siblings like 'list_obs' which handles a different data structure, though it doesn't explicitly mention this distinction. The purpose is clear but could be more specific about what 'key columns' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'it should be called for checking when other tools need var key column names input.' This clearly states when to use this tool (as a prerequisite for other tools requiring var key column names) and implies when not to use it (for other purposes). It effectively guides the agent on its role in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 clearly indicates this is a validation/checking operation (non-destructive, likely read-only), but doesn't specify what happens when genes don't exist (error, warning, partial results), performance characteristics, or authentication requirements. It provides basic behavioral context but lacks operational details.
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 perfectly concise with two sentences that each earn their place: the first states the purpose, the second provides usage guidance. There's zero waste or redundancy, and information is front-loaded appropriately.
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 validation tool with one parameter and no output schema, the description is reasonably complete. It covers purpose and usage context well. However, without annotations or output schema, it could benefit from mentioning what the tool returns (e.g., validation results, error messages) or any limitations. The lack of output information is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'var_names' as 'gene names.' The description adds minimal value beyond this by mentioning 'genes' in context, but doesn't provide additional semantic details about parameter format, constraints, or examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check if genes exist') and resource ('in adata.var_names'), making it immediately understandable. It distinguishes itself from sibling tools by focusing on gene existence validation rather than visualization, filtering, or analysis operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('before gene expression visualizations or color by genes'), providing clear context for its application. It implies an alternative would be to proceed without validation, though it doesn't name specific sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![scmcp MCP server](https://glama.ai/mcp/servers/huang-sh/scmcp/badges/card.svg)](https://glama.ai/mcp/servers/huang-sh/scmcp)

Score Badge

Copy to your README.md:

[![scmcp MCP server](https://glama.ai/mcp/servers/huang-sh/scmcp/badges/score.svg)](https://glama.ai/mcp/servers/huang-sh/scmcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/huang-sh/scmcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server