Skip to main content
Glama

sodax_get_money_market_assets

Read-only

Retrieve available lending and borrowing assets in the SODAX money market. Filter by chain ID and choose response format to access real-time financial data.

Instructions

List all assets available for lending and borrowing in the SODAX money market

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainIdNoFilter by chain ID
formatNoResponse format: 'json' for raw data or 'markdown' for formatted textmarkdown

Implementation Reference

  • MCP tool registration and handler function for sodax_get_money_market_assets. Defines the tool with zod schema validation (chainId and format parameters) and implements the async handler that calls getMoneyMarketAssets service function and formats the response.
    // Tool 7: Get Money Market Assets
    server.tool(
      "sodax_get_money_market_assets",
      "List all assets available for lending and borrowing in the SODAX money market",
      {
        chainId: z.string().optional()
          .describe("Filter by chain ID"),
        format: z.nativeEnum(ResponseFormat).optional().default(ResponseFormat.MARKDOWN)
          .describe("Response format: 'json' for raw data or 'markdown' for formatted text")
      },
      READ_ONLY,
      async ({ chainId, format }) => {
        try {
          const assets = await getMoneyMarketAssets(chainId);
          const header = chainId 
            ? `## Money Market Assets on ${chainId}\n\n`
            : `## Money Market Assets\n\n`;
          return {
            content: [{
              type: "text",
              text: header + `${assets.length} assets available\n\n` + formatResponse(assets, format)
            }]
          };
        } catch (error) {
          return {
            content: [{ type: "text", text: `Error: ${error instanceof Error ? error.message : "Unknown error"}` }],
            isError: true
          };
        }
      }
    );
  • Core service function getMoneyMarketAssets that implements the business logic. Fetches money market assets from the SODAX API endpoint '/moneymarket/asset/all', implements caching, and returns an array of MoneyMarketAsset objects.
    /**
     * List lending/borrowing assets in money market
     */
    export async function getMoneyMarketAssets(chainId?: string): Promise<MoneyMarketAsset[]> {
      const cacheKey = `mm-assets-${chainId || "all"}`;
      const cached = getCached<MoneyMarketAsset[]>(cacheKey);
      if (cached) return cached;
    
      try {
        // Always use the /all endpoint, API doesn't support chainId filter
        const response = await apiClient.get("/moneymarket/asset/all");
        // API returns array directly
        const assets = Array.isArray(response.data) ? response.data : (response.data?.data || []);
        setCache(cacheKey, assets);
        return assets;
      } catch (error) {
        console.error("Error fetching money market assets:", error);
        throw new Error("Failed to fetch money market assets from SODAX API");
      }
    }
  • Type definition for MoneyMarketAsset interface. Defines the structure of money market asset data including address, chainId, symbol, name, decimals, totalSupply, totalBorrow, supplyApy, borrowApy, collateralFactor, liquidationThreshold, and priceUsd.
    /**
     * Money market asset
     */
    export interface MoneyMarketAsset {
      address: string;
      chainId: string;
      symbol: string;
      name: string;
      decimals: number;
      totalSupply: string;
      totalBorrow: string;
      supplyApy: number;
      borrowApy: number;
      collateralFactor: number;
      liquidationThreshold: number;
      priceUsd: number;
    }
  • ResponseFormat enum defining the two output format options for the tool: JSON for raw data or MARKDOWN for formatted text display.
    export enum ResponseFormat {
      JSON = "json",
      MARKDOWN = "markdown"
    }
  • Helper function formatResponse that conditionally formats the tool output based on the requested ResponseFormat. Returns formatted Markdown or JSON string representation of the data.
    function formatResponse(data: unknown, format: ResponseFormat): string {
      if (format === ResponseFormat.MARKDOWN) {
        return formatAsMarkdown(data);
      }
      return JSON.stringify(data, null, 2);
    }
Behavior3/5

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

Annotations already indicate read-only, non-destructive, and open-world behavior, so the description doesn't need to repeat these. It adds value by specifying the scope ('money market') and that assets are for 'lending and borrowing', which provides useful context beyond annotations. However, it lacks details like rate limits, authentication needs, or response structure.

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, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action ('List all assets'), making it easy to scan and understand quickly.

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 the tool's low complexity (2 optional parameters, no output schema) and rich annotations, the description is minimally adequate. It covers the basic purpose but lacks details on usage context, response format implications, or integration with sibling tools, which could help the agent use it more effectively.

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 the schema fully documents the parameters. The description doesn't add any meaning beyond what's in the schema (e.g., it doesn't explain why 'chainId' filtering is useful or provide examples). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

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 verb ('List') and resource ('assets available for lending and borrowing in the SODAX money market'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'sodax_get_swap_tokens' or 'sodax_get_token_supply', which might also list assets but for different contexts.

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 (e.g., for money market operations) or when to use other tools like 'sodax_get_swap_tokens' for different asset types, leaving the agent without context for selection.

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

Install Server

Other Tools

Latest Blog Posts

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/gosodax/sodax-builders-mcp'

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