THC Open Mindfulness MCP

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

Adds real behavioral context beyond the annotations: a guarantee that every result is free and paid tracks are never exposed via the public API, plus the limitation that no audience metadata exists. It does not cover pagination or result ordering, but the annotations already carry the read-only/idempotent safety profile.

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?

Three sentences, front-loaded with the core purpose before the free-tier guarantee and audience caveat. Dense but each sentence carries non-redundant information; 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?

An output schema exists, so return values need not be described. For a 4-param search tool the description covers what matters most: source scope, free-only guarantee, query style, and audience semantics. The gap is unaddressed limit/duration behavior, which is minor.

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 0%, so the description must compensate, and it partially does: it clarifies query phrasing via examples and explains that category='children' is the mechanism for child-appropriate results. It says nothing about limit or max_duration_minutes, leaving half the parameters undocumented.

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 free guided audio practices) and scopes the source precisely to The Holistic Care's Stillness Library, with concrete examples. However, it never differentiates itself from the closely-named siblings, especially search_mindfulness_resources and get_mindfulness_resource, so an agent must infer the boundary.

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 usage context through example queries and an explicit rule for audience handling ('use category: children ... treat other audience assumptions as unsupported'). It stops short of naming alternatives or stating when-not-to-use, so it is clear context without exclusions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description rightly spends its space on behavior annotations can't express: age/duration filters only match games with published metadata and never infer a fit, and results may require an email for access. That is real, non-obvious disclosure beyond the structured data.

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?

Front-loaded with purpose, then the two filtering caveats, then the access caveat; every sentence carries information and none is filler. Slightly dense (em dashes and long clauses) but proportionate to the tool's complexity.

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 no explanation, and the description covers the two genuinely surprising behaviors (metadata-strict filtering, mixed free/email access). The remaining gap is guidance on the skill/audience/limit parameters, which is a minor omission for a no-required-param search tool.

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 0% with six parameters, so the description must carry the load. It explains age and max_duration_minutes matching semantics well and hints at query via examples, but says nothing about skill, audience, or limit — three of the six parameters remain undocumented anywhere.

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 ('Finds interactive mindfulness games') plus the source library, and the phrase 'interactive mindfulness games' cleanly distinguishes it from siblings like find_guided_practices and search_mindfulness_resources. An agent can pick this tool without opening any schema.

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 concrete usage examples ('a grounding game for a 9-year-old', 'a short breathing game under 5 minutes') that show what the tool is good for, and explains the match semantics for age and duration. It does not explicitly name an alternative tool or state when NOT to use this one, 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.

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful scope behavior — only public framework material is reachable and private implementation content is out of reach — which is not derivable from annotations. It does not describe pagination or how the limit truncates results.

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?

Front-loaded with what the tool returns before the lengthy exclusion clause. The private-content sentence is long but earns its place by preventing a whole class of misuse; overall it is dense rather than padded.

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?

An output schema exists, so return-format explanation is unnecessary, and the description is complete on scope and content types. The remaining gap is the undocumented 'resource_type' and 'limit' semantics, minor but real for a 4-parameter tool.

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 0%, so the description must carry parameter meaning. It partially does: the five element names map to the 'element' enum and the query examples clarify 'query', but 'resource_type' (pathway vs download) and 'limit' are never explained, leaving half the parameters undocumented anywhere.

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'), resource ('public PanchaVikas resources'), and enumerates exactly what is covered: public overview, pathway summaries, and the downloadable guide. The named five-element framework and concrete query examples make it unmistakable against the mindfulness-oriented siblings.

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 explicit example queries ('public PanchaVikas resources related to Jal') to show usage, and states a hard boundary: it does NOT retrieve the private 216-session curriculum or session plans, and tells the agent how to answer such a request. Both when-to-use and when-not-to-use are covered.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds a crucial non-obvious behavior: private and non-existent resources return an identical clean not-found result, and the tool never confirms or denies private content existence. This is valuable beyond structured fields.

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?

The description is well-structured and front-loaded: purpose first, then usage context, parameter specifics, and a privacy note. Every sentence adds information, though the first sentence is somewhat long and could be split for readability.

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?

Output schema exists, so return values need not be explained; annotations cover the safety profile. The description supplies the missing usage context, identifier semantics per resource_type, and privacy behavior, leaving no critical gaps for an agent to invoke the 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?

