Skip to main content
Glama
Yan-Vi

easy-spec-mcp

by Yan-Vi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

live_switch_tab

Pins a specific open tab to direct subsequent live automation commands to that tab. Omit the tab ID to revert to following the active browser tab.

Instructions

Pins a specific already-open tab (by id, see live_list_tabs) as the target for every other live_* call, same as picking it from the side panel's own "Target" menu. Omit tabId to go back to following whichever tab is actually active in the browser instead of a pinned one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tabIdNoOmit to unpin and follow the active tab instead
projectNoPath to the project root (same folder the side panel connects to). Defaults to the EASYSPEC_PROJECT environment variable if omitted.
sessionNoWhich connected side panel to target, by its connection id (see live_status) -- only needed when more than one side panel is connected to the same project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.4

TDQS

A4.7/5.0
Behavior4/5

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

Describes the side effect of changing the target for subsequent live_* calls, but does not mention return values or error scenarios; still adequately transparent given no annotations.

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?

Single, focused sentence that conveys the core behavior and the alternative usage without unnecessary verbosity.

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?

Provides sufficient context for the tool's role and relationships to sibling tools, with no apparent missing information given the lack of output schema.

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?

All parameters are covered in the schema with descriptions, and the tool description adds context on how tabId is used, slightly enhancing the schema's meaning.

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 the tool's function: pinning an already-open tab as the target for other live_* calls, and distinguishes from related tools like live_list_tabs and live_new_tab.

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 explains when to omit tabId to revert to following the active tab, and references live_list_tabs for obtaining tab IDs, providing actionable 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