Skip to main content
Glama
inhoinno86-hub

kakao_mcp_checktime

by inhoinno86-hub
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

kakao_mcp_checktime

부동산 체크타임 MCP의 로컬 검증 및 MCP adapter 준비 repo다.

현재 상태는 Phase 2H PlayMCP Console Asset & Metadata Preparation 단계다. 실제 PlayMCP 등록, 실제 PlayMCP in KC 서버 생성, 실제 카카오 클라우드 배포, 심사 요청, 전체 공개 전환, Player 예선 최종 제출은 수행하지 않았다.

Phase 2D baseline 로컬 검증은 PASS 상태를 유지했고, PlayMCP in KC remote endpoint에서도 local 과 동일한 GET /mcp 정책이 확인됐다. 이번 Phase에서는 서버 정책을 바꾸지 않고 representative image, MCP identifier 후보, conversation examples, auth 권장안과 기존 registration field 문서를 함께 정리했다.

관련 문서:

프로젝트 목적

  • 부동산 계약 전후 체크리스트와 일정 후보를 MCP tool 형태로 노출

  • 민감정보 차단, disclaimer 강제, 금지 표현 self-check 유지

  • PlayMCP 임시 등록 전 MCP adapter / HTTP endpoint / smoke test / readiness 경로 준비

Related MCP server: Exarp

MCP 설명

집계약 체크타임은 주택 매매·전세·월세 계약을 준비하는 매수인과 임차인을 위한 MCP 서버다.

지원되는 거래 유형과 일정 입력을 바탕으로 계약 전 확인사항, 계약 후 일정 후보, 오늘 확인할 일, 전문가 재확인 포인트를 구조화된 tool로 제공한다. 날짜가 들어오면 단순 목록만 반환하지 않고 timeline_checklist 와 action_timeline 형태로 계약일·입주일·잔금일 기준의 due-date 감각이 보이도록 정리한다.

일부 준비서류 안내는 현재 지원되는 거래 유형·역할·단계 조합에서만 제한적으로 제공한다.

법률 판단, 세무 판단, 거래 안전성 판단, 중개, 계약서 작성, 계약서 원문 검토는 수행하지 않으며, 민감한 개인정보나 계약서 원문 없이 날짜와 거래 유형 중심으로 사용하도록 설계했다.

현재 구현 범위

  • 로컬 tool runner CLI

  • MCP JSON-RPC adapter

  • stdio transport server

  • HTTP POST /mcp 기반 Streamable HTTP 후보 endpoint

  • GET /mcp without Accept: text/event-stream 시 406

  • GET /mcp with Accept: text/event-stream 시 405

  • OPTIONS /mcp preflight 후보 처리

  • Origin allowlist 후보

  • Bearer auth 후보와 local auth off 모드

  • request timeout / payload size limit 후보

  • health/readiness check

  • fixture 테스트, adapter 테스트, HTTP smoke 테스트

구현 제외 범위

  • 실제 PlayMCP 등록

  • 실제 카카오 클라우드 배포

  • 심사 요청, 전체 공개 전환, Player 예선 최종 제출

  • Kakao Tools Widget 구현

  • 톡캘린더 직접 연동

  • 외부 부동산 API / 실시간 법령 API

  • 개인정보 저장, 상세주소 저장, 문서 업로드, 계약서 원문 분석

  • 법률/세무 판단, 거래 안전성 판단, 매물 추천, 중개/매칭

  • generate_contract_day_checklist

설치

python3 -m venv .venv
source .venv/bin/activate
pip install -e .

설치 없이 바로 실행하려면 PYTHONPATH=src 를 붙인다.

로컬 Tool 실행 방법

printf '%s\n' '{"transaction_type":"lease_jeonse","user_role":"tenant","contract_date":"2026-07-12","move_in_date":"2026-08-10"}' \
  | PYTHONPATH=src python3 -m checktime_mcp.server generate_pre_contract_checklist
PYTHONPATH=src python3 -m checktime_mcp.server generate_required_documents --input tests/fixtures/scenario_monthly_documents.json

주의:

  • generate_required_documents 의 현재 정상 응답 범위:

    • home_purchase + buyer -> contract_day, after_contract

    • lease_jeonse + tenant -> before_move_in

    • lease_monthly + tenant -> before_move_in

  • 그 외 단계 조합은 성공 빈 배열 대신 documents_not_ready 오류를 반환한다.

MCP adapter / HTTP server 실행 방법

stdio:

PYTHONPATH=src python3 -m checktime_mcp.mcp_server --transport stdio

local HTTP:

PYTHONPATH=src python3 -m checktime_mcp.mcp_server --transport http --host 127.0.0.1 --port 8000

remote candidate HTTP:

CHECKTIME_AUTH_MODE=bearer \
CHECKTIME_BEARER_TOKEN=<set-at-runtime> \
CHECKTIME_ALLOWED_ORIGINS=<confirm-origin-before-use> \
CHECKTIME_REQUEST_TIMEOUT_SECONDS=10 \
CHECKTIME_MAX_BODY_BYTES=1048576 \
PORT=8080 \
PYTHONPATH=src python3 -m checktime_mcp.mcp_server --transport http --host 0.0.0.0

health/readiness:

PYTHONPATH=src python3 -m checktime_mcp.mcp_server --health

HTTP endpoint 정책

기본 endpoint:

  • MCP path: /mcp

  • health path: /health

  • 기본 응답 transport: application/json

POST /mcp

  • Content-Type: application/json 필요

  • Accept: application/json, text/event-stream 포함 필요

  • MCP-Protocol-Version 지원값:

    • 2025-06-18

    • legacy fallback policy: header 미지정 시 2025-03-26 으로 간주

  • JSON-RPC 2.0 initialize, ping, tools/list, tools/call 처리

  • 잘못된 JSON은 parse error 반환

  • 미지원 method 는 method not found 반환

  • id 없는 요청은 notification policy로 202 Accepted

GET /mcp

  • SSE 후보 경로다.

  • Accept: text/event-stream 이 없으면 406 unsupported_accept_header

  • Accept: text/event-stream 이 있으면 현재는 405 sse_not_implemented

  • body exact match 대신 ok: false, error.code, error.message 중심으로 검증한다.

  • 현재 sse_get_stream: not_implemented

OPTIONS /mcp

  • 204 No Content

  • Access-Control-Allow-Methods: POST, GET, OPTIONS

  • Access-Control-Allow-Headers: Content-Type, Accept, Authorization, MCP-Protocol-Version

Header / auth / origin 설정

환경변수:

  • CHECKTIME_AUTH_MODE

    • off: local only

    • bearer: remote candidate

  • CHECKTIME_BEARER_TOKEN

  • CHECKTIME_ALLOWED_ORIGINS

    • 예시: https://playmcp.kakao.com,https://*.kakao.com

    • 예시는 예시일 뿐이며 실제 허용 Origin 값은 확인 필요

  • CHECKTIME_REQUEST_TIMEOUT_SECONDS

    • 기본값 10

  • CHECKTIME_MAX_BODY_BYTES

    • 기본값 1048576

  • PORT

    • remote candidate 기본 예시 8080

  • CHECKTIME_MCP_DATA_DIR

    • 선택 사항

local mode 예시:

CHECKTIME_AUTH_MODE=off \
PYTHONPATH=src python3 -m checktime_mcp.mcp_server --transport http --host 127.0.0.1 --port 8000

remote candidate mode 예시:

CHECKTIME_AUTH_MODE=bearer \
CHECKTIME_BEARER_TOKEN=<set-at-runtime> \
CHECKTIME_ALLOWED_ORIGINS=<confirm-origin-before-use> \
CHECKTIME_REQUEST_TIMEOUT_SECONDS=10 \
CHECKTIME_MAX_BODY_BYTES=1048576 \
PORT=8080 \
PYTHONPATH=src python3 -m checktime_mcp.mcp_server --transport http --host 0.0.0.0

주의:

  • token 값을 README, git, Docker image 에 직접 기록하지 않는다.

  • config/deployment.env.example 는 예시 템플릿일 뿐이며 secret 값은 넣지 않는다.

  • Origin header 가 없으면 현재는 server-to-server candidate 로 허용한다.

  • 실제 PlayMCP 인증 방식, bearer token 지원 여부, 필수 Origin 값, 필수 header 규칙은 수동 확인이 필요하다.

