Skip to main content
Glama

docs_refresh

Idempotent

Reconnect to SDK documentation and refresh available tools when documentation appears stale or unavailable.

Instructions

Reconnect to SDK documentation and refresh available tools. Use if docs seem stale or unavailable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The docs_refresh tool handler implementation. Clears GitBook cache and fetches fresh tools from the GitBook MCP server, returning a success message with the list of available tools or an error message if connection fails.
    // Tool to refresh GitBook tools
    server.tool(
      "docs_refresh",
      "Reconnect to SDK documentation and refresh available tools. Use if docs seem stale or unavailable.",
      {},
      { readOnlyHint: false, destructiveHint: false, idempotentHint: true },
      async () => {
        clearGitBookCache();
        const tools = await fetchGitBookTools();
        
        if (tools.length === 0) {
          return {
            content: [{
              type: "text",
              text: `⚠️ Could not connect to docs.sodax.com\n\nThe GitBook MCP may be temporarily unavailable. Try again later or visit https://docs.sodax.com directly.`
            }]
          };
        }
        
        const toolList = tools.map(t => `- \`docs_${t.name}\`: ${t.description}`).join("\n");
        return {
          content: [{
            type: "text",
            text: `✅ Refreshed. ${tools.length} SDK documentation tools available:\n\n${toolList}`
          }]
        };
      }
    );
  • The clearGitBookCache helper function used by docs_refresh. Clears the cached tools and resets the cache timestamp to force a fresh fetch.
    export function clearGitBookCache(): void {
      cachedTools = null;
      toolsCacheTime = 0;
    }
  • The fetchGitBookTools helper function used by docs_refresh. Fetches available tools from the GitBook MCP server with 10-minute caching, handles initialization, and returns cached tools if still valid.
    export async function fetchGitBookTools(): Promise<GitBookTool[]> {
      // Return cached tools if still valid
      if (cachedTools && Date.now() - toolsCacheTime < TOOLS_CACHE_DURATION) {
        return cachedTools;
      }
      
      try {
        // Initialize connection first
        await initializeConnection();
        
        // Fetch tools list
        const result = await sendMcpRequest("tools/list") as { tools: GitBookTool[] };
        
        cachedTools = result.tools || [];
        toolsCacheTime = Date.now();
        
        if (cachedTools.length > 0) {
          console.error(`✅ Fetched ${cachedTools.length} tools from GitBook MCP`);
        } else {
          console.error(`⚠️ GitBook MCP returned empty tools list`);
        }
        return cachedTools;
      } catch (error) {
        const errorMsg = error instanceof Error ? error.message : "unknown error";
        console.error(`❌ Failed to fetch GitBook tools: ${errorMsg}`);
        // Return cached tools even if expired, or empty array
        return cachedTools || [];
      }
    }
  • Analytics mapping for docs_refresh to the 'sdk-docs' group for PostHog tracking.
    docs_refresh: "sdk-docs",
  • The getGitBookToolNames function that includes docs_refresh in the list of available GitBook tool names returned by the API.
    export async function getGitBookToolNames(): Promise<string[]> {
      try {
        const tools = await fetchGitBookTools();
        const proxyTools = tools.map(t => `docs_${t.name}`);
        return [...proxyTools, "docs_health", "docs_refresh", "docs_list_tools"];
      } catch {
        return ["docs_health", "docs_refresh", "docs_list_tools"];
      }
    }
Behavior4/5

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

Annotations provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds useful context about what triggers the refresh ('if docs seem stale or unavailable'), which isn't covered by annotations. However, it doesn't disclose potential side effects like temporary unavailability during refresh or rate limits, leaving some behavioral aspects unspecified.

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 two concise sentences that are front-loaded with the core action ('Reconnect to SDK documentation and refresh available tools') followed by usage guidance. Every word earns its place 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 complexity (simple refresh operation with no parameters), annotations covering safety/idempotency, and no output schema, the description is mostly complete. It explains what the tool does and when to use it. However, it doesn't mention what happens after refresh (e.g., tools become available) or potential errors, leaving minor gaps.

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?

The tool has 0 parameters with 100% schema description coverage. The description doesn't need to explain parameters, but it could mention that no inputs are required. Since there are no parameters, the baseline is 4, and the description adequately covers the tool's purpose without parameter details.

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 with specific verbs ('reconnect', 'refresh') and resource ('SDK documentation', 'available tools'). It distinguishes itself from sibling tools like docs_list_tools (which lists tools) or docs_searchDocumentation (which searches docs) by focusing on refreshing/reconnecting functionality.

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 explicitly states when to use this tool ('if docs seem stale or unavailable'), providing clear context for its application. It doesn't mention alternatives, but given the specific problem it addresses (stale/unavailable docs), the guidance is sufficient for an agent to know when to invoke it.

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

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