Skip to main content
Glama
Sign In
Mercury MCP Server

Mercury MCP Server

by seven0070
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

hermes_3d_visualize

Generate an embeddable 3D visualization iframe from processed data JSON to inspect an office scene.

Instructions

Generate a 3D visualization (iframe) from processed data

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": {
      "data": "<data>"
    },
    "name": "hermes_3d_visualize"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataYesProcessed data JSON (as returned by ghost_pepper_process)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations and no output schema, the description carries the full behavioral burden, yet it only hints that the result is an iframe. It does not disclose whether it returns HTML/URL, renders inline, writes a file, requires specific permissions, or has side effects.

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

Conciseness4/5

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

A single front-loaded sentence with no wasted words. It is efficient, though its brevity comes at the cost of the behavioral detail noted elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a nested object parameter, no annotations, and no output schema, the description is too thin. It does not explain the return value or rendering behavior, leaving the agent without enough context to invoke it confidently.

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?

There is one parameter with 100% schema description coverage, so the schema already documents it. The description adds marginal value by indicating the data should be 'processed' output, but gives no format or structural detail beyond what the schema and its note (ghost_pepper_process) provide.

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 verb+resource: generate a 3D visualization from processed data, and even names the output format (iframe). It does not explicitly differentiate itself from siblings like ghost_pepper_process, though 'from processed data' implies the pipeline order.

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?

There is no explicit when-to-use guidance or mention of alternatives. The phrase 'from processed data' weakly implies the prerequisite that data must first be processed, but nothing states when this tool should or should not be chosen.

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