Skip to main content
Glama
ycyun

ABLESTACK MOLD MCP Server

by ycyun

MOLD 서명/URL 디버그

mold_signDebug

Debug and validate API signatures by generating normalized strings, Base64 signatures, URL-encoded signatures, and final request URLs for ABLESTACK MOLD MCP Server API calls.

Instructions

정규화 문자열, 서명(Base64), URL 인코딩 서명, 최종 요청 URL을 생성해 점검합니다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commandYes
paramsNo
includeResponseNo
apiKeyFieldNo

Implementation Reference

  • Registers the mold_signDebug MCP tool, defining its metadata, input schema using Zod, and a thin handler function that invokes buildSignedUrlDebug and formats the response.
    server.registerTool(
      "mold_signDebug",
      {
        title: "MOLD 서명/URL 디버그",
        description: "정규화 문자열, 서명(Base64), URL 인코딩 서명, 최종 요청 URL을 생성해 점검합니다.",
        inputSchema: {
          command: z.string(),
          params: z.record(z.string(), z.union([z.string(), z.number(), z.boolean()])).optional(),
          includeResponse: z.boolean().optional(),
          apiKeyField: z.enum(["apiKey", "apikey"]).optional(),
        },
      },
      async ({ command, params, includeResponse = true, apiKeyField = "apiKey" }) => {
        const dbg = buildSignedUrlDebug(command, params ?? {}, { includeResponse, apiKeyField });
        return { content: [{ type: "text", text: JSON.stringify(dbg, null, 2) }] };
      }
    );
  • The MCP tool handler function for mold_signDebug, which calls the helper and returns structured content.
    async ({ command, params, includeResponse = true, apiKeyField = "apiKey" }) => {
      const dbg = buildSignedUrlDebug(command, params ?? {}, { includeResponse, apiKeyField });
      return { content: [{ type: "text", text: JSON.stringify(dbg, null, 2) }] };
    }
  • Core helper function implementing the debug logic: normalizes parameters, computes HMAC signature, builds and encodes the final signed URL, returns debug info.
    export function buildSignedUrlDebug(command, params = {}, { includeResponse = true, apiKeyField = "apiKey" } = {}) {
      const cfg = getConfig();
      if (!cfg.endpoint || !cfg.apiKey || !cfg.secret) {
        throw new Error(
          "MOLD 연결정보가 없습니다. mold_setConfig 도구로 endpoint/apiKey/secret 을 설정하세요."
        );
      }
    
      const baseParams = { ...(includeResponse ? { response: "json" } : {}), ...params, command };
      baseParams[apiKeyField] = cfg.apiKey;
    
      const normPairs = Object.keys(baseParams)
        .sort((a, b) => a.toLowerCase().localeCompare(b.toLowerCase()))
        .map((k) => {
          const v = baseParams[k];
          const encV = encodeURIComponent(String(v)).replace(/\+/g, "%20");
          return `${k.toLowerCase()}=${encV.toLowerCase()}`;
        });
      const normalized = normPairs.join("&");
    
      const signatureBase64 = hmac(cfg.algo, cfg.secret, normalized);
      const signatureUrlEncoded = encodeURIComponent(signatureBase64);
    
      const query = Object.entries(baseParams)
        .map(([k, v]) => `${encodeURIComponent(k)}=${encodeURIComponent(String(v))}`)
        .join("&");
      const sep = cfg.endpoint.includes("?") ? "&" : "?";
      const finalUrl = `${cfg.endpoint}${sep}${query}&signature=${signatureUrlEncoded}`;
    
      return {
        endpoint: cfg.endpoint,
        apiKeyFieldUsed: apiKeyField,
        includeResponse,
        normalized,
        signatureBase64,
        signatureUrlEncoded,
        finalUrl,
        signedParams: baseParams,
      };
    }
Behavior2/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 of behavioral disclosure. It mentions creating and checking components (normalized strings, signatures, URLs), implying a read-only or diagnostic operation, but doesn't specify if it performs actual API calls, requires authentication, has side effects, or details error handling. For a tool with 4 parameters and no annotations, this is a significant gap in transparency.

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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does, making it easy to parse. Every part of the sentence contributes essential information, earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 parameters, nested objects, no output schema, and 0% schema coverage), the description is incomplete. It lacks details on parameter usage, behavioral traits (e.g., whether it makes network calls), and output expectations. Without annotations or an output schema, the description should provide more context to guide effective tool invocation, but it falls short.

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

Parameters2/5

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

Schema description coverage is 0%, meaning none of the 4 parameters (command, params, includeResponse, apiKeyField) are documented in the schema. The description doesn't add any semantic information about these parameters—it doesn't explain what 'command' refers to, the purpose of 'params', what 'includeResponse' controls, or the significance of 'apiKeyField' enum values. With low coverage and no compensation in the description, this score reflects inadequate parameter guidance.

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: '정규화 문자열, 서명(Base64), URL 인코딩 서명, 최종 요청 URL을 생성해 점검합니다' (Creates and checks normalized strings, signatures (Base64), URL-encoded signatures, and final request URLs). It specifies the verb '생성해 점검합니다' (creates and checks) and the resources involved. However, it doesn't explicitly differentiate from sibling tools like 'mold_call_debug', which might have overlapping debugging purposes.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'mold_call_debug' or 'mold_call', nor does it specify contexts or prerequisites for usage. The tool's purpose is clear, but without usage guidelines, an agent might struggle to select it appropriately.

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/ycyun/ablestack-MCP-server'

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