Skip to main content
Glama

九玄宫奇门遁甲排盘

奇门排盘(免费、确定性)

cast_qimen
Read-onlyIdempotent

排一张时家奇门转盘拆补盘,并给出年命(可选)。计算是确定性的:同一输入得到同一盘。 调用前先补齐缺失信息,不要猜测:

  1. civilTime:北京时间 UTC+8 的钟面,例如 2026-11-13T18:54:00。用户若在别的时区,先换成北京时间再传入。拒绝带 Z 或 +08:00 的字符串。

  2. longitude:起局地东经。范围 73–135.5。用户没说就问。120 不是默认值。中国以外的经度不要调用本工具。

  3. 若用户要看年命:role 用 q 求测人、d 当事人、o 对方、t 第三方,不要要真实姓名。date 为 YYYY-MM-DD(1900–2050)。每个身份都要问清 trueSolarTime:true 才按出生地经度换真太阳时后比立春,false 按北京时间比立春。出生日跨立春就必须有 time。 成功时 text 与 structuredContent 都有。text 含九玄宫官网和两条原盘链接。structuredContent.chart 是与 pp 导出同一套的确定性 JSON(含九宫、派生、格局名)。格局名不是 AI 解盘。 pp 链接不能还原 births。本服务链接的 # 片段可以还原已提交的出生日期;默认不含备注。 示例:{"civilTime":"2026-11-13T18:54:00","longitude":120} 示例:{"civilTime":"2026-10-17T14:30:00","longitude":120,"births":[{"role":"q","date":"1989-07-01","trueSolarTime":false},{"role":"o","date":"1992-07-01","trueSolarTime":false,"note":"合伙人"}]} Cast one Qimen chart (rotating plate, chai-bu) with optional year-ming. Same input, same chart. Ask for missing Beijing civil time and a China longitude before calling. Do not invent 120. This is not an interpretation and not a global calculator.

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": {
      "civilTime": "<civilTime>",
      "longitude": "<longitude>"
    },
    "name": "cast_qimen"
  }
}

Input Schema

NameRequiredDescriptionDefault
birthsNo可选,最多四个身份。不需要年命就省略。同一 role 不能重复。Optional, at most four roles.
civilTimeYes起局北京时间(Asia/Shanghai,UTC+8)墙钟,YYYY-MM-DDTHH:MM:SS 或 YYYY-MM-DD HH:MM。不要带 Z 或 +08:00。不要传 UTC,不要传用户当地时间,不要预先换成真太阳时。年份 1900–2100。Beijing civil clock. No offset suffix. Years 1900–2100.
longitudeYes起局东经,必须由用户给出,范围 73–135.5(中国)。缺了就问,不要默认 120。120 只是示例。不是全球经度。Required east longitude inside China, 73–135.5. Do not default to 120.
includeNotesInChartLinkNo默认 false。true 时备注会进入本服务原盘链接的 URL 片段。备注可能含个人信息。Defaults to false so notes stay out of the fragment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/destructive/openWorld, and the description adds genuinely new behavior: determinism ('same input, same chart'), dual output (text plus structuredContent.chart), that text contains external 九玄宫 links, that the service's # fragment can reconstruct submitted birth dates, that notes are excluded by default for privacy, and that the API rejects certain inputs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The numbered checklist is well front-loaded, but the definition repeats itself: '120 不是默认值' and the China-only restriction appear in both the numbered list and the closing English paragraph, and the English block largely duplicates the Chinese. It is dense enough that useful rules compete with restatement.

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?

There is no output schema, yet the description explains the return shape (text with two source links, structuredContent.chart with nine palaces, derivatives, and pattern names) and warns that pattern names are not AI interpretation. Privacy behavior around notes and link fragments is also covered, leaving no significant gap for a 4-parameter tool.

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 coverage is 100%, so the baseline is 3; the description nonetheless adds decision-relevant meaning: civilTime is a Beijing wall-clock with no offset suffix, longitude has no default and must come from the user, and the birth-date year range (1900–2050) differs from the chart-year range (1900–2100). It largely restates schema text rather than adding syntax detail, so it does not reach 5.

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 (排一张时家奇门转盘拆补盘) plus optional year-ming output, and explicitly delimits scope with negatives: 'This is not an interpretation and not a global calculator.' Combined with the China-only longitude restriction, an agent can distinguish this from the sibling time/longitude helpers without further reading.

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 an explicit pre-call checklist: fill missing info before calling, never guess, ask the user for longitude, do not default to 120, convert other time zones to Beijing time first, and do not call at all for longitudes outside China. It also states the conditional rule for when trueSolarTime/time must be collected (birth day crossing 立春).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources