Allows to retrieve information about an AnnData object via MCP
anndata-mcp provides 4 well-named, READ_ONLY tools with complete input schemas and descriptions. Tool names follow verb_noun convention (get_*, view_*, locate_*), which is excellent for LLM parsing. All tools have clear descriptions (122-190 chars), meeting the baseline of 194 chars average. Input schemas are detailed with proper type declarations, enums, and nested parameter support. However, output schemas are not documented, LLMs cannot determine what fields to expect from results. Error handling guidance is absent; tools lack recovery instructions or categorization. Parameter descriptions could be more prescriptive about expected formats and edge cases. No tool annotations (readOnlyHint, etc.) despite all being read-only operations.
Provide basic descriptive statistics (e.g., count, mean, std, min, max, etc. or value counts) for an attribute or attribute value of an optionally filtered AnnData object.
Get a summary of an AnnData object from a file or URL.
Locate all AnnData stores (.h5ad or .zarr) in a data directory.
View the raw data of an AnnData object.
Output schemas are not documented. LLMs cannot determine what fields to expect from tool results, forcing them to guess downstream field names and types. This breaks tool chaining and increases hallucination risk.
No error handling guidance. Tools lack recovery instructions (e.g., 'if file not found, try locate_anndata_stores()'), actionable error messages, or error classification (retryable vs. fatal). This leaves LLMs unable to self-correct on failures.
get_summary and get_descriptive_stats lack explicit output constraints. Tools should state max output length, truncation behavior, and data limits (e.g., 'returns top 1000 genes by variance'). Current descriptions do not specify these bounds.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Complex nested parameter structures (key as array, columns_or_genes accepting glob patterns) lack concrete examples in descriptions. LLMs struggle without worked examples: 'e.g. key=["key1", "key2"] to access nested values' would clarify usage.
Filter parameter relationships underdocumented. Tools require filter_attribute, filter_column, filter_operator, and filter_value together, but descriptions do not explicitly state this dependency or provide an example filter query.
No tool annotations despite all tools being read-only. Tools should declare readOnlyHint=true to signal to LLMs and clients that these operations are safe, non-destructive, and retryable.