Skip to main content
Glama
Sign In

Shipvo

by io.github.shipvo
OverviewDiscussionsAdmin

attach_session

Attach to the phone of a live shipvo run in this project (read from .shipvo/run.json) and return its screen. The person sees every action in their browser. Same as open_app with attach: 'always', without needing the app id.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

NameRequiredDescriptionDefault
appNoApp id; default: the app of the live run
sessionNoSession name (default: generated)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Adds real behaviour beyond the annotations: it reads state from .shipvo/run.json, surfaces the device screen, and — importantly — warns that the person observes every action in their browser, which affects how cautiously the agent should act. Annotations only say non-read-only, non-destructive; the description supplies the supervision context. Failure behaviour when no run is live is not disclosed.

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?

Two tight sentences, front-loaded with the action and target, then the visibility caveat, then the sibling equivalence. No filler.

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 two-optional-parameter session tool with no output schema, the description covers the source of truth for the run, the return (screen), and the user-visibility implication. It leaves out error handling (no live run) and session lifecycle (whether end_session is expected), which are relevant given the listed siblings.

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 coverage is 100% and both optional parameters are documented in the schema ('default: the app of the live run', 'Session name (default: generated)'). The description's 'without needing the app id' reinforces why `app` is optional but adds no syntax or constraint beyond the schema, so baseline 3 applies.

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 (attach) and resource (the phone of a live `shipvo run`), plus the immediate outcome (return its screen). It explicitly positions itself against a sibling by saying it is 'Same as open_app with attach: "always", without needing the app id', so an agent can distinguish the two without opening either schema.

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?

Clear precondition (a live run in this project) and a named equivalent (open_app with attach:'always') that tells the agent when this is the preferred shortcut. It does not say what to do when no live run exists, so the negative case is left implicit.

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

All Shipvo toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources