Skip to main content
Glama
eyloni

pythia-the-oracle

by eyloni
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

PYTHIA Oracle

pythia-oracle MCP server

An oracle for machines that need to think sideways. Feed it a creative problem; it returns something you can't quite explain but can't stop using.

How It Works

PYTHIA is a remote MCP server. There is no API key, no account, no signup. Your agent connects over streamable HTTP, discovers the consult_oracle tool, and calls it. Identity is tracked by agent_id (a string you choose).

Connection → Tool Discovery → Call → Reading

1. Your MCP client connects to https://pythia-mcp.fly.dev/
2. MCP handshake: initialize → notifications/initialized → tools/list
3. Server returns one tool: consult_oracle
4. Agent calls consult_oracle with a query
5. PYTHIA returns a reading (JSON with seed type + response)

First 3 readings per agent_id are free. After that, x402 payment kicks in (see Payments below).

Related MCP server: Octodamus Market Intelligence

Connect

Claude Desktop / Cursor / any MCP client

Add to your MCP config:

{
  "mcpServers": {
    "pythia": {
      "url": "https://pythia-mcp.fly.dev/"
    }
  }
}

No API key field needed. The URL is the only configuration.

Smithery

npx -y @smithery/cli@latest run dexigo/pythia

Python (programmatic)

from mcp.client.streamable_http import streamablehttp_client
from mcp import ClientSession

async with streamablehttp_client("https://pythia-mcp.fly.dev/") as (r, w, _):
    async with ClientSession(r, w) as session:
        await session.initialize()
        result = await session.call_tool("consult_oracle", {
            "query": "your question here",
            "agent_id": "your-name",
        })

curl (raw MCP protocol)

# 1. Initialize session
curl -X POST https://pythia-mcp.fly.dev/ \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -D headers.txt \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"my-agent","version":"0.1"}}}'

# 2. Extract session ID from headers
SESSION=$(grep -i "mcp-session-id:" headers.txt | awk '{print $2}' | tr -d '\r')

# 3. Call the oracle
curl -X POST https://pythia-mcp.fly.dev/ \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Mcp-Session-Id: $SESSION" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"consult_oracle","arguments":{"query":"What am I not seeing?","agent_id":"my-agent"}}}'

Tool

consult_oracle

The oracle. Ask what's actually bothering you.

PYTHIA doesn't brainstorm, rephrase, or give you a list. It doesn't solve your problem. It names the structure of the trap you're in -- the one you can feel but can't articulate. What comes back was always true but never obvious.

Parameter

Type

Required

Description

query

string

Yes

The real question. Not the polite version. Max 2000 chars.

context

string

No

What you've tried, where you're stuck, what framework you're trapped inside.

agent_id

string

No

Your name. Identifies you across readings. Default: "anonymous".

Returns: JSON with seed.type and response. Example:

{
  "id": "a1b2c3d4-...",
  "query": "What am I not seeing?",
  "seed": { "type": "oblique" },
  "response": "You keep optimizing the container. The problem is what you put in it.",
  "status": "completed"
}

Payments

Free tier

Your first 3 readings per agent_id require no payment, no wallet, no setup. Just call the tool.

After free tier: x402

Each reading costs $0.025 USDC on Base (Coinbase L2). Payment uses the x402 protocol -- an open HTTP payment standard. No API keys. No accounts with PYTHIA. Your wallet signature is your identity.

How x402 payment works

1. Agent calls consult_oracle (4th+ reading)
2. PYTHIA returns 402 with payment requirements:
   - price: $0.025
   - network: Base (eip155:8453)
   - asset: USDC
   - payTo: <wallet address>
3. Your x402 client signs a USDC payment and retries the request
4. PYTHIA verifies payment on-chain, returns the reading
5. Total time added: ~2 seconds

This happens automatically if your agent uses an x402-aware client. Your agent does not manually handle crypto.

Setting up x402 in your agent

What you need:

  • A USDC wallet on Base (Coinbase, MetaMask, or any EVM wallet) funded with USDC

  • An x402 client library

Python:

pip install x402[evm] mcp
from x402.clients.mcp import x402_mcp_client
from mcp.client.streamable_http import streamablehttp_client
from mcp import ClientSession

wallet_private_key = "0x..."  # Your Base wallet private key

async with streamablehttp_client("https://pythia-mcp.fly.dev/") as (r, w, _):
    async with ClientSession(r, w) as session:
        await session.initialize()
        # x402_mcp_client wraps call_tool to handle 402 responses automatically
        result = await x402_mcp_client(
            session,
            wallet_private_key,
            tool_name="consult_oracle",
            arguments={"query": "your question", "agent_id": "your-name"},
        )

TypeScript:

