Skip to main content
Glama

Wellspent: fee-only financial advisors

Get a fee-only advisor's public profile

get_advisor_profile
Read-onlyIdempotent

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".

Input Schema

NameRequiredDescriptionDefault
slugYesAdvisor slug, e.g. "jane-doe-cfp".

Output Schema

NameRequiredDescriptionDefault
crdNo
firmNo
nameNo
slugYes
foundYes
titleNo
messageNo
pricingNoFees the advisor stated; null fields were not stated. aumPercent is the annual % on the first $1M.
websiteNo
locationNo
audiencesNo
engagementNo
fee_modelsNo
sec_recordNoPublic SEC (IAPD / Form ADV) facts linked to a directory listing by name and current firm.
attributionYes
credentialsNo
profile_urlNo
specialtiesNo
firm_websiteNoFacts 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_noteNo
profile_sourceNo
regulatory_lookupNo
dealer_affiliationNoCanada: the listing's investment or mutual fund dealer, from the firm's own disclosures (not fee-only).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / dealer_affiliation
      Added value: +{
      +  "description": "Canada: the listing's investment or mutual fund dealer, from the firm's own disclosures (not fee-only).",
      +  "type": "object"
      +}
    • addedOutput schema / properties / firm_website
      Added 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"
      +}
  2. Changed1 schema field changed
    • addedOutput schema / properties / sec_record
      Added value: +{
      +  "description": "Public SEC (IAPD / Form ADV) facts linked to a directory listing by name and current firm.",
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources