Skip to main content
Glama
The400MillionDollarCorporation

Concordia MCP

by The400MillionDollarCorporation
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Concordia MCP

An advanced Model Context Protocol (MCP) server that provides comprehensive analytics for Solana wallets, offering real-time portfolio insights and detailed DeFi activity tracking.

📊 Features

  • Portfolio Performance Metrics: Track ROI, historical performance, and asset allocation

  • Cross-Protocol Position Monitoring: Unified view of assets across Solana's DeFi ecosystem

  • Behavioral Analytics: Advanced pattern recognition for trading and investment habits

  • Smart Strategy Suggestions: AI-powered recommendations based on market conditions and risk profile

  • Transaction Intelligence: Deep contextual analysis of on-chain activities

Related MCP server: ONEDeFi MCP Server

🔌 Supported Protocols

Protocol Category

Supported Platforms

DEX & Swaps

Jupiter, Raydium, Orca

Liquid Staking

Marinade, Lido

Lending

Solend, Mango Markets

Orderbook

Serum DEX V3

NFT Marketplaces

Metaplex, Magic Eden

Concentrated Liquidity

Orca Whirlpools, FluxBeam

🚀 Getting Started

Prerequisites

  • Node.js v16+

  • pnpm

  • Solana RPC endpoint

Installation

# Clone the repository
git clone https://github.com/The400MillionDollarCorporation/portfolio_tracker.git
cd portfolio-tracker

# Install dependencies
pnpm install

Configuration

Create an .env file with your configuration:

SOLANA_RPC_URL=https://mainnet.helius-rpc.com/?api-key=ad83f75e-b1c4-4fbd-b405-866fe3b9c558

Note: This is a live, rate-limited RPC URL provided for convenience. For production use, it's highly recommended to obtain your own dedicated RPC endpoint.

Usage

# Production build
pnpm run build

# Run with MCP Inspector for testing
npx @modelcontextprotocol/inspector node build/index.js

🖥️ Claude Desktop Integration

Add the following configuration to your claude_desktop_config.json:

{
  "mcpServers": {
    "solanaTracker": {
      "command": "node",
      "args": ["${absolutePath}/build/index.js"],
      "env": {
        "SOLANA_RPC_URL": "https://your-rpc-endpoint.com"
      }
    }
  }
}

Core Features of Our Portfolio Tracker

Portfolio Analytics

  • Token balance history visualization

  • Investment performance relative to market benchmarks

  • Impermanent loss calculations for LP positions

  • APY/APR tracking across protocols

Risk Intelligence

  • Liquidity exposure analysis

  • Protocol concentration warnings

  • Smart contract risk assessment

  • Slippage and price impact predictions

Behavioral Insights

  • Trading timing analysis

  • Gas efficiency recommendations

  • Yield optimization opportunities

  • Strategy comparison with similar wallets

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

  1. Fork the repository

  2. Create your feature branch (git checkout -b feature/amazing-feature)

  3. Commit your changes (git commit -m 'Add some amazing feature')

  4. Push to the branch (git push origin feature/amazing-feature)

  5. Open a Pull Request

📜 License

This project is licensed under the MIT License - see the LICENSE file for details.

📧 Contact

For questions or support, please open an issue on the GitHub repository.

Available Tools

3 tools
analyzeWalletC

Analyzes a Solana wallet's DeFi activity and creates a profile with recommendations

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYes

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions analyzing activity and creating a profile with recommendations, but doesn't specify whether this is a read-only operation, if it requires authentication, what data it accesses (e.g., on-chain vs. off-chain), rate limits, or error handling. This leaves significant gaps in understanding the tool's behavior and constraints.

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, efficient sentence that front-loads the core functionality ('analyzes a Solana wallet's DeFi activity') and adds secondary details ('creates a profile with recommendations') without unnecessary elaboration. Every word earns its place, making it highly concise and well-structured.

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 the tool's complexity (involving DeFi activity analysis and profile creation), no annotations, no output schema, and low parameter schema coverage, the description is incomplete. It lacks details on what the analysis entails, the format of the profile or recommendations, error cases, or dependencies, leaving the agent with insufficient context for reliable use.

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?

The input schema has 1 parameter ('address') with 0% description coverage, so the schema provides no semantic details. The description adds minimal value by implying the parameter is a Solana wallet address, but doesn't clarify format (e.g., base58), validation, or examples. This is inadequate compensation for the low schema coverage, especially for a tool with a single critical parameter.

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's purpose with a specific verb ('analyzes') and resource ('Solana wallet's DeFi activity'), and it mentions creating a profile with recommendations. However, it doesn't explicitly distinguish this from sibling tools like 'fetchWalletActivity' or 'getTransactionDetails', which might handle similar wallet-related data but with different scopes or outputs.

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 like 'fetchWalletActivity' or 'getTransactionDetails'. It implies usage for analyzing DeFi activity and creating profiles, but lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer context without clear direction.

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

