Big Data Insights for Regional Inflow in Korea

report_issue

이용자가 이 서비스의 잘못된 값·설명·오류를 운영자에게 알린다. - 보내는 것은 이용자가 '알려 달라·제보하겠다·운영자에게 전해 달라'고 할 때만. 스스로 판단해서 보내지 말 것. - 다만 이용자가 이상하다고 말하거나 결과에 원자료 오류 가능성 주의가 있으면, 알릴 수 있다는 사실은 먼저 안내할 것. - message는 이용자가 말한 내용을 그대로(1,000자 이하). 이름·연락처·개인정보는 넣지 말 것(받지 않음). - region·period·tool에는 문제가 된 지역·기간·도구를 적으면 확인이 빨라진다. - 보낸 뒤에는 '받았다, 따로 답장은 없고 반영된 내용은 서비스에 바로 적용된다'고만 전할 것.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "message": "<message>"
    },
    "name": "report_issue"
  }
}

Input Schema

Name	Required	Default
`kind`	No	기타
`tool`	No
`period`	No
`region`	No
`message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 14, 2026

changedInput schema / properties / kind / enum

Previous value: -[
-  "값이 이상함",
-  "설명이 틀림",
-  "오류",
-  "제안",
-  "기타"
-]New value: +[
+  "값이 이상함",
+  "설명이 틀림",
+  "작동 오류",
+  "제안",
+  "기타"
+]

First observedNov 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses that personal data is not collected and must not be included, the 1,000-character limit, that the message must be verbatim from the user, that no reply will be sent, and that accepted content is applied to the service directly. These are exactly the side-effect and post-submission facts an agent needs before writing.

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?

Front-loaded purpose sentence followed by bullets that each carry a distinct, actionable rule (send condition, proactive notice, message constraints, metadata fields, post-send wording). Dense but no bullet is filler; only the post-send phrasing rule is slightly verbose.

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?

For a 5-parameter, no-annotation, no-output-schema mutation tool, the description covers send conditions, content constraints, privacy, and the outcome of submission. The remaining gap is the 'kind' parameter and any error/failure behavior, but overall an agent could invoke this correctly.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate: it explains message content and constraints, and states that region/period/tool should record the affected region, time range, and tool to speed verification. The 'kind' enum (five categories) is never mentioned in the description, leaving its selection logic to be inferred from the enum labels alone.

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 first line states a specific verb and resource ('notifies the operator of wrong values, descriptions, or errors in this service'), which is clearly distinct from every sibling tool (analysis, lookup, forecast). An agent can identify this as the feedback/escalation channel without opening the schema.

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?

Explicitly states when to send (only when the user asks to report/relay to the operator), an explicit prohibition (do not decide to send on your own), and a proactive but non-sending case (when the user says something looks odd, first inform them that reporting is possible). It also specifies what to tell the user after sending. This is a full when/when-not/alternative rule set.

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

All Big Data Insights for Regional Inflow in Korea tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?