How do I use AdvisorFinder MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AdvisorFinder MCP Server search for advisors in New York named Smith" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

AdvisorFinder MCP Server

Q: What can you do with this server?

This server provides AI assistants with access to SEC-registered financial advisor data for searching, looking up profiles, risk assessment, and more. It integrates with MCP-compatible clients like Claude Desktop, allowing natural language queries without initially requiring CRD numbers. * Search advisors (search_advisors): Find investment advisors by name, state, or firm — no CRD number needed to start. * Full advisor profiles (lookup_advisor): Retrieve detailed regulatory data including employment history, office location, registered states, years of experience, designations, exams, outside business activities, disclosures, and risk scores. * Quick verification (verify_advisor): Get active status, current firm, disclosure summary, risk score, and a recommendation. * Risk assessment (get_risk_profile): Obtain a detailed risk profile with individual risk factors and severity ratings. * Firm information (get_firm_info): Access firm overview including advisor count, disclosure rates, and location. * Database statistics (get_database_stats): Get overall statistics like total advisors (433,000+), active counts, firms, disclosure rates, top states, and data freshness. * Fallback links: If an advisor isn't found, all tools return direct links to SEC IAPD and FINRA BrokerCheck for further research. * Contextual resources: AI assistants can read resources on risk scoring methodology, financial advisor credentials, and data sources to enhance responses.

by drew-keever

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

AdvisorFinder MCP Server

An MCP server that gives AI assistants access to SEC-registered financial advisor data — search advisors by name, look up full profiles, check disclosure status, and review firm fees, all from within Claude or any MCP-compatible client.

Built by AdvisorFinder.

Quick Start

Remote server (recommended)

The fastest way to use this — no install, always up to date. Point your MCP client at:

https://mcp.advisorfinder.com/mcp

Claude (custom connector): Settings → Connectors → Add custom connector → paste the URL above.

Claude Code:

claude mcp add --transport http advisorfinder https://mcp.advisorfinder.com/mcp

pip / uvx (stdio)

Prefer a local stdio process — e.g. for MCP clients that don't yet support remote/HTTP servers directly? Install the package; it runs a thin stdio proxy in front of the same remote server above.

pip install advisorfinder-mcp

{
  "mcpServers": {
    "advisorfinder": {
      "command": "advisorfinder-mcp"
    }
  }
}

Or with uvx (no install needed):

{
  "mcpServers": {
    "advisorfinder": {
      "command": "uvx",
      "args": ["advisorfinder-mcp"]
    }
  }
}

By default the proxy talks to https://mcp.advisorfinder.com/mcp. To point it at a different deployment (e.g. staging), set ADVISORFINDER_MCP_URL:

{
  "mcpServers": {
    "advisorfinder": {
      "command": "advisorfinder-mcp",
      "env": { "ADVISORFINDER_MCP_URL": "https://staging.example.com/mcp" }
    }
  }
}

Related MCP server: SEC EDGAR MCP

What You Can Ask

Once configured, just talk to Claude naturally:

"Look up financial advisor Thomas Kopelman"
"Search for advisors named Smith in New York"
"Give me the full profile on Jane Doe at Wells Fargo"
"Is my advisor's registration active? Their name is John Doe, he's at Edward Jones in Texas"
"Does John Doe have any disclosures on file?"
"Tell me about Edward Jones as a firm — how many advisors do they have, and what do they charge?"
"How many registered advisors are in the SEC database, and how fresh is the data?"
"Find a fee-only advisor near Austin I can actually book a call with"

No CRD numbers needed — search by name, firm, city, or state.

Tools

