asset-management
Server Quality Checklist
Latest release: v2.12.2
- Disambiguation5/5
Each tool has a clearly distinct purpose: onboarding allocation, portfolio summary, risk analysis, rebalancing, fund facts, gap discovery, ticker screening, and strategic allocation. There is no ambiguity between any pair.
Naming Consistency4/5All names use snake_case with two words, but the pattern mixes verb_noun (discover_gaps, screen_candidate, propose_allocation), noun_noun (portfolio_summary, risk_report, securities_facts), and adjective_noun (starter_allocation). It is mostly consistent and readable, but not perfectly uniform.
Tool Count5/5With 8 tools, the server is well-scoped for an asset management assistant. Each tool serves a distinct function without unnecessary overlap, covering core operations like allocation, analysis, rebalancing, and screening.
Completeness5/5The tool surface covers the full lifecycle of portfolio management: starting allocation, strategic proposal, performance reporting, risk analysis, rebalancing, fund information, gap identification, and new investment screening. No obvious gaps are present for a read-only advisory system.
Average 4.6/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 70 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
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.
This server has been verified by its author.
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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds 'offline, read-only' but does not provide additional behavioral details beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the output and use case. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema present, the description sufficiently covers the tool's purpose and content. It provides complete guidance for a simple read-only query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description does not add parameter info, but none is needed. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'current holdings + P&L + annualized returns' and its use case ('what do I hold / how am I doing'), distinguishing it from sibling tools like starter_allocation or risk_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to answer...' guiding the agent on when to invoke this tool. However, it does not mention when not to use it or provide alternatives among siblings.
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?
Annotations already declare readOnlyHint and idempotentHint. The description adds that the tool is offline, never trades, and that new target tickers cannot be sized (appear under 'unpriced'), providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph that conveys all necessary information without redundancy. It could be slightly better structured (e.g., bullet points), but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description need not detail return values. It covers modes, cash behavior, offline limitations, and unpriced tickers, providing sufficient context for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully explains the 'mode' enum values and the role of 'new_cash', including requirements (e.g., requires > 0 for certain modes) and default behavior (all HOLD if 0). This adds essential meaning beyond the schema's basic types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces buy/sell/hold suggestions to move holdings toward target allocation, distinguishes itself by listing four specific modes and noting it is read-only and offline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains each mode and when they are appropriate (e.g., 'bands' only activates on threshold breach; 'fixed_dca' and 'cash_flow_only' require new_cash > 0). It does not directly contrast with sibling tools, but the context of rebalancing vs. other portfolio tools is implied.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds 'offline, read-only' which is consistent but does not provide additional behavioral traits beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but slightly dense with parenthetical details. It is front-loaded with main purpose. Could be broken into clearer structure, but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0 parameters, rich annotations, and existing output schema, the description covers the tool's purpose, usage, and behavioral constraints completely. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description does not need to add parameter info. Baseline 4 for 0 params is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's a drawdown-first risk panel for the held portfolio, listing specific metrics (max drawdown, Ulcer, CDaR, Sharpe, etc.). It distinguishes itself from portfolio_summary by noting it computes time-weighted return.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use cases: answering 'how risky / how deep are the drawdowns' and computing time-weighted return that portfolio_summary cannot. No alternative tools mentioned but sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by specifying that the tool never trades, never gives recommendations or return forecasts, and that weights are deterministic. It also notes a cache dependency for the verdict, providing actionable behavioral context. No contradiction with readOnlyHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively compact, packing multiple pieces of information into a single paragraph. It is front-loaded with the core purpose and then adds usage guidance and behavioral notes. Minor redundancy exists (e.g., restating 'propose-only'), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two parameters, validation logic, cache-dependency), the description covers the essential behaviors: what it does, what it returns, and key caveats. The presence of an output schema reduces the need to describe return structure in detail, making this sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description effectively explains both parameters: preset maps to risk posture categories (conservative/moderate/aggressive) and benchmark maps to canonical references (60-40/all-weather/permanent/none). It adds the use of benchmark='none' to skip validation, which is not evident from the enum alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a precise action: propose a strategic target allocation for a given risk posture, validated against a reference benchmark, with a drawdown verdict. It clearly distinguishes from sibling tools by emphasizing its 'propose-only' nature and deterministic core, avoiding confusion with recommendation or trading tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('Use to answer...') and provides a conditional instruction ('Pass benchmark='none' to skip validation'). It gives clear context for invocation, though it does not explicitly name alternative tools or when not to use this one.
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?
Adds context beyond annotations (offline, propose-only, fetching price history on demand). Aligns with readOnlyHint and openWorldHint. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each informative. Front-loaded purpose, followed by behavioral notes and constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input, process, constraints (offline, propose-only), output characteristics (reasons with figures), and edge case (price history fetch). Output schema exists, so no need to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description clarifies that 'ticker' is a NEW candidate to judge. Single parameter and purpose-driven description compensate for lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Judge' and resource 'a NEW ticker against the user's book', with explicit use case 'is TICKER a good fit'. Distinct from siblings which focus on portfolio-level analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case and what the tool is not for (buy recommendation, return forecast). Mentions conditional behavior with ASSET_MCP_OFFLINE, but does not list alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and description reinforces 'offline, read-only'. Adds valuable context about 7-day metadata cache and 'missing' for uncached holdings, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with three sentences, each serving a clear purpose: statement of capability, usage examples, and caching behavior. Front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, data returned, caching, and example questions. With output schema likely defining return structure, additional detail on error handling or limits would be useful but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has 0 parameters, so schema coverage is 100%. Description need not add parameter info; the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns fund facts (type, expense ratio, AUM, volume, age, category) for each user holding. Distinguishes from sibling tools by specifying it's about holdings' facts, not allocation or summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides use cases: 'what am I paying / how big / how liquid / how old are my funds'. Mentions cache behavior and 'missing' handling, but lacks explicit when-not-to-use comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds further behavioral context: 'offline, read-only, propose-only', deterministic results, and specific edge-case behavior (sector-equity handling). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but each sentence adds value. It is front-loaded with the main purpose and then covers exceptions and usage details. Minor redundancy could be trimmed, but overall it is well-structured and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 2 optional parameters, no required ones, and an output schema exists (though not shown), the description covers all necessary aspects: what is returned (gaps with comparable funds, core funds first, other_shelves), how parameters affect output, and edge cases. Completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must fully explain parameters. It explains `role` by listing the roles implicitly and noting special handling for 'sector-equity'. It explains `flavor` as 'add flavor= to see one shelf's funds'. This adds significant meaning beyond the schema's enum and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: identifying portfolio gaps (roles ≤3% market value) and suggesting comparable funds from a standard shelf. It distinguishes itself by mentioning a sibling tool `screen_candidate` for further detail, and specifies what it does not do (e.g., flag sector-equity as a gap).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use to answer what am I missing / what could I consider adding'. It also provides when-not-to-use guidance (sector-equity not flagged, calling with specific role to see shelf map) and notes that broad funds may already cover the role, giving the agent clear decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotent), description adds that the mapping is a fixed, explainable rubric (never a guess) and that it is propose-only, not a forecast, providing valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise four-sentence paragraph, front-loaded with the action, followed by essential details and exclusions. No wasteful language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 enum parameters, output schema present), the description covers inputs, mapping logic, validation step, and behavioral limitations, making it fully actionable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description lists all three required parameters with their enum values and explains the mapping to a posture and benchmark validation, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool converts user risk answers to a starting allocation, specifies inputs (three onboarding answers), and distinguishes from sibling propose_allocation by noting it uses a fixed, hand-designed rubric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to ask the three questions in plain language first, then call with answer tokens. Also clarifies it is not a recommendation or return forecast, and that propose_allocation is a similar tool.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/disin7c9/asset-management'
If you have feedback or need assistance with the MCP directory API, please join our Discord server