Skip to main content
Glama
JussCubs

mcp-server-test

by JussCubs

fetch_leaderboard

Retrieve leaderboard rankings by specifying type like PNL_WIN or TRADE_VOLUME. Returns JSON data.

Instructions

Fetch Vector leaderboard data

Args:
    leaderboard_type: Type of leaderboard (e.g., 'PNL_WIN', 'TRADE_VOLUME')
    
Returns:
    JSON string with leaderboard data

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
leaderboard_typeNoPNL_WIN

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The async function that implements the fetch_leaderboard tool. It builds a GraphQL query payload with the given leaderboard_type, sends it to the Vector GraphQL API via httpx, and returns the response text (or an error message).
    async def fetch_leaderboard(
        leaderboard_type: str = "PNL_WIN",
        ctx: Context = None
    ) -> str:
        """Fetch Vector leaderboard data
        
        Args:
            leaderboard_type: Type of leaderboard (e.g., 'PNL_WIN', 'TRADE_VOLUME')
            
        Returns:
            JSON string with leaderboard data
        """
        if ctx:
            ctx.info(f"Fetching {leaderboard_type} leaderboard data...")
        
        # Hardcoded variables as requested
        variables = {
            "after": None,
            "first": 100,
            "groupId": None,
            "leaderboardType": leaderboard_type,
            "periodsAgo": None
        }
        
        payload = {
            "query": LEADERBOARD_QUERY,
            "variables": variables
        }
        
        async with httpx.AsyncClient(verify=False) as client:
            try:
                response = await client.post(
                    API_URL, 
                    json=payload, 
                    headers=HEADERS
                )
                response.raise_for_status()
                return response.text
            except Exception as e:
                error_message = f"Error fetching leaderboard data: {str(e)}"
                if ctx:
                    ctx.error(error_message)
                return error_message
  • The decorator that registers fetch_leaderboard as an MCP tool with the name "fetch_leaderboard" on the FastMCP server instance.
    @mcp.tool(name="fetch_leaderboard")
  • The LEADERBOARD_QUERY GraphQL query string used by fetch_leaderboard. It queries leaderboardWeekly with the provided variables and includes an embedded fragment for leaderboard entries (rank, value, profile info).
    LEADERBOARD_QUERY = """
    query leaderboardScreenQuery(
      $groupId: String
      $leaderboardType: LeaderboardType!
      $periodsAgo: Int
      $first: Int
      $after: String
    ) {
      ...leaderboardFragment_31k55b
    }
    
    fragment InlineProfileFragment on Profile {
      id
      ...ProfilePicFragment
      ...ProfileUsernameFragment
    }
    
    fragment LeaderboardEntryFragment on LeaderboardEntry {
      profileId
      broadcastCount
      rank
      value
      percentileV2
      profile {
        id
        username
        profileImageUrl
        twitterUsername
        isVerified
        followerCount
        followerCountX
        ...InlineProfileFragment
        ...ProfilePicFragment
      }
    }
    
    fragment ProfileBadgesFragment on Profile {
      username
      twitterUsername
      isVerified
    }
    
    fragment ProfilePicFragment on Profile {
      id
      username
      moderationState
      profileImageUrl
      ...ProfileBadgesFragment
    }
    
    fragment ProfileUsernameFragment on Profile {
      username
      moderationState
      ...ProfileBadgesFragment
    }
    
    fragment leaderboardFragment_31k55b on Query {
      leaderboardWeekly(leaderboardType: $leaderboardType, groupId: $groupId, periodsAgo: $periodsAgo, first: $first, after: $after) {
        edges {
          node {
            profileId
            ...LeaderboardEntryFragment
            __typename
          }
          cursor
        }
        resetsAt
        pageInfo {
          endCursor
          hasNextPage
        }
      }
    }
  • The API_URL constant pointing to the Vector mainnet GraphQL endpoint and the HEADERS dict used by fetch_leaderboard for its HTTP request.
    API_URL = "https://mainnet-api.vector.fun/graphql"
    HEADERS = {
        "Host": "mainnet-api.vector.fun",
        "content-type": "application/json",
        "X-App-Version": "1.11.0",
        "X-App-Build-Number": "331",
        "accept": "*/*",
        "x-app-name": "Vector",
        "Accept-Language": "en-US;q=1",
        "user-agent": "Vector/331 CFNetwork/1568.200.51 Darwin/24.1.0",
        "pragma": "no-cache",
        "cache-control": "no-cache"
    }
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 only states that the tool fetches data and returns JSON, but does not mention any side effects, permissions, error handling, or rate limits. The description adds minimal behavioral context beyond the basic fetch 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?

The description is extremely concise, with only 5 lines front-loading the core purpose. Every sentence serves a clear function: stating the purpose, listing the parameter, and noting the return format. No waste.

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 tool's simplicity (1 parameter, returns JSON string) and the presence of an output schema, the description provides sufficient context to understand the tool's function and parameter. It lacks only minor context about the nature of leaderboard data or expected usage scenarios, but remains largely complete.

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 schema has 0% description coverage, so the description's explanation ('Type of leaderboard (e.g., 'PNL_WIN', 'TRADE_VOLUME')') adds value beyond the schema. However, it does not enumerate all possible values or constraints, leaving ambiguity about valid inputs.

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 'Fetch' and the resource 'Vector leaderboard data', distinguishing it from sibling tools like fetch_profile and fetch_token_data. The purpose is immediately understandable.

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 is provided on when to use this tool versus alternatives such as fetch_profile or fetch_token_data. There is no mention of prerequisites, context, or exclusions.

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/JussCubs/mcp-server-test'

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