Nexus Finance

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool has a clearly distinct purpose: market quotes (individual vs bulk), compliance case management (CRUD but missing update/delete), financial analysis, and risk calculators. No overlap in functionality.
Naming Consistency2/5
Tool names follow 'nexus_' prefix but mix patterns: verbs (analyze), adjective_noun (bulk_quotes, market_quote), noun_noun (rwa_calculator, var_calculator), and verb_noun (create_case, get_case, list_cases). Inconsistent structure makes prediction harder.
Tool Count5/5
8 tools is appropriate for a finance server covering market data, compliance, analysis, and risk calculation. Not too few or too many for the domain.
Completeness3/5
Core areas are covered (quotes, compliance, risk, analysis) but compliance lacks update and delete operations, and there is no historical data or portfolio aggregation tools. Minor gaps exist.
Average 3.6/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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.
This repository includes a glama.json configuration file.
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?
Lacks any behavioral details such as side effects, required permissions, idempotency, or what constitutes a valid case. With no annotations, the description carries full burden but only states the basic action.
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?
Single sentence with no superfluous information, but brevity sacrifices necessary context for a create tool. Efficient, but arguably under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Does not explain what a compliance case is, post-creation behavior, uniqueness constraints, or any related context. For a creation tool with no output schema, more details are needed.
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?
Schema coverage is 100%, and the description adds no new meaning beyond the schema. Baseline 3 is appropriate, as the description does not enhance understanding of parameters.
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?
Specifies the action (create) and resource (compliance case), clearly distinguishing from retrieval tools like nexus_get_case and nexus_list_cases. However, it does not explicitly differentiate from sibling creation tools (none present), so it's clear but not exceptional.
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, no prerequisites, constraints, or recommended usage context provided.
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?
Discloses caching behavior (15 min) and data source (Alpha Vantage), which provides useful context. However, without annotations, it lacks details on authentication, rate limits, or side effects for a read-only operation.
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?
Extremely concise with two sentences. The first sentence clearly states the action, and the second adds relevant behavioral info. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output details. The description says 'market quote' but does not specify return fields (price, volume, time, etc.). With no output schema, the description should provide at least an overview of results, which it does not.
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?
Schema coverage is 100% with descriptions for both parameters. The description's mention of asset types adds context but does not significantly augment the schema. Baseline score of 3 is appropriate.
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?
Description clearly states the tool retrieves a real-time market quote for equities, FX pairs, or commodities, which is specific and aligns with the tool name. It does not explicitly differentiate from sibling 'nexus_bulk_quotes', but the scope is clear.
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 like nexus_bulk_quotes or nexus_analyze. The description does not mention prerequisites, limitations, or exclusions.
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?
Without annotations, the description must reveal behavioral details. It mentions 'parametric' (implying normal distribution) and 'optional stress test scenarios' but does not specify assumptions, limitations (e.g., linear portfolio), or whether the tool is read-only. No contradictions with annotations (none exist).
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 sentence, concise and front-loaded with key outputs (VaR, CVaR, stress tests). No waste, but minimal structure; it could benefit from breaking out optional features.
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?
Given 7 parameters and no output schema, the description explains the core computation but lacks details on return format, units, or handling of edge cases. It adequately covers purpose but leaves gaps for an agent to infer behavior.
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?
Schema coverage is 100%, so each parameter has a description. The tool description adds no extra meaning beyond the schema, e.g., it does not explain how 'confidenceLevel' relates to VaR quantiles. Baseline 3 is appropriate given the schema's completeness.
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 computes parametric Value-at-Risk (VaR), Conditional VaR (CVaR), and optional stress test scenarios, using a specific verb ('Compute') and resource identification. It distinguishes from sibling tools like nexus_rwa_calculator (credit risk) and nexus_analyze (generic analysis) by specifying financial risk metrics.
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?
The description provides no guidance on when to use this tool versus alternatives, such as prerequisites (e.g., need normal distribution assumption) or contrasting with nexus_rwa_calculator for credit risk. It does not mention required input formats or constraints.
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?
With no annotations, the description must cover safety and behavior. It mentions authentication and filtering but omits requirements (e.g., permissions), whether it returns only user's cases, or rate limits. The behavioral disclosure is insufficient.
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 sentence that conveys key information without waste. It is appropriately sized and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks context about return format, ordering, error handling, or pagination details. For a list operation, more completeness is needed.
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?
Schema coverage is 100%, so baseline is 3. The description's 'Supports pagination and status filter' paraphrases schema descriptions without adding new meaning. No additional semantic value beyond schema.
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 'List', the resource 'compliance cases', and the user scope 'for the authenticated user'. It also mentions key features like pagination and status filter, distinguishing it from sibling tools like nexus_get_case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing cases but does not explicitly state when to use this tool versus alternatives like nexus_get_case for single case retrieval or nexus_create_case for creation. No exclusion or alternative guidance is provided.
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 provide behavioral transparency. It discloses that there is no LLM output and zero retention, which is relevant for data privacy. However, it does not discuss other behavioral aspects such as idempotency, authentication requirements, or error handling. This partial disclosure earns a 3.
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 extremely concise, using a single sentence with a clear verb and object, followed by a parenthetical behavioral note. Every part adds value.
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?
The tool has a single parameter and no output schema. The description clearly states the scope of returned data and a behavioral constraint (zero retention). For this level of complexity, the description is sufficiently complete. A minor gap is the lack of explicit idempotency guarantee, but that is implied.
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 input schema already describes the required parameter with a clear description. The tool description does not provide additional parameter semantics beyond what the schema offers. With 100% schema coverage, the baseline of 3 is appropriate.
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 the verb 'Get' and specifies the resource as 'full case detail including findings and counterparties'. This clearly distinguishes it from sibling tools like nexus_list_cases (list) and nexus_create_case (create). The additional note about zero retention adds clarity about data handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit usage guidelines or mention when to prefer this tool over siblings like nexus_list_cases or nexus_analyze. The purpose is clear but the context of use is only implied.
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 provided; description carries full burden. Clearly states it computes and returns RWA and capital requirement with specific percentages. No mention of side effects or permissions, but as a stateless calculator, behavioral expectations are adequately set.
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?
Two sentences, 15 words, no fluff. Front-loaded with purpose and output. Every phrase adds value.
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 nested input and no output schema, description provides useful context on what is returned (total RWA and capital requirement) and the regulatory framework (Basel III, 10.5%). Slightly lacking in output structure detail, but adequate for a calculator.
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?
Schema coverage is 100% with field descriptions. Description does not add extra meaning beyond the schema. Baseline score of 3 appropriate as description relies on schema for parameter details.
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?
Description clearly states it computes portfolio RWA using Basel III Standardized Approach and specifies output (total RWA and capital requirement). Distinct from sibling tools which cover analysis, market data, cases, and VaR.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives guidance. Implicitly clear for RWA tasks given sibling tool names, but lacks explicit instruction on when not to use or which sibling handles related computations.
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 provided, the description discloses critical behavioral traits: it returns full LLM output and is not persisted (Zero Retention). This is transparent, though additional details about auth or cost could enhance it.
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?
Two sentences, each adding value. The first sentence states the purpose, the second adds behavioral context. No wasted words.
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 no output schema and complex nested parameters, the description covers essential aspects: purpose, types, and ephemeral nature. It is sufficient for basic usage but could clarify output structure.
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?
Schema description coverage is 100%, so baseline is 3. The tool description mentions the analysis types which match the type enum, but does not add new meaning beyond the schema's parameter descriptions.
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 states 'Run a financial analysis' with a clear verb and resource. It lists four specific types (audit, briefing, playbook, commodity), distinguishing it from sibling tools that perform discrete tasks like market quotes or calculators.
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 implies usage for generating LLM-driven financial reports and notes zero retention, but does not explicitly state when to prefer this over siblings or provide exclusion criteria. It is clear but lacks explicit guidance.
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?
Without annotations, the description discloses important behavioral traits: result caching duration (15 min) and resource scope (equity, FX, commodity). It does not mention idempotency or rate limits, but for a read-only operation, the provided info is sufficient.
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, front-loaded with the goal, no unnecessary words. Every phrase adds value.
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 no output schema, the agent lacks information about the response format. However, for a simple quote retrieval tool with caching info and clear input, the description is mostly complete. Minor gap: output format.
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 has no descriptions (0% coverage), but the description explains the 'requests' parameter as a means to get up to 10 quotes, clarifying the array's purpose. It does not detail symbol format or exact enum semantics, but the core meaning is conveyed.
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?
Description clearly states verb (Get), resource (market quotes), limits (up to 10), and types (equity, FX, commodity), distinguishing it from sibling 'nexus_market_quote' which likely provides single quotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batching via 'in a single request' but does not explicitly state when to use this tool versus calling the singular sibling tool repeatedly. No alternatives or exclusions are mentioned.
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:

[![nexus-finance-mcp MCP server](https://glama.ai/mcp/servers/djtellado/nexus-finance-mcp/badges/card.svg)](https://glama.ai/mcp/servers/djtellado/nexus-finance-mcp)

Score Badge

Copy to your README.md:

[![nexus-finance-mcp MCP server](https://glama.ai/mcp/servers/djtellado/nexus-finance-mcp/badges/score.svg)](https://glama.ai/mcp/servers/djtellado/nexus-finance-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/djtellado/nexus-finance-mcp'

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