SureChEMBL MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no significant overlap. For example, search_by_smiles and search_by_inchi both search chemicals but use different input formats, while get_chemical_by_id retrieves specific records. The descriptions clarify distinct functions like analysis vs. export vs. search.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case, such as get_chemical_by_id, search_by_smiles, and analyze_patent_chemistry. The naming is predictable and readable throughout the set, with verbs like get, search, analyze, and export used appropriately.
Tool Count5/5
With 15 tools, the count is well-scoped for a patent chemistry database server. Each tool earns its place by covering distinct aspects like chemical retrieval, patent search, analysis, and export, without being overwhelming or too sparse for the domain.
Completeness5/5
The tool set provides complete coverage for the SureChEMBL domain, including CRUD-like operations (e.g., get, search, analyze, export) for both chemicals and patents. There are no obvious gaps; it supports chemical lookup, structure search, patent analysis, and data export, enabling full agent workflows.
Average 3/5 across 15 of 15 tools scored.
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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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 analyzes chemical content and annotations but does not specify whether this is a read-only operation, what permissions are required, how results are returned, or any rate limits. This is inadequate for a tool that likely involves data processing without structured behavioral hints.
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 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.
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. It does not explain what the analysis entails, the format of results, or any behavioral aspects like error handling. For a tool that likely returns complex chemical data, this leaves significant gaps in understanding its functionality 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?
The input schema has 100% description coverage, with the single parameter 'document_id' clearly documented. The description does not add any additional meaning beyond the schema, such as format examples or constraints, but since schema coverage is high, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 analyzing chemical content and annotations in patent documents, specifying both the action ('analyze') and resource ('chemical content and annotations in a patent document'). However, it does not explicitly differentiate from sibling tools like 'get_document_content' or 'search_patents', which might also involve patent document analysis, 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. It lacks context on prerequisites, such as needing a specific document ID, and does not mention any sibling tools like 'get_document_content' or 'search_patents' as alternatives, 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 but lacks critical behavioral details. It mentions bulk export and formats but doesn't disclose permissions needed, rate limits, file size constraints, whether it's a synchronous or asynchronous operation, or what the output contains. 'Bulk' hints at scale but without specifics, leaving 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads key information ('bulk export chemical data') and specifies formats 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., execution mode, limits), output structure, and usage context. While concise, it doesn't compensate for the missing structured data, leaving the agent with insufficient information for optimal 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 fully documents all parameters. The description adds no additional parameter semantics beyond implying bulk handling and format options, which are already covered by the schema's descriptions and enums. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('bulk export') and resource ('chemical data'), specifying the output formats (CSV or XML). It distinguishes from siblings by focusing on export functionality rather than search, analysis, or retrieval operations. However, it doesn't explicitly contrast with specific sibling tools like 'get_chemical_properties' or 'search_chemicals_by_name'.
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, ideal scenarios, or contrast with sibling tools like 'get_chemical_by_id' for single records or 'search_chemicals_by_name' for different query types. Usage is implied by the name and purpose but not explicitly stated.
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 retrieves 'detailed chemical information' but doesn't specify what that entails (e.g., structure, properties, metadata), whether it's a read-only operation, potential errors (e.g., invalid ID), or any rate limits. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
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 that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the key action and resource, making it easy to parse quickly, which is ideal for conciseness in tool descriptions.
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 insufficient for a tool that presumably returns complex chemical data. It doesn't explain what 'detailed chemical information' includes, potential response formats, or error handling, leaving the agent with incomplete context for effective use in a chemistry-focused environment.
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%, with the parameter 'chemical_id' fully documented in the schema as 'SureChEMBL chemical ID (numeric)'. The description adds no additional parameter semantics beyond this, such as format examples or constraints, so it meets the baseline for 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 action ('Get detailed chemical information') and resource ('by SureChEMBL chemical ID'), making the purpose unambiguous. However, it doesn't explicitly differentiate this from sibling tools like 'get_chemical_properties' or 'get_chemical_frequency', which might also retrieve chemical data but through different mechanisms or with different scopes.
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 a valid SureChEMBL ID), exclusions, or comparisons to siblings like 'search_chemicals_by_name' or 'get_chemical_properties', leaving the agent to infer usage context solely from the tool name and 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates an image but doesn't describe the output format (e.g., PNG, SVG), potential errors (e.g., invalid SMILES), performance characteristics, or any side effects. For a tool with no annotations and unknown output, 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every element earning its place by specifying the action, output, and input type.
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 no annotations, no output schema, and a tool that generates images (which implies specific output formats and potential errors), the description is incomplete. It doesn't address what the output looks like (e.g., image type, how to handle it), error conditions, or usage constraints, leaving the agent with insufficient context for reliable invocation.
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 three parameters (structure, height, width) with descriptions and constraints. The description adds no additional parameter semantics beyond implying that 'SMILES or other structure notation' maps to the 'structure' parameter. This meets the baseline of 3 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 tool's purpose: 'Generate chemical structure image from SMILES or other structure notation.' It specifies the verb (generate), resource (chemical structure image), and input type (SMILES/other notation). However, it doesn't explicitly differentiate from sibling tools like search_by_smiles or search_similar_structures, which might also involve SMILES input 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. It doesn't mention sibling tools like search_by_smiles (which might retrieve data rather than generate images) or get_chemical_by_id (which might fetch existing records). There's no context about prerequisites, alternatives, or exclusions.
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 action but does not reveal any behavioral traits like whether it's read-only, has rate limits, requires authentication, or what the output format might be. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any unnecessary words or fluff. It is front-loaded and efficiently communicates the core function, making it highly concise and well-structured.
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. It does not address behavioral aspects, usage context, or output details, which are crucial for a tool that likely returns complex data like molecular properties. This makes it inadequate for full understanding in a real-world scenario.
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 the parameter 'chemical_id' documented as 'SureChEMBL chemical ID'. The description does not add any additional meaning or context beyond what the schema provides, such as examples or format details, so it meets the baseline score 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 verb 'Get' and the resource 'molecular properties and descriptors for a chemical by ID', making the purpose specific and understandable. However, it does not explicitly distinguish this tool from sibling tools like 'get_chemical_by_id' or 'get_chemical_frequency', which may have overlapping or similar purposes, 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, such as 'get_chemical_by_id' or 'search_chemicals_by_name'. It lacks context on prerequisites, exclusions, or specific scenarios where this tool is preferred, offering only a basic statement of function without 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. It states it 'gets' statistics, implying a read-only operation, but doesn't specify if it's safe, has rate limits, requires authentication, or what the output format might be. For a tool with 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 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 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 complexity of statistical analysis, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'statistical overview' entails, the types of statistics returned, or any behavioral traits like error handling. For a tool with these gaps, it should provide more context to be fully 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?
Schema description coverage is 100%, so the schema already documents both parameters ('document_id' and 'include_annotations') with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as examples or context for the parameters, so it meets the baseline for high 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 ('Get statistical overview') and resource ('chemical content in patents'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'get_chemical_frequency' or 'analyze_patent_chemistry', which might offer overlapping functionality, 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 like 'get_chemical_frequency' or 'analyze_patent_chemistry'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name and schema 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 the basic function. It doesn't cover aspects like whether this is a read-only operation, potential rate limits, authentication needs, error handling, or what the search results might include (e.g., chemical IDs, names, properties). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, efficiently conveying the core purpose. It is appropriately sized and front-loaded, making it easy to parse 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 of a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., chemical records, IDs, or error messages), how results are structured, or any limitations (e.g., partial matches, case sensitivity). This leaves the agent without sufficient context 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?
The schema description coverage is 100%, with clear documentation for both parameters ('inchi' as the search string and 'limit' with range and default). The description adds no additional parameter semantics beyond what the schema provides, such as examples of InChI formats or search behavior nuances, 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 action ('Search for chemicals') and the resource ('by InChI or InChI key'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_by_smiles' or 'search_chemicals_by_name', which would require mentioning the specific chemical identifier type used.
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 'search_by_smiles' for SMILES strings or 'search_chemicals_by_name' for name-based searches, nor does it specify prerequisites or contexts where InChI searching is preferred.
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 searches for patents but doesn't describe what the search returns (e.g., patent details, metadata, or a list), whether it's a read-only operation, or any limitations like rate limits or authentication needs. 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.
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's front-loaded with the core purpose, making it easy to parse quickly. Every part of the sentence earns its place by clarifying the action and 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. It doesn't explain what the tool returns (e.g., patent data, error messages), behavioral traits like read-only status, or usage constraints. For a search tool with no structured output information, the description should provide more context to help an agent understand the full scope of the tool's operation.
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 mentions searching by 'patent numbers or publication numbers,' which aligns with the single parameter 'patent_number' in the schema. Since schema description coverage is 100% (the parameter is well-documented as 'Patent or publication number'), the description adds minimal value beyond the schema. This meets the baseline of 3, as the schema does the heavy lifting for 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: 'Search for patents by specific patent numbers or publication numbers.' It specifies the verb ('search'), resource ('patents'), and criteria ('patent numbers or publication numbers'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'search_patents' or 'get_patent_family,' which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 when to choose it over siblings like 'search_patents' (which might have broader search capabilities) or 'get_patent_family' (which might retrieve related patents). Without such context, an agent might struggle to select the correct tool for a given task.
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 is for searching, implying a read operation, but doesn't cover critical aspects like whether it's a fuzzy or exact match search, what the output format is (e.g., list of chemicals with IDs), performance characteristics (e.g., speed, accuracy), or error handling. For a search tool with no annotation coverage, 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 a single, efficient sentence: 'Search for chemicals by SMILES structure notation.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a straightforward search tool. Every part of the sentence contributes directly to understanding the tool's function.
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 chemical search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the search returns (e.g., chemical IDs, names, properties), how results are ordered, or potential limitations (e.g., database coverage). For a tool with 2 parameters and no structured output information, the description should provide more context to guide 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?
The input schema has 100% description coverage, with clear documentation for both parameters: 'smiles' as the SMILES string and 'limit' with range and default. The description adds no additional parameter semantics beyond what's in the schema, such as examples of valid SMILES strings or how the limit applies to results. With high schema coverage, the 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.
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: 'Search for chemicals by SMILES structure notation.' It specifies the verb ('Search'), resource ('chemicals'), and method ('by SMILES structure notation'). However, it doesn't explicitly distinguish this tool from its sibling 'search_by_inchi' or 'search_similar_structures,' which are related chemical search tools. 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_by_inchi' (for InChI notation), 'search_chemicals_by_name' (for name-based search), or 'search_similar_structures' (for structural similarity). There's no context on prerequisites, exclusions, or recommended scenarios, leaving the agent to 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.
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 states the search functionality but lacks critical details: whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior, or what the output format looks like. For a search tool with zero annotation coverage, 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: 'Search for chemicals by name, synonym, or common name.' It's front-loaded with the core purpose and wastes no words. Every part of the sentence contributes meaning.
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 (search operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral constraints. For a search tool in a chemical database context, more context about result format (e.g., chemical IDs, names, properties) 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?
Schema description coverage is 100%, so the schema fully documents both parameters ('name' and 'limit'). The description adds no parameter-specific information beyond what's in the schema. It mentions 'name, synonym, or common name' which aligns with the schema's 'Chemical name or synonym to search for', but provides no additional syntax or format details. 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: 'Search for chemicals by name, synonym, or common name.' It specifies the verb (search) and resource (chemicals), and indicates the search scope (name, synonym, common name). However, it doesn't explicitly differentiate from sibling tools like 'search_by_inchi' or 'search_by_smiles' which search by different chemical identifiers.
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 'search_by_inchi' (for InChI strings) or 'search_by_smiles' (for SMILES notation), nor does it specify use cases or exclusions. The agent 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.
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 'similarity search' but doesn't specify what similarity metric is used (e.g., Tanimoto, Euclidean), whether results are paginated, rate limits, authentication needs, or what the output format looks like. This leaves significant gaps for an AI agent to understand how to invoke 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Find structurally similar chemicals') without unnecessary words. Every part earns its place by specifying the method ('using similarity search'), making it appropriately sized and well-structured.
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 no annotations and no output schema, the description is incomplete for a tool with 3 parameters and behavioral complexity. It lacks details on the similarity metric, result format, error handling, or performance characteristics, which are crucial for an AI agent to use this tool correctly in a chemical search 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, clearly documenting all three parameters with types, ranges, and defaults. The description adds no additional parameter semantics beyond what's in the schema, such as explaining what 'reference_id' refers to (e.g., a database ID, SMILES string) or how 'threshold' impacts results. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and resource 'structurally similar chemicals' with the method 'using similarity search', making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'search_by_smiles' or 'search_chemicals_by_name', which might also involve chemical searching but with different criteria.
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 'search_by_smiles' or 'search_chemicals_by_name' available, there's no indication of when structural similarity search is preferred over other search methods, nor any prerequisites or exclusions 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?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It lacks information on permissions, rate limits, response format, or whether it's read-only (implied by 'Get' but not explicit), which is insufficient 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, efficient sentence with zero waste. It's front-loaded with the core purpose and 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter with full schema coverage but no annotations or output schema, the description is minimally adequate. It clarifies the purpose but lacks behavioral context and usage guidelines, making it incomplete for optimal agent decision-making in a server with many 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?
The schema description coverage is 100%, with the single parameter 'chemical_id' documented as 'SureChEMBL chemical ID'. The description adds no additional parameter semantics beyond this, so it meets the baseline score of 3 for high schema coverage without extra value.
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 ('Get') and resource ('frequency statistics for chemicals across the patent database'), making the purpose understandable. However, it doesn't explicitly differentiate from siblings like 'get_patent_statistics' or 'get_chemical_properties', which could have overlapping statistical or chemical focus.
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, exclusions, or compare to siblings such as 'get_patent_statistics' or 'search_chemicals_by_name', leaving the agent to infer 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 the full burden of behavioral disclosure. It states what the tool does but lacks details on permissions, rate limits, response format, or whether it's read-only or has side effects. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently conveys the tool's function without unnecessary elaboration.
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's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks behavioral details and usage context, making it incomplete for effective agent use without additional inference.
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%, with the parameter 'patent_id' fully documented in the schema. The description doesn't add any extra meaning beyond the schema, such as format 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.
Purpose4/5
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 'patent family members and relationships for a patent', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_patents' or 'get_patent_statistics', 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, exclusions, or compare to sibling tools such as 'search_by_patent_number' or 'get_patent_statistics', leaving usage context 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the search functionality but lacks details on permissions, rate limits, response format, or error handling. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its operational 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 that front-loads the core purpose without unnecessary words. Every part ('Search patents by text, keywords, or identifiers in SureChEMBL database') contributes directly to understanding the tool's function.
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's moderate complexity (search with three parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and output, which are needed for a more complete understanding. It meets the minimum viable threshold but has clear 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 fully documents the three parameters (query, limit, offset). The description adds minimal value by implying the query can include 'text, keywords, or identifiers', but this doesn't go beyond the schema's description of 'Search query (keywords, patent numbers, or text)'. Baseline 3 is appropriate when the schema handles most 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 action ('Search patents') and target resource ('patents in SureChEMBL database'), with the method ('by text, keywords, or identifiers') providing specific context. However, it doesn't explicitly differentiate from sibling tools like 'search_by_patent_number' or 'search_chemicals_by_name', which reduces it from 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 like 'search_by_patent_number' or 'search_chemicals_by_name'. It mentions the database (SureChEMBL) but doesn't specify use cases, exclusions, or prerequisites, leaving the agent without contextual 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves content with chemical annotations but does not describe response format, error conditions, rate limits, or authentication needs. For a read operation with no annotation coverage, this leaves significant gaps in understanding tool 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 with zero waste. It is front-loaded with the core purpose and includes all necessary elements without redundancy, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that retrieves complex content. It does not explain what 'complete patent document content' includes, the format of chemical annotations, or any limitations, leaving the agent with insufficient context 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 fully documents the single parameter. The description adds minimal value beyond the schema by implying the document_id is for patent documents and mentioning chemical annotations, but does not provide additional syntax or format details. 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 specific action ('Get complete patent document content'), the resource ('patent document'), and key features ('with chemical annotations by document ID'). It distinguishes from siblings like get_patent_family or get_patent_statistics by focusing on full content retrieval with annotations rather than metadata or statistics.
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 prerequisites, exclusions, or compare to siblings like search_patents or get_patent_family, leaving the agent to infer usage context independently.
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:

[![SureChEMBL-MCP-Server MCP server](https://glama.ai/mcp/servers/Augmented-Nature/SureChEMBL-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/Augmented-Nature/SureChEMBL-MCP-Server)

Score Badge

Copy to your README.md:

[![SureChEMBL-MCP-Server MCP server](https://glama.ai/mcp/servers/Augmented-Nature/SureChEMBL-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/Augmented-Nature/SureChEMBL-MCP-Server)

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/Augmented-Nature/SureChEMBL-MCP-Server'

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