Skip to main content
Glama
seanshin0214

Dr. QuantMaster MCP Server

by seanshin0214

diagnose_regression

Diagnose regression model issues like multicollinearity, heteroscedasticity, and autocorrelation to validate statistical assumptions and improve analysis accuracy.

Instructions

회귀분석 진단 가이드 (다중공선성, 이분산, 자기상관 등)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
issuesYes의심되는 문제 (multicollinearity, heteroscedasticity, autocorrelation, outliers)
model_typeNo모형 유형

Implementation Reference

  • Handler function that takes issues array and returns diagnostic tests, code snippets, and solutions for common regression problems like multicollinearity, heteroscedasticity, and autocorrelation.
    function handleDiagnoseRegression(args: Record<string, unknown>) {
      const issues = args.issues as string[];
      const diagnostics: Record<string, any> = {
        multicollinearity: {
          tests: ["VIF (>10 문제)", "Condition Number (>30 문제)", "Correlation Matrix"],
          r_code: "car::vif(model)",
          stata_code: "vif",
          solution: "변수 제거, PCA, Ridge regression"
        },
        heteroscedasticity: {
          tests: ["Breusch-Pagan test", "White test", "Residual plot"],
          r_code: "lmtest::bptest(model)",
          stata_code: "hettest",
          solution: "Robust SE, WLS, Log transformation"
        },
        autocorrelation: {
          tests: ["Durbin-Watson", "Breusch-Godfrey", "ACF plot"],
          r_code: "lmtest::dwtest(model)",
          stata_code: "dwstat",
          solution: "HAC SE, GLS, ARIMA errors"
        }
      };
    
      return {
        issues,
        diagnostics: issues.map(issue => diagnostics[issue] || { issue, message: "진단 정보 검색 필요" })
      };
    }
  • Registration of the 'diagnose_regression' tool in the main tools array, including name, description, and input schema.
      name: "diagnose_regression",
      description: "회귀분석 진단 가이드 (다중공선성, 이분산, 자기상관 등)",
      inputSchema: {
        type: "object",
        properties: {
          issues: {
            type: "array",
            items: { type: "string" },
            description: "의심되는 문제 (multicollinearity, heteroscedasticity, autocorrelation, outliers)"
          },
          model_type: { type: "string", description: "모형 유형" },
        },
        required: ["issues"],
      },
    },
  • Input schema defining the expected parameters: issues (array of strings) required, model_type optional.
    inputSchema: {
      type: "object",
      properties: {
        issues: {
          type: "array",
          items: { type: "string" },
          description: "의심되는 문제 (multicollinearity, heteroscedasticity, autocorrelation, outliers)"
        },
        model_type: { type: "string", description: "모형 유형" },
      },
      required: ["issues"],
    },
  • Switch case in handleToolCall that routes calls to the diagnose_regression handler.
    case "diagnose_regression":
      return handleDiagnoseRegression(args);
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 states the tool is a 'diagnosis guide' but doesn't clarify behavioral traits like whether it performs computations, provides textual guidance, requires specific inputs beyond parameters, or has any side effects. This leaves significant gaps in understanding how the tool operates beyond its basic purpose.

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 a single, efficient phrase in Korean that conveys the core purpose without unnecessary elaboration. It's front-loaded with key terms but could be slightly more structured for clarity. Overall, it's concise and to the point, with no wasted words.

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 of regression diagnostics, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., diagnostic reports, recommendations, or test results), behavioral details, or how to interpret outputs. This leaves the agent with incomplete information for effective use in a statistical context.

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%, with parameters 'issues' and 'model_type' well-documented in the schema. The description adds minimal value by listing examples (multicollinearity, heteroscedasticity, autocorrelation) that align with the schema's description for 'issues', but it doesn't provide additional context like parameter interactions or usage tips. Baseline 3 is appropriate as the schema handles most documentation.

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

Purpose3/5

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

The description '회귀분석 진단 가이드 (다중공선성, 이분산, 자기상관 등)' translates to 'Regression analysis diagnosis guide (multicollinearity, heteroscedasticity, autocorrelation, etc.)', which indicates the tool provides diagnostic guidance for regression analysis. However, it's vague about the exact action (e.g., whether it generates reports, runs tests, or offers advice) and doesn't clearly distinguish from sibling tools like 'check_assumptions' or 'interpret_diagnostics', which might overlap in functionality.

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 lacks explicit guidance on when to use this tool versus alternatives. It mentions diagnostic aspects but doesn't specify contexts, prerequisites, or exclusions, such as when to choose it over 'check_assumptions' or 'interpret_diagnostics'. No usage scenarios or comparisons are provided, leaving the agent with minimal 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