SciMCP

by Nour-elhaq

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are largely distinct in function, but generate_input, generate_workflow, and shear_sweep all produce LAMMPS input scripts, and the three nematic tools share a prefix; descriptions clarify the differences, but a few pairs could be confused at first glance.
Naming Consistency3/5
All tools share the lammps_ prefix, but the suffix mixes verb_noun (generate_input, parse_thermo, identify_plastic_events) with noun phrases (file_summary, nematic_order, shear_sweep). The pattern is readable but not fully consistent.
Tool Count5/5
With 12 tools covering simulation setup, parsing, and analysis, the server is well-scoped and each tool serves a distinct phase of the LAMMPS workflow.
Completeness4/5
The workflow from input generation to trajectory parsing to specialized analysis (nematic order, plastic events, viscosity) is well covered. Minor gaps exist, such as no tool for modifying existing input files or computing other common structural properties, but the core lifecycle is complete.
Average 4/5 across 12 of 12 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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
This repository is licensed under MIT License.
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 explains the input format (quaternions per frame) but does not disclose how the nematic alignment is computed (e.g., averaging, normalization), any constraints (e.g., equal particle counts per frame), or the output structure. The behavior remains largely opaque.
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 concise and well-structured: a one-sentence summary, a clarifying note about frame contents, and an arg definition with an example. Every sentence contributes value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter, which is thoroughly explained in the description. The presence of an output schema removes the need to document return values. However, the description does not mention potential pitfalls (e.g., frame length consistency) or the physical meaning of S(t), so it is not fully complete for a user unfamiliar with nematic order parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a type and title with 0% schema description coverage, so the description must compensate. It does so effectively by explaining that 'quaternions_frames_json' is a 'JSON string — list of (N, 4) arrays, one per frame' and providing a concrete example. This adds meaningful context beyond the schema, though it could be more explicit about quaternion normalization.
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 states a specific action with a clear resource: 'Compute nematic alignment S(t) over a trajectory.' This distinguishes it as a time-dependent computation. However, it does not explicitly differentiate from sibling tools like lammps_nematic_order or lammps_nematic_vs_z, so it earns a 4 rather than a 5.
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. There is no mention of prerequisites, expected input preprocessing, or exclusions. Usage is only implied by the tool name and the description's focus on time-dependent trajectories.
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 not how the threshold is applied (e.g., particles with D²min above threshold are identified as plastic events). No side effects, output format, or edge-case behavior is disclosed.
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 extremely concise, with a one-sentence purpose statement and a clear 'Args' section listing the two parameters. Every word earns its place with no redundancy.
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?
The tool is simple with only two parameters and has an output schema, so the description doesn't need to detail return values. However, it lacks context about how this fits into a LAMMPS workflow (e.g., that it follows lammps_d2min) and what ‘plastic rearrangement’ means in practice, leaving minor 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?
The schema has no descriptions on its properties (0% coverage), and the description partially compensates by explaining d2min_json as 'JSON string with D²min values for each particle' and threshold as 'D²min threshold for plastic events.' The threshold explanation is somewhat tautological, but it does add meaning beyond the schema.
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 tool's purpose: 'Identify particles that underwent plastic rearrangement.' This is a specific verb+resource combination that distinguishes it from sibling tools like lammps_parse_dump or lammps_nematic_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the parameter d2min_json, suggesting it consumes output from a D²min calculation, but it does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It explains the meaning of S values and gives an example, but it does not state whether the operation is read-only, how invalid or non-normalized quaternions are handled, or the exact output format (though the output schema exists). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief purpose statement, a short explanation of the output meaning, and a parameter section with an example. Every sentence contributes valuable information, and there is no wasteful repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter compute tool with an output schema, the description is nearly complete. It covers the input format, example, and interpretation of the result. The main missing pieces are edge-case behavior and normalization requirements, but these are not critical given the simplicity and available schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists a parameter named quaternions_json with type string and no description. The description compensates fully by specifying the shape (N,4), the quaternion order [w,x,y,z], and providing a concrete example. This gives the agent exactly what it needs to construct a valid parameter value.
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 that the tool computes the scalar nematic order parameter S from quaternion data. The verb 'compute' and the specific resource 'scalar nematic order parameter' make the purpose unambiguous. Though it doesn't explicitly contrast with siblings like lammps_nematic_vs_z, the 'scalar' and 'from quaternion data' distinguish it sufficiently.
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 choose this tool over alternatives like lammps_nematic_vs_z or lammps_nematic_vs_time. It never mentions that this is for a single global order parameter versus spatially or temporally resolved ones, leaving the selection criteria entirely implicit.
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, the description bears the full burden of disclosing behavioral traits. It only says 'return time-series data' without explaining the exact output structure, how malformed files are handled, or whether data is sorted. This leaves significant ambiguity for an agent invoking the tool.
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 brief and front-loaded with the action verb. It lists example columns for added context, and the 'Args' section is a minor redundancy but not wasteful. Every sentence contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 present), the description covers the essential action and input. It could mention how the returned time-series data is structured or how it differs from dump parsing, but the output schema likely fills that role. Overall it is adequate for a focused parser tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description coverage, but the description compensates by defining 'filepath' as 'Path to the LAMMPS thermo output file.' This gives the agent clear meaning for the only parameter, though it lacks details like supporting wildcards or relative/absolute paths.
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 tool's function: parsing LAMMPS thermodynamic output and returning time-series data. It specifies the resource (log/thermo.dat files) and gives concrete column examples, distinguishing it from sibling tools like lammps_parse_dump which handles dump files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning the input file types, but it does not explicitly state when to prefer this tool over alternatives such as lammps_parse_dump or lammps_file_summary. There are no exclusions or prerequisite conditions 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the phases and optional shear but does not clarify whether the script is returned as a string or written to output_file, nor any side effects or requirements. The mention of output_file hints at file writing but leaves behavior unclear.
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 well-structured with a concise intro, a numbered phase list, and a clear parameter definition section. Despite listing 21 parameters, it remains readable and front-loads the core purpose without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the multi-phase workflow and all arguments, making it fairly complete for a complex generator. However, it does not explicitly explain the return value or file-writing behavior beyond output_file, and lacks tool-selection context. The existence of an output schema mitigates the return value gap, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates with a complete Args list that explains all 21 parameters in plain language. It adds conditional context such as 'if NPT' for production_pressure and '0 to skip' for n_minimize_steps, which goes far beyond the schema's type/default information.
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 opens with 'Generate a multi-step LAMMPS workflow (minimize → equilibrate → production)', clearly stating the verb and resource. The three-phase breakdown distinguishes it from sibling tools like lammps_generate_input, which likely handles simpler input generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for multi-step workflows with its phase list, but it does not explicitly state when to choose this tool over lammps_generate_input or other siblings. No exclusions or alternative recommendations are provided, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool identifies file type and returns summary statistics, making the read-only nature implicit. However, it does not mention behavior on invalid files, format limitations, or performance considerations, so transparency is adequate but not rich.
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 concise and front-loaded, with the first sentence stating the purpose. The second sentence adds useful detail about the returned statistics, and the Args section is minimal. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema and the existence of an output schema, the description is mostly complete. It covers the supported file types (dump or thermo) and the main statistics returned. It could be improved by clarifying when to choose this summary tool over the sibling parse tools, but overall it satisfies the main needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates with an Args section explaining that filepath is the path to the LAMMPS output file. This adds meaningful context beyond the bare 'filepath' property in the schema, though it does not detail accepted extensions or data formats.
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 uses a specific verb ('Get a summary') and resource ('LAMMPS output file (dump or thermo)'), and lists exactly what statistics it returns. It clearly distinguishes itself from sibling parse tools by focusing on summary rather than full parsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a summary of a LAMMPS output file is needed, but it does not explicitly compare this to the sibling parse tools (e.g., lammps_parse_thermo, lammps_parse_dump) or state when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 does mention the side effect of writing to a file when output_file is set ('write script to this file'), which implies it can also return the script as a string, but it does not elaborate on return behavior, validation, potential errors, or file overwriting. It adds some behavioral context about supported features but lacks depth on side effects and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured: a one-sentence summary at the top, followed by a parameter list. While the list is long (18 entries), each line is terse and adds necessary meaning given zero schema coverage. The overall length is justified by the tool's complexity, and the summary is front-loaded for quick orientation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's main capabilities (potentials, ensembles, optional minimization/shear) and all parameters. An output schema exists, so detailed return-value documentation is not required. However, it does not fully address parameter interdependencies or edge cases (e.g., pressure with non-NPT/NPH ensembles), and there is no mention of required auxiliary files or runtime behavior. Still, it is reasonably complete for a complex generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does so thoroughly with an Args list covering all 18 parameters. Each parameter has a meaningful description (e.g., 'Lattice constant in Angstroms', 'Target pressure (for NPT/NPH)') that goes well beyond the raw schema, which only provides parameter names and defaults. This fully bridges the schema coverage gap.
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 opens with 'Generate a complete LAMMPS input script for molecular dynamics simulation', which is a specific verb+resource pair. It further distinguishes the tool from siblings by enumerating supported potentials, ensembles, and optional features like minimization and shear deformation, making it clear this is the input-generation tool, not a parser or workflow orchestrator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for creating LAMMPS input files, but it provides no explicit guidance on when to choose this tool over alternatives like lammps_generate_workflow. There are no usage exclusions or comparisons with sibling tools, though the parameter details hint at typical molecular dynamics simulation use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It mentions that the tool reads files and extracts specific data, but does not disclose potential side effects (e.g., file access patterns, input format limitations, or error behavior). This is minimal but not inadequate.
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 concise and well-structured, starting with a one-sentence summary followed by a details paragraph and clean Args listing. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description adequately covers the operation and parameters. It could mention limitations or performance considerations for large files, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (filepath and max_frames) are fully described in the docstring, including the special meaning of max_frames=0. Since schema description coverage is 0%, this is essential and well-handled.
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 tool parses LAMMPS dump files and returns trajectory frame summaries, with a specific verb and resource. This distinguishes it from sibling tools like lammps_parse_thermo, which handles thermo output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through 'Reads lammpstrj files' and the description of extracting atom positions and box dimensions, but there is no explicit statement about when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must cover behavioral transparency on its own. It describes the computation's purpose and output interpretation (D²min deviation from affine deformation), which conveys that this is a read-only analysis operation. It does not discuss error handling or input validation, but the 'Compute' framing and scientific context make the behavior reasonably clear.
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 concise and well-structured, leading with the core purpose, then providing one-sentence background on D²min, and ending with a clear Args list. Every sentence adds value, and the line breaks make it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key context: what the tool computes, what the result means, and what all three parameters represent. Since an output schema exists, the description does not need to enumerate return values. It lacks explicit usage alternatives and edge-case guidance, but for a straightforward compute tool, the provided information is sufficient for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It explicitly explains that positions are JSON strings with shape (N, 3) and describes r_cut as 'cutoff radius for neighbor finding,' adding meaning beyond the bare input schema. It omits units for r_cut and does not mention coordinate frame assumptions, but the core semantics are present.
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 opens with a specific verb 'Compute' and identifies the exact resource: 'non-affine displacement D²min for each particle between two frames.' It explains the physical meaning of D²min, clearly distinguishing this tool from sibling analysis tools like lammps_nematic_order or lammps_parse_dump.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is useful for identifying plastic events ('High D²min = plastic event'), which gives contextual guidance. However, it does not explicitly state when to use this tool versus alternatives such as lammps_identify_plastic_events, nor does it mention any exclusions or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states that it creates one input script per shear rate and mentions output_dir for writing scripts, but does not disclose potential side effects like file overwriting, directory creation, or preconditions (e.g., requiring LAMMPS or potential files). This is a generation tool, but the description stops short of revealing all behavioral traits.
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 front-loaded with a clear one-sentence purpose, followed by a brief elaboration and a complete parameter list. Every sentence serves a purpose—no fluff or repetition of schema defaults. The structure is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, but an output schema exists), the description covers the core purpose, parameter semantics, and basic output behavior. It lacks details on directory structure or script contents, but these are not strictly necessary given the output schema and clear purpose. The description is well-rounded and sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description's Args list is the only semantic source. It provides meaningful explanations for all 9 parameters (e.g., shear_rates as 'JSON array of shear rates to simulate', shear_direction with valid planes). While some descriptions are terse (e.g., 'potential' without allowed values), they do add value beyond the schema's bare property names.
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 tool's function: 'Generate LAMMPS input scripts for a shear-rate sweep.' It then elaborates on creating one script per shear rate to study rheology, distinguishing it from sibling tools like generic input generation. This is a specific verb+resource+scope, fully differentiating it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear, and the description implies use for shear-rate sweep studies. However, it does not explicitly contrast with alternatives (e.g., lammps_generate_input for single simulations) or provide when-not-to-use guidance. The context is clear but lacks exclusionary details, matching 'clear context, no exclusions.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the power-law fitting model, defines the meaning of n (Newtonian, shear-thinning, shear-thickening), and clearly specifies the input data. It does not disclose the exact return format or fitting algorithm, but for a pure computation tool with no side effects, this is adequate 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 concise and front-loaded: the first sentence states the purpose, followed by an optional model explanation, and then parameter definitions. Every sentence contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 string parameters, no nested objects, output schema present), the description adequately covers purpose, model, and parameter semantics. It does not describe return values, but the presence of an output schema means the description need not explain them. It also does not mention edge cases (e.g., equal array lengths, numeric formats), but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names and types (string) with no descriptions, so the description fully compensates. It explicitly defines shear_rates_json as a JSON array of shear rates and shear_stresses_json as a JSON array of corresponding shear stresses, adding meaning beyond the structured schema.
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 tool estimates viscosity from shear rate vs shear stress data. It uses a specific verb ('estimate') and resource ('viscosity from shear rate vs shear stress data'), and distinguishes itself from sibling tools like lammps_parse_thermo or lammps_shear_sweep by its unique modeling focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool—when you have shear rate and shear stress data and need to fit a power-law model. It does not explicitly name alternatives or exclusions, but the niche purpose and model explanation imply its usage. Given sibling tools are primarily parsing/generation tools, the intended scenario is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries the full burden. It discloses the algorithmic behavior ('bins particles by z-coordinate and computes S in each bin') and clearly signals a pure compute operation. It does not explicitly state absence of side effects, but the verb 'compute' and the context make this reasonably transparent.
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 concise and front-loaded with the main purpose. The Args section is structured and each entry provides essential information without unnecessary verbosity. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate complexity (3 params, JSON parsing) and an output schema is present. The description covers the algorithm, the parameter formats, and the use case. No major gaps remain; return values are handled by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates. It explains the exact shape of both JSON strings ('shape (N, 4) quaternion data' and 'shape (N,) z-coordinates') and clarifies n_bins. This adds significant meaning beyond the raw schema types.
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?
Description explicitly states 'Compute nematic alignment profile S(z) along the z-axis' with a specific verb, resource (S(z)), and scope. It distinguishes itself from siblings like lammps_nematic_vs_time and lammps_nematic_order by specifying spatial binning along z.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context with 'useful for studying alignment near surfaces or interfaces,' implying when to use it. However, it does not explicitly mention alternatives or exclusion criteria, so it misses a direct when-not or comparison to sibling tools.
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:

[![scimcp MCP server](https://glama.ai/mcp/servers/Nour-elhaq/scimcp/badges/card.svg)](https://glama.ai/mcp/servers/Nour-elhaq/scimcp)

Score Badge

Copy to your README.md:

[![scimcp MCP server](https://glama.ai/mcp/servers/Nour-elhaq/scimcp/badges/score.svg)](https://glama.ai/mcp/servers/Nour-elhaq/scimcp)

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/Nour-elhaq/scimcp'

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