Skip to main content
Glama
pythia-the-oracle

pythia-oracle-mcp

Official

lookup_event_feed

Reverse-lookup a Pythia Event feedId (bytes32) to its human-readable feed name, eliminating the need for dApps to maintain a feedId-to-name table.

Instructions

Reverse-lookup a Pythia Event feedId (bytes32) to its human-readable feed name.

Subscribers receive bytes32 feedId in SubscriptionCreated and PythiaEvent events. This tool maps that hash back to the canonical feed name (e.g. 'pol_RSI_5M_14') so dApps don't need to maintain their own feedId → name table or query the registry contract on every event.

Args: feed_id_hex: bytes32 hash, with or without '0x' prefix, any case.

Returns: Single-section report with feed_name + matching token + indicator suffix. If the hash is not in the registered lookup table, returns a diagnostic pointer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
feed_id_hexYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The actual implementation of the lookup_event_feed tool. It reverse-looks up a bytes32 feedId hash to its human-readable feed name by querying the feed_hash_lookup table from the live data feed.
    async def lookup_event_feed(feed_id_hex: str) -> str:
        """Reverse-lookup a Pythia Event feedId (bytes32) to its human-readable feed name.
    
        Subscribers receive `bytes32 feedId` in SubscriptionCreated and PythiaEvent
        events. This tool maps that hash back to the canonical feed name (e.g.
        'pol_RSI_5M_14') so dApps don't need to maintain their own feedId → name
        table or query the registry contract on every event.
    
        Args:
            feed_id_hex: bytes32 hash, with or without '0x' prefix, any case.
    
        Returns:
            Single-section report with feed_name + matching token + indicator
            suffix. If the hash is not in the registered lookup table, returns
            a diagnostic pointer.
        """
        h = feed_id_hex.strip().lower()
        if not h.startswith("0x"):
            h = "0x" + h
    
        data = await _fetch_data()
        events = data.get("events", {}) if data else {}
        lookup = events.get("feed_hash_lookup", {})
    
        feed_name = lookup.get(h)
        if not feed_name:
            return (
                f"Feed id {feed_id_hex} not found in registered lookup table.\n"
                "Possible reasons:\n"
                "  - Invalid hash (must be keccak256(feed_name) as bytes32)\n"
                "  - Feed not yet registered with the Event registry\n"
                "  - Feed deactivated\n"
                f"Total registered feeds: {len(lookup)}. Use list_tokens() + "
                "get_token_feeds(engine_id) to discover live feed names."
            )
    
        parts = feed_name.split("_", 1)
        engine_id = parts[0] if parts else feed_name
        suffix = parts[1] if len(parts) > 1 else ""
    
        tokens = data.get("tokens", []) if data else []
        token = next((t for t in tokens if t.get("engine_id") == engine_id), None)
    
        out = [
            f"Feed name: {feed_name}",
            f"Feed ID:   {h}",
        ]
        if token:
            out.append(f"Token:     {token.get('symbol')} ({token.get('name')})")
            out.append(f"Engine id: {engine_id}")
        if suffix:
            out.append(f"Indicator: {suffix}")
        return "\n".join(out)
  • Registration of lookup_event_feed as an MCP tool via the @mcp.tool() decorator on the async function definition.
    @mcp.tool()
  • The function signature and docstring define the input schema: feed_id_hex (str) — a bytes32 hash with or without '0x' prefix. Returns a text report with feed name, matching token, and indicator suffix.
    @mcp.tool()
    async def lookup_event_feed(feed_id_hex: str) -> str:
        """Reverse-lookup a Pythia Event feedId (bytes32) to its human-readable feed name.
    
        Subscribers receive `bytes32 feedId` in SubscriptionCreated and PythiaEvent
        events. This tool maps that hash back to the canonical feed name (e.g.
        'pol_RSI_5M_14') so dApps don't need to maintain their own feedId → name
        table or query the registry contract on every event.
    
        Args:
            feed_id_hex: bytes32 hash, with or without '0x' prefix, any case.
    
        Returns:
            Single-section report with feed_name + matching token + indicator
            suffix. If the hash is not in the registered lookup table, returns
            a diagnostic pointer.
        """
  • The tool relies on _fetch_data() to get the live feed-status.json, then reads events.feed_hash_lookup to do the reverse mapping.
    data = await _fetch_data()
    events = data.get("events", {}) if data else {}
    lookup = events.get("feed_hash_lookup", {})
Behavior4/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. It clearly indicates a read-only lookup by describing the reverse-mapping behavior and the diagnostic pointer for unmatched hashes. It does not explicitly state it is non-destructive, but the context leaves no ambiguity that it is a safe query.

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 concise and well-structured: a one-sentence purpose, a paragraph of context, then explicit Args and Returns sections. Every sentence adds value, and there is no redundancy or fluff.

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 availability of an output schema (not shown), the description provides a sufficient overview of inputs and outputs, including a fallback 'diagnostic pointer' for unmatched hashes. It could elaborate on edge cases, but it covers the primary use case thoroughly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates well. It explains that `feed_id_hex` is a bytes32 hash, accepts optional '0x' prefix and any case, and outlines the return fields (feed_name, token, indicator suffix). This adds critical formatting guidance beyond the schema's simple type string.

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 tool's purpose: 'Reverse-lookup a Pythia Event feedId (bytes32) to its human-readable feed name.' This specific verb+resource combination (reverse-lookup feedId to feed name) distinguishes it from sibling tools, which focus on other aspects like oracle health, contracts, or subscriptions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that subscribers receive bytes32 feedId in events and this tool maps it to the canonical name, eliminating the need for a custom registry or contract queries. While it doesn't explicitly state when not to use it or list alternatives, the context is clear and actionable.

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/pythia-the-oracle/pythia-oracle-mcp'

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