HTTP 호출 예시

curl -i http://127.0.0.1:8000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2025-06-18' \
  --data '{"jsonrpc":"2.0","id":1,"method":"ping","params":{}}'

Tool 목록

  • generate_pre_contract_checklist

  • generate_post_contract_timeline

  • generate_required_documents

  • generate_calendar_items

  • flag_expert_review_points

  • get_today_tasks

주요 응답 구조

  • generate_pre_contract_checklist

    • items: 계약 전 확인 항목 원본 목록

    • timeline_checklist: 계약일 7일 전, 계약일 3일 전, 계약일 1일 전 같은 due-date 버킷

  • generate_post_contract_timeline

    • timeline_items: 계약 후 기준 일정 이벤트

    • action_timeline: 일정 이벤트 + 체크리스트 + 준비서류를 날짜 순으로 합친 통합 액션 타임라인

  • generate_required_documents

    • documents: 단계별 준비서류 원본 목록

    • timeline_checklist: 입주일 7일 전, 입주일 3일 전, 입주일 1일 전 또는 계약일 당일 같은 준비 시점 버킷

테스트 실행 방법

fixture runner:

python3 scripts/run_fixtures.py

pytest:

pytest

adapter smoke:

python3 scripts/smoke_mcp_adapter.py

HTTP smoke:

python3 scripts/smoke_http_server.py

auth smoke:

CHECKTIME_AUTH_MODE=bearer \
CHECKTIME_BEARER_TOKEN=local-test-token \
python3 scripts/smoke_http_server.py

origin smoke:

CHECKTIME_ALLOWED_ORIGINS=http://localhost:3000 \
python3 scripts/smoke_http_server.py

remote HTTPS smoke:

python3 scripts/smoke_http_server.py --base-url https://<DEPLOYED_HOST>/mcp --strict

remote HTTPS bearer smoke:

python3 scripts/smoke_http_server.py \
  --base-url https://<DEPLOYED_HOST>/mcp \
  --bearer-token <RUNTIME_OR_TEST_TOKEN> \
  --origin <CONFIRMED_ORIGIN_IF_NEEDED> \
  --strict

주의:

  • --bearer-token 을 주면 local CHECKTIME_AUTH_MODE 값과 무관하게 Authorization: Bearer <token> 헤더를 보낸다.

  • 설치형 runtime 과 Docker runtime 에서는 CHECKTIME_MCP_DATA_DIR 또는 working directory 기준 data/ 가 유효해야 한다.

health/readiness:

PYTHONPATH=src python3 -m checktime_mcp.mcp_server --health

금지 표현 / 민감정보 유도 grep:

bash scripts/grep_risk_terms.sh

Docker 실행 후보

build:

docker build -t checktime-mcp:local .

run:

docker run --rm -p 8080:8080 \
  -e CHECKTIME_AUTH_MODE=off \
  checktime-mcp:local

외부 terminal 에서 smoke:

python3 scripts/smoke_http_server.py --base-url http://127.0.0.1:8080/mcp

strict smoke:

python3 scripts/smoke_http_server.py --base-url http://127.0.0.1:8080/mcp --strict

bearer smoke:

python3 scripts/smoke_http_server.py \
  --base-url http://127.0.0.1:8080/mcp \
  --bearer-token <RUNTIME_OR_TEST_TOKEN> \
  --strict

Phase 2D 메모:

  • Docker tools/call 실패 원인은 installed package runtime 에서 기본 data 경로가 site-packages 상위 .../lib/pythonX.Y/data 로 계산되던 점이다.

  • Docker image 는 CHECKTIME_MCP_DATA_DIR=/app/data 를 기본 주입하고, app 은 working directory 기준 data/ fallback 도 사용한다.

  • remote HTTPS 배포 전에 위 Docker smoke를 먼저 통과시켜야 한다.

PlayMCP in KC Git Source Deployment Readiness

이번 Phase는 PlayMCP 최종 등록이나 심사 요청이 아니라, https://playmcp.kakaocloud.io 의 Git 소스 빌드 방식으로 배포할 준비 상태를 점검하고 수동 등록 절차를 문서화하는 작업이다.

