Server is built on Node.js and requires Node.js 18 or higher to run the Human Protein Atlas MCP server
Uses npm for package management, installation, and running server commands
Implements TypeScript best practices for server development and contributions
Supports XML as one of the output formats for protein data retrieval
Supports yarn as an alternative package manager for installation
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ProteinAtlas MCP Server get tissue expression for TP53"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A comprehensive Model Context Protocol (MCP) server for accessing Human Protein Atlas data, providing information about protein expression, subcellular localization, pathology, and more.
The Human Protein Atlas MCP Server enables seamless access to the vast repository of protein data from the Human Protein Atlas (https://www.proteinatlas.org). This server provides tools and resources for:
Protein Search and Information: Search for proteins by name, gene symbol, or description
Tissue Expression: Access tissue-specific expression profiles
Subcellular Localization: Retrieve protein localization data
Pathology Data: Access cancer-related protein information
Blood and Brain Expression: Specialized expression data for blood cells and brain regions
Antibody Information: Validation and staining data for antibodies
Batch Processing: Efficient lookup of multiple proteins
Advanced Search: Complex queries with multiple filters
Related MCP server: Reactome MCP Server
🔍 Comprehensive Search: Find proteins using various identifiers and keywords
🧬 Multi-Modal Data: Access expression, localization, and pathology information
🩸 Specialized Atlases: Blood Atlas and Brain Atlas data integration
📊 Batch Processing: Efficient handling of multiple protein queries
🔬 Research-Grade Data: High-quality, peer-reviewed protein information
⚡ Fast Response: Optimized for quick data retrieval
Basic Protein Information
Gene symbols and Ensembl IDs
Protein descriptions and classifications
UniProt cross-references
Expression Data
Tissue-specific RNA expression
Blood cell expression profiles
Brain region expression data
Single-cell expression information
Subcellular Localization
Protein localization patterns
Reliability scores
Immunofluorescence data
Pathology Information
Cancer prognostic markers
Disease associations
Therapeutic targets
Antibody Data
Antibody validation information
Staining patterns
Reliability assessments
Node.js 18 or higher
npm or yarn package manager
Clone or download the server code
Install dependencies:
cd proteinatlas-server
npm installBuild the server:
npm run buildThe server is now ready to use!
Run the server directly:
npm start
# or
node build/index.jsAdd to your MCP client configuration:
{
"mcpServers": {
"proteinatlas": {
"command": "node",
"args": ["/path/to/proteinatlas-server/build/index.js"]
}
}
}search_proteinsSearch Human Protein Atlas for proteins by name, gene symbol, or description.
Parameters:
query (required): Search query (gene name, protein name, or keyword)
format: Output format (json, tsv) - default: json
columns: Specific columns to include in results
maxResults: Maximum number of results (1-10000) - default: 100
compress: Whether to compress the response - default: false
Example:
{
"query": "BRCA1",
"format": "json",
"maxResults": 10
}get_protein_infoGet detailed information for a specific protein by gene symbol.
Parameters:
gene (required): Gene symbol (e.g., BRCA1, TP53)
format: Output format (json, tsv, xml, trig) - default: json
get_protein_by_ensemblGet protein information using Ensembl gene ID.
Parameters:
ensemblId (required): Ensembl gene ID (e.g., ENSG00000139618)
format: Output format (json, tsv, xml, trig) - default: json
get_tissue_expressionGet tissue-specific expression data for a protein.
Parameters:
gene (required): Gene symbol
format: Output format (json, tsv) - default: json
search_by_tissueFind proteins highly expressed in specific tissues.
Parameters:
tissue (required): Tissue name (e.g., liver, brain, heart)
expressionLevel: Expression level filter (high, medium, low, not detected)
format: Output format (json, tsv) - default: json
maxResults: Maximum number of results (1-10000) - default: 100
get_blood_expressionGet blood cell expression data for a protein.
get_brain_expressionGet brain region expression data for a protein.
get_subcellular_locationGet subcellular localization data for a protein.
search_by_subcellular_locationFind proteins localized to specific subcellular compartments.
Parameters:
location (required): Subcellular location (e.g., nucleus, mitochondria, cytosol)
reliability: Reliability filter (approved, enhanced, supported, uncertain)
format: Output format (json, tsv) - default: json
maxResults: Maximum number of results (1-10000) - default: 100
get_pathology_dataGet cancer and pathology data for a protein.
search_cancer_markersFind proteins associated with specific cancers or with prognostic value.
Parameters:
cancer: Cancer type (e.g., breast cancer, lung cancer)
prognostic: Prognostic filter (favorable, unfavorable)
format: Output format (json, tsv) - default: json
maxResults: Maximum number of results (1-10000) - default: 100
advanced_searchPerform advanced search with multiple filters and criteria.
Parameters:
query: Base search query
tissueSpecific: Tissue-specific expression filter
subcellularLocation: Subcellular localization filter
cancerPrognostic: Cancer prognostic filter
proteinClass: Protein class filter
chromosome: Chromosome filter
antibodyReliability: Antibody reliability filter
format: Output format (json, tsv) - default: json
columns: Specific columns to include in results
maxResults: Maximum number of results (1-10000) - default: 100
batch_protein_lookupLook up multiple proteins simultaneously.
Parameters:
genes (required): Array of gene symbols (max 100)
format: Output format (json, tsv) - default: json
columns: Specific columns to include in results
compare_expression_profilesCompare expression profiles between multiple proteins.
Parameters:
genes (required): Array of gene symbols to compare (2-10)
expressionType: Type of expression data (tissue, brain, blood, single_cell) - default: tissue
format: Output format (json, tsv) - default: json
The server provides several resource templates for direct data access:
hpa://protein/{gene}: Complete protein atlas data for a gene symbol
hpa://ensembl/{ensemblId}: Complete protein atlas data for an Ensembl gene ID
hpa://tissue/{gene}: Tissue-specific expression data for a gene
hpa://subcellular/{gene}: Subcellular localization information for a gene
hpa://pathology/{gene}: Cancer and pathology data for a gene
hpa://blood/{gene}: Blood cell expression data for a gene
hpa://brain/{gene}: Brain region expression data for a gene
hpa://antibody/{gene}: Antibody validation and staining information for a gene
hpa://search/{query}: Search results for proteins matching the query
// Access tissue expression data for BRCA1
const resource = await client.readResource("hpa://tissue/BRCA1");
// Search for insulin-related proteins
const searchResults = await client.readResource("hpa://search/insulin");This server accesses data from:
Human Protein Atlas: Main protein atlas database
Tissue Atlas: Normal tissue expression data
Blood Atlas: Blood cell expression profiles
Brain Atlas: Brain region expression data
Pathology Atlas: Cancer-related protein data
Cell Atlas: Single-cell expression information
The server implements appropriate rate limiting to respect the Human Protein Atlas API
For batch operations, consider breaking large requests into smaller chunks
Use specific column selections to reduce response size when possible
Cache frequently accessed data when appropriate
The server provides comprehensive error handling:
Invalid Parameters: Clear error messages for incorrect input
Network Issues: Retry logic for transient failures
Data Format Errors: Graceful handling of unexpected response formats
Rate Limiting: Appropriate backoff strategies
// Search for BRCA1 protein
const result = await callTool("search_proteins", {
query: "BRCA1",
format: "json",
});// Get tissue expression for multiple genes
const comparison = await callTool("compare_expression_profiles", {
genes: ["BRCA1", "BRCA2", "TP53"],
expressionType: "tissue",
});// Find breast cancer prognostic markers
const markers = await callTool("search_cancer_markers", {
cancer: "breast cancer",
prognostic: "unfavorable",
maxResults: 50,
});// Look up multiple proteins at once
const batchResult = await callTool("batch_protein_lookup", {
genes: ["BRCA1", "BRCA2", "TP53", "EGFR", "MYC"],
format: "json",
});# Install dependencies
npm install
# Build the project
npm run build
# Run in development mode
npm run dev# Run the server
npm start
# Test with MCP client or direct stdio communicationContributions are welcome! Please ensure:
Code follows TypeScript best practices
Error handling is comprehensive
Documentation is updated for new features
Tests are included for new functionality
MIT License - see LICENSE file for details.
For issues and questions:
Check the Human Protein Atlas documentation: https://www.proteinatlas.org/about/help
Review the MCP specification: https://modelcontextprotocol.io/
Submit issues via the project repository
Human Protein Atlas team for providing the comprehensive protein database
Model Context Protocol community for the standardized communication framework
TypeScript and Node.js communities for the development tools
This server provides programmatic access to Human Protein Atlas data for research and educational purposes. Please cite appropriate sources when using this data in publications.
If you use this project in your research or publications, please cite it as follows:
author = {Moudather Chelbi},
title = {Human Protein Atlas MCP Server},
year = {2025},
howpublished = {https://github.com/Augmented-Nature/ProteinAtlas-MCP-Server/},
note = {Accessed: 2025-06-29}Perform advanced search with multiple filters and criteria
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Base search query | |
| tissueSpecific | No | Tissue-specific expression filter | |
| subcellularLocation | No | Subcellular localization filter | |
| cancerPrognostic | No | Cancer prognostic filter | |
| proteinClass | No | Protein class filter | |
| chromosome | No | Chromosome filter | |
| antibodyReliability | No | Antibody reliability filter | |
| format | No | Output format (default: json) | |
| columns | No | Specific columns to include in results | |
| maxResults | No | Maximum number of results (1-10000, default: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden but offers minimal behavioral insight. It mentions 'advanced search' but doesn't disclose critical traits like whether it's read-only, potential rate limits, authentication needs, or what happens with large result sets. The description lacks details on output behavior, error handling, or performance characteristics, which are essential for a tool with 10 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core function ('Perform advanced search'). There's no wasted text, but it could be more structured by hinting at the domain or key filters. It's appropriately sized for a tool name like 'advanced_search,' though slightly more detail might improve clarity without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain what is being searched (e.g., proteins or biological data), the return format implications, or how filters interact. For a tool with many parameters and sibling alternatives, more context is needed to guide effective use, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 10 parameters with descriptions and constraints. The description adds no additional meaning beyond implying 'multiple filters,' which is redundant with the schema. With high coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract from the well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs 'advanced search with multiple filters and criteria,' which indicates a search function but is vague about what domain or resource is being searched. It mentions 'multiple filters' but doesn't specify the target (e.g., proteins, genes, or data). This distinguishes it from simpler search siblings like 'search_by_tissue' but lacks specificity compared to others like 'search_cancer_markers.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'search_by_tissue' and 'search_cancer_markers,' it's unclear if this is a comprehensive search or when to prefer it over more specific tools. No exclusions, prerequisites, or context for usage are mentioned, leaving the agent to guess based on parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up multiple proteins simultaneously
| Name | Required | Description | Default |
|---|---|---|---|
| genes | Yes | Array of gene symbols (max 100) | |
| format | No | Output format (default: json) | |
| columns | No | Specific columns to include in results |
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 batch capability but fails to describe key traits like rate limits, authentication needs, error handling, or what the output looks like (e.g., structure, pagination). This leaves significant gaps for a tool with multiple 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.
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 function without unnecessary words. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema, and multiple sibling tools), the description is incomplete. It doesn't address behavioral aspects, usage context, or output expectations, leaving the agent with insufficient information to effectively invoke the tool beyond basic parameter input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 (e.g., 'genes' as an array with limits, 'format' with enum, 'columns' as optional). The description adds no meaning beyond this, such as explaining gene symbol conventions or column options, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('look up') and resource ('multiple proteins simultaneously'), which is specific and unambiguous. However, it doesn't distinguish this batch operation from sibling tools like 'get_protein_info' or 'get_protein_by_ensembl' that might handle individual protein lookups, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With siblings like 'get_protein_info' and 'get_protein_by_ensembl', the description lacks context on whether this is for bulk efficiency, specific data types, or other use cases, offering no explicit or implied usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare expression profiles between multiple proteins
| Name | Required | Description | Default |
|---|---|---|---|
| genes | Yes | Array of gene symbols to compare (2-10) | |
| expressionType | No | Type of expression data to compare (default: tissue) | |
| format | No | Output format (default: json) |
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 action 'compare' but doesn't explain what the comparison entails (e.g., statistical analysis, visualization, or raw data), potential limitations (e.g., data availability), or output characteristics (e.g., format details beyond schema). This leaves significant gaps for an AI 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.
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 is front-loaded and wastes no space, making it easy 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of comparing expression profiles (a non-trivial operation) and the lack of annotations and output schema, the description is insufficient. It doesn't cover what the comparison outputs (e.g., metrics, visualizations), how results are structured, or any behavioral nuances, leaving the AI agent with incomplete context for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for all parameters (e.g., 'Array of gene symbols to compare (2-10)'). The description adds no additional meaning beyond the schema, such as explaining the significance of 'expressionType' choices or 'format' implications. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'compare' and the resource 'expression profiles between multiple proteins', which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'get_tissue_expression' or 'get_blood_expression', which appear to fetch expression data for single proteins rather than comparing multiple ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description doesn't mention prerequisites, context, or exclusions, such as when to choose this over individual expression tools or how it relates to siblings like 'advanced_search' or 'search_by_tissue'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get antibody validation and staining information for a protein
| Name | Required | Description | Default |
|---|---|---|---|
| gene | Yes | Gene symbol | |
| format | No | Output format (default: json) |
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 retrieves information but doesn't mention any behavioral traits such as rate limits, authentication requirements, data freshness, or what happens if the gene isn't found. This leaves significant gaps for an AI agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 any unnecessary words. It's front-loaded and wastes no space, making it easy 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and output expectations. Without annotations or an output schema, more guidance would be helpful for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('gene' as a gene symbol and 'format' as an output format with enum values). The description doesn't add any meaningful semantic context beyond what the schema provides, such as examples or constraints, 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.
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 ('Get') and resource ('antibody validation and staining information for a protein'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_protein_info' or 'get_pathology_data', which might also provide related protein information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 available for protein-related queries (e.g., 'get_protein_info', 'get_pathology_data'), there's no indication of what makes this tool unique or when it should be preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get blood cell expression data for a protein
| Name | Required | Description | Default |
|---|---|---|---|
| gene | Yes | Gene symbol | |
| format | No | Output format (default: json) |
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 fails to describe key traits such as whether it's a read-only operation, if it requires authentication, rate limits, error handling, or the structure of returned data. This is a significant gap 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.
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 is appropriately sized and front-loaded, making it easy to parse quickly, with no wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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. It does not address behavioral aspects like safety, permissions, or data format details, nor does it explain return values or potential errors. For a tool with no structured support, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters ('gene' and 'format'), including an enum for 'format'. The description does not add any meaning beyond what the schema provides, such as explaining gene symbol conventions or format implications, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'blood cell expression data for a protein', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_brain_expression' or 'get_tissue_expression', which target different biological contexts, so it lacks sibling distinction for 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.
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 when to choose it over sibling tools such as 'get_brain_expression' or 'get_tissue_expression', nor does it specify prerequisites or exclusions, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get brain region expression data for a protein
| Name | Required | Description | Default |
|---|---|---|---|
| gene | Yes | Gene symbol | |
| format | No | Output format (default: json) |
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 what the tool does but doesn't cover important traits like whether it's a read-only operation, potential rate limits, error handling for invalid genes, or the structure of the returned data. This leaves gaps for an AI agent to understand operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 front-loaded and wastes no space, making it easy 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.
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. It doesn't explain what the returned expression data includes (e.g., numerical values, brain region names, statistical metrics) or how to interpret results. For a tool with 2 parameters and no structured output guidance, more context is needed to ensure proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for both parameters ('gene' as a gene symbol and 'format' as an output format with enum values). The description doesn't add extra meaning beyond the schema, such as examples of valid gene symbols or implications of choosing 'tsv' over 'json', but the schema provides adequate baseline information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('brain region expression data for a protein'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_tissue_expression' or 'get_blood_expression', which might offer similar expression data for different biological contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_tissue_expression' or 'compare_expression_profiles'. The description lacks context about prerequisites, such as needing a valid gene symbol, or when this tool is preferred over others for brain-specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cancer and pathology data for a protein
| Name | Required | Description | Default |
|---|---|---|---|
| gene | Yes | Gene symbol | |
| format | No | Output format (default: json) |
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 retrieves data but does not cover aspects like authentication needs, rate limits, data freshness, or error handling. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It states what data is retrieved but lacks details on output structure, data scope, or integration with sibling tools. Without annotations or output schema, more context would improve completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting the 'gene' and 'format' parameters. The description adds no additional meaning beyond the schema, such as explaining what 'cancer and pathology data' entails or providing examples. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('cancer and pathology data for a protein'), making the purpose understandable. However, it does not distinguish this tool from siblings like 'search_cancer_markers' or 'get_protein_info', which might overlap in scope, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'search_cancer_markers' or 'get_protein_info'. It implies usage for retrieving pathology data but offers no context on prerequisites, exclusions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get protein information using Ensembl gene ID
| Name | Required | Description | Default |
|---|---|---|---|
| ensemblId | Yes | Ensembl gene ID (e.g., ENSG00000139618) | |
| format | No | Output format (default: json) |
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's function but lacks details on permissions, rate limits, error handling, or what 'protein information' entails (e.g., structure, function, sequences). This is a significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose, making it easy to scan and understand quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of protein data retrieval, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'protein information' includes or the tool's behavior, leaving critical gaps for an agent to use it effectively in a biological context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 (e.g., 'ensemblId' with an example, 'format' with enum and default). The description adds no additional meaning beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get protein information') and the resource identifier ('using Ensembl gene ID'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_protein_info' or 'get_protein_classes', which might also retrieve protein-related data, 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.
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 available (e.g., 'get_protein_info', 'search_proteins'), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess 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.
Get protein classification and functional annotation data
| Name | Required | Description | Default |
|---|---|---|---|
| gene | Yes | Gene symbol | |
| format | No | Output format (default: json) |
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 what data is retrieved but doesn't mention critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or what the output looks like (beyond format options). For a data retrieval 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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. It doesn't explain what 'classification and functional annotation data' includes, how results are structured, or any limitations (e.g., supported genes). For a tool in a complex domain with many siblings, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 ('gene' and 'format') adequately. The description doesn't add any meaningful context beyond what's in the schema, such as explaining what 'protein classification' entails or how the 'gene' parameter maps to results. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'protein classification and functional annotation data', making the purpose understandable. However, it doesn't differentiate this tool from similar siblings like 'get_protein_info' or 'get_protein_by_ensembl', which likely retrieve overlapping information about proteins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 focused on protein data (e.g., 'get_protein_info', 'get_tissue_expression'), users are left to guess which tool is appropriate for classification versus other protein attributes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information for a specific protein by gene symbol
| Name | Required | Description | Default |
|---|---|---|---|
| gene | Yes | Gene symbol (e.g., BRCA1, TP53) | |
| format | No | Output format (default: json) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It does not disclose behavioral traits such as rate limits, authentication needs, error handling, or what 'detailed information' includes (e.g., structure, function, interactions). This leaves significant gaps for a tool with potential complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded with the core purpose and appropriately sized for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 2 parameters with full schema coverage, the description is minimally adequate. It covers the basic purpose but lacks details on return values, error cases, or behavioral context, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters (gene symbol and format). The description adds no additional meaning beyond implying the gene parameter is required, which is already in the schema. Baseline 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information for a specific protein', specifying the lookup method 'by gene symbol'. It distinguishes from siblings like 'get_protein_by_ensembl' (different identifier) and 'batch_protein_lookup' (batch vs single), but does not explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when detailed protein information is needed for a single gene symbol, but provides no explicit guidance on when to choose this over alternatives like 'advanced_search' or 'batch_protein_lookup'. It lacks exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get subcellular localization data for a protein
| Name | Required | Description | Default |
|---|---|---|---|
| gene | Yes | Gene symbol | |
| format | No | Output format (default: json) |
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 what the tool does but lacks details on permissions, rate limits, data sources, or response structure. For a tool with no annotation coverage, this minimal description is insufficient to inform safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words, making it highly concise and front-loaded. It efficiently communicates the core purpose without any fluff or redundancy, earning a top score for brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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. It doesn't explain what the returned data includes (e.g., localization details, confidence scores) or any behavioral aspects like error handling. For a tool with 2 parameters and no structured output, more context is needed to ensure proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 baseline score is 3. The schema already documents the 'gene' parameter as a gene symbol and 'format' as an enum for output format, so the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Get') and resource ('subcellular localization data for a protein'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_by_subcellular_location' or 'get_protein_info', which might offer overlapping functionality, 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.
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. For example, it doesn't specify if this is for single-protein lookups compared to batch operations or how it differs from 'search_by_subcellular_location'. Without such context, users must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tissue-specific expression data for a protein
| Name | Required | Description | Default |
|---|---|---|---|
| gene | Yes | Gene symbol | |
| format | No | Output format (default: json) |
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 the action without details on permissions, rate limits, data sources, or response behavior. It fails to address critical aspects like whether this is a read-only operation, potential data freshness, or error handling, leaving 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, effectively front-loading the core purpose. It is appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 insufficient for a tool that likely returns complex expression data. It does not explain return values, data structure, or potential limitations, leaving the agent under-informed about what to expect from the tool's behavior and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting both parameters ('gene' and 'format') clearly. The description adds no additional meaning beyond the schema, such as examples or constraints, but the schema adequately covers the semantics, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('tissue-specific expression data for a protein'), making the purpose specific and understandable. However, it does not explicitly differentiate from siblings like 'get_blood_expression' or 'get_brain_expression', which might handle specialized subsets, leaving room for ambiguity in tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'search_by_tissue' or 'compare_expression_profiles'. The description lacks context about prerequisites, exclusions, or specific use cases, offering minimal assistance in tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find proteins localized to specific subcellular compartments
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Subcellular location (e.g., nucleus, mitochondria, cytosol) | |
| reliability | No | Reliability filter | |
| format | No | Output format (default: json) | |
| maxResults | No | Maximum number of results (1-10000, default: 100) |
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 finds proteins but doesn't reveal key traits: whether it's a read-only operation, if it requires authentication, rate limits, pagination behavior, or what the output looks like (e.g., list format, error handling). For a search tool with zero annotation coverage, 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.
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 any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly. Every word earns its place, contributing to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a search function with 4 parameters) and the absence of both annotations and an output schema, the description is incomplete. It doesn't cover behavioral aspects like safety or performance, and without an output schema, it fails to explain return values (e.g., protein lists, error formats). This leaves critical gaps for an agent to invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning beyond the schema, such as explaining how 'location' values map to biological terms or the implications of 'reliability' levels. Since the schema handles the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find proteins localized to specific subcellular compartments.' It specifies the verb ('Find') and resource ('proteins'), and the scope ('localized to specific subcellular compartments') is well-defined. However, it doesn't explicitly differentiate from sibling tools like 'get_subcellular_location' or 'search_by_tissue,' which might offer similar 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.
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 lacks context about prerequisites, such as needing a specific location input, and doesn't mention sibling tools like 'get_subcellular_location' or 'search_by_tissue' that might be relevant for related queries. This omission leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find proteins highly expressed in specific tissues
| Name | Required | Description | Default |
|---|---|---|---|
| tissue | Yes | Tissue name (e.g., liver, brain, heart) | |
| expressionLevel | No | Expression level filter | |
| format | No | Output format (default: json) | |
| maxResults | No | Maximum number of results (1-10000, default: 100) |
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 'highly expressed' but doesn't clarify what that means quantitatively, whether results are paginated, if there are rate limits, or what the output looks like beyond format options. For a search tool with no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It earns its place by clearly stating what the tool does, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address key aspects like result format details beyond 'json' or 'tsv,' how 'highly expressed' maps to parameters, or usage context relative to siblings, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema, which has 100% coverage. It implies filtering by 'highly expressed' but doesn't explain how this relates to the 'expressionLevel' parameter or other inputs. With high schema coverage, the baseline is 3, as the schema already documents parameters well, and the description doesn't compensate with additional insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find proteins highly expressed in specific tissues.' It specifies the verb ('Find'), resource ('proteins'), and key constraint ('highly expressed in specific tissues'). However, it doesn't explicitly differentiate from sibling tools like 'get_tissue_expression' or 'search_proteins,' which might offer similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 related to tissue expression (e.g., 'get_tissue_expression,' 'get_brain_expression,' 'search_proteins'), the lack of context leaves the agent guessing about the best choice for a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find proteins associated with specific cancers or with prognostic value
| Name | Required | Description | Default |
|---|---|---|---|
| cancer | No | Cancer type (e.g., breast cancer, lung cancer) | |
| prognostic | No | Prognostic filter | |
| format | No | Output format (default: json) | |
| maxResults | No | Maximum number of results (1-10000, default: 100) |
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 'finds' proteins, implying a read operation, but lacks details on permissions, rate limits, data sources, or response format. This is inadequate for a search tool with multiple 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality without any wasted words. It's appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral context, usage guidelines, and details on return values, which are crucial for effective tool invocation in this domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameters. The description adds no additional meaning beyond implying that 'cancer' and 'prognostic' are key filters, but it doesn't explain parameter interactions or usage nuances, 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.
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 ('Find') and resource ('proteins'), specifying the context of cancer association and prognostic value. It distinguishes itself from siblings like 'search_proteins' by focusing on cancer markers, though it doesn't explicitly contrast with all siblings such as 'search_by_tissue' or 'search_by_subcellular_location'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'search_proteins' or 'search_by_tissue', nor does it specify prerequisites, exclusions, or contextual cues for selection, leaving usage decisions ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Human Protein Atlas for proteins by name, gene symbol, or description
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (gene name, protein name, or keyword) | |
| format | No | Output format (default: json) | |
| columns | No | Specific columns to include in results | |
| maxResults | No | Maximum number of results (1-10000, default: 100) | |
| compress | No | Whether to compress the response (default: false) |
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 search functionality but lacks behavioral details: no mention of rate limits, authentication needs, pagination, error handling, or what the response contains (e.g., result structure). For a search tool with 5 parameters and no output schema, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('Search Human Protein Atlas for proteins') and specifies searchable fields concisely. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of proteins with details), how results are ordered, or behavioral constraints. For a search tool in a rich sibling set, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds minimal value beyond the schema, only implying the 'query' parameter's purpose without detailing semantics for others like 'columns' or 'compress'. Baseline 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and target resource ('Human Protein Atlas for proteins'), specifying searchable fields (name, gene symbol, description). It distinguishes from siblings like 'get_protein_by_ensembl' or 'search_by_tissue' by indicating broader keyword-based search, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Siblings include specialized tools like 'search_by_tissue' or 'get_protein_info', but the description doesn't mention these or provide context for choosing between them. Usage is implied by the search scope but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose with no ambiguity. For example, 'get_protein_info' retrieves general details, while 'get_subcellular_location' focuses on localization, and 'search_by_tissue' finds proteins based on tissue expression. The descriptions clearly differentiate between retrieval, search, and comparison operations.
Tool names follow a highly consistent verb_noun pattern throughout, such as 'get_protein_info', 'search_proteins', and 'compare_expression_profiles'. All tools use snake_case with clear, descriptive verbs like 'get', 'search', and 'compare', making the naming predictable and easy to understand.
With 16 tools, the count is well-scoped for a comprehensive protein atlas server. Each tool earns its place by covering distinct aspects like expression data, pathology, searches, and comparisons, without feeling excessive or thin for the domain's complexity.
The tool surface provides complete coverage for the protein atlas domain, including retrieval (e.g., 'get_protein_info'), search (e.g., 'search_proteins'), comparison (e.g., 'compare_expression_profiles'), and specialized data access (e.g., 'get_pathology_data'). There are no obvious gaps, supporting full agent workflows from basic lookups to advanced analyses.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Human Protein Atlas (HPA) MCP — keyless.
UniProt MCP — protein sequence + function database.
EBI PRIDE Archive MCP — proteomics (mass-spectrometry) data repository.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Augmented-Nature/ProteinAtlas-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
