For parents and teachers: SEL trait guides, practice scenarios, what-to-say guides (ages 6-14).
Scored across 4 tools
get_site_overview and list_traits are clearly distinct, but find_practice_situation and get_what_to_say both take a real-life situation/topic and can return practice scenarios plus a parent-facing link, creating partial overlap. The descriptions do clarify the child-practice vs parent-guide focus, so an agent can mostly tell them apart.
All four tools follow a clean verb_noun snake_case pattern: find_practice_situation, get_site_overview, get_what_to_say, list_traits. The verbs (find/get/list) are used sensibly and consistently.
Four tools is a lean but reasonable set for a read-only informational server covering scenarios, guides, an overview, and traits. It is on the lower edge but each tool earns its place with no filler.
The read-only retrieval surface covers the main needs (practice scenarios, parent guides, site info, trait definitions) with sensible not_covered/no_article_yet fallbacks. Minor gaps exist, such as no way to browse all scenarios or filter by age/trait directly, but these are workarounds.
Finds up to 3 public Life Scenario practice scenarios for a real-life situation a child is facing (for example: left out at recess, peer pressure, cheating in a group chat, parents arguing, a new school). Returns each scenario's title, a short excerpt, the ages it is written for, the traits it practises, a link the adult can open to try it together with the child without an account and, when one is published, the parent page or what-to-say guide about the same situation. match_quality is "close" (the scenarios are about this situation) or "loose" (they only touch it and may not fit). An empty or loose result means only that no public scenario fits. Returns authored practice scenarios only, never other children's answers. Topics involving risk of harm, or medical or legal questions, return status "not_covered" with no guide or practice link.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Optional child age (6–14). Scenarios written for this age are ranked first. | |
| situation | Yes | The situation in everyday words, e.g. "friends pressure him to laugh at another kid". |
| Name | Required | Description |
|---|---|---|
| note | No | |
| status | No | Present only when the topic is not covered: no guide or practice link is returned. |
| matches | Yes | Up to 3 practice scenarios; empty when no public scenario fits or the topic is not covered. |
| topic_area | No | With status not_covered: the kind of topic that was recognised. |
| urgent_help | No | With status not_covered, for topics involving risk of harm: where to get urgent help, in the wording published in Life Scenario's guides. |
| how_it_works | No | |
| match_quality | No | close = the scenarios are about this situation; loose = they only touch it and may not fit. Absent when there are no matches. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, closed-world, non-destructive), and the description layers on real behavioral context: the 3-result cap, the meaning of match_quality close vs loose, that empty/loose means no public scenario fits (not a negative judgement), that only authored scenarios are returned and never other children's answers, and that risk/medical/legal topics return status 'not_covered' with no links.
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?
A single dense paragraph, front-loaded with the core action and capped result count, followed by the return contents and the match_quality/not_covered caveats. Nearly every clause earns its place, though the enumeration of returned fields is lengthy for a tool with an output schema.
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?
Given an output schema exists, the description needn't explain returns, yet it still covers result semantics, the empty/loose interpretation, the not_covered safety path, and the authorship guarantee. Nothing an agent needs to call this correctly or interpret its output is missing.
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 description coverage is 100%, so both parameters are already documented in the schema, establishing the baseline of 3. The description corroborates the domain (child age range, everyday-words situation phrasing) but adds no syntax, format, or edge-case detail 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?
States a specific verb (finds) and resource (public practice scenarios) with an explicit cap of 3 and a concrete scope (a real-life situation a child faces). The examples (recess exclusion, peer pressure, parents arguing) make the retrieval target unambiguous and separate it from the sibling tools that fetch what-to-say guides or traits.
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?
Gives clear context of use — an adult looking for something to try together with the child — and references the related parent page / what-to-say guide, implying the sibling relationship. It also states what empty and loose results mean, which guides interpretation. It stops short of an explicit 'use this instead of X when Y' routing rule, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Factual overview of Life Scenario: what the SEL practice game for children aged 6–14 does, what it is not, how child safety is handled, what this server can and cannot see, and key links.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| links | No | |
| safety | No | |
| traits | No | |
| company | No | |
| website | Yes | |
| what_it_is | Yes | |
| what_it_is_not | No | |
| about_this_server | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real context beyond them: it discloses that the response covers 'what it is not' and, notably, 'what this server can and cannot see' – useful scope transparency about the server's visibility limits.
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?
A single front-loaded sentence naming the subject, followed by a compact colon list of the covered topics. Dense but every clause names distinct content, so nothing is wasted; only slightly list-heavy.
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 an output schema present, return values need not be explained, and a zero-parameter tool needs no argument guidance. The description adequately frames the content scope; the only gap is the absent routing guidance toward or away from siblings.
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 takes no parameters, which is the baseline-4 case. There is nothing for the description to disambiguate, and the empty schema is consistent with the description.
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?
States a specific verb (overview) and resource (Life Scenario), then enumerates exactly what the overview contains: the game's purpose, boundaries, child-safety handling, server visibility, and links. It is clearly the orientation-style tool among specific lookups, though it never names a sibling to sharpen the contrast.
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 never states when to call this versus find_practice_situation, get_what_to_say, or list_traits. Usage is only implied by the word 'overview' and by the fact that it is content-agnostic while its siblings presume Life Scenario context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds the published Life Scenario page for parents that best matches a topic (for example: "nobody will play with me", "being teased", "a friend wants to copy my child's homework"): a "What to say" guide or a scenario page (one situation, with example replies by age), whichever is closer. Returns its short answer, the key lines a child can say, its URL and, when it has one, a practice_url: a practice scenario on a similar situation that the adult can open with the child without signing up. If no guide or scenario page on that topic is published, returns status "no_article_yet" and, when a public practice scenario is about the same situation, that scenario. Topics involving risk of harm, or medical or legal questions, return status "not_covered" with no guide or practice link.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The topic or the words the child used, e.g. "left out at recess". |
| Name | Required | Description |
|---|---|---|
| url | No | |
| note | No | |
| title | No | |
| status | No | Absent when a guide or scenario page is returned. |
| more_at | No | The page, which has all of its lines. Present only when it has more than 8. |
| updated | No | |
| for_ages | No | |
| page_type | No | Present with an answer: a /what-to-say guide, or a /scenarios page about one situation (its short answer is the page's introduction and advice for parents, its key_scripts the page's example replies by age). |
| guides_hub | No | The list of all published what-to-say guides. Present with status no_article_yet. |
| topic_area | No | With status not_covered: the kind of topic that was recognised. |
| key_scripts | No | Lines a child can say, at most 8. |
| reviewed_by | No | Name and credentials of the page's reviewer. Present only when the page has a named reviewer. |
| urgent_help | No | Where to get urgent help: the wording of the guide's own section of that name, or, with status not_covered, the same published wording for topics involving risk of harm. |
| how_it_works | No | |
| practice_url | No | A practice scenario on a similar situation; opens without an account. Present only when the guide or page has one. |
| short_answer | No | |
| match_quality | No | Present with a guide or scenario page, and with nearest_practice_situation. |
| practice_note | No | What the practice link is, and the ages the scenario is written for when narrower than the guide's or page's. |
| nearest_practice_situation | No | A public practice scenario about the same situation. Present only with status no_article_yet, and only when one fits closely. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, and the description adds real value beyond them: the two status sentinels, the practice_url fallback that requires no signup, and that the topic is matched against published content only. The return-shape detail partly overlaps the output schema, keeping it short of a 5.
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?
Purpose is front-loaded in the first clause, and the parenthetical examples are useful. It is a dense single paragraph that runs long, with some sentences restating what the output schema already covers, but each clause still carries meaning.
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?
Given an output schema exists, return values need not be explained, yet the description still clarifies the status semantics and the practice_url fallback. For a single-parameter read-only lookup, nothing an agent needs to invoke it correctly is missing.
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% and the single 'topic' parameter is fully documented with an example in the schema itself. The description restates example topics but adds no parsing, format, or length guidance beyond what the schema already provides, so the baseline 3 applies.
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?
States a specific verb and resource: finds the published Life Scenario page / 'What to say' guide best matching a topic. It explicitly distinguishes the two content kinds it may return (guide vs. single-situation scenario page), so an agent can tell it apart from find_practice_situation.
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?
Gives clear conditional outcomes: normal match, status 'no_article_yet' when nothing is published, and status 'not_covered' for risk-of-harm, medical, or legal topics — an effective when-not rule. It does not explicitly route the agent to find_practice_situation versus using this tool, but the boundary is implied by the topic-matching framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the 15 social and emotional learning (SEL) traits Life Scenario practises, each with a plain-language description and the everyday skills it covers. For questions about what a trait means for a child aged 6–14.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| traits | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds useful domain context: the fixed count of 15 traits, what each entry contains, and the target audience. It does not describe ordering or pagination, but with a closed 15-item set and an output schema that is a minor gap.
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?
Two sentences, front-loaded with what the tool returns, then the qualifying context. No filler or restatement of the title.
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 an output schema documenting the return shape, rich annotations, and zero parameters, the description covers everything an agent needs to select and invoke this tool 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?
The tool takes no parameters, so there is nothing for the description to disambiguate. The baseline for zero-parameter tools applies, and the description correctly describes a no-input listing call.
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?
States a specific verb and resource ('Lists the 15 SEL traits') and adds the scope of the content returned (plain-language description plus covered everyday skills). It is unambiguous versus the siblings, though it does not explicitly contrast itself with them.
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?
Gives a clear triggering context: 'For questions about what a trait means for a child aged 6–14.' That is a concrete when-to-use signal. It stops short of naming when NOT to use it or pointing to an alternative tool.
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.
get_what_to_say12 fields changedOutput schema / descriptionPrevious value: -"One of three shapes. A published guide: title, url, short_answer, key_scripts and, when available, practice_url (no status field). No guide on the topic: status \"no_article_yet\" with guides_hub and, when a public practice scenario is about the same situation, nearest_practice_situation. Topic not covered: status \"not_covered\" with topic_area and note, and no link."New value: +"One of three shapes. A published guide or scenario page: page_type, title, url, short_answer, key_scripts and, when available, practice_url (no status field). Nothing published on the topic: status \"no_article_yet\" with guides_hub and, when a public practice scenario is about the same situation, nearest_practice_situation. Topic not covered: status \"not_covered\" with topic_area and note, and no link."Output schema / properties / guides_hub / descriptionPrevious value: -"The list of all published guides. Present with status no_article_yet."New value: +"The list of all published what-to-say guides. Present with status no_article_yet."Output schema / properties / key_scripts / items / properties / by_ageAdded value: +{
+ "description": "Scenario pages only: the same reply worded for each age band the page shows.",
+ "items": {
+ "properties": {
+ "ages": {
+ "description": "e.g. \"6–8\".",
+ "type": "string"
+ },
+ "say": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ages",
+ "say"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / key_scripts / items / properties / say / descriptionAdded value: +"The line. On a scenario page: the reply for the middle age band."Output schema / properties / key_scripts / items / properties / when / descriptionAdded value: +"When the line fits, or why it works."Output schema / properties / match_quality / descriptionPrevious value: -"Present with a guide, and with nearest_practice_situation."New value: +"Present with a guide or scenario page, and with nearest_practice_situation."Output schema / properties / more_at / descriptionPrevious value: -"The guide's page, which has all of its lines. Present only when the guide has more than 8."New value: +"The page, which has all of its lines. Present only when it has more than 8."Output schema / properties / page_typeAdded value: +{
+ "description": "Present with an answer: a /what-to-say guide, or a /scenarios page about one situation (its short answer is the page's introduction and advice for parents, its key_scripts the page's example replies by age).",
+ "enum": [
+ "what_to_say_guide",
+ "scenario_page"
+ ],
+ "type": "string"
+}Output schema / properties / practice_note / descriptionPrevious value: -"What the practice link is, and the ages the scenario is written for when narrower than the guide's."New value: +"What the practice link is, and the ages the scenario is written for when narrower than the guide's or page's."Output schema / properties / practice_url / descriptionPrevious value: -"A practice scenario on a similar situation; opens without an account. Present only when the guide has one."New value: +"A practice scenario on a similar situation; opens without an account. Present only when the guide or page has one."Output schema / properties / reviewed_by / descriptionPrevious value: -"Name and credentials of the guide's reviewer. Present only when the guide has a named reviewer."New value: +"Name and credentials of the page's reviewer. Present only when the page has a named reviewer."Output schema / properties / status / descriptionPrevious value: -"Absent when a guide is returned."New value: +"Absent when a guide or scenario page is returned."find_practice_situation5 fields changedOutput schema / properties / match_quality / descriptionPrevious value: -"close = the scenarios are about this situation; loose = they only touch it, check that they fit before sharing. Absent when there are no matches."New value: +"close = the scenarios are about this situation; loose = they only touch it and may not fit. Absent when there are no matches."Output schema / properties / matches / descriptionPrevious value: -"Up to 3 practice scenarios; empty when no public scenario fits."New value: +"Up to 3 practice scenarios; empty when no public scenario fits or the topic is not covered."Output schema / properties / statusAdded value: +{
+ "description": "Present only when the topic is not covered: no guide or practice link is returned.",
+ "enum": [
+ "not_covered"
+ ],
+ "type": "string"
+}Output schema / properties / topic_areaAdded value: +{
+ "description": "With status not_covered: the kind of topic that was recognised.",
+ "enum": [
+ "self_harm_or_suicide",
+ "abuse_or_sexual_harm",
+ "violence_or_weapons",
+ "eating_or_body",
+ "medical_or_diagnostic",
+ "legal",
+ "bereavement_or_serious_illness"
+ ],
+ "type": "string"
+}Output schema / properties / urgent_helpAdded value: +{
+ "description": "With status not_covered, for topics involving risk of harm: where to get urgent help, in the wording published in Life Scenario's guides.",
+ "type": "string"
+}get_what_to_say19 fields changedOutput schema / descriptionPrevious value: -"Either a published guide (title, url, short_answer, key_scripts and, when available, practice_url) or status \"no_article_yet\" with the list of published guides and the nearest public practice scenario."New value: +"One of three shapes. A published guide: title, url, short_answer, key_scripts and, when available, practice_url (no status field). No guide on the topic: status \"no_article_yet\" with guides_hub and, when a public practice scenario is about the same situation, nearest_practice_situation. Topic not covered: status \"not_covered\" with topic_area and note, and no link."Output schema / properties / guides_hub / descriptionAdded value: +"The list of all published guides. Present with status no_article_yet."Output schema / properties / key_scripts / descriptionAdded value: +"Lines a child can say, at most 8."Output schema / properties / key_scripts / items / propertiesAdded value: +{
+ "say": {
+ "type": "string"
+ },
+ "when": {
+ "type": "string"
+ }
+}Output schema / properties / key_scripts / items / requiredAdded value: +[
+ "say"
+]Output schema / properties / match_quality / descriptionPrevious value: -"For a guide: \"close\". With status no_article_yet: how well nearest_practice_situation fits, \"close\" or \"loose\"."New value: +"Present with a guide, and with nearest_practice_situation."Output schema / properties / match_quality / enumAdded value: +[
+ "close"
+]Output schema / properties / more_atAdded value: +{
+ "description": "The guide's page, which has all of its lines. Present only when the guide has more than 8.",
+ "type": "string"
+}Output schema / properties / nearest_practice_situation / descriptionAdded value: +"A public practice scenario about the same situation. Present only with status no_article_yet, and only when one fits closely."Output schema / properties / nearest_practice_situation / propertiesAdded value: +{
+ "age_note": {
+ "description": "Present when the scenario is not written for the age that was asked about.",
+ "type": "string"
+ },
+ "ages": {
+ "description": "Ages the scenario is written for, e.g. \"8–14\".",
+ "type": "string"
+ },
+ "play_url": {
+ "description": "Opens the scenario without an account.",
+ "type": "string"
+ },
+ "scenario_page_url": {
+ "description": "Published page for parents about this situation, when there is one.",
+ "type": "string"
+ },
+ "situation": {
+ "description": "Short excerpt of the scenario text.",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "traits_practised": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "what_to_say_guide_url": {
+ "description": "Published what-to-say guide that uses this scenario, when there is one.",
+ "type": "string"
+ }
+}Output schema / properties / nearest_practice_situation / requiredAdded value: +[
+ "title",
+ "situation",
+ "ages",
+ "play_url"
+]Output schema / properties / nearest_practice_situation / typePrevious value: -[
- "object",
- "null"
-]New value: +"object"Output schema / properties / noteAdded value: +{
+ "type": "string"
+}Output schema / properties / published_guidesRemoved value: -{
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / properties / reviewed_byAdded value: +{
+ "description": "Name and credentials of the guide's reviewer. Present only when the guide has a named reviewer.",
+ "type": "string"
+}Output schema / properties / status / descriptionAdded value: +"Absent when a guide is returned."Output schema / properties / status / enumAdded value: +[
+ "no_article_yet",
+ "not_covered"
+]Output schema / properties / topic_areaAdded value: +{
+ "description": "With status not_covered: the kind of topic that was recognised.",
+ "enum": [
+ "self_harm_or_suicide",
+ "abuse_or_sexual_harm",
+ "violence_or_weapons",
+ "eating_or_body",
+ "medical_or_diagnostic",
+ "legal",
+ "bereavement_or_serious_illness"
+ ],
+ "type": "string"
+}Output schema / properties / urgent_helpAdded value: +{
+ "description": "Where to get urgent help: the wording of the guide's own section of that name, or, with status not_covered, the same published wording for topics involving risk of harm.",
+ "type": "string"
+}find_practice_situationget_site_overviewget_what_to_saylist_traitsPlain-English child psychiatry library — short explainers and decision guides for parents.
Helps people name what they feel: 796 feeling words and a body map of 243 sensations.
Guided practice with Thinking Brain School lessons your family has unlocked, inside your AI app.
A 2-minute assessment to help parents understand and respond to student safety concerns with clarity
Add one secure layer between your agents and this server.
