Click on "Deploy 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., "@PubChem MCP Server Get the molecular formula and SMILES for Caffeine"
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.
the mcp is used to extract the drug basic chemical infomation from pubchem API.
Python 3.10
python-dotenv
requests
mcp
uvicorn
Related MCP server: PubChem Chemical Safety MCP Server
Install the dependencies(local):
Install directly from the project directory
git clone [project repository URL]
cd [project directory]
pip install .Configure servers(pypi):
The servers_config.json follows the same structure as Claude Desktop, allowing for easy integration of multiple servers.
Here's an example:
{
"mcpServers": {
"pubchem": {
"command": "uvx",
"args": ["pubchem_mcp_server"]
}
}
}{
"Drug Name": "Aspirin",
"CAS Number": "50-78-2",
"Molecular Weight": 180.16,
"Molecular Formula": "C9H8O4",
"SMILES": "CC(=O)OC1=CC=CC=C1C(=O)O",
"Synonyms": [
"2-(Acetyloxy)benzoic Acid",
"Acetylsalicylic Acid",
"Acetysal",
"Acylpyrin",
"Aloxiprimum",
"Aspirin",
"Colfarit",
"Dispril",
"Easprin"
],
"InchI Key": "BSYNRYMUTXBXSQ-UHFFFAOYSA-N",
"IUPAC Name": "2-acetyloxybenzoic acid",
"ATC Code": "N02BA01",
"Details Link": "https://pubchem.ncbi.nlm.nih.gov/compound/2244"
}获取化学物质的详细信息
Args: name: 化学物质名称
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive 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?
描述极短，仅一行加参数说明，但过于简略，未充分利用空间。对于无注释和模式描述的工具，应提供更多结构化信息，当前形式属于过度精简而非高效。
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?
考虑到工具简单且有输出模式，描述应说明返回数据的类型和内容（如性质、用途等），但仅提'详细信息'，未涉及输出结构或检索范围，完整性不足。
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?
模式覆盖率为0%，描述为'name'参数添加了中文解释'化学物质名称'，补充了模式中仅有的'Name'标题。但未提供格式、限制或示例，缺乏深度。
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?
描述明确说明工具用于获取化学物质的详细信息，即从名称获取详细数据。但与同级工具（如get_cid_by_name、search_chemical_by_cas）的区别未明确，且未指明返回数据的具体范围。
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?
描述未提供何时使用此工具而非替代方案的指南。未提及与其他工具（如通过名称获取CID或按CAS搜索）的比较或条件，缺乏适用场景说明。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据化学物质名获得CID
Args: name: 化学物质名称
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for disclosing behavioral traits, but it merely states the function. It does not mention whether the operation is read-only, requires permissions, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only two meaningful lines plus an 'Args' section. It is front-loaded with the core purpose. However, it is slightly under-specified for a production 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 tool's simplicity (one parameter, output schema exists), the description is minimally adequate. It identifies the input and purpose, but lacks any context about the output format or potential errors.
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 0%, so the description should compensate. However, it only reiterates that 'name' is a chemical substance name, adding minimal meaning beyond the schema title 'Name'. No details about format or examples.
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 explicitly states the tool retrieves a CID by chemical name, with clear verb '获得' (get) and resource 'CID'. It is distinct from siblings like 'get_chemical_info' and 'search_chemical_by_cas', which provide broader info or search by CAS number.
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, nor any exclusions or prerequisites. It only states the input, 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.
通过CAS号搜索化学物质信息
Args: cas_number: 化学物质的CAS号
| Name | Required | Description | Default |
|---|---|---|---|
| cas_number | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it searches for information, but lacks details on behavioral traits such as read-only nature, authentication, rate limits, or error 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 extremely concise, consisting of two lines. The first line clearly states the purpose, and the second line defines the parameter without wasted words.
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 simplicity (one required param, output schema exists), the description is too minimal. It omits details like what constitutes 'chemical substance information', handling of invalid CAS numbers, or pagination. While output schema exists, the description still lacks 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?
The parameter description in the tool text (cas_number: 化学物质的CAS号) merely restates the schema title 'Cas Number' without adding format, validation, or example details. Schema coverage is 0%, yet no extra semantic value is provided.
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 'search' and the resource 'chemical substance information' by CAS number. It distinguishes from sibling tools 'get_chemical_info' and 'get_cid_by_name' by specifying the search method using CAS.
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 on when to use this tool vs alternatives. It does not mention when not to use or provide context for selecting this tool over siblings like 'get_cid_by_name'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.7get_chemical_infoget_cid_by_namesearch_chemical_by_casScored across 3 tools
Tools have distinct purposes: get_chemical_info returns details by name, get_cid_by_name returns CID by name, and search_chemical_by_cas searches by CAS number. However, slight overlap exists between the first two since both accept a name parameter, but the outputs differ, so an agent can distinguish them with careful reading.
All tools use snake_case and follow a verb_noun or verb_noun_by_param pattern (get_chemical_info, get_cid_by_name, search_chemical_by_cas). The verbs are mostly 'get' except one 'search', which is a minor inconsistency, but overall the pattern is clear and predictable.
With only 3 tools, the server feels under-scoped for a domain like PubChem, which typically requires many lookup and search capabilities. The count is borderline but still within a reasonable minimum, though it likely limits usefulness.
The tool surface covers only name and CAS lookups, missing many common operations like searching by formula, structure, or synonyms, and does not support listing or multiple results. This leaves significant gaps for a comprehensive chemical information server.
Search PubChem compounds, properties, safety data, bioactivity, and cross-references.
Link compounds to protein targets, rank bioactivity, and look up drug mechanisms and indications.
Biomedical data: compounds, drug info, and molecular targets
PubChem MCP — NIH chemistry compound database (no auth)