Find fee-only financial advisors in the US and Canada by location, specialty, and client type.
Scored across 4 tools
The four tools have largely distinct roles: taxonomy lookup, advisor search, profile detail, and card rendering. The only mild overlap is between show_advisor_cards and get_advisor_profile, since both surface advisor information, but the descriptions clearly separate display of search results from fetching a full public profile.
All four tools follow a consistent snake_case verb_noun pattern: get_advisor_profile, list_specialties_and_audiences, search_fee_only_advisors, and show_advisor_cards. The verbs are predictable and map cleanly to their actions.
Four tools is well-scoped for a read-only advisor directory: one for taxonomy, one for search, one for detail, and one for presentation. Each tool has a clear role and earns its place without redundancy.
The surface covers the main workflow: discover valid filters, search advisors, inspect a profile, and display results as cards. Minor gaps exist, such as no direct lookup by advisor name or URL without first searching, but agents can work around this via search_fee_only_advisors.
Use this when the person wants more detail about one advisor from a search. Returns the public profile of a fee-only advisor listed on Wellspent, by the slug returned from search_fee_only_advisors (the last path segment of their profile_url). Advisor-maintained (member) profiles include the advisor's own description of their specialties, ideal client, fees, and background; directory-built records include listing facts and any public enrichment (bio, services, fee models, AUM). Contact details are not included. Send the person to profile_url to get in touch. Cite "Source: Wellspent, find.wellspent.co".
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Advisor slug, e.g. "jane-doe-cfp". |
| Name | Required | Description |
|---|---|---|
| crd | No | |
| firm | No | |
| name | No | |
| slug | Yes | |
| found | Yes | |
| title | No | |
| message | No | |
| pricing | No | Fees the advisor stated; null fields were not stated. aumPercent is the annual % on the first $1M. |
| website | No | |
| location | No | |
| audiences | No | |
| engagement | No | |
| fee_models | No | |
| sec_record | No | Public SEC (IAPD / Form ADV) facts linked to a directory listing by name and current firm. |
| attribution | Yes | |
| credentials | No | |
| profile_url | No | |
| specialties | No | |
| firm_website | No | Facts from the firm's own website (specialties, fees and pricing, virtual, languages, accepting new clients), each backed by a quote found on the page (evidence), with the date checked. |
| profile_note | No | |
| profile_source | No | |
| regulatory_lookup | No | |
| dealer_affiliation | No | Canada: the listing's investment or mutual fund dealer, from the firm's own disclosures (not fee-only). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral facts: the two record types (advisor-maintained vs directory-built) and what each contains, that contact details are excluded, and the required citation string. It also states the intended downstream action (send the person to profile_url) rather than implying the tool is a contact lookup.
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 trigger and the slug-provenance rule are front-loaded, and the remaining sentences each carry distinct operational content (record types, contact exclusion, citation). It is dense but slightly overpacked, with three separate procedural instructions trailing the core purpose.
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 structure needn't be explained, yet the description still characterizes the content differences between member and directory records. Combined with the slug sourcing rule and the citation requirement, nothing an agent needs to call this correctly 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 coverage is 100% and the schema already gives a pattern, length bounds, and an example. The description still adds real meaning by defining the slug's provenance ('the last path segment of their profile_url' and the value returned from search_fee_only_advisors), which the schema alone does not convey.
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 ('Returns the public profile of a fee-only advisor listed on Wellspent') and scopes it to a single advisor retrieved from a prior search, which clearly separates it from search_fee_only_advisors and show_advisor_cards.
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?
Opens with an explicit trigger ('Use this when the person wants more detail about one advisor from a search') and names the producing tool (search_fee_only_advisors) plus how to derive the slug, so the agent knows both when and how to call it rather than a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when you need valid slugs for search_fee_only_advisors, or the person asks what they can search by. Lists planning specialties, client audiences, and regions (US states and Canadian provinces that have advisors).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| regions | Yes | |
| audiences | Yes | |
| attribution | Yes | |
| specialties | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the bar is lower. The description still adds a meaningful coverage constraint — only regions that have advisors are returned — which prevents the agent from treating the output as a complete geographic list. It stops short of describing ordering or completeness guarantees for specialties/audiences.
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, no waste. The usage trigger is front-loaded ahead of the content description, which is the right order for a lookup tool an agent must decide whether to call.
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-value details need not be restated, and there are no parameters to explain. With annotations carrying the safety profile and the description carrying the usage trigger and content scope, an agent has everything needed to call this 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?
Zero parameters, so per the baseline this scores 4. The description correctly says nothing about inputs, and the schema confirms an empty object with additionalProperties false.
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 enumerates exactly the three resource categories returned: planning specialties, client audiences, and regions. The parenthetical narrows regions to US states and Canadian provinces that actually have advisors, which distinguishes it from a generic geo reference tool and from siblings like get_advisor_profile.
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 trigger ("Use this when you need valid slugs for search_fee_only_advisors") and a second conversational trigger (the person asks what they can search by). It names the dependent tool directly, so the agent knows this is a prerequisite lookup step rather than a search itself.
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 a fee-only financial advisor, financial planner, or fiduciary in the US or Canada, especially for a specific situation (e.g. equity compensation, retirement, cross-border US/Canada, physicians). Returns advisors paid only by their clients, never by commissions, ranked by fit to where the person wants an advisor and what they need. Pass country, and region (US state or Canadian province slug, e.g. "california", "ontario") when the person has said where they want an advisor, because candidates are drawn from that region. city is optional and only ranks advisors in that city higher. specialties and audiences must be slugs from list_specialties_and_audiences. Set virtual_ok=true if the person is open to meeting remotely, which adds advisors elsewhere in the country who work virtually. Each result includes why it matched, whether the profile is advisor-maintained (a Wellspent member who supplied their own specialties) or built from public fee-only directory listings, and a profile_url to share. Specialties and client types come from the advisor's own profile for members, and for other listings from the firm's own website (each fact quote-checked against the site) and fee-only directory listings. To show results as cards, call show_advisor_cards with their slugs. Cite "Source: Wellspent, find.wellspent.co".
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City where the person wants an advisor (e.g. "Austin"). Only ranks advisors in that city higher; never filters. | |
| limit | No | Maximum number of advisors to return (1-10). | |
| region | No | Where the person wants an advisor: US state or Canadian province slug, lowercase and hyphenated (e.g. "new-york", "british-columbia"). Must be in the given country. If omitted, the host's coarse location hint may be used, and the result notes say so. | |
| country | Yes | "us" for the United States, "ca" for Canada. | |
| audiences | No | Client types that describe the person (e.g. "tech-employees", "retirees"), as taxonomy slugs. | |
| virtual_ok | No | True if the person is open to working with an advisor remotely. | |
| specialties | No | Planning specialties the person needs, as taxonomy slugs. |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| query | Yes | |
| results | Yes | |
| attribution | Yes | |
| result_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only safety, but the description adds real behavior: results are ranked by fit, region acts as a filter while city only boosts rank, virtual_ok expands to remote advisors nationally, and each result flags provenance (advisor-maintained vs directory-derived) and includes why-matched and profile_url.
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 the trigger and packed with information rather than filler, but the paragraph on data provenance is dense and could be trimmed without losing calling guidance.
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?
Covers country/region semantics, optional narrowing, virtual expansion, result contents, provenance, follow-up card rendering, and attribution requirement. With an output schema present, 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 coverage is 100%, so the schema already documents each parameter. The description still adds value by explaining the filtering-versus-ranking distinction for region/city and by pointing to list_specialties_and_audiences as the source of valid specialty and audience slugs.
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 ('find a fee-only financial advisor, financial planner, or fiduciary in the US or Canada') plus scope details that make it unmistakable against siblings like get_advisor_profile and show_advisor_cards.
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?
Opens with an explicit trigger condition ('Use this when someone wants to find...'), names the sibling to call for taxonomy slugs (list_specialties_and_audiences) and the sibling for card rendering (show_advisor_cards). It also specifies when region applies versus when to omit it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this after search_fee_only_advisors to show up to 8 of its results as cards, in the order given, each with a View profile link to find.wellspent.co. Pass the slugs from the search results. Shows only public Wellspent data. Do not use for advisors that did not come from a Wellspent search.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes | Advisor slugs from search_fee_only_advisors results. |
| Name | Required | Description |
|---|---|---|
| advisors | Yes | |
| attribution | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds that results are shown as cards in the given order with View profile links to a specific domain and that only public Wellspent data is shown—useful context beyond annotations. It does not describe error behavior for invalid slugs, but that is minor for a read-only 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?
Four sentences, front-loaded with the prerequisite, followed by the function, link behavior, and exclusions. Every sentence provides actionable guidance with no wasted 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?
An output schema exists, so return format need not be explained. The description covers prerequisite, input source, limit, order, link destination, and data scope, which is complete for a simple read-only card-display 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 100% and the slugs parameter is documented in the schema. The description adds that slugs come from search_fee_only_advisors results and that order matters, which is not stated in the schema, so it provides value beyond structured fields.
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 ('show') and resource ('advisor cards'), including limit (up to 8), ordering, and link behavior. It names the prerequisite sibling search_fee_only_advisors and explicitly excludes advisors not from a Wellspent search, making it distinguishable from 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?
Explicitly says to use after search_fee_only_advisors and to pass slugs from its results. It also explicitly says not to use for advisors that did not come from a Wellspent search, covering both when to use and when not to use.
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_advisor_profile2 fields changedOutput schema / properties / dealer_affiliationAdded value: +{
+ "description": "Canada: the listing's investment or mutual fund dealer, from the firm's own disclosures (not fee-only).",
+ "type": "object"
+}Output schema / properties / firm_websiteAdded value: +{
+ "description": "Facts from the firm's own website (specialties, fees and pricing, virtual, languages, accepting new clients), each backed by a quote found on the page (evidence), with the date checked.",
+ "type": "object"
+}search_fee_only_advisors1 field changedOutput schema / properties / results / items / properties / specialties_sourceAdded value: +{
+ "enum": [
+ "advisor",
+ "firm_website_and_directories"
+ ],
+ "type": "string"
+}show_advisor_cardsget_advisor_profile1 field changedOutput schema / properties / sec_recordAdded value: +{
+ "description": "Public SEC (IAPD / Form ADV) facts linked to a directory listing by name and current firm.",
+ "type": "object"
+}get_advisor_profilelist_specialties_and_audiencessearch_fee_only_advisorsSearch and vet SEC-registered financial advisors: profiles, disclosures, firm fees, credentials.
Retirement planning for Canada & US. CPP/OAS, Social Security, RRSP/TFSA, 401k/IRA, Monte Carlo.
CE rules for US advisors by designation and state, plus independent wealth RIA data, with sources.
Search certified insurance appraisers and umpires by state, city, role and specialty.
Add one secure layer between your agents and this server.