Tool	Description
`search_advisors`	Search SEC-registered investment adviser representatives by name, firm, city, and/or state. Returns CRD, name, linked firm(s), a four-state disclosure status, and an SEC IAPD link per match.
`get_advisor`	Full profile by CRD: employment history, exams, state investment-adviser registrations, self-reported professional designations, years in the industry, and four-state disclosure status.
`check_advisor`	Quick verification by CRD or name (optionally narrowed by firm/state): is the registration active, their state investment-adviser registrations, how long in the industry, and disclosure status. Never returns a numeric risk score — only the underlying facts.
`find_bookable_advisors`	Search advisors listed on AdvisorFinder's marketplace — a few hundred members with public profiles you can view and contact directly (optionally filtered by specialty, city, and/or state). Returns each member's self-provided profile info, a link to their full AdvisorFinder profile, and regulatory facts for their CRD: the same registration + four-state disclosure status as any other advisor when their CRD is in our SEC dataset, or a labeled "not in our SEC dataset" note with verify links when it isn't (typically state-registered or BD-side advisors) — never presented as if clean.
`search_firms`	Search SEC- and state-registered investment adviser firms by name and/or state. Returns CRD, name, city/state, AUM band, advisor headcount, and an SEC IAPD link. State-registered-only firms are included but flagged — purely state-registered firms have no advisor rosters at all; state-listed firms showing rosters are dual-registered.
`get_firm`	Full firm profile by CRD: locations, other/prior names, fee schedule (from Form ADV Part 2A where available), disciplinary flags, and advisor roster count.
`get_database_stats`	Database-wide stats: firm and advisor counts, data vintages (as-of dates for each upstream source), and a full four-state disclosure tally.

Disclosure status is always one of four honest states — none_reported, disclosed_no_detail, disclosed_with_detail, or unknown — never phrased as "clean" or "safe." When we don't have a record for someone, every tool returns direct links to SEC IAPD and FINRA BrokerCheck so you can still look them up through official sources.

Resources

Resource	Description
`advisorfinder://credentials-guide`	Guide to financial advisor credentials — CFP, CFA, CPA, ChFC, Series 7/65/66, and more (all self-reported; not independently verified here).
`advisorfinder://data-sources`	About SEC IAPD, FINRA BrokerCheck, what we store vs. don't, and how to verify data independently.
`advisorfinder://coverage-and-limitations`	What's covered, what isn't (state-only firms, disclosure detail, verified designations, the AdvisorFinder marketplace), and what an empty result actually means.

Data & Limitations

Coverage: SEC-registered investment adviser firms and the active investment adviser representatives (IARs) linked to them. Advisor rosters cover IARs at SEC-registered advisers only — complete as of 2026-08 (416,000+ active IARs; validated within 1% of FINRA's CRD statistics, and per-firm against Form ADV Item 5 self-reports). Purely state-registered advisers (~16k firms, ~47k IARs per NASAA) have no rosters; state-listed firms showing rosters are dual-registered. An empty roster for a state-registered firm means not covered, not empty. Use get_database_stats for current firm/advisor counts and per-source data vintages (as-of dates), which move independently of this package's version.

Disclosure detail is deliberately not republished here. We store and surface a disclosure status (one of the four states above), never the underlying event narratives, allegations, or settlement amounts. Always check FINRA BrokerCheck or SEC IAPD directly for the full disclosure record before making any decision.

Designations are self-reported. Every professional designation (CFP, CFA, etc.) shown here comes from the advisor's own filing — none of it is independently verified against the issuing body. Check directly with the issuing body if a credential matters to your decision.

No numeric risk score. This server intentionally does not compress disclosure/registration facts into a single risk number — it surfaces the underlying facts so you can judge for yourself.

AdvisorFinder marketplace. Some advisors are listed on AdvisorFinder's marketplace (find_bookable_advisors, and enrichment on other tools' results). Their listings add self-provided profile information and a link to contact them. Being listed is a business relationship with AdvisorFinder — it is labeled on every result, never affects search ranking, and is not an endorsement. Regulatory data is shown identically for all advisors. AUM and client-count figures in marketplace listings are self-reported, always labeled "as listed on their AdvisorFinder profile." Some marketplace members are state-registered or broker-dealer-side advisors whose records may not appear in our SEC-roster data — those results are clearly labeled, with FINRA BrokerCheck / SEC IAPD verify links included.

Disclaimer

This MCP server is provided by AdvisorFinder and is intended for informational and research purposes only. It is not financial, legal, or investment advice.

The data served through this tool originates from publicly available SEC and FINRA databases. AdvisorFinder acts as an intermediary to make this public data more accessible — we do not independently verify, endorse, or guarantee the accuracy or completeness of the underlying data.

Important:

