Prices, insurance plans, Medicare and Medicaid, and prescribing policy for 68 US online therapy and psychiatry services, plus what 26 platforms pay therapists. Every answer carries the service's own source pages and the date checked.
Scored across 6 tools
The consumer-facing trio (search, get, compare) is distinguishable but adjacent: compare is essentially a batched get, and an agent could pick either for a two-service lookup. The two clinician tools are clearly separate domains from the consumer tools, so no tool duplicates another outright.
Half the tools follow verb_noun (compare_, get_, search_online_therapy_services), but three use noun-phrase or vague labels (online_therapy_prices_overview, therapist_platforms_pay_and_fees, paid_ai_training_work_for_clinicians). There is also a singular/plural slip between get_online_therapy_service and search_online_therapy_services.
Six tools is lean and well-scoped: one search, one detail, one comparison, one aggregate price view, plus two distinct clinician resources. No tool appears redundant or tacked on for its own sake.
The consumer path (search -> get -> compare -> prices overview) covers a full read-only research lifecycle, and the clinician side has platform pay and AI-training job coverage. Minor gaps: no tool to enumerate all services or all insurance plans directly, and no way to query platform detail beyond naming one within the fees tool.
Cost, insurance, plans, Medicare and Medicaid, prescribing and ages for 2 to 4 named services, side by side, each with its sources page.
| Name | Required | Description | Default |
|---|---|---|---|
| services | Yes | Service names or slugs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world behavior, so the baseline is low; the description still adds value by disclosing the return payload ('each with its sources page') and the 2-4 service comparison constraint. It does not say what happens when a supplied service name is not recognized, which is the main remaining behavioral 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?
A single dense sentence with no filler, listing the compared dimensions up front. The telegraphic, verb-less phrasing is slightly harder to parse than a full clause would be, but nothing is wasted.
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 a well-annotated profile, the description covers dimensions compared and output provenance, which is adequate. It leaves open how services are matched and what the comparison output looks like structurally, which matters given there is no output 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 coverage is 100% and the single 'services' parameter is already documented as names or slugs with minItems 2 and maxItems 4 in the schema. The description's '2 to 4 named services' restates the schema bounds rather than adding meaning such as slug format or matching behavior; 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?
The description names the exact comparison dimensions (cost, insurance, plans, Medicare/Medicaid, prescribing, ages) and the 'side by side' framing makes the compare verb unambiguous, which distinguishes it from the single-service sibling get_online_therapy_service. It never states a verb outright and does not name the alternative tools, so it falls short of 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?
Usage is only implied: '2 to 4 named services' signals that the caller must already know service names, hinting that search_online_therapy_services should run first, and 'side by side' implies multi-service comparison rather than single lookup. There is no explicit when-to-use, when-not-to-use, or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything OnlineTherapy.me records about one service (e.g. 'BetterHelp', 'Talkspace', 'Rula', 'Cerebral'): every price row with the page that states it, the insurance plans it names, Medicare and Medicaid, prescribing policy, formats, ages, how matching and switching work, and when it was checked.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | The service's name or its onlinetherapy.me slug, e.g. 'BetterHelp' or 'brightside-health'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds real behavioral value beyond that: it discloses that price rows are returned with the source page that states them and that data carries a 'when it was checked' freshness stamp, which tells an agent how to cite and trust results. It stops short of describing not-found behavior or payload size.
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?
It is a single front-loaded sentence with the core noun phrase first and the returned fields enumerated afterward; no sentence is wasted. It is long, but the length comes from a purposeful field list rather than 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?
With only one parameter, full schema coverage, and annotations, the main remaining burden is describing the return payload, which the description does via an enumerated field list (prices, insurance, Medicare/Medicaid, prescribing, formats, ages, matching/switching, last-checked). Only edge cases such as an unknown service name or missing coverage are unaddressed.
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 schema already documents that the parameter accepts a name or onlinetherapy.me slug with an example. The description only reinforces the singular constraint ('one service') and adds a few more real-world name examples, which is marginal added meaning over the structured field.
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 names the exact resource (one online therapy service on OnlineTherapy.me) and enumerates the record types returned, with concrete entity examples like BetterHelp and Talkspace. It is clearly a single-record detail fetch, distinguishable from siblings such as compare_online_therapy_services and search_online_therapy_services, though it never explicitly names those siblings 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?
Usage is implied rather than stated: the tool returns detail for one already-identified service, and the phrasing 'everything ... records about one service' signals a full-detail lookup versus a list/search. However, there is no explicit guidance on when to prefer it over search_online_therapy_services or compare_online_therapy_services, and no note about needing a valid service name/slug first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The self-pay price of one regular session at every service that publishes one (median, lowest, highest, how many at or under $100), the range of insured per-session figures services state, and each service's figure with its source page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly=true, idempotent=true, closed-world), so the description's job is to explain what comes back, and it does: per-service self-pay figures plus median, lowest, highest, count at or under $100, insured ranges, and source page per figure. It stops short of saying how many services are covered or whether services lacking published prices are omitted from the output.
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 sentence, front-loaded with the core object ('the self-pay price of one regular session'), with the metric list tucked into a parenthetical rather than scattered. It is dense but every clause names a real output field; only the trailing 'each service's figure with its source page' clause could be tightened.
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 no input parameters and no output schema, the description carries the full burden of describing results, and it enumerates the aggregate and per-service fields adequately. The main remaining gap is output shape and volume: it does not say whether results are a table, how many services appear, or how services without published prices are handled.
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, which is the baseline-4 case; there is no argument to explain. The description correctly implies a parameterless, whole-catalog call by not referencing any filters, so nothing is left ambiguous on the input side.
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 names a specific resource (self-pay per-session prices) and a specific scope (every service that publishes one), and enumerates the exact aggregates produced: median, lowest, highest, count at or under $100. That clearly separates it from the per-service siblings such as get_online_therapy_service and search_online_therapy_services.
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?
Usage is implied rather than stated: the phrase 'at every service that publishes one' signals a breadth-first census, which contrasts implicitly with the per-service siblings. However, no sibling is named and there are no explicit when-to-use or when-not-to-use conditions, so the agent has to infer that this is the aggregate-first choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open, paid roles where licensed mental-health clinicians (psychologists, psychiatrists, LCSWs, LPCs, nurse practitioners) help train or evaluate AI models, read from the hiring companies' own job boards (micro1, Mercor, AfterQuery): title, hourly pay as posted, contract type, location and date posted. Optional filter by a word in the title.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many roles (default 10). | |
| query | No | A word in the role title, e.g. 'psychologist', 'psychiatrist', 'LCSW', 'Spanish'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and open-world, so the safety profile is covered. The description adds real context beyond that: provenance (listings come from the hiring companies' own job boards, not an aggregator) and a freshness caveat via 'hourly pay as posted', signaling pay is unnormalized. It stops short of stating freshness, deduplication, or ordering behavior.
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?
It is essentially one long but well-ordered sentence: what the tool returns, where the data comes from, the returned fields, then the optional filter. It is front-loaded and has no filler, though the parenthetical license list and source list make it denser than strictly necessary.
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 only two optional parameters, no output schema, and no nested objects, the main risk is unknown return fields — and the description enumerates them (title, pay, contract type, location, date posted). Safety behavior is handled by annotations. Minor gaps remain around result ordering, freshness, and duplicate listings across the three boards.
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 (limit with default 10 and max 25, query as a title word) are already documented, and the description adds little beyond confirming the filter matches a word in the title. Baseline 3 is appropriate when the schema carries the semantics.
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 names a specific verb+resource: open, paid roles for licensed mental-health clinicians to train or evaluate AI models, and names the exact sources (micro1, Mercor, AfterQuery). It lists the clinician license types in scope and the fields returned, which lets an agent distinguish it immediately from the online-therapy-service 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?
Usage is only implied: an agent can infer this is the job-listing lookup rather than a therapy-service lookup, since no sibling covers hiring boards. There is no explicit when-to-use/when-not statement, and the only guidance is that the title filter is optional, leaving the agent to infer that omitting it returns the default set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find US online therapy and psychiatry services by insurance plan, self-pay price per session, medication prescribing, age group or a word in the name or focus (e.g. 'ADHD', 'couples', 'OCD'). Each result gives the service's cost and insurance answer as its own pages state them, the date checked, and the onlinetherapy.me page with the sources.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results (default 10). | |
| query | No | Words to match in the service's name, other names, parent company or focus, e.g. 'ADHD' or 'Talkspace'. | |
| age_group | No | Only services that serve this group. | |
| insurance_plan | No | Only services whose own pages name this plan as in network (or that take Medicare / Medicaid). | |
| takes_insurance | No | true: only services that bill insurance in network; false: only self-pay services. | |
| prescribes_medication | No | true: only services with psychiatric prescribers. | |
| max_self_pay_per_session_usd | No | Only services whose stated self-pay price for one regular session is at or under this amount. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a read-only, idempotent, closed-world search, so safety is covered. The description adds real value beyond that by disclosing result provenance and freshness: costs and insurance answers are reported 'as its own pages state them', plus the date checked and a source page. It does not describe pagination or behavior when no results match, which keeps it below 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?
Two sentences with no filler: the first enumerates the filter surface, the second describes the return payload and its sourcing caveat. The search capability is front-loaded and nothing is repeated from the title. The density is appropriate for a seven-parameter search tool.
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?
There is no output schema, but the description compensates by explaining what each result carries: cost, insurance answer, date checked, and the source page. For a seven-parameter but all-optional, read-only search this is nearly sufficient. The remaining gap is routing context relative to its four siblings and what happens on an empty match set.
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 every one of the seven parameters is already documented in the schema, including enum values for age_group and insurance_plan. The description echoes the same filter axes (insurance, price, medication, age, keyword) without adding format, precedence, or interaction semantics such as how query behaves alongside the boolean filters. 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?
The description states a specific verb and resource ('Find US online therapy and psychiatry services') and enumerates the filterable dimensions: insurance plan, self-pay price, medication prescribing, age group, keyword. It is unambiguous as to what the tool returns. It falls short of a 5 because it never distinguishes itself from sibling tools such as compare_online_therapy_services or get_online_therapy_service, which an agent must choose between.
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?
Usage is only implied by the filter list: it is clear you use this to narrow a list of services by criteria, but there is no explicit 'when to use this vs. compare_online_therapy_services' or 'use get_online_therapy_service for a single service's detail'. No exclusions or prerequisite guidance are given, so the agent must infer routing from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For licensed clinicians choosing where to work: how each of 26 platforms (Headway, Alma, Rula, Grow Therapy, SonderMind, BetterHelp, Talkspace and others) works with therapists, contractor or employee, the fees it takes, published pay figures, credentialing and licenses accepted, each fact with the platform's own source page. Filter by license or name one platform.
| Name | Required | Description | Default |
|---|---|---|---|
| license | No | Only platforms that accept this license type. | |
| platform | No | One platform's name or slug for its full record, e.g. 'Headway' or 'grow-therapy'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: dataset breadth (26 platforms), sourcing ('each fact with the platform's own source page'), and the fact that a single platform yields its 'full record'. It says nothing about how the two filters interact or what a record contains.
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?
It leads with the audience and purpose, then enumerates the covered fields, then states the two call modes — a sensible front-loaded order. The inline platform-name list (Headway, Alma, Rula, Grow Therapy, SonderMind, BetterHelp, Talkspace) is slightly padded but does convey dataset scope efficiently.
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 two-optional-parameter, read-only lookup with full schema coverage and no output schema, the description covers dataset scope, field coverage, provenance and the two invocation modes. The remaining gap is minor: it does not say whether the two filters can be combined or what the single-platform record structure looks like.
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%, so both parameters are already documented, including the license enum and the platform example values. The description only restates the filtering intent ('Filter by license or name one platform') and adds the hint that naming a platform returns its full record, which is already conveyed by the schema 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?
The description states a specific resource (a 26-platform dataset covering contractor/employee status, fees, published pay, credentialing and accepted licenses) with named examples, so an agent knows exactly what comes back. It does not explicitly differentiate itself from the sibling online_therapy_prices_overview or search_online_therapy_services, leaving overlap to be inferred from the title's 'pay and charge therapists' framing.
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 audience framing 'For licensed clinicians choosing where to work' and the closing 'Filter by license or name one platform' imply the two usage modes (browse by license vs. fetch one platform). However, no alternative tool is named and no when-not-to-use condition is given, so routing against the four siblings remains implicit.
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.
paid_ai_training_work_for_clinicianscompare_online_therapy_servicesget_online_therapy_serviceonline_therapy_prices_overviewsearch_online_therapy_servicestherapist_platforms_pay_and_fees
Add one secure layer between your agents and this server.