Skip to main content
Glama
Johnhyeon

StockLens

by Johnhyeon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

save_analysis_to_excel

Need a record of your analysis? Save your compiled stock tables, candidate lists, and notes directly to an Excel workbook.

Instructions

분석결과저장 — 당신이 정리한 표를 그대로 Excel로 저장합니다.

scan_to_excel 은 정해진 지표를 종목별로 담는 도구입니다. 이 도구는 그와 달리, 여러 도구를 돌려 직접 판단하고 정리한 결과(후보 목록, 단계 판정, 겹침 분석 같은 것)를 사용자가 파일로 가져갈 수 있게 만듭니다.

반드시 지킬 것

  1. rows 의 숫자는 도구가 돌려준 값만 씁니다. 기억이나 추정으로 채우지 마세요. 확인 못 한 칸은 "-" 또는 "확인 안 됨" 으로 두고, 0 으로 채우지 않습니다.

  2. sources 에 어떤 도구를 썼는지 적습니다. 파일만 남았을 때 이 숫자가 어디서 왔는지 알 수 있어야 합니다. 예: ["screen_by_flow", "get_indicators_bulk"]

  3. 판단 근거와 한계를 notes 에 적습니다. 무엇을 걸렀고 무엇을 못 봤는지, 장중 잠정치인지 같은 것. 표만 남으면 나중에 잘못 읽힙니다.

  4. 매수·매도 권유, 목표가·손절가는 넣지 않습니다.

rows 구성 요령

  • 각 dict 의 키가 곧 열 이름입니다. 한글로 쓰세요(예: "종목명", "수급(2일)").

  • 모든 행이 같은 키를 갖도록 맞춥니다. 빠진 키는 빈칸이 됩니다.

  • 숫자는 숫자 그대로 넣으세요(문자열 "12.5%" 대신 12.5). 자릿점·색은 저장할 때 자동으로 붙습니다. 단위는 열 이름에 넣으세요("기간수익률(%)").

  • 종목이 20개 이하면 비교 그래프가 자동으로 함께 저장됩니다.

