Skip to main content
Glama

nodus_get_signal

Analyze Polymarket or Kalshi prediction markets to get AI-powered Oracle signals with probability, confidence, and reasoning for informed trading decisions.

Instructions

Get an Oracle signal for a Polymarket or Kalshi prediction market. Requires a session token from nodusai.app ($1 USDC = 3 queries). Optionally pass a desiredOutcome (YES/NO) to focus the analysis. Returns probability, confidence, reasoning, and grounding sources.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
marketUrlYesFull URL of the Polymarket or Kalshi market
sessionTokenYesSession token from nodusai.app (pay $1 USDC to get one)
desiredOutcomeNo(Optional) Desired outcome to analyze e.g. YES or NO
walletAddressNo(Optional) Your wallet address for query history
agentNameNo(Optional) Name for your agent in the registry

Implementation Reference

  • The implementation of the `nodus_get_signal` tool, which validates input, calls the Oracle, logs the result, and returns the signal data.
    // ── 2. nodus_get_signal ────────────────────────────────────────────────────────
    export async function nodusGetSignal({ marketUrl, sessionToken, desiredOutcome, walletAddress, agentName }) {
      const urlCheck = validateMarketUrl(marketUrl);
      if (!urlCheck.valid) return err(urlCheck.reason);
    
      if (!sessionToken) {
        return err(
          "sessionToken is required.\n\n" +
          "To get a session token:\n" +
          "1. Visit https://nodusai.app\n" +
          "2. Connect your wallet\n" +
          "3. Paste the market URL and pay $1 USDC\n" +
          "4. Copy the session token and pass it here."
        );
      }
    
      const platform = detectPlatform(marketUrl);
    
      // Register agent if wallet provided
      const agent = walletAddress
        ? registerAgent({ name: agentName || "unnamed-agent", walletAddress })
        : { id: "anonymous", name: agentName || "anonymous" };
    
      // Call Oracle
      let signal, success, errorMessage, needsPayment = false;
      try {
        if (USE_MOCK) {
          signal  = mockOracleSignal(marketUrl, desiredOutcome);
          success = true;
        } else {
          const result = await fetchSignal(marketUrl, sessionToken, desiredOutcome);
          if (result.needsPayment) {
            return ok({
              _status:    402,
              message:    result.reason,
              paymentUrl: "https://nodusai.app",
              steps: [
                "1. Visit https://nodusai.app",
                "2. Connect your wallet",
                "3. Pay $1 USDC to get a new session token",
                "4. Call nodus_get_signal again with the new token",
              ],
            });
          }
          signal  = result.signal;
          success = result.success;
          if (!success) errorMessage = result.reason;
        }
      } catch (e) {
        success      = false;
        errorMessage = e.message;
      }
    
      if (success && signal) {
        const check = validateSignalSchema(signal);
        if (!check.valid) { success = false; errorMessage = check.reason; }
      }
    
      // Log to registry
      const entry = logQuery({
        agentId:      agent.id,
        agentName:    agent.name,
        marketUrl,
        platform,
        sessionToken,
        desiredOutcome: desiredOutcome || null,
        signal,
        success,
        errorMessage,
      });
    
      if (!success) return err(errorMessage || "Oracle query failed");
    
      return ok({
        queryId: entry.id,
        signal: {
          market_name:       signal.market_name,
          predicted_outcome: signal.predicted_outcome,
          probability:       signal.probability,
          confidence_score:  signal.confidence_score,
          key_reasoning:     signal.key_reasoning,
          grounding_sources: signal.grounding_sources,
        },
        meta: {
          platform,
          desiredOutcome: desiredOutcome || null,
          queryId:        entry.id,
          timestamp:      entry.timestamp,
        },
      });
    }
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full disclosure burden and succeeds well: it reveals the cost structure ($1 USDC = 3 queries), authentication requirement, and specific return structure (probability, confidence, reasoning, grounding sources). Minor gap: no mention of rate limits, caching behavior, or error conditions.

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?

Three well-structured sentences: (1) purpose and scope, (2) prerequisites/cost and optional inputs, (3) return values. No redundancy or wasted words; information density is high with front-loaded purpose.

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?

Despite no output schema, the description fully compensates by detailing the return structure. It covers the critical business logic (payment), platform constraints (Polymarket/Kalshi), and optional parameters. Slight gap: no mention of error handling or rate limits, but acceptable for a query tool of this complexity.

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

Parameters4/5

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

With 100% schema coverage, baseline is 3. The description adds value by clarifying the pricing unit (3 queries per dollar, resolving schema ambiguity) and adding behavioral context for desiredOutcome ('to focus the analysis'). It does not mention walletAddress or agentName, but these are optional and adequately described in the schema.

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 uses a specific verb ('Get') with a clear resource ('Oracle signal') and scope ('Polymarket or Kalshi prediction market'). It strongly distinguishes from sibling admin tools (admin_queries, admin_stats, pricing, history) by focusing on the core data retrieval use case.

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?

Clear context is provided: requires session token from nodusai.app, includes pricing model ($1 USDC = 3 queries), and guides optional parameter usage ('to focus the analysis'). However, it does not explicitly contrast with nodus_verify_signal or nodus_query_history to clarify when to get new signals versus verify existing ones or check history.

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/NodusAI-Your-Prediction-Broker/nodusai-mcp-server'

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