PyThermoCalcDB-NASA-MCP — это сервер протокола контекста модели (Model Context Protocol) для выполнения выбранных термодинамических расчётов pythermocalcdb-nasa из агентов и клиентов, совместимых с MCP.
Пакет MCP является интерфейсным и оркестрационным слоем. Он проверяет структурированные запросы, создаёт ModelSource, вызывает детерминированные функции pythermocalcdb-nasa и возвращает результаты в формате, безопасном для JSON. Он не реализует сам научный расчёт.
Рабочий процесс по умолчанию использует встроенную базу данных NASA-9 SQLite, включённую в pythermocalcdb-nasa. Если компонент недоступен локально, сервер MCP возвращает структурированную ошибку. Поиск внешних данных не входит в обязанности этого сервера MCP; другой агент или вызывающая сторона должны подготовить полное содержимое REFERENCE для pyThermoDB и вызвать инструмент с параметром source: "reference".
Используйте этот пакет для:
Расчёта H_T, S_T, G_T и Cp_T для одного компонента.
Расчёта dH_rxn_STD, dS_rxn_STD, dG_rxn_STD, Keq и Keq_vh_shortcut для реакций.
Проверки предварительно подготовленного содержимого YAML-ссылок pyThermoDB.
Related MCP server: MoziChem-MCP
pip install pythermocalcdb-nasa-mcpДля локальной разработки:
uv syncSTDIO — транспорт по умолчанию:
pythermocalcdb-nasa-mcp --mode stdioТакже поддерживается HTTP-транспорт:
pythermocalcdb-nasa-mcp --mode http --host 127.0.0.1 --port 8000 --path /mcpИз локальной копии репозитория:
uv run pythermocalcdb-nasa-mcp --mode stdio🧵 STDIO:
{
"mcpServers": {
"pythermocalcdb-nasa": {
"command": "pythermocalcdb-nasa-mcp",
"args": ["--mode", "stdio"]
}
}
}🌍 HTTP:
{
"mcpServers": {
"pythermocalcdb-nasa": {
"url": "http://127.0.0.1:8000/mcp"
}
}
}Вы можете протестировать сервер с помощью официального MCP Inspector.
Для прямого тестирования STDIO из локальной копии:
npx @modelcontextprotocol/inspector uv run pythermocalcdb-nasa-mcp --mode stdioДля HTTP-тестирования сначала запустите сервер:
uv run pythermocalcdb-nasa-mcp --mode http --host 127.0.0.1 --port 8000 --path /mcpЗатем подключите Inspector к:
http://127.0.0.1:8000/mcppythermocalcdb-nasa://references/nasa-requirements
Политика источников, символы NASA, единицы измерения, температурные диапазоны и границы агента.
pythermocalcdb-nasa://workflows/species-properties
Рабочий процесс для H_T, S_T, G_T и Cp_T.
pythermocalcdb-nasa://workflows/reaction-properties
Рабочий процесс для dH_rxn_STD, dS_rxn_STD, dG_rxn_STD, Keq и Keq_vh_shortcut.
pythermocalcdb-nasa://guidance/agent-checklist
Контрольный список для надёжных вызовов с использованием базы данных и ссылок.
🔥 Инструменты для веществ:
calc_H_T
calc_S_T
calc_G_T
calc_Cp_T
⚗️ Инструменты для реакций:
calc_dH_rxn_STD
calc_dS_rxn_STD
calc_dG_rxn_STD
calc_Keq
calc_Keq_vh_shortcut
🛠️ Вспомогательный инструмент:
check_yaml_reference
Инструменты расчёта получают один аргумент Pydantic с именем request. Они используют общие доменные модели из pythermodb_settings, включая Component, Temperature и ComponentKey.
🗄️ Запрос вещества на основе базы данных:
{
"request": {
"component": {
"name": "carbon dioxide",
"formula": "CO2",
"state": "g"
},
"temperature": {
"value": 300.0,
"unit": "K"
},
"source": "database",
"component_key": "Name-Formula",
"nasa_type": "nasa9",
"basis": "molar"
}
}📄 Запрос вещества на основе ссылки:
{
"request": {
"component": {
"name": "component name from prepared reference",
"formula": "Formula",
"state": "g"
},
"temperature": {
"value": 300.0,
"unit": "K"
},
"source": "reference",
"reference_content": "REFERENCES:\n ...",
"component_key": "Name-Formula",
"nasa_type": "nasa9",
"basis": "molar"
}
}🗄️ Запрос реакции на основе базы данных:
{
"request": {
"name": "Water-Gas Shift Reaction",
"reaction": "CO(g) + H2O(g) => CO2(g) + H2(g)",
"components": [
{"name": "carbon monoxide", "formula": "CO", "state": "g"},
{"name": "dihydrogen monoxide", "formula": "H2O", "state": "g"},
{"name": "carbon dioxide", "formula": "CO2", "state": "g"},
{"name": "dihydrogen", "formula": "H2", "state": "g"}
],
"temperature": {
"value": 398.15,
"unit": "K"
},
"source": "database",
"component_key": "Name-Formula",
"nasa_type": "nasa9"
}
}Используйте ту же форму запроса реакции с calc_Keq_vh_shortcut, когда запрашивается оценка по сокращённому уравнению Вант-Гоффа. Она возвращает безразмерную константу равновесия.
Ответы следуют этому контракту:
{
"success": true,
"message": "H_T completed successfully.",
"results": {
"operation": "H_T",
"value": 0.0,
"unit": "J/mol"
},
"analysis": {
"source": "database"
},
"warnings": []
}Сначала используйте source: "database" для данных NASA-9 в поддерживаемых фазах g, l и s.
Используйте source: "reference" только с полным предварительно подготовленным reference_content.
Не просите этот сервер MCP искать внешние научные данные.
Вводите температуру в кельвинах.
Убедитесь, что каждый вид реакции присутствует как в уравнении реакции, так и в components.
Используйте nasa_type: "nasa9" с источником базы данных.
Проверяйте success, message и warnings перед сообщением результатов.
python -m py_compile pythermocalcdb_nasa_mcp/server.py
python -m py_compile pythermocalcdb_nasa_mcp/interface/core.py
python -m py_compile pythermocalcdb_nasa_mcp/models/nasa.py
python -m unittest discover testsПримеры форм полезной нагрузки доступны в examples/request_payloads.py.
Этот проект лицензирован под Apache License 2.0. См. LICENSE.
Calculate component heat capacity Cp_T using the embedded NASA-9 database by default, or caller-supplied reference_content when source='reference'.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Request for a single-component NASA property calculation. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It reveals that the tool uses an embedded NASA-9 database or custom reference_content, but fails to disclose error behavior (e.g., missing data, out-of-range temperature), permissions, or side effects. Critical gaps exist for a computational tool.
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 sentence of 22 words, front-loaded with the purpose. It is concise with no redundant phrases, though slight tightening is possible (e.g., 'using the embedded NASA-9 database' could be 'using the NASA-9 database').
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?
Despite the tool's complexity (nested objects, many parameters), the description is minimal. It does not explain return values (though output schema exists), temperature validity ranges, or prerequisites. Annotations are absent, leaving significant gaps for correct 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?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the dual-mode behavior (database vs reference) for the 'source' and 'reference_content' parameters. However, it does not elaborate on other parameters like mode, basis, or nasa_type, which are only documented in the 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 clearly states it calculates component heat capacity Cp_T, specifying the verb 'Calculate' and resource. It mentions the default NASA-9 database and alternative reference_source, but does not explicitly distinguish from sibling tools like calc_H_T or calc_S_T beyond the property name.
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 internal context about using the database by default or caller-supplied reference_content, but offers no guidance on when to use this tool versus sibling tools (e.g., calc_H_T, calc_G_T). No exclusions or when-not-to-use conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate standard Gibbs free energy change of reaction using the embedded NASA-9 database by default, or caller-supplied reference_content when source='reference'.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Request for a reaction NASA property calculation. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 uses the NASA-9 database by default and accepts caller-supplied content, but it does not mention any side effects, error handling, required permissions, or what happens if the reference content is missing or invalid. For a calculation tool, this is minimal but not misleading, hence a 2.
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 sentence of 18 words, front-loading the main purpose and then concisely noting the two data-source modes. No superfluous words or repetition. It is as efficient as possible.
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 the input schema (nested object with many required subfields), the description is very terse. It does not summarize the inputs or provide an example. However, the schema descriptions are complete, and an output schema exists (so return values are covered). The description is adequate but could be more helpful by briefly listing required inputs or clarifying the reaction format.
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 baseline is 3. The description adds the context that the default database is 'NASA-9', which is not in the schema's source parameter description. However, this is a minor addition. The description does not elaborate on any other parameters, leaving the schema to carry the full semantic load, which it does 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 tool calculates standard Gibbs free energy change of reaction, with a specific verb ('Calculate') and resource ('standard Gibbs free energy change of reaction'). It distinguishes between two data sources (embedded NASA-9 database vs. caller-supplied reference). However, it does not explicitly differentiate this tool from its siblings (e.g., calc_dH_rxn_STD, calc_dS_rxn_STD), though the name alone implies the distinction.
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 its siblings or alternatives. It mentions two modes (database vs. reference) but lacks criteria for choosing one over the other, nor does it explain prerequisites or conditions for use. No 'when to use' or 'when not to use' statements are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate standard enthalpy change of reaction using the embedded NASA-9 database by default, or caller-supplied reference_content when source='reference'.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Request for a reaction NASA property calculation. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the default database and the option for reference content, but it does not disclose whether the tool is read-only or destructive, error behavior, or performance characteristics. The description adds context about data sources beyond the schema, but behavioral details are minimal.
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 sentence that front-loads the core purpose and effectively conveys both default behavior and optional customization. Every word earns its place without any fluff.
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 the input schema (nested objects, multiple enums) and the presence of an output schema, the description is concise yet adequate for an agent to understand when to use source='reference'. It could benefit from mentioning that the output provides the enthalpy value and units, but the output schema presumably covers that.
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 baseline is 3. The description adds value by clarifying the role of reference_content and the source parameter, which govern whether to use the embedded database or external YAML. This context helps the agent understand when to provide reference_content, going beyond what the schema enumerates.
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 calculates the standard enthalpy change of reaction, specifying the default data source (embedded NASA-9 database) and the alternative source (reference_content when source='reference'). This distinguishes it from sibling tools like calc_dS_rxn_STD and calc_dG_rxn_STD, which likely compute other thermodynamic quantities.
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 implicitly tells the agent when to use this tool (for standard enthalpy calculations) and when to use source='reference' (for custom data). However, it does not explicitly exclude scenarios where other tools like calc_G_T or calc_Keq would be more appropriate, though sibling tool names provide some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate standard entropy change of reaction using the embedded NASA-9 database by default, or caller-supplied reference_content when source='reference'.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Request for a reaction NASA property calculation. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It reveals the data source choice (NASA-9 database vs reference_content) but omits side effects, error handling, permission needs, or what happens with incomplete inputs. This is adequate but not comprehensive for a calculation tool.
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?
A single sentence that is front-loaded with the verb and resource. No fluff or repetition. Could be slightly more structured (e.g., noting that standard state conditions apply) but overall efficient.
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?
The output schema exists so return values need not be described. However, the description misses high-level context like standard state conditions (1 bar), implicit temperature range validity, or required reaction balancing. The comprehensive schema compensates but the description alone is thin.
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 coverage is 100% so baseline is 3. The description adds meaning by specifying the default database ('NASA-9') and conditionally exposing reference_content usage via the source parameter. This goes beyond the schema's enum descriptions and helps the agent understand the data source mode.
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 calculates 'standard entropy change of reaction', with a specific verb and resource. It differentiates from sibling tools (calc_dH_rxn_STD, calc_dG_rxn_STD) through the dimension 'entropy' but does not explicitly call out the distinction.
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 given on when to use this tool versus alternatives like calc_dH_rxn_STD or calc_dG_rxn_STD. The description only explains the data source modes (database vs reference) but lacks explicit context on experimental design or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate component Gibbs free energy G_T using the embedded NASA-9 database by default, or caller-supplied reference_content when source='reference'.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Request for a single-component NASA property calculation. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals that the tool uses a default database or custom reference content, but it does not mention side effects, authentication needs, rate limits, or error handling. The minimal disclosure limits the agent's ability to predict 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 sentence that is front-loaded with the core purpose. Every word earns its place; there is no redundancy or filler. It is an example of efficient communication.
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 (nested objects, many parameters, output schema exists) and the presence of sibling tools, the description is minimal. It does not mention the required temperature input or the component object structure, though those are covered in the schema. The description is adequate but could be improved by briefly noting that the tool operates on a single component and requires a temperature.
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% (baseline 3). The description adds value by clarifying that the default source is 'database' (NASA-9) and that reference_content is only needed when source='reference'. This relationship is not fully obvious from the schema alone, even though the schema's description for reference_content already states the condition. The added mention of 'NASA-9' provides useful context.
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 specific verb ('calculate') and resource ('component Gibbs free energy G_T'), and distinguishes from sibling tools like calc_H_T and calc_S_T by focusing on Gibbs free energy. The mention of using NASA-9 database or reference content further specifies the domain.
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 the tool is for calculating Gibbs free energy, but it does not explicitly state when to use it versus alternatives (e.g., calc_H_T for enthalpy). It lacks guidance on exclusions or prerequisites, leaving the agent to infer context 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.
Calculate component enthalpy H_T using the embedded NASA-9 database by default, or caller-supplied reference_content when source='reference'.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Request for a single-component NASA property calculation. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 disclosing behavioral traits. It does not mention whether the calculation is read-only, whether any side effects occur (e.g., caching, logging), or what happens if the component is not in the database. For a calculation tool that accesses a database, 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 sentence of 18 words, specifying the default behavior and the alternative. It is concise and avoids redundancy. However, it could benefit from a brief additional sentence on the required inputs or sibling differentiation without becoming verbose.
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 the tool (many parameters, nested objects, no annotations, but has output schema), the description is minimal. It covers the core function (calculating enthalpy from database/reference) but omits details about return values, error handling, or parameter selection. The output schema exists, so return format is covered, but the agent lacks guidance on parameter usage and behavioral constraints.
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%, so the schema already documents the nested object structure and field meanings. The description adds minimal value: it mentions the default NASA-9 database and the alternative reference source, which clarifies the 'source' and 'reference_content' parameters. However, it does not explain the 'mode', 'nasa_type', or 'component_key' parameters, nor does it provide context for when to use each. Baseline 3 is appropriate since the schema is comprehensive.
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 it calculates component enthalpy H_T and mentions the default NASA-9 database and the alternative reference source. However, it does not clearly differentiate this from sibling tools like calc_S_T or calc_G_T, which likely share a similar interface. The description could be more specific about what distinguishes this enthalpy calculation from entropy or Gibbs free energy calculations.
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 only briefly notes when to use 'source='reference'' vs the default database. There is no guidance on when to use this tool vs alternatives (e.g., when you need enthalpy vs entropy), no prerequisites (e.g., need component and temperature), and no mention of when not to use it. The agent is left to infer usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate reaction equilibrium constant Keq using the embedded NASA-9 database by default, or caller-supplied reference_content when source='reference'.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Request for a reaction NASA property calculation. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden of behavioral disclosure. It states the tool calculates Keq using specified data sources, but does not mention whether the tool is read-only, what permissions are needed, how errors are handled, or any side effects. This is a significant gap for a complex calculation tool.
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, front-loaded sentence that efficiently conveys the core purpose and the key usage condition. While it is very concise, it could benefit from briefly mentioning the sibling tool or additional context without losing efficiency.
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 (many parameters, nested objects, output schema exists), the description is minimal. It covers the main data source distinction but lacks details on calculation methodology, error handling, and how it relates to the sibling tool. The presence of an output schema reduces the need to describe return values, but more context would improve usability.
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 coverage is 100%, so baseline is 3. The description adds value by explaining the conditional use of 'reference_content' when 'source' is set to 'reference', and clarifies that the default uses the embedded NASA-9 database. This enriches the parameter semantics beyond the schema alone.
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 'Calculate' and the resource 'reaction equilibrium constant Keq', distinguishing between two data sources (default NASA-9 database and caller-supplied reference content). However, it does not differentiate from the sibling tool 'calc_Keq_vh_shortcut', which may serve a similar purpose.
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 conditions usage on the 'source' parameter, indicating when to use the database vs. reference content. However, it provides no guidance on when to use this tool over its sibling 'calc_Keq_vh_shortcut', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate reaction equilibrium constant Keq_vh_shortcut using the van't Hoff shortcut and the embedded NASA-9 database by default, or caller-supplied reference_content when source='reference'.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Request for a reaction NASA property calculation. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only mentions data source options and does not disclose behavioral traits such as error handling, temperature range validity, standard state assumptions, or what happens if components are missing from the database. This is minimal disclosure for a kinetic calculation tool.
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 concise sentence that efficiently conveys the core purpose and two data source modes. It is well-structured and front-loaded with the verb and resource. However, it could be slightly improved by separating the two modes for 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 complex nested input schema, no annotations, and the presence of a sibling calc_Keq, the one-sentence description is insufficient. It does not mention the output format, constraints, prerequisites, or when to prefer this shortcut over the full calculation. The output schema exists but is not referenced in the description.
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 baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides. It mentions 'source' and 'reference_content' but these are already documented in the schema with descriptions and defaults.
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 calculates the reaction equilibrium constant Keq_vh_shortcut using the van't Hoff shortcut, with two data source options (embedded NASA-9 database or caller-supplied reference). The name 'shortcut' distinguishes it from sibling calc_Keq, and the method is explicitly mentioned.
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 when to use the 'reference' source but does not provide explicit guidance on when to choose this tool over siblings like calc_Keq. No comparisons or alternatives are mentioned, so the agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate component entropy S_T using the embedded NASA-9 database by default, or caller-supplied reference_content when source='reference'.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Request for a single-component NASA property calculation. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only describes the computation and data sources, without stating whether the operation is read-only, safe, or has side effects. For a thermodynamic calculation tool, this omission leaves uncertainty about idempotency and permissions.
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 sentence that is front-loaded with the core action and efficiently conveys the primary purpose and key variation (default vs reference source). No extraneous words; every clause earns its place.
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 presence of an output schema (not shown but noted), the description does not need to detail return values. It covers the essential purpose and the two operational modes. However, it could be slightly more complete by mentioning preconditions (e.g., valid component data) or error scenarios, though this is not critical for basic 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 detailed parameter documentation. The description adds significant meaning by explaining the two data source modes and the condition when 'reference_content' is required, which goes beyond what the schema alone provides. This helps agents decide how to populate the source and reference_content parameters.
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 it calculates component entropy S_T, specifies the default embedded NASA-9 database, and mentions the alternative caller-supplied reference_content when source='reference'. This is a specific verb+resource combination that distinguishes it from sibling tools like calc_H_T or calc_G_T, which calculate different thermodynamic properties.
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 for entropy calculations and explains the two source modes (database vs reference), but it does not explicitly state when to choose this tool over its siblings (e.g., which property to compute) or provide when-not-to-use guidance. Comparatively, it lacks explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate pythermodb YAML reference content for use with pyThermoDB.
| Name | Required | Description | Default |
|---|---|---|---|
| yaml_content | Yes | The YAML content to be checked as a reference. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. The term 'validate' implies a non-destructive check, but it fails to state whether the tool modifies state, requires special permissions, or what side effects (if any) occur. The description is insufficiently transparent.
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 sentence with no wasted words. It efficiently conveys the core action and target resource, earning its place without 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?
Given the simple tool signature (one parameter) and the existence of an output schema (which likely describes the validation result), the description is minimally adequate. However, it does not explain what the output represents (e.g., success, errors) or how validation failures are communicated, leaving some ambiguity.
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 coverage is 100%, so the parameter is fully described in the schema. The description adds no additional meaning beyond the schema; it merely restates the tool's purpose. Per the rubric, baseline 3 applies when schema coverage is high, and the description does not contribute further.
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 uses the specific verb 'validate' and identifies the resource as 'pythermodb YAML reference content'. It clearly distinguishes this tool from its sibling calculation tools (all calc_*), making the purpose unmistakable.
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 its siblings or any alternatives. It does not state that validation should precede calculations or specify any prerequisites or exclusions.
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. Dates show when Glama detected each change.
v0.1.0calc_Cp_Tcalc_dG_rxn_STDcalc_dH_rxn_STDcalc_dS_rxn_STDcalc_G_Tcalc_H_Tcalc_Keqcalc_Keq_vh_shortcutcalc_S_Tcheck_yaml_referenceEach tool targets a distinct thermodynamic quantity (H, S, G, Cp, reaction changes, Keq), with clear naming and no overlap. The 'calc_' prefix immediately distinguishes calculation tools from the validation tool, and the specific property is uniquely identified in each name.
All calculation tools follow a perfect 'calc_[property]' pattern, with consistent underscore separation and standard thermodynamic abbreviations (H_T, S_T, G_T, Cp_T, dH_rxn_STD, etc.). The one validation tool uses 'check_' instead of 'calc_', which is appropriate and maintains the pattern.
10 tools is ideal for a thermodynamics calculation server. It covers the essential single-component properties, reaction thermodynamics, and equilibrium without being bloated. Each tool serves a distinct and necessary purpose, earning its place.
The tool set comprehensively covers NASA-9 polynomial applications: all four fundamental thermodynamic functions (H, S, G, Cp) for single components, their reaction analogues (dH, dS, dG), plus equilibrium constants. The inclusion of check_yaml_reference and calc_Keq_vh_shortcut shows thoughtful coverage for both standard and practical calculations. No obvious gaps exist for the stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for aerospace calculations: orbital mechanics, ephemeris, DSN operations, ...
Engineering calculation MCP server for oil and gas engineering applications.
Science MCP — free science data APIs
Materials MCP — computed (DFT) materials structures & thermodynamic properties.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sinagilassi/PyThermoCalcDB-NASA-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
