Skip to main content
Glama

get_template_list

Retrieve available development record templates with names and descriptions to identify templates for detailed content access.

Instructions

获取可用的开发记录模板列表。返回包含模板名称、文件名和描述的结构化数据。返回的 templates 数组中每个模板都有 templateName 字段,这是后续调用 get_template_detail 时必需的参数。使用此工具来发现可用的模板,然后使用返回的 templateName 来获取具体模板内容。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dummyNoDummy parameter for no-parameter tools

Implementation Reference

  • Main execution logic for the get_template_list tool: validates input, reads template directory, filters .md files, constructs list with templateName, filename, and description, returns structured JSON response.
    case "get_template_list": {
      const parsed = GetTemplateListSchema.safeParse(args);
      if (!parsed.success) {
        throw new Error(`Invalid arguments for get_template_list: ${parsed.error}`);
      }
    
      try {
        const templateDir = getTemplateDir();
        const files = await readdir(templateDir);
        
        // 过滤出 .md 文件并构建模板信息
        const templates = files
          .filter((file: string) => extname(file) === ".md")
          .map((file: string) => {
            const templateName = basename(file, ".md");
            return {
              templateName,
              filename: file,
              description: getTemplateDescription(templateName)
            };
          });
    
        // 返回标准化格式,便于AI识别和使用
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify({
                success: true,
                templates,
                count: templates.length,
                message: `Found ${templates.length} available templates`,
                usage: "Use the 'templateName' field from any template to call get_template_detail"
              }, null, 2)
            }
          ]
        };
      } catch (error) {
        const errorMessage = error instanceof Error ? error.message : String(error);
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify({
                success: false,
                error: `Failed to get template list: ${errorMessage}`,
                templates: []
              }, null, 2)
            }
          ],
          isError: true,
        };
      }
    }
  • Zod input schema for get_template_list tool, allowing optional dummy parameter since it's a no-arg tool.
    const GetTemplateListSchema = z.object({
      dummy: z.string().optional().describe("Dummy parameter for no-parameter tools")
    });
  • src/index.ts:85-91 (registration)
    Tool registration in listTools handler, defining name, detailed description, and input schema.
      name: "get_template_list",
      description:
        "获取可用的开发记录模板列表。返回包含模板名称、文件名和描述的结构化数据。" +
        "返回的 templates 数组中每个模板都有 templateName 字段,这是后续调用 get_template_detail 时必需的参数。" +
        "使用此工具来发现可用的模板,然后使用返回的 templateName 来获取具体模板内容。",
      inputSchema: zodToJsonSchema(GetTemplateListSchema) as ToolInput,
    },
  • Helper function to resolve the path to the template directory, handling build vs src contexts.
    function getTemplateDir(): string {
      // 如果在build目录中运行,需要回到上级目录找src/template
      const srcDir = __dirname.includes('build') ? join(__dirname, '..', 'src') : __dirname;
      return join(srcDir, "template");
    }
  • Helper function providing human-readable descriptions for each template by name.
    function getTemplateDescription(templateName: string): string {
      const descriptions: Record<string, string> = {
        "meeting-record": "会议记录模板 - 用于记录会议内容、决策和行动项",
        "project-summary": "项目总结模板 - 用于总结项目进展、问题和计划",
        "learning-notes": "学习笔记模板 - 用于记录学习内容和心得体会",
        "daily-standup": "每日站会模板 - 用于记录团队每日站会内容"
      };
      
      return descriptions[templateName] || "通用记录模板";
    }
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it returns structured data with specific fields (templateName, filename, description), explains the output format (templates array), and clarifies that templateName is required for subsequent calls to get_template_detail. However, it doesn't mention potential limitations like pagination or rate limits.

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 perfectly concise with three sentences that each serve a distinct purpose: stating the tool's function, describing the return structure, and providing usage guidance. There is zero wasted text, and information is front-loaded appropriately.

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 low complexity (no real parameters, no output schema, no annotations), the description is nearly complete. It explains what the tool does, what it returns, and how to use the output. The only minor gap is lack of explicit mention that this is a read-only operation, though that's reasonably inferred from the 'get' prefix and list functionality.

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 input schema has 100% description coverage but only documents a dummy parameter. The description correctly indicates this is essentially a no-parameter tool by not mentioning any required inputs, adding value beyond the schema. It compensates for the dummy parameter's lack of real meaning by focusing on the tool's parameterless nature.

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 ('获取可用的开发记录模板列表') and resource ('模板列表'). It distinguishes from its sibling tool 'get_template_detail' by explaining this tool discovers available templates while the sibling gets specific template content.

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 guidance on when to use this tool ('使用此工具来发现可用的模板') and when to use the alternative ('然后使用返回的 templateName 来获取具体模板内容'). It clearly establishes the workflow relationship with the sibling tool.

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/seenbefore/DevRecord'

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