Skip to main content
Glama

sodax_get_solver_intent

Read-only

Get solver-side details and fill history for an intent hash. Use includeAll to view all related documents.

Instructions

Get solver-side details for an intent including fill history. Use includeAll to see all solver documents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
intentHashYesThe intent hash to look up
includeAllNoInclude all intent documents (history) instead of just the latest
formatNoResponse format: 'json' for raw data or 'markdown' for formatted textmarkdown

Implementation Reference

  • MCP tool registration and handler for 'sodax_get_solver_intent'. Defines the tool with Zod schema (intentHash, includeAll, format), calls getSolverIntent service, and returns formatted response.
    // Tool 20: Get Solver Intent Details
    server.tool(
      "sodax_get_solver_intent",
      "Get solver-side details for an intent including fill history. Use includeAll to see all solver documents.",
      {
        intentHash: z.string()
          .describe("The intent hash to look up"),
        includeAll: z.boolean().optional().default(false)
          .describe("Include all intent documents (history) instead of just the latest"),
        format: z.nativeEnum(ResponseFormat).optional().default(ResponseFormat.MARKDOWN)
          .describe("Response format: 'json' for raw data or 'markdown' for formatted text")
      },
      READ_ONLY,
      async ({ intentHash, includeAll, format }) => {
        try {
          const intent = await getSolverIntent(intentHash, includeAll);
          if (!intent) {
            return {
              content: [{ type: "text", text: `Solver intent not found: ${intentHash}` }]
            };
          }
          return {
            content: [{
              type: "text",
              text: `## Solver Intent Details\n\n` + formatResponse(intent, format)
            }]
          };
        } catch (error) {
          return {
            content: [{ type: "text", text: `Error: ${error instanceof Error ? error.message : "Unknown error"}` }],
            isError: true
          };
        }
      }
    );
  • Service function that makes the actual HTTP GET request to /solver/intents/:intentHash. Handles includeAll query param and 404 responses.
    /**
     * Get solver intent details by intent hash
     */
    export async function getSolverIntent(intentHash: string, includeAll?: boolean): Promise<unknown> {
      try {
        const params = new URLSearchParams();
        if (includeAll) params.append("includeAll", "true");
    
        const queryString = params.toString();
        const url = `/solver/intents/${intentHash}${queryString ? `?${queryString}` : ""}`;
        const response = await apiClient.get(url);
        return response.data;
      } catch (error) {
        if (axios.isAxiosError(error) && error.response?.status === 404) {
          return null;
        }
        console.error("Error fetching solver intent:", error);
        throw new Error("Failed to fetch solver intent from SODAX API");
      }
    }
  • Zod input schema for sodax_get_solver_intent: intentHash (required string), includeAll (optional boolean, default false), format (optional ResponseFormat enum, default markdown).
    {
      intentHash: z.string()
        .describe("The intent hash to look up"),
      includeAll: z.boolean().optional().default(false)
        .describe("Include all intent documents (history) instead of just the latest"),
      format: z.nativeEnum(ResponseFormat).optional().default(ResponseFormat.MARKDOWN)
        .describe("Response format: 'json' for raw data or 'markdown' for formatted text")
    },
  • src/index.ts:243-244 (registration)
    Tool is registered in the 'intents' category listing for the startup status report.
      "sodax_get_solver_intent"
    ],
  • API drift check entry mapping GET /solver/intents/:intentHash to the sodax_get_solver_intent tool with params intentHash and includeAll.
    "GET /solver/intents/:intentHash": {
      tool: "sodax_get_solver_intent",
      params: ["intentHash", "includeAll"],
      requiredParams: ["intentHash"],
    },
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, making the tool's safety profile clear. The description adds value by specifying it returns solver-side details including fill history, which is behavioral context beyond the annotations.

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 two sentences, front-loading the purpose and adding one relevant usage hint. Every word contributes value with 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 tool's simplicity (3 parameters, no output schema), the description covers the core purpose and one key parameter. It does not mention the format parameter, but the schema already handles that. Overall, it is complete enough for a read-only lookup, though a brief note on response format would improve it.

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 input schema has 100% description coverage, so parameters are already well-documented. The description adds minimal extra meaning—merely hinting to use includeAll for full history. This meets the baseline expectation but does not significantly enhance understanding beyond 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 'Get solver-side details for an intent including fill history' uses a specific verb ('Get') and resource ('solver details for an intent'), distinguishing it from sibling tool sodax_get_intent which likely provides general intent data. It also mentions a key parameter (includeAll) that clarifies scope.

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

Usage Guidelines3/5

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

The description implies when to use this tool (for solver-specific details) but lacks explicit guidance on when not to use it or how it compares to similar tools like sodax_get_intent. The hint 'Use includeAll to see all solver documents' provides usage context for one parameter but not overall selection criteria.

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/gosodax/builders-sodax-mcp-server'

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