A disclosure on an advisor's record does not necessarily indicate wrongdoing. Always review the full context of any disclosure event through official SEC and FINRA sources.
AI assistants may interpret or summarize data in ways that are incomplete or inaccurate. Always verify AI-generated assessments against official sources before making decisions.
This tool should not be used as the sole basis for selecting, evaluating, or dismissing a financial advisor.

Changelog

2.1.0 — Marketplace layer

Non-breaking addition on top of 2.0.0:

New tool: find_bookable_advisors — search AdvisorFinder marketplace members (a few hundred advisors) by specialty, city, and/or state; returns their self-provided profile info plus regulatory facts for their CRD (the same registration + four-state disclosure status as any other advisor when the CRD is in our SEC dataset, or a labeled "not in our SEC dataset" note with verify links when it isn't).
Marketplace enrichment. search_advisors, get_advisor, and check_advisor now include a labeled AdvisorFinder marketplace listing block on results for advisors who are marketplace members — never an endorsement, never affecting ranking.
get_database_stats now reports a marketplace member count and snapshot date.
New resource copy: advisorfinder://coverage-and-limitations documents the marketplace layer.

2.0.0 — Breaking changes

This is a full rebuild, not an incremental update:

New toolset. verify_advisor → check_advisor; lookup_advisor → get_advisor; get_risk_profile is removed; search_firms and get_firm are new.
Numeric risk score removed entirely. v1's get_risk_profile tool and the advisorfinder://risk-scoring-methodology resource are gone. Disclosure information is now surfaced only as the four honest states described above — never compressed into a score.
Backend replaced. The server now reads from a local, periodically-refreshed SQLite export instead of querying upstream sources live per-request.
v1.x clients should upgrade. The old v1 API surface (verify_advisor, lookup_advisor, get_risk_profile, advisorfinder://risk-scoring-methodology) is being retired and will stop working. Update to the new tool names and drop any reliance on risk scores.

Available Tools

6 tools

get_database_statsAInspect

Get overall statistics about the SEC advisor database including total advisors, active count, firms, disclosure rates, and top states.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description does not disclose any behavioral traits beyond a basic read operation. With no annotations provided, it fails to mention non-obvious aspects such as whether the data is cached, return format, or any side effects. It merely lists some output fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that conveys the tool's purpose and key outputs without any superfluous information. Every part is informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (no parameters, no nested objects) and the existence of an output schema, the description provides adequate context. However, it could be slightly improved by mentioning that the output is aggregate-only and not filtered by user or workspace.

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?

The tool has zero parameters, so no parameter documentation is needed. The absence of parameters is reflected in the empty input schema. The description adds no parameter information, but the base score for zero parameters is 4.

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?

The description clearly states it retrieves overall statistics about the SEC advisor database and explicitly lists the types of statistics included (total advisors, active count, firms, disclosure rates, top states). This is distinct from sibling tools that focus on individual firms, risk profiles, or specific advisor lookups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus its siblings. For example, it does not clarify that this tool is for aggregate stats while get_firm_info is for individual firm details. The agent must infer usage from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_firm_infoBInspect

Get information about an investment advisory firm including advisor count, disclosure rates, and statistics.

ParametersJSON Schema

Name	Required	Description	Default
`firm_crd`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must stand alone. It indicates a read operation ('Get information'), but does not disclose potential side effects, authentication needs, rate limits, or other behavioral traits beyond the obvious. It is adequate but not enriched.

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 description is a single, front-loaded sentence that efficiently conveys the tool's purpose. It is concise without being overly terse, though it could benefit from light structuring.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter and an output schema exists (though not evaluated), the description sufficiently covers the retrieval of firm information. It does not mention optional parameters (none exist) and is adequate for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description does not explain the 'firm_crd' parameter (likely a CRD number). The parameter name is somewhat self-explanatory, but the lack of explicit semantics leaves room for misinterpretation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves information about an investment advisory firm, listing specific data types like advisor count, disclosure rates, and statistics. While distinct from sibling tools (which target advisors or global stats), it does not explicitly differentiate itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor any exclusion criteria. The description only states what it does, leaving the agent to infer appropriate usage contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_risk_profileBInspect

Get a detailed risk assessment for an investment advisor including risk score, risk factors with severity levels, and recommendation.

ParametersJSON Schema

Name	Required	Description	Default
`crd_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It does not mention behavioral traits such as read-only nature, authentication needs, rate limits, or whether it requires advisor existence. The description only states what it returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that is direct and front-loaded with the purpose. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the return values are implied. The description covers key components (score, factors, severity, recommendation). However, it lacks context on when this is appropriate (e.g., IAR vs firm) and if the advisor must exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'crd_number' is not explained in the description. Schema coverage is 0%, meaning no description in schema either. The description should clarify that crd_number is the unique identifier for the advisor.

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?

The description clearly states the verb 'Get' and the resource 'detailed risk assessment for an investment advisor', specifying the contents: risk score, risk factors with severity levels, and recommendation. It distinguishes from sibling tools like get_firm_info or lookup_advisor by focusing on risk profile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., when you need a full advisor profile vs risk assessment). No context on prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_advisorAInspect

Look up a registered investment advisor by their CRD number. Returns regulatory data from SEC IAPD: employment history, registrations, exams, designations, disclosures, and risk scoring.

IMPORTANT: When presenting results to users, always include ALL returned data — especially employment_history (shows career timeline and actual office location), designations (professional credentials), exams (indicates years of experience from earliest exam date), and registrations (licensed states). Calculate years of experience from the earliest exam or employment date. If the user asks for a 'full profile', also do a web search to find the advisor's practice name, team, awards, and specializations.

ParametersJSON Schema

Name	Required	Description	Default
`crd_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses the tool's behavior: it returns regulatory data from SEC IAPD and lists specific fields. It also instructs on experience calculation and web search integration. Missing details like data freshness, rate limits, or error handling, but the coverage is good for a simple 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 description is structured with a purpose statement followed by usage instructions. It is about 150 words, front-loaded, and each sentence adds value. Could be slightly more concise but is appropriate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter, no annotations, and an output schema (assumed to describe return fields), the description covers the tool's functionality and output handling. It does not address error cases or invalid inputs, but for the complexity level, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions the CRM number parameter but does not explain its format (e.g., numeric, length). Since schema coverage is 0%, the description adds the basic meaning but lacks detail. For a single integer parameter that is domain-specific, this is minimally adequate.

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?

The description uses a clear verb ('Look up') and specifies the resource ('registered investment advisor') with a unique identifier ('CRD number'). It enumerates the returned data fields, which distinguishes it from siblings like 'search_advisors' (which likely supports different query parameters) and 'get_firm_info' (firm-level).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit instructions on how to handle the returned data: always include all fields, calculate years of experience, and perform a web search for a 'full profile'. It implies the tool's limitation (no practice name, team, etc.) but does not explicitly state when not to use this tool or compare it to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_advisorsAInspect

Search for investment advisors by name, state, or firm. Name can be a full name like 'Joseph Montgomery' or just a last name like 'Montgomery'.

After finding results, use lookup_advisor with the CRD number to get the full profile. If no results found, suggest the user check FINRA BrokerCheck and SEC IAPD directly — links are provided in the response.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No
`state`	No
`firm`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It discloses that the response includes external links and that the tool supports partial name matches. However, it does not explicitly state that the operation is read-only or mention any potential side effects. Overall, it provides sufficient transparency for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences. The first sentence states the purpose, the second gives a concrete example, and the third provides follow-up instructions. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, no required fields, a hidden output schema), the description covers the essential aspects: search criteria, follow-up action, and fallback. It explains the link to lookup_advisor. However, it does not describe the output schema or what fields are returned, which would be helpful. The existence of an output schema reduces the burden slightly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning for three parameters (name, state, firm) by explaining that name can be full or last name, and that state and firm are search criteria. However, the 'limit' parameter is not mentioned in the description, and the schema has 0% description coverage. The description partially compensates but misses the limit parameter.

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?

The description clearly states the tool's purpose: to search for investment advisors by name, state, or firm. It distinguishes itself from sibling tools like lookup_advisor by specifying the follow-up action, and it provides a clear fallback recommendation when no results are found.

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?

The description explicitly instructs when to use lookup_advisor after searching, and what to do if no results are found (check FINRA/SEC with provided links). This provides clear guidance on tool usage and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_advisorAInspect

Quick verification check for an investment advisor. Returns active status, current firm, disclosure summary, risk score, and recommendation. Use this for a quick yes/no safety check. For full details use lookup_advisor instead.

ParametersJSON Schema

Name	Required	Description	Default
`crd_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It explains that the tool returns specific data fields and is quick, but does not mention error handling, authentication requirements, or what happens if the advisor is not found. The behavioral coverage is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, each serving a distinct purpose: the first defines the tool's function and outputs, the second provides usage guidance and an alternative. No superfluous words are present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, output schema present), the description adequately covers purpose, usage, and outputs. It does not address potential errors or prerequisites, but these are less critical for a quick verification check. Overall, it is complete enough for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description adds no explanation for the single parameter 'crd_number'. It does not clarify its meaning, format, or valid ranges, forcing the agent to rely solely on the schema type (integer). Given the low coverage, the description should compensate but does not.

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?

The description explicitly states the tool performs a 'quick verification check for an investment advisor' and lists specific outputs (active status, current firm, disclosure summary, risk score, recommendation). It distinguishes itself from the sibling 'lookup_advisor' by indicating that tool is for full details.

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?

The description provides a clear directive: 'Use this for a quick yes/no safety check' and explicitly contrasts with 'lookup_advisor' for full details. This gives an agent unambiguous guidance on when to choose this tool over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.1.3May 26, 2026
- First observedget_database_stats
- First observedget_firm_info
- First observedget_risk_profile
- First observedlookup_advisor
- First observedsearch_advisors
- First observedverify_advisor

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored 2026-05-26 21:00 across 6 tools

Disambiguation4/5

Tools are mostly distinct: database stats, firm info, search, and various advisor detail levels (quick verify, risk profile, full lookup). Some overlap exists between get_risk_profile, lookup_advisor, and verify_advisor, but their descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (get_database_stats, lookup_advisor, etc.), making them predictable and easy to understand.

Tool Count5/5

With 6 tools, the server is well-scoped for an advisor lookup service—covering overview, firm info, search, full details, quick check, and risk assessment without being excessive.

Completeness4/5

The tool set covers key query types (overview, firm, search, detailed advisor info, quick check, risk). Minor gap: no direct method for a 'full profile' with web-based info, but the search tool includes instructions for that.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ko-mcp A
io.github.SharpLu
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Finance Government Data
242
openfolio
io.github.dodenbach
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Government Data Open Data Search
1
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1

Related MCP Servers

edgar-mcp
Finance Government Data
mcpwright
A
license
A
quality
B
maintenance
MCP server providing read-only access to SEC EDGAR filings, allowing LLMs to look up companies, search filings, and retrieve securities offering data.
Updated 21 days ago (2026-08-20 18:04 UTC)
3
1
MIT
SEC EDGAR MCP
Finance Government Data
stefanoamorelli
A
license
C
quality
B
maintenance
MCP server for accessing SEC EDGAR filings. Connects AI assistants to company filings, financial statements, and insider trading data with exact numeric precision.
Updated 21 days ago (2026-08-21 10:17 UTC)
21
355
AGPL 3.0
Sablier MCP Serverofficial
Finance AI & Machine Learning Research & Data
sablier-ai
A
license
A
quality
D
maintenance
An MCP server that lets AI assistants analyze portfolios, stress-test scenarios, generate synthetic market paths, and scan SEC filings — in under 2 minutes.
Updated 3 months ago (2026-05-28 05:46 UTC)
83
3
MIT
sec-edgar-mcp
Finance Government Data Open Data
guptaprakhariitr
A
license
Not graded
quality
D
maintenance
Hosted MCP server that gives AI agents real-time access to SEC EDGAR filings search, 10-K/8-K reading, XBRL financial facts, and insider-trade (Form 4) alerts.
Updated 3 months ago (2026-06-11 08:39 UTC)
15
1
MIT

AdvisorFinder MCP Server

Quick Start

Remote server (recommended)

pip / uvx (stdio)

What You Can Ask

Tools

Resources

Data & Limitations

Disclaimer

Changelog

2.1.0 — Marketplace layer

2.0.0 — Breaking changes

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Sablier MCP Serverofficial