Skip to main content
Glama
PTCuong-1102

story-architect-mcp

by PTCuong-1102

Query Context Budget

story_query_context

Extracts optimal story context via knowledge graph and token budget; finds shortest relationship path between two characters when from/to provided.

Instructions

Trích xuất và tổng hợp Context Budget tối ưu nhất bằng Knowledge Graph (Bible + Relationships + Timeline) kết hợp ngân sách token. Truyền from+to để hỏi đường liên hệ ngắn nhất giữa hai nhân vật.

Input Schema

NameRequiredDescriptionDefault
toNoNhân vật đích cho truy vấn đường đi (đi kèm from)
fromNoNhân vật xuất phát cho truy vấn đường đi (đi kèm to)
queryYesChủ đề hoặc từ khóa cần lấy context (ví dụ: "Tiêu Viêm Thanh Vân Sơn")
maxDepthNoĐộ sâu mở rộng quan hệ nhân vật (BFS) trong đồ thị
budgetTokensNoNgân sách token tối đa cho context (mặc định 2000 tokens ~ 1500 từ)
rebuildIndexNoBuộc build lại index .cbm/index.json từ dữ liệu mới nhất

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.7.0
    • addedInput schema / properties / budgetTokens / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / budgetTokens / minimum
      Added value: +100
    • changedInput schema / properties / budgetTokens / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / from
      Added value: +{
      +  "description": "Nhân vật xuất phát cho truy vấn đường đi (đi kèm to)",
      +  "type": "string"
      +}
    • addedInput schema / properties / maxDepth
      Added value: +{
      +  "default": 2,
      +  "description": "Độ sâu mở rộng quan hệ nhân vật (BFS) trong đồ thị",
      +  "maximum": 10,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / query / minLength
      Added value: +1
    • addedInput schema / properties / rebuildIndex
      Added value: +{
      +  "default": false,
      +  "description": "Buộc build lại index .cbm/index.json từ dữ liệu mới nhất",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / to
      Added value: +{
      +  "description": "Nhân vật đích cho truy vấn đường đi (đi kèm from)",
      +  "type": "string"
      +}
  2. First observedv0.1.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations exist, so the description carries the full burden and it falls short. It never states that the tool is a read operation, that rebuildIndex writes/replaces the .cbm/index.json file on disk, or how truncation behaves when the token budget is exhausted (which content gets dropped). The phrase 'tối ưu nhất' asserts quality without explaining the selection or ranking behavior.

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?

Two sentences, the core capability front-loaded, and the mode switch placed second. Nothing is padding, though 'tối ưu nhất' is unverifiable marketing rather than information, which keeps it from a 5.

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?

For a six-parameter tool with no annotations and no output schema, the description leaves too much unsaid: it does not describe what the returned 'Context Budget' looks like (synthesized prose, entity list, graph slice?), how query and from/to modes interact, or the cost/impact of rebuildIndex. The agent must open the schema and guess the rest.

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%, so all six parameters (query, from, to, maxDepth, budgetTokens, rebuildIndex) are already documented in the schema, establishing the baseline of 3. The description's mention of from+to merely restates what the schema already says and adds no format, interaction (from+to vs query precedence), or unit detail beyond it.

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 first sentence names a specific action (extract and synthesize an optimal Context Budget) and the sources it draws from (Bible + Relationships + Timeline in a Knowledge Graph), which is far more informative than the bare name 'story_query_context'. The second sentence carves out a distinct second mode (from+to shortest relationship path). It stops short of explicitly contrasting itself with siblings like story_map_relationships or story_generate_writing_prompt, so differentiation is only partial.

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 sentence 'Truyền from+to để hỏi đường liên hệ ngắn nhất giữa hai nhân vật' does give a concrete condition for the path-query mode, so usage is more than bare implication. However, it never says when to prefer this tool over story_generate_writing_prompt, story_map_relationships, or story_extract_entities_to_bible, nor when not to use it. The rival-sibling exclusions an agent would need are absent.

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