현재 확인된 적합성:

  • 저장소 루트에 Dockerfile 이 있다.

  • Dockerfile 은 pyproject.toml, README.md, src/, data/ 를 이미지에 포함한다.

  • 컨테이너 기본 환경변수로 PORT=8080, CHECKTIME_MCP_DATA_DIR=/app/data 를 주입한다.

  • HTTP 서버는 PORT 환경변수를 읽고 기본 endpoint 를 /mcp 로 노출한다.

  • PYTHONPATH=src python3 -m checktime_mcp.mcp_server --health 결과에서 playmcp_registration_status: manual_step_required 와 ok: true 를 확인했다.

  • .dockerignore 는 tests, docs, scripts 를 제외한다. 운영 runtime 에 필요한 src/ 와 data/ 는 제외하지 않는다.

실행 한계:

  • 현재 Codex 세션은 docker.sock 권한이 없어 Docker build/run 을 재실행하지 못했다.

  • 따라서 Phase 2D의 Docker PASS 이력은 유지 문맥으로 취급하고, 이번 Phase에서는 Dockerfile/런타임 구조와 로컬 baseline PASS를 다시 확인했다.

PlayMCP in KC 등록 입력값 템플릿

실제 등록은 사용자가 수동으로 수행한다. PAT, token, secret, 실제 endpoint URL 은 문서나 로그에 기록하지 않는다.

MCP 서버 이름:
  checktime-mcp

설명:
  부동산 직거래 당사자를 위한 계약 전/후 체크리스트, 준비서류, 일정, 전문가 검토 포인트 안내용 MCP 서버입니다. 법률 판단, 계약서 작성, 거래 안전성 판단은 수행하지 않습니다.

Git URL:
  <user-confirmed-git-url>
  current remote candidate: https://github.com/inhoinno86-hub/kakao_mcp_checktime.git

브랜치 / ref:
  <user-confirmed-branch-or-main>
  current local branch: main

Dockerfile 경로:
  Dockerfile

PAT:
  public repository라면 비워둠
  private repository라면 사용자가 직접 입력
  문서/로그/보고서에는 절대 기록하지 않음

확인 필요:

  • 현재 origin remote 는 잡혀 있지만, 실제 PlayMCP in KC 에서 사용할 Git URL 과 public/private 상태는 사용자가 최종 확인해야 한다.

  • repository 가 private 이면 PAT 가 필요하다.

  • repository 가 public 이면 PAT 는 비워둘 수 있다.

PlayMCP in KC 수동 등록 절차

  1. 브라우저에서 https://playmcp.kakaocloud.io 접속

  2. PlayMCP 에 가입된 카카오 계정으로 로그인

  3. + 새 MCP 서버 등록 클릭

  4. Git 소스 빌드 선택

  5. MCP 서버 이름 입력

  6. 설명 입력

  7. Git URL 입력

  8. 브랜치/ref 입력

  9. Dockerfile 경로 입력

  10. private repo 라면 PAT 를 사용자가 직접 입력

  11. public repo 라면 PAT 는 비움

  12. 등록하기 클릭

  13. Status 가 Starting 에서 Active 로 바뀔 때까지 대기

  14. 상세 정보에서 Endpoint URL 복사

  15. Endpoint URL 기준으로 remote smoke 수행

주의:

  • MCP 서버는 최대 2개까지 등록 가능하므로 중복 생성에 주의한다.

  • 삭제 후 복구 불가다.

  • PAT, token, secret 은 문서와 로그에 남기지 않는다.

  • Endpoint URL 은 공개 가능 여부를 판단한 뒤에만 공유한다.

  • Endpoint URL 획득 후 PlayMCP 최종 등록 전에 smoke test 를 먼저 수행한다.

Endpoint URL 획득 후 remote smoke

auth off candidate:

python3 scripts/smoke_http_server.py \
  --base-url '<endpoint-url>/mcp' \
  --strict

Endpoint URL 이 이미 /mcp 를 포함하는 경우:

  • https://example.playmcp... 이면 base-url 은 https://example.playmcp.../mcp

  • https://example.playmcp.../mcp 이면 base-url 은 그대로 사용

bearer candidate:

python3 scripts/smoke_http_server.py \
  --base-url '<endpoint-url-or-endpoint-url-with-mcp>' \
  --bearer-token '<deployment-token>' \
  --strict

