Skip to main content
Glama
ExQA
by ExQA

mock_route_setup

Set up a Map Remote rule in Charles Proxy to route a host or domain glob to a local dispatcher, enabling mock traffic while letting unmocked requests pass through unchanged.

Instructions

Send a host (or domain glob) through the dispatcher; once per host/domain. One Charles Map Remote mapping (https:// -> local dispatcher, empty destination path, preserve host header) covers every path and action under it; after that, mocks are only data. Unmocked requests pass through unchanged. apply=true writes the mapping into the Charles config; only while Charles is closed, because Charles overwrites its config from memory on quit. This tool never quits or starts Charles: ask the user to save the session and quit Charles, not to reopen it until the write is done, then to start it. apply=false returns manual steps that work in the UI without a restart.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostYesHostname or domain glob. Use a glob such as *.example.com when the same API runs on several hosts (dev, stage, ...).
pathNoPath pattern: /* for every path, /api/* for a prefix, or one path./*
portNo
applyNo
verify_tlsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostYes
pathYes
appliedNo
warningsNo
route_fileYes
config_pathNo
instructionsNo
config_backupNo
mapping_addedNo
map_remote_ruleYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/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 behavioral burden and does so thoroughly: it discloses config mutation, the Charles overwrite-on-quit risk, that this tool never quits or starts Charles, and that unmocked requests pass through unchanged. This gives an agent the critical side-effect and safety context needed before 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?

Every sentence earns its place: the mapping mechanism, pass-through behavior, config-write caveat, and exact user workflow are all essential. The most critical warning about Charles being closed is front-loaded, and there is no filler or redundant restatement.

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 tool with a user-interaction workflow and config mutation, the description covers the prerequisites, apply modes, and pass-through behavior well. The missing port/verify_tls semantics and lack of explicit sibling differentiation are the main gaps, but the core workflow is fully described and an output schema exists.

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

Parameters2/5

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

Host and path are already documented in the schema, and the description adds useful routing semantics for them. However, port and verify_tls have no schema descriptions and are never mentioned in the description, so with only 40% schema coverage a significant parameter-meaning gap remains.

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 clear operation: send a host/domain glob through the dispatcherorphan via a Charles Map Remote mapping, covering every path and action under that host. The 'once per host/domain' scope makes the resource and purpose specific, though it does not explicitly distinguish itself from the similarly named sibling mock_setup_host.

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?

It gives strong operational guidance: use apply=true only while Charles is closed, ask the user to save and quit, and avoid reopening Charles until the write completes. It also explains that apply=false provides manual UI steps without a restart, but it does not explicitly name when to prefer this tool over related siblings.

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