Skip to main content
Glama
anboyu-alt

dart-risk-mcp

by anboyu-alt

analyze_company_risk

Detect unfair trading risk signals in Korean DART public disclosures by company name or stock code. Returns signal patterns, timelines, and public-record references for compliance review.

Instructions

기업명 또는 종목코드로 공시 기반 불공정거래 위험 신호를 분석한다.

공개기록 레지스트리(opt-in)가 설정돼 있고 이 회사가 등재 행위자의 관련기업으로 태깅된 경우, 리포트 말미에 공개기록 참고 섹션이 추가된다.

Args: company_name: 기업명 (예: "에코프로") 또는 종목코드 6자리 (예: "086520") lookback_years: 조회 기간(년). 기본 1년, 1~5년 범위. 1년을 넘으면 원문 사실 블록 없이 신호·패턴·타임라인만 담은 "지도"가 된다 — 특정 구간을 깊게 보려면 from_date/to_date로 좁혀 다시 조회한다. from_date: 조회 시작일(선택). "2024-01-01"·"20240101" 형식. 주면 lookback_years는 무시된다. to_date: 조회 종료일(선택). 미지정 시 오늘. from_date만 주면 그날부터 오늘까지, to_date만 주면 그날 기준 1년.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
to_dateNo
from_dateNo
company_nameYes
lookback_daysNo
lookback_yearsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.21.25
    • addedInput schema / properties / from_date
      Added value: +{
      +  "default": "",
      +  "title": "From Date",
      +  "type": "string"
      +}
    • addedInput schema / properties / to_date
      Added value: +{
      +  "default": "",
      +  "title": "To Date",
      +  "type": "string"
      +}
  2. Addedv1.10.3
  3. Removedv1.6.0
  4. Changed4 schema fields changedv1.4.0
    • addedInput schema / properties / lookback_days / anyOf
      Added value: +[
      +  {
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / lookback_days / default
      Previous value: -90New value: +null
    • removedInput schema / properties / lookback_days / type
      Removed value: -"integer"
    • addedInput schema / properties / lookback_years
      Added value: +{
      +  "default": 1,
      +  "title": "Lookback Years",
      +  "type": "integer"
      +}
  5. First observedv1.0.3

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses conditional behavior (registry opt-in section), output mode changes (map without original fact blocks), and date-override semantics. It does not cover errors or side effects, but the disclosed behaviors are substantive.

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?

Opens with the core purpose, isolates the conditional registry behavior, and structures the parameter details in a compact Args block. Every sentence adds meaningful information without repeating schema defaults.

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 no annotations and zero schema descriptions, the description covers most operational details well and can rely on the output schema for return values. The main gaps are the undocumented lookback_days parameter and lack of guidance on choosing among risk-analysis sibling tools.

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?

Schema description coverage is 0%, and the description compensates by explaining company_name, lookback_years, from_date, and to_date with examples, formats, defaults, and precedence. However, lookback_days appears in the schema but is completely undocumented, leaving a gap.

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

Purpose4/5

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

States a clear and specific action: analyze disclosure-based unfair trading risk signals for a company name or stock code. The resource and verb are concrete, but it does not explicitly differentiate itself from the similarly named sibling tool check_disclosure_risk.

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

Usage Guidelines4/5

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

Provides concrete usage conditions: lookback_years range and default, the map mode when exceeding one year, and the recommendation to narrow with from_date/to_date for deeper sections. No explicit when-not-to-use or sibling exclusions are given, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.