Memory care facility directory — pricing, services, inspection records by city and state.
Scored across 6 tools
Each tool targets a distinct operation: single-record retrieval (get_listing), aggregate counts (get_stats), three different metadata listings (categories, places, sources), and a filtered search (search_listings). The list_* tools are clearly separated by the resource they enumerate, and search_listings is distinguishable from get_listing by its query-based scope.
All names follow a consistent snake_case verb_noun pattern (get_listing, get_stats, list_categories, list_places, list_sources, search_listings). The verbs match the action (get for retrieval, list for enumeration, search for querying), and there are no mixed conventions.
Six tools is well-scoped for a read-only directory API, with each tool covering a clear facet: individual lookup, search, category/place/source metadata, and overall stats. No tool feels redundant or missing for the apparent purpose.
The surface covers core discovery workflows: search, single-listing retrieval, category/place/source enumeration, and summary statistics. Minor gaps exist, such as a dedicated way to fetch details for a specific place or category beyond their names/counts, but agents can work around this with search and list tools.
Get one published memory care home by its slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The listing slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and a closed-world scope, so the safety profile is fully covered. The description contributes one useful behavioral fact beyond that: only *published* homes are retrievable, so unpublished slugs presumably fail. No error or not-found behavior is described.
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 with no filler; the resource and the keying mechanism both appear immediately. Nothing could be removed without losing information.
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, so the description ideally would indicate what a returned listing contains or whether related collections are embedded. For a single-record fetcher this is a modest gap, and the 'published' scope plus the resource type give an agent enough to call it 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 100% and the sole parameter carries a defined pattern, maxLength, and minLength, so the schema does the heavy lifting. The description only reinforces that the slug identifies the record and adds no format or lookup semantics beyond that.
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 (Get), resource (one published memory care home), and access key (its slug), so an agent can distinguish it from search_listings at a glance. It does not explicitly name a sibling, and the resource wording ('memory care home') differs slightly from the tool name ('listing'), which adds minor ambiguity.
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 phrase 'by its slug' implies the precondition of already holding a slug (presumably obtained from search_listings or list_places), but no alternative tool is named and there is no when-not guidance, such as what to do without a slug. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the number of published memory care homes, places and categories, and when the data last changed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds real value by stating what the response contains (counts of homes, places, categories) and that it reports the last data-change time, which is behavioral context the annotations do not provide.
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 stating the counts and the freshness field, with no filler or redundancy. Every clause earns its place.
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 trivial zero-parameter read with no output schema, the description adequately conveys the returned content. Minor gaps remain: it does not clarify the format of the counts or the timestamp, but nothing essential for correct invocation 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?
The tool takes zero parameters, so there are no semantics to explain and the baseline is 4. The description correctly implies no input filtering is needed.
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 pairs a specific verb ('Get the number of') with concrete resources (published memory care homes, places, categories) plus a freshness indicator. It clearly reads as an aggregate-counts tool, distinct from the listing/search siblings, though it never names a sibling to differentiate against.
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 by the nature of the tool – a zero-parameter summary call – but the description states no explicit when-to-use or when-not-to-use guidance, nor does it point to alternatives like get_listing or search_listings for detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List categories with their memory care home counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the description does not carry the safety burden. It adds one useful behavioral fact (results include aggregate home counts), but says nothing about ordering, result size, or whether the category set is fixed.
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 with no filler. Every word contributes to identifying the tool and its payload.
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 no-parameter list tool with annotations covering safety, the description is nearly sufficient; it even indicates what is returned despite no output schema. It stops short of noting result ordering or that the category list is presumably small/static.
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 per the rubric the baseline is 4. Schema coverage is 100% and there is nothing parameter-related the description needs to compensate for.
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 ("List categories") and adds a meaningful detail about the payload (memory care home counts). It does not differentiate itself from siblings like list_places or list_sources, so an agent must infer which listing surface it wants.
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?
No guidance on when to use this versus list_places, list_sources, or search_listings. Usage is only implied by the resource name; no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List countries, regions and cities that have memory care homes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuine behavioral fact beyond the annotations: the result is pre-filtered to places that actually contain memory care homes. It says nothing about ordering, hierarchy, or whether results are paginated, so it adds only modest value.
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 short sentence with the scoping qualifier front-loaded after the resource. Zero filler and no redundancy with the schema or annotations.
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 parameterless list tool with no output schema, the description conveys enough to call it correctly: what entity types are returned and that they are limited to memory-care locations. It could additionally note the ordering/hierarchy of the returned list, which is the only meaningful 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?
The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies a no-input, whole-catalog enumeration.
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 (list) and a specific resource set (countries, regions and cities), scoped to those with memory care homes. The resource is clearly distinct from siblings like list_categories and list_sources, though it doesn't 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?
Usage is implied: an agent would call this to discover available geographic reference values. There is no explicit guidance on when to prefer it over search_listings or get_stats, and no stated prerequisites, but for a zero-param enumeration tool the intended use is reasonably self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List where the memory care home data comes from, with the license and refresh of each source.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world scope, so the safety profile is covered. With no output schema, the description usefully discloses what each entry contains (license and refresh of each source), which is the main behavioral gap it has to fill for this tool.
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 with the verb and scope first and the returned content second. Every clause earns its place; there is no filler or redundancy.
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, closed-world list tool with no output schema, the description tells the agent what it returns and at what granularity, which is nearly all that is needed. It stops short of stating whether the full set is always returned or whether ordering/counts matter, but no critical calling information 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?
The tool takes zero parameters, so there is no argument syntax for the description to explain; the baseline for a parameterless tool is 4. Nothing in the schema is left ambiguous by 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 ("List") and a clearly bounded resource (data provenance sources for the memory care home data), plus the fields surfaced per source (license, refresh). The resource is distinct from list_places/list_categories/search_listings, though the description never explicitly contrasts itself with those 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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_places or get_listing. The agent can infer this is for provenance questions, but nothing in the text routes it there.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published memory care homes by text, place and category.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search text, with at least one letter or digit. Matches name, categories, attributes, description and place. Typos fall back to close matches. | |
| city | No | City slug, from /places. | |
| sort | No | `relevance` needs `q` and is the default with it. `name` is the default without `q`. `recent` is newest first. | |
| limit | No | Items per page. | |
| cursor | No | `page.nextCursor` from the previous response. Opaque. Send the same filters and `limit`. | |
| region | No | Region slug, from /places. | |
| country | No | ISO 3166-1 alpha-2 country code, any case. A country the directory does not cover, as listed in /places, gives 400. | |
| category | No | Category slug, from /categories. A parent slug also matches its children. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact – only 'published' homes are returned – but says nothing about pagination behavior, empty-result handling, or result ordering beyond what the schema states.
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 with no filler; the verb, resource, scope qualifier ('published'), and filter axes all land in the first clause. Nothing redundant or trailing.
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 8 parameters, 0 required, and no output schema, the description leaves real gaps: no statement of what a response contains, how `cursor`/`limit` paginate, or how multiple filters combine (AND semantics). The 'published' scoping helps, but an agent still has to infer the result envelope from the cursor parameter description.
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 parameters are already well documented (q semantics, slug formats, sort defaults, opaque cursor). The description only restates the filter axes at a high level and adds no syntax, format, or interaction detail beyond the schema. 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 (Search) and a well-scoped resource (published memory care homes) plus the three filter axes. An agent can tell it apart from get_listing (single record) and the list_* siblings, but the description never names or contrasts those alternatives explicitly.
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?
There is no when-to-use, when-not-to-use, or alternative-tool guidance. Nothing tells the agent when to prefer search_listings over get_listing, list_places, or list_categories, or that a bare browse without `q` is also valid here. Usage is only weakly implied by the facet list.
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_listingget_statslist_categorieslist_placeslist_sourcessearch_listings
Add one secure layer between your agents and this server.