Schema description coverage is 50% (only identifier has a schema description). The description compensates by explaining that identifier is a slug for five resource types and a stable id (e.g. 'PV-pathway-jal') for panchavikas types, adding format and example detail beyond the schema. It does not define resource_type itself, but the enum values are self-descriptive.

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 ('Fetches the full detail record') and resource ('ONE specific, already-identified public resource'), and explicitly differentiates itself from search/find siblings by instructing use after a search tool surfaces an identifier. An agent can immediately tell this is a detail-retrieval tool, not a search or list tool.

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 clear context: use after search_mindfulness_resources or another find/search tool has surfaced a slug or id you want the complete record for. It names one sibling explicitly and implies the rest, but does not provide explicit when-not-to-use guidance or name all alternatives.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive) and world-openness, but the description adds meaningful behavior: at most one best match returned, optional etymology and related terms, and an explicit no-match result rather than a fabricated definition. This no-hallucination guarantee is valuable context beyond the annotations.

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, with examples and return behavior following. Two sentences of moderate length, each clause contributing useful information without padding.

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 and full annotation coverage, return shape and safety need not be restated, and the no-match/etymology note is extra value. The one real gap is the unexplained 'pillar' parameter, which leaves a caller unable to use the tool's only optional filter confidently.

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 0%, so the description carries the full burden, yet it never explains the optional 'pillar' parameter or its enum values, nor the 120-character term limit. The listed domains (yoga, kundalini, ayurveda, etc.) loosely echo the enum but are not framed as a filtering parameter, so an agent would not know it can narrow by pillar.

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 (looks up), a specific resource (definition of a single term), and the exact scope (The Holistic Care's public glossary), backed by concrete example queries. It is clearly distinguishable from siblings that search or find broader resource collections.

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 example queries ('What does aparigraha mean?', 'define yoga nidra') make the intended use case clear and demonstrate single-term lookup versus the broader search/find siblings. However, no alternative tool is named and no explicit when-not-to-use condition is given.

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

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

Annotations already declare read-only, open-world, idempotent, non-destructive behavior. The description adds substantial context beyond that: each result is a real study with authors, year, journal, and limitations note; never a THC-authored medical claim; and includes disclaimers about medical advice and outcome guarantees.

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?

Front-loaded with purpose and examples, then output details, then disclaimers. Well-structured and mostly efficient, though the final disclaimer sentence is slightly wordy and somewhat repetitive of the medical-advice point.

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?

The description covers purpose and the nature of results, and an output schema exists so return values need not be explained. However, with four parameters and 0% schema coverage, it lacks guidance on filters (topic, study_type) and limit, leaving invocation less complete than it could be.

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 0%, so the description must compensate. It only offers two example queries and does not explain the limit, topic, or study_type parameters, nor the enum values available. This is minimal compensation for four undocumented parameters.

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 ('plain-language summaries of published research'), and the scope clearly distinguishes it from generic resource, practice, or game search siblings. An agent can tell it returns research summaries, not practices or terms, without opening another schema.

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?

Provides example queries that imply how to phrase a search, but gives no explicit guidance on when to use this tool versus siblings like search_mindfulness_resources, nor any exclusions or prerequisites. The medical disclaimer is a boundary, not usage guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds a genuinely non-obvious behavioral trait: the structured filters are post-filters over text results, so narrow filters plus a rare term can legitimately return few or zero results even when matches exist. That caveat materially changes how an agent should interpret an empty result set.

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?

The purpose and entry-point guidance are front-loaded, and every sentence carries information. The final sentence is a long run-on packing the post-filter caveat and the four alternatives together, which slightly hurts scannability.

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 and annotations covering safety, the description needs only to add the caveats an agent cannot infer — and it does deliver the post-filter/empty-result warning. Limits behavior (pagination, default limit) and the semantics of the 'query' field itself are left to the schema.

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 0%, so the description must carry parameter meaning, and it does explain five of seven filters (resource_type, category, audience, skill, age) as post-filters over the text query — a semantic the schema does not convey. It stops short of describing valid value shapes or the limit default/max, so it is strong but not complete.

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 ('Free-text search across every public resource family') and enumerates the families covered (blog, games, practices, research, glossary, PanchaVikas). It also explicitly positions itself as the general entry point, which separates it cleanly from the narrower find_*/lookup_* siblings.

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 an explicit when-to-use rule ('when a request doesn't clearly belong to one specific family'), two concrete example queries, and names the four alternatives for when you do want a single family with server-side filtering. Both the selection case and the exclusion case are covered.

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