명령 히스토리 노출을 줄이려면 env 사용:

export CHECKTIME_REMOTE_BASE_URL='<endpoint-url-or-endpoint-url-with-mcp>'
export CHECKTIME_REMOTE_BEARER_TOKEN='<deployment-token>'

python3 scripts/smoke_http_server.py \
  --base-url "$CHECKTIME_REMOTE_BASE_URL" \
  --bearer-token "$CHECKTIME_REMOTE_BEARER_TOKEN" \
  --strict

negative smoke 는 bearer mode endpoint 에서만 수행:

python3 scripts/smoke_http_server.py \
  --base-url "$CHECKTIME_REMOTE_BASE_URL" \
  --strict
python3 - <<'PY'
import json
import os
import urllib.request
import urllib.error

url = os.environ["CHECKTIME_REMOTE_BASE_URL"]

payload = json.dumps({
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {}
}).encode("utf-8")

req = urllib.request.Request(
    url,
    data=payload,
    method="POST",
    headers={
        "Content-Type": "application/json",
        "Accept": "application/json",
        "MCP-Protocol-Version": "2025-06-18",
        "Authorization": "Bearer invalid-token"
    },
)

try:
    with urllib.request.urlopen(req, timeout=10) as resp:
        print("status", resp.status)
        print(resp.read().decode("utf-8", errors="replace"))
except urllib.error.HTTPError as exc:
    print("HTTPError", exc.code)
    print(exc.read().decode("utf-8", errors="replace"))
except Exception as exc:
    print(type(exc).__name__, exc)
PY

기대 결과:

  • connection reset 이 아니라 401 또는 안전한 HTTP error

  • response 에 token 원문 노출 없음

  • log 에 token 원문 노출 없음

  • stack trace 노출 없음

PlayMCP 등록 전 남은 수동 단계

  • 카카오 클라우드 MCP 서버 생성

  • HTTPS endpoint 생성

  • PlayMCP 개발자 콘솔 접근

  • 등록 URL 형식 확인

  • 최신 필수 필드 확인

  • 인증 방식 확인

  • bearer token 지원 여부 확인

  • Origin / header / timeout 규칙 확인

  • 임시 등록 테스트

  • 최종 제출용 서버 심사 요청

  • 심사 통과 후 전체 공개 전환

  • Player 예선 최종 제출

안전 / 리스크 정책 요약

  • 상세주소, 주민등록번호, 계좌번호, 신분증 이미지, 계약서 원문 입력 차단

  • 모든 응답에 disclaimer 포함

  • 금지 표현 출력 self-check 적용

  • 공식 재검증이 끝나지 않은 일정/제도 항목은 official_check_needed 또는 confirmation_required 유지

  • HTTP error response 에도 stack trace 와 민감정보 재노출 금지

known limitations

  • 현재 서버는 PlayMCP 임시 등록 전 로컬/HTTP preflight 후보 상태다.

  • 실제 PlayMCP 등록, 실제 PlayMCP in KC 서버 생성, 실제 카카오 클라우드 배포, 심사 요청은 수행하지 않았다.

  • GET 기반 SSE stream은 구현하지 않았다.

  • PlayMCP 개발자 콘솔의 최신 필수 필드, transport 선택값, 인증 방식, timeout/header 규칙, 실제 Origin 값은 수동 확인이 필요하다.

  • Endpoint URL 획득 전에는 remote smoke 를 수행할 수 없다.

  • Authorization, MCP-Protocol-Version, Content-Type, Accept, timeout, payload size, /mcp path 처리 방식은 PlayMCP in KC 에서 official_check_needed 상태다.

  • generate_contract_day_checklist 는 이번 Phase에서 구현하지 않았다.

관련 문서:

Available Tools

6 tools
flag_expert_review_points전문가 검토 포인트 추출B
Read-onlyIdempotent

