Skip to main content
Glama
seanshin0214

Dr. QuantMaster MCP Server

by seanshin0214

write_results_section

Generate results section templates for quantitative research papers using APA, ASA, or Econometrica formatting styles based on analysis type and findings.

Instructions

결과 섹션 작성 템플릿 생성

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
analysis_typeYes분석 유형
resultsYes주요 결과
styleNo스타일

Implementation Reference

  • Registers the 'write_results_section' tool in the main tools array, including its name, description, and input schema definition.
      name: "write_results_section",
      description: "결과 섹션 작성 템플릿 생성",
      inputSchema: {
        type: "object",
        properties: {
          analysis_type: { type: "string", description: "분석 유형" },
          results: { type: "object", description: "주요 결과" },
          style: { type: "string", enum: ["apa", "asa", "econometrica"], description: "스타일" },
        },
        required: ["analysis_type", "results"],
      },
    },
  • The main handler function that implements the logic for the 'write_results_section' tool. It extracts analysis_type and style from args and returns a placeholder template response.
    function handleWriteResultsSection(args: Record<string, unknown>) {
      return {
        analysis_type: args.analysis_type,
        style: args.style,
        template: "Results section template based on analysis type and style guide"
      };
    }
  • Dispatches calls to the 'write_results_section' tool to its handler function within the central handleToolCall switch statement.
    case "write_results_section":
      return handleWriteResultsSection(args);
  • Defines the input schema for the 'write_results_section' tool, specifying properties for analysis_type, results, and style with required fields.
    inputSchema: {
      type: "object",
      properties: {
        analysis_type: { type: "string", description: "분석 유형" },
        results: { type: "object", description: "주요 결과" },
        style: { type: "string", enum: ["apa", "asa", "econometrica"], description: "스타일" },
      },
      required: ["analysis_type", "results"],
    },
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. It states the tool creates a template, implying a write operation, but does not disclose behavioral traits like whether it modifies existing data, requires specific permissions, or has rate limits. The description is too vague to provide adequate transparency for a tool with potential mutation effects.

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

Conciseness3/5

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

The description is a single, concise sentence in Korean, which is efficient. However, it is under-specified rather than truly concise, as it lacks necessary details for clarity and usage. The structure is front-loaded but incomplete, earning a middle score for brevity without sufficient content.

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 no annotations, no output schema, and a tool that likely involves creating content (implying mutation), the description is incomplete. It does not explain what the tool outputs (e.g., a text template, file path) or provide context on its role among sibling tools. For a 3-parameter tool with nested objects, more detail is needed to guide effective use.

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 all parameters (analysis_type, results, style) with descriptions. The tool description does not add any meaning beyond the schema, such as explaining the purpose of 'results' as an object or the context for style choices. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description '결과 섹션 작성 템플릿 생성' (creates a results section writing template) restates the tool name 'write_results_section' in Korean, making it tautological. It specifies creating a template for a results section but does not clarify what type of results (e.g., statistical, research) or distinguish it from sibling tools like 'apa_reporting' or 'table_code' that might involve similar reporting tasks.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, and it fails to reference sibling tools that might be related, such as 'apa_reporting' or 'journal_guide', leaving the agent without usage direction.

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/seanshin0214/quantmaster-mcp-server'

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