fetchWalletActivityC

Fetches the transaction activity history for a Solana wallet address

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYes
limitNo

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'fetches' which implies a read operation, but doesn't specify critical details like rate limits, authentication requirements, error handling, or the format of the returned activity history. This leaves significant gaps in understanding the tool's behavior.

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, efficient sentence that gets straight to the point without unnecessary words. It's appropriately front-loaded with the core purpose, though it could be slightly more structured if it included brief parameter hints.

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 the complexity of fetching transaction history, lack of annotations, 0% schema coverage, and no output schema, the description is insufficient. It doesn't explain what 'activity history' includes, how results are formatted, or any behavioral constraints, making it incomplete for effective agent use.

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%, so the description must compensate for undocumented parameters. It only mentions 'wallet address' for the 'address' parameter, ignoring the 'limit' parameter entirely. This fails to add meaningful semantics beyond the basic schema, leaving key usage details unclear.

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 action ('fetches') and resource ('transaction activity history for a Solana wallet address'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'analyzeWallet' or 'getTransactionDetails', which might offer overlapping functionality.

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 the sibling tools 'analyzeWallet' or 'getTransactionDetails'. It lacks context about alternatives, prerequisites, or specific scenarios where this tool is preferred, leaving the agent to infer usage from the tool name alone.

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

getTransactionDetailsC

Gets detailed information about a specific Solana transaction by signature

ParametersJSON Schema
NameRequiredDescriptionDefault
signatureYes

TDQS

C2.9/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 the full burden of behavioral disclosure. While it indicates this is a read operation ('Gets'), it doesn't describe what 'detailed information' includes, whether there are rate limits, authentication requirements, error conditions, or what format the response takes. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple lookup tool and front-loads the essential information (action + resource + identifier).

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 that there are no annotations, no output schema, and low schema description coverage (0%), the description is insufficiently complete. For a tool that presumably returns complex transaction data, the description should provide more context about what information is returned, error handling, or usage constraints. The current description leaves too many questions unanswered for effective tool invocation.

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 0%, meaning the single parameter (signature) has no documentation in the schema. The description adds some semantic context by specifying it's a 'Solana transaction signature,' which helps the agent understand what type of identifier is expected. However, it doesn't provide format examples, length constraints, or validation rules that would be needed for proper usage.

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 action ('Gets detailed information') and resource ('about a specific Solana transaction by signature'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling tools (analyzeWallet, fetchWalletActivity), which likely operate on different resources or provide different types of information.

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. It doesn't mention when this tool is appropriate, when other tools should be used instead, or what distinguishes it from the sibling tools (analyzeWallet, fetchWalletActivity). The agent must infer usage context solely from the tool name and description.

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.

  1. 3 tool updatesv1.0.0
    • First observedanalyzeWallet
    • First observedfetchWalletActivity
    • First observedgetTransactionDetails
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.9/5.0

Scored across 3 tools

Disambiguation4/5

The tools have distinct primary purposes: analyzeWallet focuses on DeFi profiling and recommendations, fetchWalletActivity retrieves transaction history, and getTransactionDetails provides specific transaction data. However, there is some overlap as analyzeWallet likely uses transaction data, but the descriptions clarify their different intents well.

Naming Consistency3/5

The naming is mixed: analyzeWallet and fetchWalletActivity use camelCase, while getTransactionDetails uses a different verb style and structure. This inconsistency makes the set less predictable, though the names remain readable and descriptive of their functions.

Tool Count3/5

With only 3 tools, the server feels thin for a DeFi/Solana wallet analysis domain. While the tools cover key operations, more comprehensive coverage (e.g., for token balances or portfolio tracking) might be expected, making the count borderline for the apparent scope.

Completeness3/5

The tools provide good coverage for wallet analysis and transaction details, but there are notable gaps. For example, there are no tools for fetching token balances, interacting with DeFi protocols, or updating wallet data, which could limit agent workflows in this domain.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • ONEDeFi MCP Server

    JMadhan1
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI-powered DeFi operations across Ethereum, Polygon, and Solana with automated portfolio optimization, risk assessment, and yield farming strategies. Provides intelligent portfolio diagnostics, investment strategy generation, and multi-chain DeFi protocol integration through natural language.
    -

  • cryptoiz-mcp

    dadang11
    A
    license
    Not graded
    quality
    C
    maintenance
    AI-powered Solana DEX smart money signals. Detects whale/dolphin accumulation, divergence patterns, and market phase across 170+ tokens. Pay-per-call via x402 USDC micropayments.
    30 npm
    1
    MIT

  • Solana DeFi Analytics MCP

    kirtiraj22
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides comprehensive analytics and insights for Solana wallets and their DeFi activities, including transaction tracking, DeFi position monitoring, risk profiling, and strategy recommendations.
    15 npm
    7
    MIT