Skip to main content
Glama

contract-compass

by build.naru

예규·세부기준 통합 검색

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`가 있으면
사용자가 타이핑한 말에 용어집 별칭을 덧붙인 질의로 검색·재정렬한 것이다(실무 어휘를
법령 어휘로 잇는 다리 — 원문은 보존).

Args:
    query: 자연어 검색어 (예: "적격심사 낙찰하한율 50억 미만")
    top_k: 반환 건수 (기본 6, 최대 12)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
top_kNo

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses that no LLM is used, only original source text is returned, backend LLM budget is not consumed, tax corpus is out of scope, and how matched_section/query_expanded affect result interpretation. This is high-value behavioral context with no contradiction.

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 but well-organized into scope, usage, exclusions, and result semantics. It earns most of its length; minor redundancy exists in stating 'LLM 미사용' early and then repeating 'AI 생성 없이' and 'LLM 예산 미차감' later.

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 output schema, the description goes far by explaining result semantics: matched_section points to the responsible paragraph while the returned body is the whole article, and query_expanded adds glossary aliases. It still omits a full picture of the return shape, but an agent has enough to call and interpret results correctly.

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%, but the description carries full weight: query is defined as a natural-language search term with a concrete example, and top_k is defined as result count with default 6 and maximum 12. This far exceeds the bare schema.

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 scope ('공공계약 코퍼스 통합 검색') and enumerates the covered corpora: 법령, 계약예규, 조달청·행안부 세부기준, 실무가이드. It explicitly contrasts itself with search_law ('법령 조문 전용'), so an agent can clearly distinguish sibling tools.

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?

It gives a clear use case: questions outside the statute text such as 낙찰하한율, 적격심사 배점, and 실무 절차. It also names exclusions and routes tax-law questions to search_law or get_law_article, warning against treating 0 results as evidence that a tax provision doesn't exist.

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

All contract-compass toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation4/5

Most tools have clearly distinct purposes: calculation tools (check_price_adjustment, estimate_delay_penalty, decide_contract_method), reference tools (get_law_article, get_case), and search tools. The only potential confusion is between search_law and search_references since both cover statutes, but their descriptions explicitly delineate scope (statutes-only vs. statutes+guidelines+rulings).

Naming Consistency4/5

Tool names overwhelmingly follow a snake_case verb_noun pattern (check_price_adjustment, estimate_delay_penalty, get_law_article, search_cases). One outlier is delay_exemption_guide, which uses a noun-led pattern rather than a verb-led one, but it is still readable and consistent in style.

Tool Count5/5

Eleven tools is well within the ideal range for a specialized legal advisory server. Each tool covers a distinct function: rule-based determinations, calculations, legal research, historical lookup, case retrieval, and issue reporting. No tool feels redundant or superfluous.

Completeness4/5

The toolset covers the core advisory workflow well: searching statutes, guidelines, and cases; retrieving full texts and historical versions; and performing key calculations for price adjustments and delay penalties. Minor gaps exist such as calculators for other contract lifecycle adjustments, but those are reasonably addressable through the search and reference tools.

Resources