Skip to main content
Glama
MarkdownLM

MarkdownLM MCP Server

Official
by MarkdownLM

resolve_gap

Log undocumented decisions as knowledge gaps when no documented guidance exists, then returns how to proceed based on the team's configured gap policy: ask user, infer, or agent decide.

Instructions

Call this when query_knowledge_base returned no documented guidance for a decision you need to make. Logs the undocumented decision as a knowledge gap so the developer can review and document it. Returns how you should proceed based on the team's configured gap policy: "ask_user" = stop and ask the developer for a decision before continuing; "infer" = MarkdownLM has auto-resolved the gap, use the returned resolution value; "agent_decide" = proceed with your best judgement and document your reasoning. Do NOT call this if query_knowledge_base returned matching rules — it is only for genuinely undocumented decisions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
questionYesThe specific undocumented decision you need to make, phrased as a question. Be precise so the developer understands exactly what is missing from the knowledge base. Example: "Which HTTP client library should I use for server-side requests — axios, got, or native fetch?"
categoryYesCategory that best describes the gap. Helps the developer triage and document the missing rule.

Implementation Reference

  • src/index.ts:132-171 (registration)
    Tool definition and input schema for 'resolve_gap' registered in the ListToolsRequestSchema handler. Name, description, and inputSchema with 'question' (string) and 'category' (enum) required fields.
    {
      name: 'resolve_gap',
      description:
        "Call this when query_knowledge_base returned no documented guidance for a decision you need to make. " +
        "Logs the undocumented decision as a knowledge gap so the developer can review and document it. " +
        "Returns how you should proceed based on the team's configured gap policy: " +
        '"ask_user" = stop and ask the developer for a decision before continuing; ' +
        '"infer" = MarkdownLM has auto-resolved the gap, use the returned resolution value; ' +
        '"agent_decide" = proceed with your best judgement and document your reasoning. ' +
        'Do NOT call this if query_knowledge_base returned matching rules — it is only for genuinely undocumented decisions.',
      inputSchema: {
        type: 'object' as const,
        properties: {
          question: {
            type: 'string',
            description:
              'The specific undocumented decision you need to make, phrased as a question. ' +
              'Be precise so the developer understands exactly what is missing from the knowledge base. ' +
              'Example: "Which HTTP client library should I use for server-side requests — axios, got, or native fetch?"',
          },
          category: {
            type: 'string',
            enum: [
              'architecture',
              'stack',
              'testing',
              'deployment',
              'security',
              'style',
              'dependencies',
              'error_handling',
              'business_logic',
              'general',
            ],
            description: 'Category that best describes the gap. Helps the developer triage and document the missing rule.',
          },
        },
        required: ['question', 'category'],
      },
    },
  • The tool execution handler for 'resolve_gap'. Extracts 'question' and 'category' from arguments, validates them as required strings, calls client.resolveGap(), logs the outcome, and returns the result.
    case 'resolve_gap': {
      const question = requireString(safeArgs, 'question')
      if (!question) { log(toolName, safeArgs, 'error', 'missing question'); return err('question is required') }
      const category = requireString(safeArgs, 'category')
      if (!category) { log(toolName, safeArgs, 'error', 'missing category'); return err('category is required') }
      const result = await client.resolveGap({ question, category })
      log(toolName, { question, category }, 'ok')
      return ok(result)
    }
  • ResolveGapInput type definition: requires 'question' (string) and 'category' (string).
    export interface ResolveGapInput {
      question: string
      category: string
    }
  • ResolveGapResult type definition: includes 'gap_detected' (boolean), 'resolution_mode' (union of 'markdownlm' | 'ask_user' | 'agent_decide' | 'none'), optional 'resolution' (string), and optional 'gap_id' (string).
    export interface ResolveGapResult {
      gap_detected: boolean
      resolution_mode: 'markdownlm' | 'ask_user' | 'agent_decide' | 'none'
      resolution?: string
      gap_id?: string
    }
  • The client-side resolveGap method. Accepts ResolveGapInput, makes a POST request to '/gaps/detect' with 'query' (the question) and 'category', and returns a Promise<ResolveGapResult>.
    async resolveGap(input: ResolveGapInput): Promise<ResolveGapResult> {
      return this.request<ResolveGapResult>('/gaps/detect', {
        query: input.question,
        ...(input.category ? { category: input.category } : {}),
      })
    }
Behavior4/5

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

No annotations are provided, so the description must disclose behavioral traits. It explains the tool logs a knowledge gap and returns a policy decision. However, it does not mention whether the operation is read-only, requires authentication, or has side effects beyond logging. While it covers essential behavior, slightly more context about safety and effects would improve transparency. Still, it is clear and accurate.

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 well-structured with a clear front-loading of the primary use case. It uses three sentences to convey the purpose, conditions, and expected return values. While it is moderately concise, it could be slightly more compact without losing clarity. Every sentence earns its place, but there is minor redundancy (e.g., 'undocumented decision' repeated).

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 moderate complexity, no output schema, and no annotations, the description provides a fairly complete picture. It explains the input parameters, the condition for use, and the three possible return values with actionable instructions. A minor gap is the lack of detail on what logging entails (e.g., is it persistent?), but overall it is sufficient for an agent to use the tool correctly.

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?

Input schema coverage is 100%, so the baseline is 3. The description adds some extra guidance for the 'question' parameter (phrasing as a precise question) but does not add significant meaning beyond the schema. The 'category' parameter is already fully described by the enum. Thus, minimal added value warrants a score of 3.

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 tool's purpose: to be called when query_knowledge_base returns no documented guidance. It distinguishes itself from the sibling tool 'query_knowledge_base' by specifying the condition under which to use it, and explicitly says when not to call it. This meets the criteria for a specific verb+resource with sibling differentiation.

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?

The description provides explicit usage guidelines: call this only when query_knowledge_base returns no matching rules, and do NOT call it if rules exist. It explains the three possible outcomes based on the team's gap policy, giving agents clear instructions on how to proceed. This fully satisfies the dimension with explicit when/when-not and alternative behavior.

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/MarkdownLM/mcp'

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