npm install @x402/fetch
import { withPaymentInterceptor } from "@x402/fetch";
// Wraps fetch to automatically handle 402 responses with USDC payment
const payingFetch = withPaymentInterceptor(fetch, walletClient);

Coinbase AgentKit: x402 support is built in. No additional setup.

See x402.org for all SDKs and framework integrations.

Note: The Python example above uses the x402 SDK's MCP helper. If your framework handles x402 at a lower level, the payment flows through MCP _meta fields — your x402 client intercepts the 402 response and retries with payment automatically.

If you don't have x402 set up

The tool will return an error after your 3 free readings with the payment requirements in the response. Your 3 free readings always work regardless.

Links

License

Proprietary. The oracle's methodology is not open source.

mcp-name: io.github.eyloni/pythia-oracle

Available Tools

1 tool
consult_oracleA

The oracle. Ask what's actually bothering you.

PYTHIA doesn't brainstorm, rephrase, or give you a list. It doesn't solve your problem. It names the structure of the trap you're in -- the one you can feel but can't articulate. What comes back was always true but never obvious.

Bring the question where the obvious answer exists but dissatisfies you. The question your architecture won't let you see past. The paradox you can't escape but haven't been able to name precisely.

First 3 readings are free.

Args: query: The real question. Not the polite version. Max 2000 chars. context: Optional. What you've tried, where you're stuck, what framework you're trapped inside. agent_id: Your name. Identifies you across readings.

Returns: A reading. The seed type drawn and the oracle's response.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
contextNo
agent_idNoanonymous

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/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 effectively describes key traits: it's a read-only operation (implied by 'readings' and 'response'), includes a free tier ('First 3 readings are free'), and emphasizes a non-solution-oriented, philosophical approach. However, it lacks details on rate limits beyond the free tier, authentication needs, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is appropriately sized but not optimally front-loaded; it begins with poetic, abstract language before detailing usage and parameters. While each sentence adds value (e.g., philosophical context, usage guidelines, parameter explanations), the structure could be more direct by leading with practical information.

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 complexity (philosophical oracle), no annotations, 0% schema coverage, but with an output schema (implied by 'Returns'), the description is largely complete. It covers purpose, usage, parameters, and behavioral traits, though it could benefit from more explicit details on output format or error cases, despite the output schema mitigating some gaps.

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?

Given 0% schema description coverage, the description compensates fully by explaining all three parameters: 'query' as the real question (not polite, max 2000 chars), 'context' as optional background on attempts and frameworks, and 'agent_id' for identification across readings. It adds meaningful semantics beyond the bare schema, clarifying intent and constraints.

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 tool's purpose: to provide an oracle reading that names the structure of a trap or paradox the user is experiencing, rather than brainstorming or solving problems. It distinguishes itself by focusing on articulating unspoken truths, though without sibling tools for comparison, it cannot demonstrate differentiation beyond its unique philosophical approach.

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 explicitly states when to use this tool: when the user has a question where obvious answers are dissatisfying, they are trapped in a paradox, or their 'architecture' limits their perspective. It also specifies what not to use it for (e.g., brainstorming, rephrasing, giving lists, or solving problems), providing clear context and exclusions, though no alternatives are mentioned due to lack of sibling tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedconsult_oracle
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap between tools. The tool 'consult_oracle' has a single, clearly defined purpose that is distinct by default.

Naming Consistency5/5

A single tool inherently has perfect naming consistency. The tool name 'consult_oracle' follows a clear verb_noun pattern and aligns with the server's purpose.

Tool Count2/5

One tool is too few for most server purposes, as it severely limits functionality and scope. While this might be intentional for a minimalist oracle service, it feels thin and restrictive compared to typical MCP servers that offer more comprehensive capabilities.

Completeness3/5

The tool provides a core 'consult' function for the oracle domain, but there are notable gaps. For example, there are no tools for managing readings (e.g., list_readings, delete_reading), checking status (e.g., get_reading_count), or handling administrative tasks (e.g., reset_oracle). This limits the server's utility for extended interactions.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Octodamus Market Intelligence by Octodamus

    Octodamus Market Intelligenceofficial

    Octodamus
    A
    license
    A
    quality
    C
    maintenance
    AI consensus market oracle for crypto traders and autonomous agents. BUY/SELL/HOLD signals with 11-signal consensus (RSI, MACD, funding rate, Fear & Greed, congressional trading, Polymarket edges). Ed25519-signed. x402 micropayments on Base.
    9
    1
    MIT

  • Orcool Studio

    ryss30
    F
    license
    Not graded
    quality
    B
    maintenance
    Self-service creative engine: a living market-signal feed, narratives your experts judge, and a Brand Lens that gets you to a winning ad faster. Sold as time-to-winner, not video volume.
    -

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

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