context 태그를 기준으로 전문가 재확인 포인트를 반환합니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
stageNo문서 또는 단계 구분.
regionNo시/군/구 수준까지만 허용. 상세주소 금지.
contextYes전문가 검토 트리거용 문맥 태그.
user_roleYes사용자 역할. buyer 또는 tenant.
closing_dateNoYYYY-MM-DD 형식의 잔금일.
current_dateNoYYYY-MM-DD 형식의 기준일.
move_in_dateNoYYYY-MM-DD 형식의 입주일.
contract_dateNoYYYY-MM-DD 형식의 계약일.
calendar_styleNo캘린더 출력 스타일.
lease_end_dateNoYYYY-MM-DD 형식의 임대차 종료일.
transaction_typeYes거래 유형. home_purchase, lease_jeonse, lease_monthly 중 하나.
deposit_amount_rangeNo정확한 액수 대신 범위 문자열.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
dataNo
errorNo
unknownsYes
disclaimerYes
expert_review_pointsYes
source_status_summaryYes

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that it returns points based on context tags, which is some additional behavioral context but does not disclose any side effects or other traits.

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 a single, clear sentence with no unnecessary words. Every part contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 12 parameters (3 required) and the existence of an output schema, the description is too minimal. It does not explain how other parameters like stage, region, or dates affect the output, leaving significant gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so each parameter is already documented. The tool description adds no extra meaning beyond what the schema provides, meeting the baseline expectation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns expert review points based on context tags. It distinguishes itself from sibling tools like calendar items or checklists, but the term 'expert review points' is not further elaborated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or how it fits into a workflow.

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

generate_calendar_items캘린더 항목 생성B
Read-onlyIdempotent

타임라인을 캘린더 입력용 항목으로 변환합니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
stageNo문서 또는 단계 구분.
regionNo시/군/구 수준까지만 허용. 상세주소 금지.
contextNo전문가 검토 트리거용 문맥 태그.
user_roleYes사용자 역할. buyer 또는 tenant.
closing_dateNoYYYY-MM-DD 형식의 잔금일.
current_dateNoYYYY-MM-DD 형식의 기준일.
move_in_dateNoYYYY-MM-DD 형식의 입주일.
contract_dateNoYYYY-MM-DD 형식의 계약일.
calendar_styleNo캘린더 출력 스타일.
lease_end_dateNoYYYY-MM-DD 형식의 임대차 종료일.
transaction_typeYes거래 유형. home_purchase, lease_jeonse, lease_monthly 중 하나.
deposit_amount_rangeNo정확한 액수 대신 범위 문자열.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
dataNo
errorNo
unknownsYes
disclaimerYes
expert_review_pointsYes
source_status_summaryYes

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating no side effects. The description 'converts' aligns with a transformation operation but adds no extra behavioral context. No contradictions found.

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 a single sentence with no wasted words. However, it is very brief and could benefit from more detail without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having 12 parameters and an output schema, the description is minimal. It does not explain what constitutes a timeline or how the conversion works. The context of calendar items and the input format is insufficient for confident usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 12 parameters are described in the schema (100% coverage). The description adds no additional parameter-level meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool converts a timeline into calendar items, providing a clear verb and resource. However, it does not differentiate from siblings like generate_post_contract_timeline or generate_required_documents, which have distinct purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives, nor are there any prerequisites or exclusions. The description only states what it does, not the context of use.

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

generate_post_contract_timeline계약 후 일정 후보 생성B
Read-onlyIdempotent

기준 날짜를 바탕으로 계약 후 일정 후보를 계산합니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
stageNo문서 또는 단계 구분.
regionNo시/군/구 수준까지만 허용. 상세주소 금지.
contextNo전문가 검토 트리거용 문맥 태그.
user_roleYes사용자 역할. buyer 또는 tenant.
closing_dateNoYYYY-MM-DD 형식의 잔금일.
current_dateNoYYYY-MM-DD 형식의 기준일.
move_in_dateNoYYYY-MM-DD 형식의 입주일.
contract_dateNoYYYY-MM-DD 형식의 계약일.
calendar_styleNo캘린더 출력 스타일.
lease_end_dateNoYYYY-MM-DD 형식의 임대차 종료일.
transaction_typeYes거래 유형. home_purchase, lease_jeonse, lease_monthly 중 하나.
deposit_amount_rangeNo정확한 액수 대신 범위 문자열.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
dataNo
errorNo
unknownsYes
disclaimerYes
expert_review_pointsYes
source_status_summaryYes

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety traits. It adds the context of 'based on reference dates', which is mildly informative but not deeply behavioral.

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 a single, concise sentence that conveys the core purpose with no unnecessary words. It is effectively front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (12 parameters, 2 required, enums, output schema), the description is too sparse. It does not explain the output structure, usage scenarios, or how parameters interact, relying heavily on the schema and output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 12 parameters have descriptions in the schema (100% coverage), so the description adds no additional semantic context for parameters. The description merely mentions 'reference dates' in a general sense.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it calculates post-contract schedule candidates based on reference dates, which clearly identifies the tool's purpose. However, it does not explicitly differentiate from siblings like generate_calendar_items, leaving some ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor any context on prerequisites or when not to use it.

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

