Skip to main content
Glama

예규·세부기준 통합 검색

search_references
Read-onlyIdempotent

공공계약 코퍼스 통합 검색 — 법령+계약예규+조달청·행안부 세부기준+실무가이드. LLM 미사용.

search_law가 법령 조문 전용인 것과 달리 예규·적격심사 세부기준·실무가이드까지
검색한다. 낙찰하한율·적격심사 배점·실무 절차 등 법령 본문 밖 질문에 사용하라.
AI 생성 없이 검색 근거 원문만 반환한다(백엔드 LLM 예산 미차감).

**세법은 이 도구가 못 본다(2026-08-29 정직 공시).** 세법 조문은 별도 코퍼스
(`tax_articles` 64개 법령)에 있고 여기 붙어 있는 채널(BM25·doc2query·rerank)은
공공계약 코퍼스 것이다. 소득세법·법인세법·부가가치세법류 질문은 **search_law**
(자동으로 세법 축으로 간다) 또는 get_law_article로 가라 — 여기서 0건이 나온 것을
"세법에 그런 규정이 없다"로 옮기지 마라.

히트의 `matched_section`이 있으면 그 자리를 만든 것은 **그 항**이고 실려온 본문은
조 전체다 — 근거를 인용할 때 그 항을 밝혀라. 최상위 히트의 `query_expanded`가 있으면
사용자가 타이핑한 말에 용어집 별칭을 덧붙인 질의로 검색·재정렬한 것이다(실무 어휘를
법령 어휘로 잇는 다리 — 원문은 보존).

**히트마다 `as_of`(그 문서가 언제 기준인가)가 붙는다.** 법령·예규는 우리가 들고 있는
스냅샷의 시행일자, 실무가이드는 발간 시점이다. 모르는 문서는 `as_of_unknown: true`로
오고 그것은 "현행"이라는 뜻이 아니다. 정적 발간물이 자기보다 **나중에 개정된 법령**을
인용하고 있으면 `superseded_risk`(어느 법령이 언제 개정됐는지)와 `vintage_warning`이
함께 오고, 응답 최상위 `vintage`가 그 요약이다 — 그때는 발췌의 금액·기준 수치를
현행으로 옮기지 말고 get_law_article로 현행 조문을 대조하라(계약방법 판정은
decide_contract_method가 현행 룰로 낸다).

**응답에 `off_topic: true`가 있으면 이 질의는 우리 코퍼스 주제 밖으로 측정됐다**
(2026-09-03). 히트가 남아 있어도 그것은 낱말이 겹쳐 회수된 것일 뿐 근거가 아닐 수
있다 — `off_topic_distance`가 최근접 주제 거리이고 `note_off_topic`이 대역을 말한다.
**이때 "관련 규정이 없다"고 옮기지 마라**(우리가 안 담고 있을 뿐이다). excerpt를
직접 읽어 실제로 질문에 답하는지 확인하고, 범위 밖이면 사용자에게 그 사실을 밝힌 뒤
사용자의 원문 질문을 report_issue(category='question_log')로 남겨라.

Args:
    query: 자연어 검색어 (예: "적격심사 낙찰하한율 50억 미만")
    top_k: 반환 건수 (기본 6, **허용 1~12**). 범위 밖 값은 오류가 아니라 가장
        가까운 허용값으로 **보정**되며(0·음수→1, 12 초과→12) 보정 사실은 응답의
        `top_k_applied`에 요청값·적용값·이유로 공시된다

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
top_kNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The annotations already declare readOnly, openWorld, idempotent, and non-destructive, but the description adds substantial behavior beyond them: no LLM generation, no backend LLM budget usage, matched_section semantics, as_of and superseded_risk, off_topic detection, and top_k clamping behavior. It explains exactly how returned fields should and should not be interpreted. No contradiction with annotations exists.

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 long and dense, and each section adds operational context that prevents a user from drawing false legal conclusions. It is front-loaded with purpose and sibling differentiation, though the date-stamped warnings and multiple caveats make it heavier than a minimal-purpose description. Overall the length is justified, but it is not maximally concise.

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?

With no output schema, the description must explain return semantics itself, and it does: it covers hit-level fields, query expansion behavior, as_of and vintage semantics, superseded_risk, off_topic handling, and parameter coercion. Given the tool’s complexity, an agent has what it needs to invoke it correctly and interpret results safely.

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%, so the description carries the full burden for the parameter semantics. It provides a query example and precisely documents top_k defaults, allowed range, clamping rules, and the top_k_applied response disclosure. This greatly exceeds the bare schema and fully compensates for the missing schema descriptions.

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?

The description opens with a specific verb and resource: it is a public-contract corpus search across laws, contract rules, detailed standards, and practical guides. It explicitly differentiates from search_law, and names concrete use cases like '낙찰하한율·적격심사 배점·실무 절차', so an agent can recognize when this tool is the right one.

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?

The description gives clear when-to-use and when-not-to-use guidance: use this for questions outside statutory text, and route tax-law questions to search_law or get_law_article instead. It also warns against treating zero hits as evidence of absence in tax law and instructs when to escalate to report_issue, making the boundary between siblings explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.