Sissoo

Search Sissoo sessions

search_services

Read-onlyIdempotent

Finds bookable holistic and wellbeing sessions on Sissoo (sissoo.com), from reiki, massage and yoga to coaching, counselling and psychotherapy, online or in person, in several languages. Matches a short description of what the person is looking for, with optional place, format, session language, timing, budget and stage (new to it, or going deeper). Returns up to 8 sessions with price (booking fee included), next free time and a link to the service page with that date picked. Read-only: booking and payment happen on sissoo.com. Not for emergencies or crisis support: crisis wording returns helplines instead of sessions.

Input Schema

TableJSON Schema

Name	Required	Description
`lang`	No	Language of titles and booking pages: en, de, fr, es, it or pt. Default: the user's locale, else en.
`need`	Yes	What the person is looking for, in a few of their own words: a type of session ("reiki", "life coaching") or what they hope for ("sleep better", "less stress"). No names or health records.
`place`	No	City or country, for in-person sessions.
`stage`	No	Where the person is with this kind of session (Sissoo's 3 E's). emerge: new to it or trying it for the first time; first steps (free intro calls, first sessions) come first and repeats, follow-ups and programmes are left out. evolve: has tried it and wants to go deeper; programmes, series and follow-ups come first. Leave it out when they haven't said.
`format`	No	Online, in person or either (default).
`currency`	No	Currency for prices: GBP (default), EUR, USD or AUD.
`max_price`	No	Highest price per session in the chosen currency, booking fee included.
`within_days`	No	Only sessions with a free time within this many days.
`session_language`	No	Language the session is held in, as a two-letter code, e.g. "de".

Output Schema

TableJSON Schema

Name	Required	Description
`as_of`	Yes	When the free times were last refreshed.
`count`	Yes
`crisis`	Yes	Set when the words suggest self-harm or an emergency: helplines instead of sessions.
`notice`	Yes
`results`	Yes
`crisis_note`	No	Helplines, set whenever talking therapies are listed.
`medical_note`	No
`suggested_types`	No	Service types on Sissoo, when nothing matched.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / stage

Added value: +{
+  "description": "Where the person is with this kind of session (Sissoo's 3 E's). emerge: new to it or trying it for the first time; first steps (free intro calls, first sessions) come first and repeats, follow-ups and programmes are left out. evolve: has tried it and wants to go deeper; programmes, series and follow-ups come first. Leave it out when they haven't said.",
+  "enum": [
+    "emerge",
+    "evolve"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / results / items / properties / stages

Added value: +{
+  "description": "Sissoo's 3 E's, where a client is with this kind of session: emerge alone = a first step for someone new to it; evolve alone = for going deeper (series, programmes, follow-ups); both = open to anyone; empower = community or guiding others. Empty until Sissoo has sorted it.",
+  "items": {
+    "enum": [
+      "emerge",
+      "evolve",
+      "empower"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (which already declare readOnly/idempotent/non-destructive), it discloses the result shape and cap ('up to 8 sessions with price, booking fee included, next free time, link with that date picked') and a genuinely non-obvious behavior: crisis wording returns helplines instead of sessions. It also scopes the tool's boundary by stating where booking/payment actually occur.

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?

Three sentences, front-loaded with the action and scope, with the exclusions placed last where an agent will still see them. The domain example list ('reiki, massage and yoga to coaching, counselling and psychotherapy') is slightly padded, but the rest of the prose is dense with useful information rather than filler.

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?

For a 9-parameter search with full schema coverage, an output schema, and complete annotations, nothing an agent needs is missing: it knows what is searched, what filters exist, what comes back, and that the tool is a safe read that cannot transact. The crisis-routing caveat removes the last realistic ambiguity.

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?

Schema coverage is 100%, so the baseline is 3; the description earns extra by characterizing the required 'need' parameter as a short, free-text description and glossing the stage parameter as 'new to it, or going deeper'. The enumerated optional facets (place, format, language, timing, budget, stage) largely echo the schema, so it does not go much beyond it.

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?

The description opens with a specific verb and resource ('Finds bookable holistic and wellbeing sessions on Sissoo'), then bounds the domain with concrete examples and states the matching mechanism ('Matches a short description of what the person is looking for'). This is clearly a discovery/search tool, distinguishable at a glance from the ID-based siblings (get_service, get_practitioner, next_free_times) and from help_article.

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?

It gives a clear usage condition (when someone describes what they're looking for) plus explicit exclusions: 'Not for emergencies or crisis support' and 'booking and payment happen on sissoo.com'. It does not name a sibling tool and the condition that would select it instead, so it falls short of the 5 bar for routing between alternatives.

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

All Sissoo 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?