Skip to main content
Glama
Sign In
GuangminJu

mellos-mapping

by GuangminJu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Open the map pane

mmap_open

For automatic display beside the current ChatGPT desktop conversation in Codex mode, use surface: "web-terminal", then call open_in_codex with the returned browser hostOpen object. No paste or Computer Use is needed.

Instructions

For automatic display beside the current ChatGPT desktop conversation in Codex mode, use surface: "web-terminal", then call open_in_codex with the returned browser hostOpen object. No paste or Computer Use is needed. For the native host terminal, use surface: "codex-terminal": prepare absolute watcher commands for the current project, then ask the host to open its right terminal. This does not launch the watcher or type into that terminal. Agent exec PTYs cannot be attached using their numeric session ids. For a document panel, use surface: "markdown": generate MD + SVG files, enable automatic preview updates after successful map writes, then use the HOST file-opening tool to display the returned absolute Markdown path on the right of the current conversation. Generated does not mean visible: this server cannot open or observe the desktop side panel. For interactive maps, choose surface: "web": start or reuse a project-local web viewer and pass the returned URL to the host browser-opening tool. Markdown and terminal remain available. The default surface is "terminal", preserving the terminal workflow. Put the live map on the user's screen: a terminal pane beside this conversation that redraws on every write. Call it whenever a result says pane: CLOSED — and do NOT ask permission first, because a user who has set a mapping policy has already said they want to see the map. With a pane already open this RETARGETS it to page instead of opening a second one, so it is also how you show the user a particular page when they ask for one. It never closes a pane: taking the map off the screen belongs to the user (the q key in the pane, or typing mmap in a terminal). The reply says whether a pane actually reported itself in afterwards, not merely that a command was run. Automatic terminal opening supports Windows Terminal, tmux on Linux/macOS, and Pebrel, which splits the conversation's own pane. omp (Oh My Pi) has no side panel of its own: there the routes are this same terminal pane (a Windows Terminal split, or a tmux split on Linux/macOS) and the web viewer, whose URL the session opens with its own browser tool. If opening fails, relay the reason and copyable command; retry only after the environment changes or the user asks.

Input Schema

NameRequiredDescriptionDefault
pageNopage to show first — the page THIS effort lives on, the same slug you pass to the other tools. Omit only for the default page: without it a fresh pane opens on whichever page was written last, which after a gap is rarely the one under discussion.
windowNoopen the map in its own "mellos-mapping" window (a new tmux window on Linux/macOS) instead of splitting this conversation's window. Pass it only when the user asked for the map separate (a second monitor, a small screen); the split is the default because the map is meant to sit beside what it describes.
surfaceNoweb-terminal = automatically started mmap terminal in a local browser page; codex-terminal = prepare a command for the desktop host terminal; web = local browser viewer; markdown = MD/SVG; terminal = Windows Terminal, tmux or Pebrel launcher (default)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.28.0
    • changedInput schema / properties / surface / description
      Previous value: -"web-terminal = automatically started mmap terminal in a local browser page; codex-terminal = prepare a command for the desktop host terminal; web = local browser viewer; markdown = MD/SVG; terminal = Windows Terminal or tmux launcher (default)"New value: +"web-terminal = automatically started mmap terminal in a local browser page; codex-terminal = prepare a command for the desktop host terminal; web = local browser viewer; markdown = MD/SVG; terminal = Windows Terminal, tmux or Pebrel launcher (default)"
  2. Addedv0.26.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses that an open pane is RETARGETED rather than duplicated, that it never closes a pane (closing belongs to the user), that the reply reports whether a pane actually reported in rather than just running a command, and that opening failure yields a reason plus copyable command. It also names supported hosts (Windows Terminal, tmux, Pebrel, omp) and their constraints.

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

Conciseness2/5

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

Roughly 350 words of dense prose split across surface workflows, and the central purpose (put the map pane on screen) is not front-loaded — the opening sentence dives straight into web-terminal wiring. The content is mostly substantive, but the size and ordering make it hard to extract the primary action quickly.

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?

Without an output schema or annotations, the description compensates by describing return semantics (whether a pane reported in), failure handling, and host-specific behavior. It is close to complete for a launcher tool; only minor ambiguity about exact reply contents remains.

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 100% and the enum values are already documented in the schema, so the baseline is 3. The description adds workflow context for choosing a surface (e.g. web-terminal requires a follow-up open_in_codex call) and ties `page` to the retargeting behavior, but much of the surface explanation overlaps the schema's own enum descriptions.

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 and resource — "Put the live map on the user's screen: a terminal pane beside this conversation that redraws on every write" — which is clear and actionable. However, this core purpose is buried behind surface-routing details, and no sibling tool (e.g. mmap_view) is named for contrast, so differentiation is left to inference.

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?

Explicit triggers and alternatives: call it whenever a result says `pane: CLOSED`, don't ask permission first, use window only when the user wants the map separate, and route to web/markdown/codex-terminal surfaces under named conditions. It also specifies retry behavior ("retry only after the environment changes or the user asks"). The when-to-use, when-not, and alternative paths are all spelled out.

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