Args: title: 파일 제목. 첫 시트 이름과 요약에 쓰입니다. 예: "기대 부상후보 스캔" rows: 표 데이터. [{"종목명": "성광벤드", "기간수익률(%)": -8.9}, ...] notes: 판단 근거·제외 기준·한계. 한 줄에 하나씩. sources: 근거가 된 도구 이름들. detail_codes: 종목별 흐름 시트를 만들 6자리 코드들(최대 8개). 각 시트에 종가 추이·기관/외국인 순매매 그래프와 원자료가 들어갑니다. 목록만 있으면 "그래서 어떻게 움직이고 있나"를 다시 조회해야 하므로, 사용자가 더 볼지 정할 수 있게 후보 상위 몇 개는 넣어 주세요. detail_days: 흐름 시트에 담을 거래일 수 (기본 60, 최대 120). extras: 다른 렌즈에서 가져온 것을 종목 시트에 얹습니다. StockLens 는 TelegramLens·DartLens 를 직접 부르지 못하므로, 그 도구들을 먼저 호출해 결과를 여기에 담아 주세요. {"042660": [{"title": "텔레그램 언급", "cols": ["시각","채널","내용"], "rows": [["08-26 10:30","매경 자이앤트","원전 수주 기대"]]}]} 형식이며, 카드는 담은 순서대로 붙습니다. 넣을 만한 것: · TelegramLens — telegram_stock_buzz(언급 원문·telegram_link 를 url 로), telegram_timeline(확산 흐름) · DartLens — get_major_holders(5%룰: 연기금·행동주의 진입), get_insider_trades(임원·주요주주 매매 = 안에서 먼저 움직인 흔적), list_disclosures(정기·수시 공시), get_order_backlog(수주잔고 추이) · StockLens — get_us_short(미국 공매도), get_event_reactions(공시 반응) 행은 ["값", ...] 또는 {"cells": [...], "url": "원문 링크"} 로 넣습니다. ⚠️ 원문에 있는 내용만 옮기고, 없는 것을 지어내지 마세요. filename: 파일명 (비우면 제목으로 자동 생성)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsYes
notesNo
titleYes
extrasNo
sourcesNo
filenameNo
detail_daysNo
detail_codesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed18 schema fields changedv1.1.3
    • removedInput schema / properties / detail_codes / anyOf
      Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / detail_codes / default
      Removed value: -null
    • addedInput schema / properties / detail_codes / items
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / detail_codes / type
      Added value: +"array"
    • removedInput schema / properties / detail_days / default
      Removed value: -60
    • addedInput schema / properties / extras / additionalProperties
      Added value: +true
    • removedInput schema / properties / extras / anyOf
      Removed value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / extras / default
      Removed value: -null
    • addedInput schema / properties / extras / type
      Added value: +"object"
    • removedInput schema / properties / filename / default
      Removed value: -""
    • removedInput schema / properties / notes / anyOf
      Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / notes / default
      Removed value: -null
    • addedInput schema / properties / notes / items
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / notes / type
      Added value: +"array"
    • removedInput schema / properties / sources / anyOf
      Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / sources / default
      Removed value: -null
    • addedInput schema / properties / sources / items
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / sources / type
      Added value: +"array"
  2. Addedv1.0.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations (readOnlyHint:false, openWorldHint:true) are consistent with a file-creating tool, and the description adds substantial behavior beyond them: auto-generated comparison graph when ≤20 stocks, automatic decimal/color formatting, detail sheets with closing price and institutional/foreign net-buy graphs for detail_codes, and the data-integrity rules (never fabricate rows, mark unverified cells as '-', never use 0 as filler). No annotation contradiction. The only gap is silence on output/return value, which is acceptable given the output schema exists.

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 exceptionally long and would benefit from trimming. The 'rows 구성 요령' section overlaps with the rows parameter explanation (both cover key/column-name and number-format rules), and the '넣을 만한 것' list in extras sprawls with parenthetical explanations of each sibling tool. However, it is well-structured: critical rules are front-loaded in the '반드시 지킬 것' section with numbered items, and bolded headers aid scanning. Given 8 parameters and 0% schema coverage, much of the length is justified, but redundancy and the verbose tool enumeration cost it a higher score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with 0% schema coverage and nested objects, the description is thorough and complete: every parameter has meaning, format, and constraints, with concrete examples for rows and extras. It covers edge behaviors (missing keys become blanks, auto-graph at ≤20 stocks, max 8 detail_codes, max 120 days), data-integrity rules, and the workflow requirement of calling upstream tools first. Since an output schema exists, not explaining return values is acceptable. Nothing an agent needs to invoke this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the full burden — and it fully compensates. Every parameter gets a Korean explanation, format, and often an example: title (used in first sheet name and summary), rows (dict keys become column names, Korean headers required, numbers as numbers not strings, units in column names), notes (one per line), detail_codes (6-digit, max 8), detail_days (default 60, max 120), extras (full JSON example with tool-specific guidance), and filename (auto-generated from title if empty).

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?

States a specific verb+resource ('저장합니다' saves to Excel) and precisely defines what content is saved ('당신이 정리한 표'). Explicitly contrasts with sibling scan_to_excel (fixed indicators per stock) vs. this tool (individually judged/organized results like candidate lists, stage judgments, overlap analyses). An agent can unambiguously distinguish it from scan_to_excel and export_to_excel.

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?

Explicitly names the sibling scan_to_excel and gives the selection condition ('정해진 지표를 종목별로 담는 도구' vs. '직접 판단하고 정리한 결과'). Also states when the tool should be used (after running multiple tools and organizing findings) and provides prerequisites for correct invocation — calling TelegramLens/DartLens first and passing results via extras since StockLens cannot call them directly. Exclusion guidance is equally explicit: no buy/sell recommendations, no target prices or stop-losses.

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

Deploy Server

Other Tools