The value is the fixed order — analyse, pick a persona, answer as it, then advise on using the answer — because a caller gets that sequence whether or not the surrounding conversation was steering toward it. What the interface does not carry is state: there is no session identifier and no store among the arguments, so continuity between one situation and the next is the caller's to supply.
A single-tool server built around get_support, which reads the situation you describe, picks the persona best suited to it, answers in that persona's voice, and closes with guidance on incorporating the feedback.
- One call in place of a prompt chain: get_support runs analysis, persona selection, the persona's support and the follow-up guidance as one fixed sequence, so a client gets the same shape back each time rather than whatever the model improvises that turn.
- Inputs kept apart rather than folded into one string: situation carries what happened, emotional_state carries how it is landing, and context carries what surrounds both, each supplied as its own argument.
- Nothing to configure before the first call: get_support takes everything it works from as call arguments.
No account and no key. get_support reads its situation, emotional_state and context from the call itself, so there is nothing to hold before you make one.
One command — npx mcp-emotional-support