Calm, animated breathing sessions paced to your breath. Runs locally and collects nothing.
Scored across 3 tools
list_patterns is clearly a catalog tool, but breathe and start_session both produce breathing sessions. Their descriptions carve out distinct triggers—generic 'breathing break' requests versus feeling-based session matching—though a request like 'help me relax with a breathing exercise' could plausibly hit either.
list_patterns and start_session follow a consistent verb_noun pattern, but breathe is a bare verb that breaks the convention. It is still clear and readable, and the mixed style is minor.
Three tools is a compact but reasonable surface for a domain that only needs pattern discovery, a default session, and a matched session. It does not feel padded, though it is close to the thin end.
The server covers discovery and session generation well, but there is no explicit way to request a specific named pattern from the catalog for immediate playback. Users can see patterns like Box Breathing exist but cannot directly start that exact session.
Creates an animated VirWave breathing session the person can follow with their eyes. Invoke it when someone asks for a breathing break, a breathing exercise, guided breathing, or a moment to calm down, relax, or reset: the visual session is the breathing break. In a client that supports MCP Apps (Claude on the web and in the desktop app, for example), the session appears in the chat itself. The result also carries a link to the same session as a web page, for any client that cannot draw it there. Either way the session opens at rest and starts when the person presses Begin, so nothing moves without their say-so. With no inputs, it plays the default Circle 4-8 Breathing session, which has no breath holds.
| Name | Required | Description | Default |
|---|---|---|---|
| shape | No | Shape to draw. Each pattern lists the shapes it can use; defaults to the pattern's first. box: A square whose outline draws itself once per breath cycle. triangle: A triangle whose outline draws itself once per breath cycle. circle: A ring that draws itself once per breath cycle, with no corners to turn. focus-point: A calm point drifting slowly across the field. infinity: A continuous figure-eight with no start or end. ripple: Rings spreading out from a point of contact. color-field: Slow colour folding into itself. | |
| cycles | No | Exact number of breath cycles. Takes precedence over minutes. | |
| minutes | No | Approximate session length; rounded to whole breath cycles. | |
| pattern | No | Pattern id from list_patterns. Defaults to in-out-extended-exhale. list_patterns marks each hold-free pattern with "holdFree": true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and provide little context, so the description carries the behavioral burden. It explains client support (MCP Apps vs web-page link), that the session opens at rest and waits for the person to press Begin, and that the default session has no breath holds. This is meaningful behavioral disclosure beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and trigger, followed by useful behavioral context. It is a few sentences long, but each sentence contributes meaningful information about when and how the session behaves.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers intended use, default behavior, client rendering, and user control, while the schema covers parameters. There is no output schema, but the description at least notes the result carries a web link. It could be more explicit about the result shape and about sibling tool relationships.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all four parameters with detailed descriptions, so the baseline is 3. The description adds the no-input default behavior but does not explain parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates an animated VirWave breathing session the person can follow with their eyes,' which clearly names the verb, resource, and effect. It is clearly a session-creation tool, though it does not explicitly contrast with siblings like start_session or list_patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger list: 'Invoke it when someone asks for a breathing break, a breathing exercise, guided breathing, or a moment to calm down, relax, or reset.' This is strong when-to-use guidance, but it does not state when not to use it or how to choose between this and start_session/list_patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the VirWave breathing patterns this server can play: phases and seconds, what each rhythm is good for, which shapes can draw it, whether it is hold-free, and any safety note about breath holds. Hold-free patterns are listed first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, and the description adds useful behavioral details beyond that: result ordering ('Hold-free patterns are listed first'), the scope ('this server can play'), and included safety notes about breath holds. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and resource, then adds a compact enumeration of the returned fields and the ordering guarantee. Every clause earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully covers what the agent should expect: phases, seconds, purpose, shapes, hold-free status, and safety notes. The ordering behavior is also disclosed, making the tool self-contained for a parameterless read-only call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is nothing semantic to document. The baseline of 4 applies because there is no parameter ambiguity for an agent to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists') and resource ('VirWave breathing patterns this server can play'), then enumerates the details returned. This clearly differentiates it from the action-oriented siblings breathe and start_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this is the tool for discovering available patterns and what they are good for, which implies use before or without starting a session. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Invoke it when someone says how they are feeling, or what they would like to feel instead, and wants a breathing session that fits. 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. In a client that supports MCP Apps (Claude on the web and in the desktop app, for example), the session appears in the chat itself. The result also carries a link to the same session as a web page, for any client that cannot draw it there. Either way the session waits for Begin, and the result says why it was picked and which stages it has. Every matched session is hold-free: breathe in, a longer breath out.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What 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.) | |
| feeling | Yes | How 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.) | |
| minutes | Yes | How long they have: 2, 5, 10, or 15 minutes. Longer sessions move through more stages, not just more time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing minimal behavioral info. The description compensates richly: the session waits for Begin, the result explains why it was picked and which stages it has, it may appear in chat or via a web link, the session moves through named stages, and the breathing pattern is hold-free. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every sentence carries useful information, especially given the lack of an output schema. It is front-loaded with purpose and trigger, then covers behavior and result. It could be tightened slightly but is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description is thorough: it explains when to invoke, what happens during the session, what the result contains, client-specific rendering, and the breathing style. There are no obvious missing pieces an agent would need to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed enum descriptions, so baseline is 3. The description adds a meaningful nuance for minutes: 'Longer sessions move through more stages, not just more time,' which goes beyond the schema. It also restates the three inputs coherently without adding conflicting syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific: it states the verb 'Matches', the resource 'VirWave session', and exactly how the matching works (feeling clarity, desired alternative, length). It also distinguishes this from siblings by targeting the app's entry flow, which is clearly separate from simple breathing (breathe) or pattern lookup (list_patterns).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit trigger: 'Invoke it when someone says how they are feeling, or what they would like to feel instead, and wants a breathing session that fits.' This is clear and actionable context, though it does not explicitly name sibling tools or state when not to use them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
breathelist_patternsstart_sessionA free one-minute reset for people, delivered by AI, with no account or personal data.
The adaptive health-messaging engine for apps and agents. Federally-sourced. Not medical advice.
Track, curate, and analyze data about your health, habits, and goals.
Brain dump, routines, task planning, focus, and instant thought retrieval
Add one secure layer between your agents and this server.