generate_pre_contract_checklist계약 전 체크리스트 생성B
Read-onlyIdempotent

거래 유형과 역할 기준으로 계약 전 확인 항목 후보를 반환합니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
stageNo문서 또는 단계 구분.
regionNo시/군/구 수준까지만 허용. 상세주소 금지.
contextNo전문가 검토 트리거용 문맥 태그.
user_roleYes사용자 역할. buyer 또는 tenant.
closing_dateNoYYYY-MM-DD 형식의 잔금일.
current_dateNoYYYY-MM-DD 형식의 기준일.
move_in_dateNoYYYY-MM-DD 형식의 입주일.
contract_dateNoYYYY-MM-DD 형식의 계약일.
calendar_styleNo캘린더 출력 스타일.
lease_end_dateNoYYYY-MM-DD 형식의 임대차 종료일.
transaction_typeYes거래 유형. home_purchase, lease_jeonse, lease_monthly 중 하나.
deposit_amount_rangeNo정확한 액수 대신 범위 문자열.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
dataNo
errorNo
unknownsYes
disclaimerYes
expert_review_pointsYes
source_status_summaryYes

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool's safety profile is clear. The description adds no additional behavioral context, but does not contradict 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 a single concise sentence that is front-loaded with the key purpose. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (12 parameters, many date fields, enums), the description is too minimal. It does not explain how parameters like dates or stage affect the checklist, nor what the output contains. Output schema exists but still, the description lacks sufficient context for proper use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description mentions transaction_type and user_role as bases but adds no further meaning beyond what the schema provides.

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 clearly states the tool returns pre-contract check item candidates based on transaction type and role. The verb '반환합니다' (returns) and resource '계약 전 확인 항목 후보' are specific, and it distinguishes from siblings like 'flag_expert_review_points' and 'generate_calendar_items'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives. It only states the basic functionality, missing explicit context for when it is appropriate or not.

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

generate_required_documents단계별 준비서류 생성A
Read-onlyIdempotent

거래 유형, 역할, 단계 기준으로 준비서류 후보를 반환합니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
stageYes문서 또는 단계 구분.
regionNo시/군/구 수준까지만 허용. 상세주소 금지.
contextNo전문가 검토 트리거용 문맥 태그.
user_roleYes사용자 역할. buyer 또는 tenant.
closing_dateNoYYYY-MM-DD 형식의 잔금일.
current_dateNoYYYY-MM-DD 형식의 기준일.
move_in_dateNoYYYY-MM-DD 형식의 입주일.
contract_dateNoYYYY-MM-DD 형식의 계약일.
calendar_styleNo캘린더 출력 스타일.
lease_end_dateNoYYYY-MM-DD 형식의 임대차 종료일.
transaction_typeYes거래 유형. home_purchase, lease_jeonse, lease_monthly 중 하나.
deposit_amount_rangeNo정확한 액수 대신 범위 문자열.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
dataNo
errorNo
unknownsYes
disclaimerYes
expert_review_pointsYes
source_status_summaryYes

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns 'candidates' (implying a selection, not a definitive list), which provides marginal behavioral context beyond the annotations. No contradictions.

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 a single sentence (11 words) that front-loads the core function with zero wasted words. Every element serves to clarify the tool's purpose.

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 the complexity (12 parameters, 3 required, output schema exists), the description is succinct but covers the essential inputs and output. The presence of an output schema reduces the need to describe return values. It adequately positions the tool among siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with detailed parameter descriptions. The tool description only mentions three key parameters (transaction_type, user_role, stage) without adding any additional meaning to the 12 parameters. Baseline 3 is appropriate.

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 clearly states the verb 'returns', the resource 'document candidates', and the criteria (transaction type, role, stage). It distinguishes itself from sibling tools like 'generate_pre_contract_checklist' and 'flag_expert_review_points' by focusing on document generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies its usage is for generating document candidates based on stage, role, and transaction type, but does not explicitly state when to use it versus alternatives like 'get_today_tasks' or 'generate_calendar_items'. No exclusions or context for when not to use it are provided.

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

