Skip to main content
Glama
AdamikHQ

Adamik MCP Server

Official

getApiSpecification

Retrieve the OpenAPI specification for Adamik API to access exact schemas for blockchain operations across 80+ networks, including transaction formats, parameters, and error handling.

Instructions

Get the comprehensive OpenAPI specification for the Adamik API covering 80+ blockchain networks. This provides authoritative reference for: • Exact request/response schemas for all transaction types (transfer, stake, unstake, claimRewards, convertAsset, etc.) • Complete chain family details (EVM, Cosmos, Bitcoin, Solana, Starknet, etc.) with supported features • Precise parameter formats (amounts in smallest units, address formats, token IDs, validator addresses) • Transaction encoding formats (RLP, PSBT, BOC, BCS, etc.) and signature requirements • Account state schemas (native/token balances, staking positions, rewards) • Error handling patterns and validation rules • Pagination support for large datasets Use this when you need exact API contract details for blockchain operations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sectionNoOptional: specific section like 'paths', 'components', 'schemas'. If not provided, returns full spec
refreshNoOptional: refresh the cached specification from API

Implementation Reference

  • The main execution logic for the getApiSpecification tool. It manages an in-memory cache of the OpenAPI spec fetched from the Adamik API endpoint, supports optional refresh, filters by section if specified, and returns the JSON stringified result.
    async ({ section, refresh }) => {
      if (!cachedApiSpec || refresh) {
        cachedApiSpec = await makeApiRequest<any>(
          `${ADAMIK_API_BASE_URL.replace("/api", "")}/openapi.json`,
          ADAMIK_API_KEY
        );
      }
    
      const result = section && cachedApiSpec[section] ? cachedApiSpec[section] : cachedApiSpec;
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(result, null, 2),
          },
        ],
      };
    }
  • Zod input schema defining optional parameters: 'section' (string for specific OpenAPI section) and 'refresh' (boolean to bypass cache).
    {
      section: z
        .string()
        .optional()
        .describe(
          "Optional: specific section like 'paths', 'components', 'schemas'. If not provided, returns full spec"
        ),
      refresh: z.boolean().optional().describe("Optional: refresh the cached specification from API"),
    },
  • src/module.ts:508-549 (registration)
    The server.tool() registration call that defines the tool name, description, input schema, and references the handler function.
    server.tool(
      "getApiSpecification",
      [
        "Get the comprehensive OpenAPI specification for the Adamik API covering 80+ blockchain networks.",
        "This provides authoritative reference for:",
        "• Exact request/response schemas for all transaction types (transfer, stake, unstake, claimRewards, convertAsset, etc.)",
        "• Complete chain family details (EVM, Cosmos, Bitcoin, Solana, Starknet, etc.) with supported features",
        "• Precise parameter formats (amounts in smallest units, address formats, token IDs, validator addresses)",
        "• Transaction encoding formats (RLP, PSBT, BOC, BCS, etc.) and signature requirements",
        "• Account state schemas (native/token balances, staking positions, rewards)",
        "• Error handling patterns and validation rules",
        "• Pagination support for large datasets",
        "Use this when you need exact API contract details for blockchain operations.",
      ].join(" "),
      {
        section: z
          .string()
          .optional()
          .describe(
            "Optional: specific section like 'paths', 'components', 'schemas'. If not provided, returns full spec"
          ),
        refresh: z.boolean().optional().describe("Optional: refresh the cached specification from API"),
      },
      async ({ section, refresh }) => {
        if (!cachedApiSpec || refresh) {
          cachedApiSpec = await makeApiRequest<any>(
            `${ADAMIK_API_BASE_URL.replace("/api", "")}/openapi.json`,
            ADAMIK_API_KEY
          );
        }
    
        const result = section && cachedApiSpec[section] ? cachedApiSpec[section] : cachedApiSpec;
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify(result, null, 2),
            },
          ],
        };
      }
    );
  • In-memory cache variable specific to the getApiSpecification tool for storing the fetched OpenAPI spec.
    // Simple in-memory cache for the API spec
    let cachedApiSpec: any = null;
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by detailing what the specification covers (request/response schemas, chain families, parameter formats, etc.). It mentions 'cached specification' which aligns with the 'refresh' parameter, but doesn't disclose potential limitations like rate limits or authentication requirements.

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

Conciseness4/5

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

The description is appropriately sized and front-loaded with the core purpose, followed by bullet points detailing coverage areas. While comprehensive, the bulleted list is somewhat lengthy but each point adds value for understanding the specification's scope.

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?

For a tool with no annotations and no output schema, the description provides substantial context about what the specification contains and when to use it. However, it doesn't describe the return format (e.g., JSON/YAML structure) or potential error cases, leaving some gaps in completeness.

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?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for high schema coverage.

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 'Get' and the resource 'comprehensive OpenAPI specification for the Adamik API', with specific scope covering '80+ blockchain networks'. It distinguishes from siblings by focusing on API documentation rather than operations like broadcastTransaction or getAccountState.

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

Usage Guidelines5/5

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

Explicitly states 'Use this when you need exact API contract details for blockchain operations', providing clear when-to-use guidance. It contrasts with siblings by implying this is for reference purposes rather than executing actions like deriveAddress or getTransactionDetails.

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/AdamikHQ/adamik-mcp-server'

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