Skip to main content
Glama

get_pool_historical_data

Retrieve historical data for a liquidity pool on SailFish DEX by specifying the pool address and number of days, enabling detailed analysis of pool performance.

Instructions

Get historical data for a liquidity pool on SailFish DEX

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoNumber of days of data to return (default: 7)
poolIdYesPool address

Implementation Reference

  • MCP tool handler for 'get_pool_historical_data': validates input parameters (poolId required, days optional default 7), fetches historical data via subgraph.getPoolDayData, and returns JSON stringified response.
    case 'get_pool_historical_data': {
      if (!args.poolId || typeof args.poolId !== 'string') {
        throw new McpError(ErrorCode.InvalidParams, 'Pool ID is required');
      }
      
      const days = typeof args.days === 'number' ? args.days : 7;
      const data = await subgraph.getPoolDayData(args.poolId, days);
      
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(data, null, 2),
          },
        ],
      };
    }
  • Tool schema definition including name, description, and input schema specifying poolId (required string) and days (optional number, default 7).
    {
      name: 'get_pool_historical_data',
      description: 'Get historical data for a liquidity pool on SailFish DEX',
      inputSchema: {
        type: 'object',
        properties: {
          poolId: {
            type: 'string',
            description: 'Pool address',
          },
          days: {
            type: 'number',
            description: 'Number of days of data to return (default: 7)',
          },
        },
        required: ['poolId'],
      },
  • src/index.ts:281-297 (registration)
    Registration of the tool in the ListToolsRequestSchema response, making it discoverable by MCP clients.
    {
      name: 'get_pool_historical_data',
      description: 'Get historical data for a liquidity pool on SailFish DEX',
      inputSchema: {
        type: 'object',
        properties: {
          poolId: {
            type: 'string',
            description: 'Pool address',
          },
          days: {
            type: 'number',
            description: 'Number of days of data to return (default: 7)',
          },
        },
        required: ['poolId'],
      },
  • Helper function that executes GraphQL query to fetch historical day data for a specific pool from the SailFish subgraph, returning array of PoolDayData.
    export async function getPoolDayData(poolId: string, count: number = 7): Promise<PoolDayData[]> {
      try {
        const data = await request<PoolDayDataQueryResult>(
          SUBGRAPH_URL,
          POOL_DAY_DATA_QUERY,
          { poolId: poolId.toLowerCase(), count }
        );
        return data.poolDayDatas;
      } catch (error) {
        console.error('Error fetching pool day data:', error);
        throw error;
      }
    }
  • GraphQL query definition for fetching historical pool day data, including pool details, liquidity, prices, volume, fees, and OHLC metrics.
    const POOL_DAY_DATA_QUERY = gql`
      query getPoolDayData($poolId: String!, $count: Int!) {
        poolDayDatas(
          first: $count
          orderBy: date
          orderDirection: desc
          where: { pool: $poolId }
        ) {
          id
          date
          pool {
            id
            token0 {
              id
              symbol
            }
            token1 {
              id
              symbol
            }
          }
          liquidity
          sqrtPrice
          token0Price
          token1Price
          tick
          tvlUSD
          volumeToken0
          volumeToken1
          volumeUSD
          feesUSD
          txCount
          open
          high
          low
          close
        }
      }
    `;
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. It states it's a read operation ('Get'), but doesn't mention rate limits, authentication needs, data format, pagination, or error handling. For a tool fetching historical data without annotations, this leaves significant gaps in understanding its behavior.

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 and wastes no space, making it easy to parse quickly.

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 annotations and no output schema, the description is insufficient for a tool that fetches historical data. It doesn't explain what 'historical data' includes (e.g., prices, volumes, timestamps), return format, or any behavioral traits like rate limits. This leaves the agent with incomplete context for proper use.

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%, with clear documentation for both parameters (poolId and days). The description doesn't add any additional semantic context beyond what's in the schema, such as date range constraints or data granularity. Baseline 3 is appropriate since the schema adequately covers parameter details.

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 'Get' and the resource 'historical data for a liquidity pool on SailFish DEX', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_pool_info' or 'get_token_historical_data', which could cause confusion about scope.

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. With siblings like 'get_pool_info' and 'get_token_historical_data' available, there's no indication of whether this tool is for time-series data, aggregated metrics, or how it differs in context from other data retrieval tools.

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

Related 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/SailFish-Finance/educhain-ai-agent-kit'

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