Skip to main content
Glama
dolseom

gongsi-mcp

by dolseom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

탐지 결과 상세 이어 읽기

read_detection_result

Fetch the detailed rationale, caveats, and sections of a detection result by its ID, without re-running the detection engine. Supports partial reads via section and offset for paginated retrieval.

Instructions

detect_undisclosed_transactions 요약이 준 result_id 로 판정 근거·caveat 전문을 읽습니다 (키 불요, 탐지 엔진을 다시 돌리지 않습니다).

  • section 에 요약의 available_sections 중 하나를 넣으세요 (예: goods_services_signals · coverage · scope_caveats · notes · action_items). 생략하면 결과 전체를 읽습니다

  • 한 번에 최대 8000자이고 응답 크기 예산에 맞춰 더 짧게 올 수도 있습니다. next_offset 을 그대로 다시 넣으면 이어집니다 — 조각을 순서대로 이어붙이면 원본과 정확히 같습니다. 중간 조각은 그 자체로 유효한 JSON 이 아닙니다

  • offset·total_chars 는 UTF-16 코드 단위입니다 (바이트가 아닙니다 — 한글 1자 = 1 단위)

  • ⚠️ 상세는 서버 프로세스 메모리에만 30분 보관됩니다. 만료·회수·서버 재시작 뒤에는 result_unavailable 로 거절하고 다시 탐지해야 합니다 — 다른 결과를 대신 돌려주지 않습니다

  • ⚠️ 읽지 않은 상세를 "확인했다"고 말하지 마세요. 요약의 details_required 는 아직 안 읽은 근거가 있다는 뜻입니다

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo한 번에 읽을 최대 문자 수 (UTF-16 코드 단위, 기본·최대 8000). 응답 크기 예산에 맞춰 더 짧게 돌아올 수 있습니다
offsetNo이어 읽을 시작 위치 (UTF-16 코드 단위, 기본 0). 앞 호출이 준 next_offset 을 그대로 넣으세요
sectionNo읽을 최상위 항목 이름 (요약의 available_sections 목록 중 하나). 예: goods_services_signals · coverage · scope_caveats · notes. 생략하면 결과 전체를 읽습니다. 파일 경로나 a.b 형태의 중첩 표현은 받지 않습니다
result_idYesdetect_undisclosed_transactions 요약 응답이 준 result_id. 수명은 30분이고 서버 프로세스 안에서만 유효합니다

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4.7/5.0
Behavior5/5

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

Despite having no annotations, the description discloses the 30-minute memory TTL, result_unavailable rejection after expiry/retrieval/server restart, the non-JSON nature of intermediate chunks, the exact-concatenation guarantee, and the prohibition on claiming unread details as confirmed. This is far more than minimal behavioral disclosure.

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 purpose is front-loaded in the first sentence, and the remaining content is organized into compact, information-dense bullets covering pagination, unit semantics, and warnings. No filler is present; each warning earns its place as safety-critical guidance.

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 a paginated reader with no output schema and no annotations, it covers input selection, chunk size limits, ordering and concatenation behavior, failure mode, TTL, and result semantics. The references to next_offset and total_chars provide enough of the response contract for an agent to use the tool correctly.

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 coverage is 100%, so the baseline is 3, but the description adds operational nuance: using next_offset as-is, UTF-16 code units with Hangul = 1 unit, response-size budget shortening, and section values drawn from available_sections. Most of this reinforces the schema rather than adding entirely new parameter information, but the added emphasis is genuinely useful.

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 sentence names the action (읽습니다), the object (판정 근거·caveat 전문), and the required identifier (result_id). It also clarifies what the tool is not: it does not rerun the detection engine and needs no key, which distinguishes it from detect_undisclosed_transactions.

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?

States clearly that this is the reader for a detect_undisclosed_transactions summary and explains section selection, omission for full output, and next_offset-based continuation. It does not explicitly name alternative tools for re-running detection, so the when-not guidance is implied rather than fully explicit.

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