get_mbti_horoscope'MBTI 운세', '오늘 내 MBTI 운세', 'ENFP 운세'처럼 MBTI 기반 오늘의 운세를 물을 때 사용합니다. 운세 내용은 포함하지 않고 제목·발행일·원문 링크만 반환하며, 운세 본문은 다른 기사와 동일하게 item.url 의 한국일보 원문에서만 확인할 수 있습니다. 기본은 오늘(한국 시간), date(YYYY-MM-DD)로 특정 날짜 지정 가능.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | 조회할 날짜(YYYY-MM-DD). 생략 시 오늘(한국 시간) 운세. |
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | 반환된 운세의 발행 일시. | |
| item | No | 운세 기사 카드(메타데이터·원문 링크만, 운세 내용 미포함). |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/destructive annotations, the description discloses the key behavioral constraint: the tool does NOT return the horoscope body, only the title, publish date, and original link, and the text lives solely at item.url on the 한국일보 site. That is the non-obvious fact an agent needs before calling; only pagination/result-count behavior is left unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the usage trigger, then the return-shape caveat, then the date parameter. No filler, though the return-shape sentence is somewhat verbose about where the body lives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description doesn't need to enumerate return fields, yet it usefully warns the body is absent — the biggest failure mode for this tool. The only missing piece is explicit routing versus the sibling horoscope tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already states YYYY-MM-DD plus the default of today (Korea time). The description repeats that same information in Korean without adding format edge cases or timezone subtleties, so it is baseline value only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource: it fetches the MBTI-based horoscope article (title, publish date, link) rather than the horoscope text. It clearly scopes the tool to MBTI horoscopes via example queries, but never names the sibling get_daily_horoscope, so the agent must infer how the two horoscope tools differ.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Concrete trigger phrases ('MBTI 운세', '오늘 내 MBTI 운세', 'ENFP 운세') make the intended invocation context unambiguous, and the default-to-today behavior is stated. It stops short of explicit exclusions, e.g. when to prefer get_daily_horoscope over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.