AdvisorFinder MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.3
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.
Average 3.7/5 across 6 of 6 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 35 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![advisorfinder-mcp MCP server](https://glama.ai/mcp/servers/drew-keever/advisorfinder-mcp/badges/card.svg)](https://glama.ai/mcp/servers/drew-keever/advisorfinder-mcp)

Score Badge

Copy to your README.md:

[![advisorfinder-mcp MCP server](https://glama.ai/mcp/servers/drew-keever/advisorfinder-mcp/badges/score.svg)](https://glama.ai/mcp/servers/drew-keever/advisorfinder-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/drew-keever/advisorfinder-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server