Skip to main content
Glama

sodax_get_orderbook

Read-only

Retrieve current orderbook entries showing pending or open intents to analyze market depth and liquidity. Supports JSON or Markdown output formats with configurable limits.

Instructions

Get current orderbook entries showing pending/open intents

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of orders to return (1-100)
formatNoResponse format: 'json' for raw data or 'markdown' for formatted textmarkdown

Implementation Reference

  • The getOrderbook function implements the core logic to fetch orderbook data from the SODAX API. It accepts optional limit parameter, constructs the API request to /solver/orderbook endpoint, and returns an array of OrderbookEntry objects.
    export async function getOrderbook(options?: {
      limit?: number;
    }): Promise<OrderbookEntry[]> {
      try {
        const params = new URLSearchParams();
        if (options?.limit) params.append("limit", options.limit.toString());
    
        const queryString = params.toString();
        const url = `/solver/orderbook${queryString ? `?${queryString}` : ""}`;
        const response = await apiClient.get(url);
        // API returns { total, data }
        return response.data?.data || response.data || [];
      } catch (error) {
        console.error("Error fetching orderbook:", error);
        throw new Error("Failed to fetch orderbook from SODAX API");
      }
    }
  • Tool registration with MCP server, defining the tool name 'sodax_get_orderbook', description, input schema (limit and format parameters), and the async handler that calls getOrderbook service and formats the response.
    // Tool 6: Get Orderbook
    server.tool(
      "sodax_get_orderbook",
      "Get current orderbook entries showing pending/open intents",
      {
        limit: z.number().min(1).max(100).optional().default(20)
          .describe("Maximum number of orders to return (1-100)"),
        format: z.nativeEnum(ResponseFormat).optional().default(ResponseFormat.MARKDOWN)
          .describe("Response format: 'json' for raw data or 'markdown' for formatted text")
      },
      READ_ONLY,
      async ({ limit, format }) => {
        try {
          const orderbook = await getOrderbook({ limit });
          return {
            content: [{
              type: "text",
              text: `## Orderbook\n\n${orderbook.length} orders found\n\n` + formatResponse(orderbook, format)
            }]
          };
        } catch (error) {
          return {
            content: [{ type: "text", text: `Error: ${error instanceof Error ? error.message : "Unknown error"}` }],
            isError: true
          };
        }
      }
    );
  • TypeScript interface defining the OrderbookEntry schema with fields for orderId, chainId, maker, tokenIn, tokenOut, price, status, createdAt, and expiresAt.
    export interface OrderbookEntry {
      orderId: string;
      chainId: string;
      maker: string;
      tokenIn: {
        address: string;
        symbol: string;
        amount: string;
      };
      tokenOut: {
        address: string;
        symbol: string;
        amount: string;
      };
      price: number;
      status: "open" | "partial" | "filled" | "cancelled";
      createdAt: number;
      expiresAt?: number;
    }
  • src/index.ts:193-205 (registration)
    Tool metadata registration listing 'sodax_get_orderbook' as part of the api tools array in the server configuration.
    api: [
      "sodax_get_supported_chains",
      "sodax_get_swap_tokens",
      "sodax_get_transaction",
      "sodax_get_user_transactions",
      "sodax_get_volume",
      "sodax_get_orderbook",
      "sodax_get_money_market_assets",
      "sodax_get_user_position",
      "sodax_get_partners",
      "sodax_get_token_supply",
      "sodax_refresh_cache"
    ],
  • Analytics mapping that categorizes 'sodax_get_orderbook' under the 'api' group for PostHog event tracking.
    const TOOL_GROUPS: Record<string, string> = {
      // SODAX API tools
      sodax_get_supported_chains: "api",
      sodax_get_swap_tokens: "api",
      sodax_get_transaction: "api",
      sodax_get_user_transactions: "api",
      sodax_get_volume: "api",
      sodax_get_orderbook: "api",
      sodax_get_money_market_assets: "api",
      sodax_get_user_position: "api",
      sodax_get_partners: "api",
      sodax_get_token_supply: "api",
      sodax_refresh_cache: "api",
    
      // GitBook SDK docs meta-tools
      docs_health: "sdk-docs",
      docs_refresh: "sdk-docs",
      docs_list_tools: "sdk-docs",
    };
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 content ('pending/open intents'), but doesn't disclose additional traits like rate limits, authentication needs, or data freshness, resulting in a moderate score for adding some 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it highly concise and well-structured for quick understanding.

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 parameters, no output schema) and rich annotations, the description is minimally adequate. It covers the basic purpose but lacks details on output format implications or integration with sibling tools, leaving some contextual gaps despite the structured data support.

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 has 100% description coverage, clearly documenting both parameters with details like ranges and defaults. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline score of 3 for not compensating but not detracting either.

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 ('Get') and resource ('current orderbook entries showing pending/open intents'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'sodax_get_swap_tokens' or 'sodax_get_volume', which also retrieve data but for different resources, so it doesn't reach the highest score for sibling distinction.

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 other 'sodax_get_' tools for different data types. It lacks context about prerequisites, timing, or exclusions, leaving the agent without clear usage instructions beyond the basic purpose.

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