Skip to main content
Glama
virwave

virwave-breathe

Official
by virwave
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Start a matched session

start_session

Match a breathing session to your current feeling, desired state, and available time. Generates a self-contained HTML page that opens in your browser and guides you through hold-free breathing.

Instructions

Matches a VirWave session the way the app's entry flow does: how clearly a feeling is coming through, what they'd like instead, and how long they have. The session moves through stages (arrive, the matched core, close), each with its own shape, at one steady breath pace, and ends at the chosen length. Saves a self-contained HTML page on this computer that waits for Begin, and returns its path, why it was picked, and the stages. Unless out_dir is given, the page also opens in the person's default browser (they can turn that off in settings). Every matched session is hold-free: breathe in, a longer breath out.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYesWhat they'd like instead. grounded (Grounded: Back in the body, contact restored.) calm (Calm: Slower, softer, less pressure.) clear (Clear: One thing at a time, in focus.) unstuck (Unstuck: The loop loosens and moves on.) settled (Settled: Steady enough to rest.)
feelingYesHow the feeling is coming through: how clearly, not which feeling it is. The options describe how clear the signal is, and none of them names an emotion. flat (Flat / no signal: Numb, far off, nothing registers.) faint (Faint trace: Something is there but not describable.) nameable (Nameable: A word fits, with hedging.) directional (Directional: It points at something specific.) insistent (Insistent: Hard to set aside, keeps returning.) saturating (Saturating: Too much at once, loud and fast.)
minutesYesHow long they have: 2, 5, 10, or 15 minutes. Longer sessions move through more stages, not just more time.
out_dirNoDirectory to write the page into, for a client that shows the page itself (for example, by publishing it as an Artifact). When set, the page is not opened in the browser. When left out, the page is saved to the person's chosen folder (by default a VirWave Breathe folder in the system temp directory) and opened in their browser.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior5/5

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

With annotations only providing false hints, the description carries the full behavioral burden and does so well. It discloses that the tool saves an HTML file on the computer, waits for Begin, returns the path and stages, opens the browser unless out_dir is set, and follows a hold-free breath pattern. This gives the agent a clear picture of side effects and runtime behavior.

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?

The description is front-loaded with the core purpose and every sentence carries useful information: stages, output, file/browser behavior, out_dir exception, and breathing pattern. It is relatively long, but the tool has real behavioral complexity, and none of the sentences are wasted.

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?

The description covers inputs, the stage progression, the saved file side effect, browser behavior, the out_dir alternative, and the return content. There is no output schema, so the brief mention of 'why it was picked' is somewhat vague, but overall the agent has enough to invoke the tool and understand what will happen.

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 the schema already provides rich descriptions for all parameters, including enums. The description maps the main inputs to the app's entry flow but does not add meaning beyond the schema; out_dir is also already described in the schema, so the description is consistent but not additive. Baseline 3 is appropriate.

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 clearly states the tool's job with a specific verb and resource: it matches a VirWave session the way the app's entry flow does, using feeling, goal, and length. It is immediately understandable and distinct from list_patterns, but it does not explicitly contrast itself with the sibling 'breathe', so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives good context: this is for a matched session with a feeling, a desired alternative, and a duration, and it explains the out_dir conditional behavior. However, it never explicitly says when to prefer this over the sibling 'breathe' or when not to use it, so usage guidance is mostly implied rather than stated.

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