get_today_tasks오늘 해야 할 일 후보 생성A
Read-onlyIdempotent

기준일과 일정 후보를 조합해 오늘 해야 할 일과 임박 일정 후보를 반환합니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
stageNo문서 또는 단계 구분.
regionNo시/군/구 수준까지만 허용. 상세주소 금지.
contextNo전문가 검토 트리거용 문맥 태그.
user_roleYes사용자 역할. buyer 또는 tenant.
closing_dateNoYYYY-MM-DD 형식의 잔금일.
current_dateNoYYYY-MM-DD 형식의 기준일.
move_in_dateNoYYYY-MM-DD 형식의 입주일.
contract_dateNoYYYY-MM-DD 형식의 계약일.
calendar_styleNo캘린더 출력 스타일.
lease_end_dateNoYYYY-MM-DD 형식의 임대차 종료일.
transaction_typeYes거래 유형. home_purchase, lease_jeonse, lease_monthly 중 하나.
deposit_amount_rangeNo정확한 액수 대신 범위 문자열.

Output Schema

ParametersJSON Schema
NameRequiredDescription
okYes
dataNo
errorNo
unknownsYes
disclaimerYes
expert_review_pointsYes
source_status_summaryYes

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by explaining the combination logic (reference date + schedule candidates) and specifying outputs (today's tasks and imminent schedule candidates). No contradictions 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured Korean sentence that front-loads the core function. No redundant or unnecessary words. Achieves clarity in minimal space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the tool's complexity (12 parameters, many date fields), the description only provides a high-level overview. It omits details like how 'schedule candidates' are determined or the role of the stage parameter. The existence of an output schema partially compensates, but behavioral completeness is lacking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already documents all parameters. The description adds no parameter-specific details or interaction guidance. It does not explain how parameters like stage or region affect the output.

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?

Description uses specific verbs ('combines', 'returns') and clearly identifies the resource ('today's tasks and imminent schedule candidates'). Distinguishes from siblings like 'generate_calendar_items' and 'generate_pre_contract_checklist' by focusing on daily tasks based on combined dates and transaction types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for generating a task list for today based on input dates and transaction type. However, it provides no explicit guidance on when to use it versus alternatives (e.g., generate_calendar_items for calendar output). No exclusions or prerequisites are stated.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation5/5

Each tool targets a distinct aspect of contract timeline management: pre-contract checklist, required documents, post-contract timeline, calendar conversion, expert review points, and daily tasks. No two tools serve the same purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (flag_expert_review_points, generate_calendar_items, etc.) with clear verbs and plural nouns.

Tool Count5/5

6 tools provide a focused set for contract timeline assistance without unnecessary extras or missing core functionality.

Completeness5/5

The tools cover the full workflow from pre-contract preparation through post-contract scheduling to daily task tracking, with no obvious gaps.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Real Estate MCP Server

    agentic-ops
    A
    license
    Not graded
    quality
    A
    maintenance
    A comprehensive Model Context Protocol server for real estate data management that provides tools and resources for property listings, agent management, market analysis, client relationships, and area intelligence.
    53
    AGPL 3.0

  • pdf-mcp

    talipovvs
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server for generating PDF reports on real estate properties. Supports location analysis, market reports, and project summaries.
    Mozilla Public 2.0

  • MCP Vista CRM Loft

    fabiohsan-dev
    A
    license
    C
    quality
    D
    maintenance
    Enterprise-level MCP server integrating with Vista CRM (Loft Edition) for real estate operations, offering 40+ tools for property search, pipeline management, lead capture, and agenda control.
    42
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/inhoinno86-hub/kakao_mcp_checktime'

If you have feedback or need assistance with the MCP directory API, please join our Discord server