Skip to main content
Glama
Johnhyeon

StockLens

by Johnhyeon

get_report_content

Read-onlyIdempotent

Fetch the full text or a concise summary of a single stock research report, or get a link to the original.

Instructions

리포트읽기 — 증권사 리포트 한 건의 PDF 본문을 읽어옵니다.

⚠️ 한 번에 한 건만. 리포트 하나가 1만 자를 넘어서, 여러 건을 이어 부르면 대화 토큰을 통째로 먹습니다. 목록·목표가·짧은 요약은 get_reports로 충분하고, "이 리포트 자세히", "목표가 근거" 처럼 한 건을 깊게 볼 때만 쓰세요.

어느 모드를 고를지는 사용자 말에 맞춥니다. 사용자가 따로 말하지 않으면 summary로 두세요.

mode

무엇을 주나

이렇게 말할 때

summary (기본)

앞 4,000자 발췌

"리포트 봐줘", "목표가 근거가 뭐야"

full

본문 전체 (상한 50,000자)

"전문 다 보여줘", "빠짐없이", "부록까지"

link

본문 없이 링크만

"링크만 줘", "내가 직접 볼게"

summary로 충분한 이유: 실측상 리포트는 앞쪽에 투자의견·목표가 산출 근거· 실적 추정이 모이고, 뒤쪽은 재무제표 부록과 컴플라이언스 고지문입니다. 판단 근거는 대개 앞 3,000자 안에 다 있습니다.

증권사마다 PDF 만드는 방식이 달라, 글자가 아니라 이미지로 렌더링해 내는 곳은 본문을 읽을 수 없습니다. 그 경우 억지로 몇 글자 내놓지 않고 못 읽었다고 알려주며 원문 링크로 안내합니다.

Args: nid: 리포트 번호. get_reports 결과에 함께 표시됩니다. mode: "summary"(기본) / "full" / "link". 한글("요약"·"전문"·"링크")도 됩니다. max_chars: 글자 수를 직접 지정하고 싶을 때만. 비우면 mode 기본값을 씁니다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nidYes
modeNo
max_charsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.1.3
    • removedInput schema / properties / max_chars / anyOf
      Removed value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / max_chars / default
      Removed value: -null
    • addedInput schema / properties / max_chars / type
      Added value: +"integer"
    • removedInput schema / properties / mode / default
      Removed value: -"summary"
  2. Addedv0.8.0

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark this as read-only and idempotent; the description adds meaningful behavior beyond that: it warns about token consumption, explains why summary mode is usually sufficient, and discloses that image-rendered PDFs may be unreadable and will result in a clear failure message with a link instead of fabricated text.

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 front-loaded with the core purpose, then uses a compact warning, a clear table, and brief rationale paragraphs. No sentence is redundant; each adds either usage context, failure-mode awareness, or parameter semantics.

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?

Given the output schema exists and the annotations already cover safety, the description covers every operational need: required parameter, mode defaults, optional parameter behavior, token-cost warning, sibling routing, and failure handling for image-based PDFs. Nothing necessary for correct invocation 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 description coverage is 0%, but the Args section fully compensates: nid is tied to get_reports output, mode is explained with all three values including Korean aliases and defaults, and max_chars is explicitly optional with behavior defined when omitted.

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?

First line states the exact action and scope: reads the PDF body of exactly one securities report. It explicitly contrasts itself with get_reports, so an agent can immediately tell which tool handles lists/summaries vs. deep single-report reading.

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?

Provides explicit when-to-use guidance: only for deep reading of a single report, while get_reports suffices for lists and short summaries. It also gives a mode-selection table with user-phrase examples, a clear default (summary), and guidance to avoid multi-call token exhaustion.

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