Vayu Breathing

Get a wind-down routine for better sleep

get_sleep_routine

Read-onlyIdempotent

Return an evening wind-down routine for better sleep, built around Vayu's Bedtime calm practice, and show that practice in a timer: settling prompts, then breathing in for 4 and out for 8. The routine covers a steady wake time, caffeine and alcohol, the last hour before bed, what to do if awake for more than about 20 minutes, a morning check-in, and when to talk to a doctor. Use it when the user wants to sleep better, fall asleep more easily, get back to sleep after waking, or wind down for bed. General wellness guidance, not medical treatment or a diagnosis. Nothing is saved.

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": "get_sleep_routine"
  }
}

Input Schema

Name	Required	Description	Default
`bedtime`	No	The user's usual bedtime in 24-hour HH:MM, e.g. 22:30, if they gave one. Used only to put clock times on the routine.
`minutes`	No	Length of the bedtime breathing in minutes. Defaults to 5.
`trouble`	No	The main sleep trouble, if the user said. falling_asleep: takes a long time to fall asleep. racing_mind: can't switch off at night. waking_at_night: wakes up during the night. early_waking: wakes too early. general: wants better sleep overall. Defaults to general.	general

Output Schema

Name	Required	Description	Default
`steps`	Yes
`bedtime`	Yes
`trouble`	Yes
`practice`	Yes
`seeADoctor`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description adds real context beyond them: "Nothing is saved" makes the no-persistence behavior explicit, the timer content (settling prompts, 4-in/8-out breathing) previews what the agent will surface, and the wellness-vs-medical disclaimer tells the agent how to frame the output. This is disclosure that the annotations alone do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Core purpose and the embedded timer are front-loaded in the first sentence, and usage triggers follow. The middle inventory of routine topics is a long list but each item earns its place by telling the agent what the returned routine contains. Minor verbosity only.

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?

A read-only generator with an output schema and fully described parameters has little remaining burden, and the description still covers purpose, when to use, what the return will contain, persistence behavior, and the medical boundary. Nothing an agent needs in order to call this correctly is missing.

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 description coverage is 100% and all three parameters are self-documenting, including enum meanings, so the baseline applies. The description slightly reinforces the breathing-length parameter by describing the 4-in/8-out pattern, but never explains how `trouble` changes the routine or how `bedtime` interacts with `minutes`. Marginal value over the schema.

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?

States a specific verb and resource ("Return an evening wind-down routine for better sleep") plus the concrete contents (wake time, caffeine/alcohol, last hour before bed, 20-minute rule, morning check-in, doctor guidance) and notes it embeds the Bedtime calm practice as a timer. That makes it distinguishable from a plain breathing plan or session tool. It stops short of naming a sibling, so the differentiation is inferred from content rather than stated.

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?

Explicit when-to-use triggers are given: wants to sleep better, fall asleep more easily, get back to sleep after waking, or wind down for bed. It also sets a scope boundary ("General wellness guidance, not medical treatment or a diagnosis"). No exclusions or named alternatives are offered, so 4 rather than 5.

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

All Vayu Breathing tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?