Find Australian NDIS providers by service and location, with public profiles and links.
Scored across 3 tools
Each tool has a clearly distinct role: search providers, list service categories, and fetch a specific provider profile by slug. The descriptions explicitly define when to use each and warn against overlapping use cases such as billing or booking.
All three tools follow a consistent snake_case verb_noun pattern: get_ndis_provider, list_ndis_services, search_ndis_providers. The domain prefix is applied predictably across the set.
Three tools are well-scoped for a read-only provider directory: find providers, understand service categories, and inspect a provider profile. No tool feels redundant or out of place.
The core discovery workflow is covered: category mapping, provider search, and profile lookup. Minor gaps exist around browsing locations or paginating beyond the first 20 search results, but agents can work around them.
Use this to read a public provider profile after search, using its returned slug ID. Returns available contact details, broad service category IDs, locations, update timestamps and a citation URL. Missing data is unknown. Do not treat registration status as a live official verification or a claimed profile as accreditation. Cannot book or contact providers.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact provider slug ID returned by search_ndis_providers, e.g. 101-physio. Never supply a URL. |
| Name | Required | Description |
|---|---|---|
| provider | Yes | |
| source_url | Yes | |
| limitations | Yes | |
| retrieved_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world and non-destructive behaviour, and the description adds real context beyond them: what a result contains (contacts, category IDs, locations, timestamps, citation URL), that missing data reads as unknown, and that registration status is not a live official verification. Slightly vague on what 'unknown' means in practice, and error behaviour for a bad slug is unstated.
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?
Four short sentences, front-loaded with the action and the key, then returns, then caveats. Dense with no filler, though the two disclaimer sentences could be tightened into one.
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 with an output schema and full annotations, the description covers purpose, sequencing, return shape summary and interpretation caveats. The remaining gap is not-found/error handling and any staleness expectations, which an agent would want before calling.
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 is fully documented in the schema, including the slug pattern example and 'Never supply a URL'. The description's 'using its returned slug ID' merely restates that, adding no format or edge-case detail. 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 ('read a public provider profile') and pins the lookup key ('its returned slug ID'), which makes the search-then-read relationship clear. It does not explicitly distinguish itself from the other sibling, list_ndis_services, leaving one boundary to inference.
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?
'Use this to read a public provider profile after search' gives a clear usage context and sequence, and 'Cannot book or contact providers' sets a firm out-of-scope boundary. No sibling is named as an explicit alternative, so the routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when mapping a requested NDIS support to directory service categories before searching. Returns category IDs, names, synonyms and source links. Therapy services is a broad category, not proof that a provider offers a specific therapy. Do not use for NDIS billing item codes or funding advice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| services | Yes | |
| source_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuine domain context beyond that: what the payload contains (IDs, names, synonyms, source links) and the important interpretation caveat that 'Therapy services' is a broad category, not proof a provider offers that therapy. It stops short of describing pagination or enumeration size, which would push it to 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?
Four short sentences, front-loaded with the triggering condition, then return contents, then a caveat, then the exclusion. Every sentence carries distinct information and none restates the title 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?
An output schema exists, so return fields need only be named, which they are. With annotations covering safety and no parameters to explain, the description closes the remaining gap an agent would hit: what the categories mean and where they must not be applied.
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 nothing to disambiguate and the description correctly spends no words on inputs. Baseline of 4 applies; a 5 is unnecessary since no parameter guidance is required.
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 NDIS directory service categories) plus exactly what is returned: category IDs, names, synonyms and source links. The opening clause ties it to a concrete task ('mapping a requested NDIS support ... before searching'), which separates it from get_ndis_provider and search_ndis_providers without naming 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 an explicit use case with sequencing ('before searching') and an explicit exclusion ('Do not use for NDIS billing item codes or funding advice'). The agent knows both when this tool is the right entry point and when it is the wrong one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants to find or compare Australian NDIS providers by support category, state, city, suburb, postcode or name. Returns up to 20 public listings per page, registration status, available review data and citation URLs, ordered by name. Ask for service or location if missing. Do not use for diagnosis, funding eligibility, emergency help, booking or sending enquiries.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name, e.g. Melbourne. Matches directory outlet locations, not a distance radius. | |
| page | No | Page of up to 20 matches. Use next_page from the last response. | |
| query | No | Provider name, ABN, or postcode, e.g. 3000. Use service_ids for service categories. | |
| state | No | Australian state or territory abbreviation. | |
| suburb | No | Suburb name, e.g. Richmond; specify state to disambiguate. | |
| language | No | Exact language label, e.g. Arabic. Missing language data does not imply the service is unavailable. | |
| service_ids | No | Directory category IDs returned by list_ndis_services. Multiple IDs require all categories; these are not NDIS billing item codes. | |
| accepting_only | No | Only claimed listings reporting they accept participants; not a live vacancy guarantee. | |
| registered_only | No | Defaults to NDIS registered listings. False includes other directory registration statuses. |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| total | Yes | |
| next_page | Yes | |
| providers | Yes | |
| source_url | Yes | |
| limitations | Yes | |
| total_pages | Yes | |
| retrieved_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful non-obvious context beyond annotations: page size (up to 20), ordering by name, returned fields (registration status, review data, citation URLs), and a prompt to ask for missing service/location. It does not mention rate limits or data staleness, keeping it from 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?
The description is four tight sentences, front-loaded with the primary usage condition. Each sentence earns its place: purpose, return shape, missing-input guidance, and exclusions. No redundant or filler text.
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 the tool has a full output schema and comprehensive annotations, the description covers the remaining agent-facing needs: when to use, what the response contains, ordering and pagination expectations, missing-input handling, and exclusions. 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?
Schema description coverage is 100%, so the schema already documents all nine parameters thoroughly. The description maps the high-level facets ('support category, state, city, suburb, postcode or name') to the search dimensions and adds a note about pagination, but it does not add syntax, format, or selection guidance beyond what the schema provides. Baseline 3 is appropriate.
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 ('find or compare'), resource ('Australian NDIS providers'), and the facets used for filtering (support category, state, city, suburb, postcode, name). It also signals the search/list shape by stating it returns up to 20 listings per page, which distinguishes it from a single-provider lookup tool like get_ndis_provider.
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 explicitly states when to use the tool ('when someone wants to find or compare...') and gives clear exclusions ('Do not use for diagnosis, funding eligibility, emergency help, booking or sending enquiries'). It also says to ask for service or location if missing. It does not explicitly name alternative sibling tools, so it falls short of the 5-level rubric for naming alternatives.
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_ndis_providerlist_ndis_servicessearch_ndis_providersFree source-backed NDIS pricing, packaging, care and licensing tools; searchable register previews.
Agent-readable search over the NDIS Provider Register (CC BY 4.0 AU) by location and service.
Search 118,000+ Australian manufacturers by category and state, with Business contact access.
Australian company search by name, ABN, ACN, ABN status, state and postcode, with trading names.
Add one secure layer between your agents and this server.
