Skip to main content
Glama

contract-compass

by app.sallim

예규·세부기준 통합 검색

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.9/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld/idempotent annotations: it discloses that results are raw source text with no AI generation, that the tax corpus is excluded, that matched_section refers to a specific paragraph while the body is the whole article, and that query_expanded indicates glossary-alias query expansion. No contradiction with annotations.

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 longer than average but front-loaded with the core function and usage, and the key tax-scope warning is bolded. It is dense and mostly earns its length, though the no-LLM point is made twice and the dated honesty notice adds minor redundancy.

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 read-only search tool with no output schema, this is complete: it defines scope, exclusions, output nature, special hit-field semantics, routing to sibling tools, and parameter behavior. An agent has everything needed to invoke it correctly and interpret the important result fields.

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 fully compensates: query is explained as a natural-language search term with a concrete Korean example, and top_k is defined as return count with default 6 and maximum 12, adding the max constraint absent from the 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?

States a specific verb and resource: integrated search over the public-contract corpus (법령+계약예규+조달청·행안부 세부기준+실무가이드). It explicitly distinguishes itself from sibling search_law, which is limited to statutory articles, so the agent can tell them apart immediately.

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?

Gives explicit when-to-use: questions about 낙찰하한율, 적격심사 배점, 실무 절차 outside statutory text. It also gives explicit when-not-to-use and alternatives: tax-law questions should go to search_law or get_law_article, and zero results must not be taken as evidence that a tax rule does not 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

Each tool has a distinct role: decision-rules, price adjustment, delay penalties, exemption guidance, statute retrieval, case retrieval, and three specialized search tools. search_law, search_references, and search_cases look similar at first glance, but their descriptions clearly separate statutory text, full reference corpus, and caselaw/interpretation. The main ambiguity is between search_law and search_references for mixed practical queries.

Naming Consistency4/5

Almost all tools follow a snake_case verb_noun pattern: check_price_adjustment, decide_contract_method, estimate_delay_penalty, get_law_article, search_references. delay_exemption_guide is the one name that leads with a noun rather than a verb, and get_law_article_asof adds an as-of suffix that is not mirrored elsewhere, but the overall style remains predictable.

Tool Count5/5

Eleven tools are well-scoped for a Korean public-contract advisory server: three rule calculators, one exemption guide, paired search/retrieval tools, an as-of law lookup, and a feedback/question-log tool. Each tool earns its place, and the count is neither bloated nor too thin.

Completeness4/5

The server covers the main contract lifecycle well: selecting contract method, price escalation, delay penalty calculation, and delay exemption guidance, backed by statutes, references, and caselaw retrieval. Some narrower lifecycle aspects such as termination, sanctions, or post-award administration are only reachable through general search rather than dedicated decision tools, which is a minor gap agents can work around.

Resources