Skip to main content
Glama
jonathan6620

PyMOL-MCP

by jonathan6620
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Server Quality Checklist

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

  • Latest release: v0.1.0

  • Disambiguation5/5

    Each tool serves a distinct purpose: list_commands provides command syntax, list_instances shows running instances, and parse_and_execute executes commands. There is no overlap.

    Naming Consistency5/5

    All tool names use lowercase snake_case with a verb_noun pattern (list_commands, list_instances, parse_and_execute). The naming is consistent and predictable.

    Tool Count5/5

    With 3 tools, the set is well-scoped for the server's purpose—providing help, instance information, and command execution. No unnecessary tools.

    Completeness4/5

    The tool surface covers the core workflow of querying syntax, checking instances, and executing commands. A minor gap is the lack of a direct way to get the current state or result of previous commands, but agents can work around this.

  • Average 4.6/5 across 3 of 3 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 68 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

  • Behavior3/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, so the description bears full responsibility. It explains that each PyMOL claims its own port and that loaded object names distinguish windows, implying a read-only operation. However, it does not explicitly confirm read-only behavior or mention any safety aspects.

    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 three sentences long, begins with the primary purpose, and efficiently conveys key usage details. Every sentence adds value without redundancy.

    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?

    Given the absence of parameters and the presence of an output schema, the description comprehensively covers purpose, usage context, and relationship to sibling tools. It explains how to interpret the results (loaded object names vs. port numbers) and when to use this 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 tool has no parameters, and the description does not need to explain them. It adds context about the returned information (port numbers and loaded object names), which is helpful for understanding the output. Baseline for 0 parameters is 4.

    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 lists running PyMOL instances and their loaded objects. It distinguishes itself from sibling tools 'list_commands' and 'parse_and_execute' by specifying its unique output and usage context.

    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 explicitly indicates when to use the tool (when a command reports ambiguity or the user refers to a particular window) and references the alternative 'parse_and_execute' for driving a specific instance. However, it does not explicitly state 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?

    Describes output differences with/without filter: without filter returns one-line descriptions, with filter returns full detail (regex, params). No annotations, so description must stand alone; it adequately discloses behavior.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    Three concise sentences: purpose, behavior clarification, and examples. No redundant information, well-organized.

    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?

    Complete for a documentation tool with one optional parameter. Output schema exists for return details. Covers what tool does, parameter usage, and use case. No missing critical information.

    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 only provides name and default; description adds that filter is a substring match against names and descriptions, and its presence triggers detailed output. Fully clarifies parameter meaning and effect.

    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?

    Clearly states it lists PyMOL commands accepted by parse_and_execute, with distinct behaviors for with/without filter. Distinguishes from sibling tools list_instances and parse_and_execute.

    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?

    Explicitly explains when to use filter (for full detail on matches) vs without (list all). Suggests use case: 'confirm syntax before calling parse_and_execute'. Lacks explicit when-not-to-use alternatives.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior5/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations provided, so description carries full burden. It explains user_input is matched against fixed pattern table, behavior for instance parameter (default null, error if multiple instances), common mistakes, selection syntax, and return value (PyMOL output or failure message).

    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 relatively long but all sections (purpose, guidelines, examples, parameter details) are relevant. Slightly verbose but well-structured with front-loaded purpose.

    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?

    Given the complexity of PyMOL command execution, the description covers purpose, usage guidelines, parameter details, common pitfalls, examples, and return value. The output schema exists, so return values are adequately handled.

    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 coverage is 0% (no descriptions), but the description provides full semantics: user_input is a PyMOL command string, instance is the port with default null and clear behavior explanation. Adds significant value 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 states it executes a single PyMOL command in literal PyMOL syntax, not natural language, clearly distinguishing from sibling tools list_commands and list_instances.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines5/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    Explicitly tells when to use (single PyMOL command) and when not (multiple commands, natural language, incorrect syntax). Provides examples of common mistakes and directs to list_commands for syntax and list_instances for instance selection.

    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

PyMOL-MCP MCP server — quality and maintenance score on Glama

Copy to your README.md:

Score Badge

PyMOL-MCP MCP server — quality and maintenance score on Glama

Copy to your README.md:

shields.io Endpoint

PyMOL-MCP MCP server — quality and maintenance score on Glama

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

Latest Blog Posts

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/jonathan6620/pymol-mcp'

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