Skip to main content
Glama
Sign In
MolTalk

MolTalk

by DomFico
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Draw Named Molecule

draw_named_molecule
Read-onlyIdempotent

Resolve a molecule name such as "cubane" or "FAD" and render its structure inline in one call, using a bundled library, OPSIN, or an optional PubChem lookup.

Instructions

Resolve a molecule name and render the resulting structure inline, in one call (for requests such as "draw cubane" or "show me FAD"). Resolution is the same as resolve_name: MolTalk's bundled library, then OPSIN for systematic names, with an optional PubChem lookup when allow_network=true. Ambiguous or unknown names, and names that do not say which stereoisomer, return an error without drawing a structure. A successful result (rendered: true) is already on screen. numbering and hydrogens are as in draw_molecule.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "draw_named_molecule"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
hydrogensNo
numberingNonone
allow_networkNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds real value beyond them by disclosing the resolution chain (bundled library, then OPSIN, then optional PubChem) and tying PubChem to allow_network, which explains the openWorldHint. It also discloses failure behavior — ambiguous, unknown, or stereo-unspecified names error with no structure drawn — which an agent needs to interpret an error rather than retry blindly.

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?

Four tight sentences, front-loaded with the action and followed by examples, resolution path, failure modes, and success signal — each sentence adds distinct information with no restatement of the name or title.

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?

With no output schema, the description does well to say that rendered:true means the structure is already on screen. But for a tool with a network-enabled fallback and three non-trivial options, the undefined hydrogens/numbering values and the absent note on what a failed render returns leave gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden: it does explain allow_network (PubChem lookup) and constrains name semantics (must be unambiguous and stereo-specific). However, hydrogens and numbering are handled only by deferring to draw_molecule, which leaves an agent without meaning for those two params unless it reads the sibling.

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?

States a specific verb and resource ("Resolve a molecule name and render the resulting structure inline, in one call") and implicitly distinguishes itself from draw_molecule (which takes a structure) and resolve_name (which doesn't render). The example phrasings ("draw cubane", "show me FAD") make the input shape immediately concrete.

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?

Gives clear triggering context via example user requests and points to resolve_name for the resolution semantics, so the agent knows this is the one-shot name-to-picture path. It does not explicitly state the inverse condition (use draw_molecule when you already have a SMILES/structure), so it stops short of full when/when-not guidance.

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

Deploy Server

Other Tools