Helps people name what they feel: 796 feeling words and a body map of 243 sensations.
Scored across 4 tools
Each tool has a distinct primary function: retrieving sensations by body region, retrieving feeling words by category, listing all categories/regions, and searching across both datasets. However, both list_categories and search_words are described as relevant to vague queries like 'I feel off', creating a minor overlap in use-case guidance.
All tools use a consistent snake_case verb_noun pattern: get_body_sensations, get_feeling_words, list_categories, search_words. The verbs (get, list, search) clearly indicate the operation, and the naming is predictable throughout.
With only 4 tools, the set is well-scoped for a reference-lookup server. Each tool serves a clear, non-redundant purpose, and the count aligns with the domain's simplicity without feeling thin or excessive.
The tools cover the main access patterns: browsing categories/regions, retrieving words by category, retrieving sensations by region, and searching across both. A minor gap exists in that there is no direct way to retrieve all feeling words or all body sensations in a single call without iterating through categories or regions.
Returns the physical sensations people report in one body region of the Surfacing body map, such as "Heart & Chest", "Stomach", or "Face & Expression". Relevant when someone describes a feeling through their body, for example "my chest is tight" or "my jaw is clenched".
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | Body region name, for example "Breathing" or "Legs & Feet". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that it returns sensations reported in the body map, but does not say what the return shape looks like, whether it lists multiple sensations, or how exhaustive the data is. With annotations carrying safety, this is adequate but not rich.
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 is returned and where, followed by the contextual trigger. No filler, though the example region names in the description partly overlap the schema's own examples.
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?
A low-complexity one-param read tool with annotations covering safety, and no output schema. The description gives the what and a usage cue, but leaves routing vs. get_feeling_words unresolved and says nothing about output, which is acceptable given no output schema but leaves a selection gap.
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% and the single region parameter is fully documented with examples in the schema. The description echoes a couple of region names but adds no format, case, or lookup guidance beyond the schema, 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+resource (returns physical sensations) with scope (one body region of the Surfacing body map) and concrete examples. However, it does not distinguish itself from the sibling get_feeling_words, which could also be relevant when someone describes a feeling through their body.
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 implied usage context ('relevant when someone describes a feeling through their body, e.g., my chest is tight'), which helps an agent recognize the right moment. But it never says when NOT to use it or how to choose between this and get_feeling_words, which is a clear alternative for feeling language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns every word in one category of the Surfacing feelings list, such as "Sadness", "Fear & Anxiety", "Contempt & Malice", or "Calm & Grounded". Relevant when someone wants a more precise word for a feeling.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category name, for example "Overwhelmed" or "Relational Hurt". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful trait ('every word' in the category, i.e. complete enumeration, no filtering or paging), but says nothing about behavior on an invalid or misspelled category, which is a real risk for a free-text input.
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 compact sentences with zero waste: the core behavior is front-loaded and the usage cue follows. Nothing is padded or repeated from 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?
For a one-parameter read-only tool with no output schema, the description covers what is returned at a high level. However, it omits how to obtain a valid category value (the sibling list_categories) and any error behavior, leaving a meaningful gap for correct invocation.
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% and the single parameter already carries its own examples in the schema. The description's sample category names ('Sadness', 'Fear & Anxiety', 'Contempt & Malice', 'Calm & Grounded') supplement rather than duplicate the schema examples, giving marginal extra value — baseline 3 fits.
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 gives a specific verb+resource ('Returns every word in one category of the Surfacing feelings list') and enumerates concrete category examples, so the scope is unambiguous. It does not explicitly contrast itself with siblings like list_categories or search_words, which is the only thing separating it from a 5.
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?
'Relevant when someone wants a more precise word for a feeling' gives a clear situational trigger, but there are no exclusions or named alternatives. Notably, it never points to list_categories as the way to discover valid category names, which is the most likely upstream need given the required enum-less category parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every category in the Surfacing feelings list (796 curated feeling words), with example words, plus every body region for physical sensations. Relevant when someone is trying to name or understand what they feel, for example "I feel off" or "I can't describe it".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety and scope profile is covered. The description adds the content-level disclosure (categories with example words plus body regions, drawn from a curated 796-word list), but says nothing about response shape, ordering, or size. With annotations carrying the safety burden, a 3 is appropriate.
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 is returned and then the situation that calls for it. The parenthetical count earns its place by conveying scope; there is no filler.
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 zero-parameter list tool with no output schema, the description conveys most of what an agent needs: what is returned (categories, example words, body regions) and when to use it. Minor gap is that the exact return structure is not hinted at, but no output schema exists to carry that.
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 zero parameters, so there is no parameter semantics for the description to add; baseline 4 applies. The description correctly implies a parameterless catalogue 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 (lists) and precisely scoped resources (feeling categories in the Surfacing list, plus body regions), and quantifies the corpus (796 curated words) with example words included. This clearly separates it from get_feeling_words (individual words) and search_words (query-driven lookup).
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 trigger condition — when someone is trying to name or understand what they feel — with two concrete example utterances ('I feel off', 'I can't describe it'). It does not name alternatives or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches all 796 feeling words and 243 body sensations in the Surfacing list for a word or fragment and returns each match with its category or body region. Relevant when someone uses a vague or partial word for how they feel, such as "heavy", "tight", "numb", or "off".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matches to return (default 40). | |
| query | Yes | A word or part of a word. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful scope details (796 words, 243 sensations) and return content ("category or body region"), but does not address pagination, case sensitivity, or other behavioral nuances.
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 does and followed by when it is relevant. Every sentence earns its place with no filler or repetition.
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 simple search tool with no output schema, the description supplies the essential return information ("each match with its category or body region") and usage context. It could be slightly more complete by clarifying whether results are paginated or how the limit applies, but the schema already covers those parameter details.
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 the parameters are already documented in the schema. The description implies that "query" accepts a word or fragment, matching the schema, but adds no new semantics and does not discuss the optional "limit" parameter.
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 ("Searches") and resources ("all 796 feeling words and 243 body sensations") and explains that matches include category or body region. The purpose is clear, though it does not explicitly contrast itself with sibling retrieval tools like get_feeling_words or get_body_sensations.
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 a clear context for use: "Relevant when someone uses a vague or partial word for how they feel," with helpful examples like "heavy", "tight", "numb", and "off". It does not, however, state when not to use the tool or name alternative tools for complete-list retrieval.
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_body_sensationsget_feeling_wordslist_categoriessearch_wordsThe Emotion Dictionary's 402 emotions: define a word, resolve a feeling, body maps. CC BY 4.0.
Affect analysis, 3D avatar params, empathy hints and somatic emotion decode.
Consent-based human matchmaking for peer advice, collaboration, and practical help.
For parents and teachers: SEL trait guides, practice scenarios, what-to-say guides (ages 6-14).
Add one secure layer between your agents and this server.
