Skip to main content
Glama

search_knowledge

Read-only

Search the offline Miliastra knowledge base by keyword to find guide sections, course lessons, FAQs, sample-save breakdowns, transcripts, and worked examples before building a mechanic.

Instructions

Full-text search of the offline knowledge base: the official Miliastra guide (every component, level setting, UI control, class, item/currency/shop system and node, 219 pages), the official course (84 lessons with step-by-step editor configuration), the FAQ, dissections of 48 official sample saves (which graphs hang on which entities, which events they use) and transcripts of the official videos. Use it before inventing a mechanic: the platform usually already has a component for it (collision trigger, option tab, timer, custom variable, currency, shop, UI text). Chinese or English words separated by spaces; hits come back as the best matching sections. section limits to guide / course / faq / samples / transcripts / notes / examples. The examples section holds our own worked levels, each recorded from a real run made with these tools only: every tool call in order with its arguments, and the source of every node graph (read_knowledge {id: "example-events"} is the small one to copy, "example-kingdom4" a whole game with a day and night and enemies, "example-hop" a platform course with a moving platform, a lever and gate, a skill and a countdown, "example-farm" a grow-and-sell loop with plots that keep their own state, tools, a signal that carries a string and currency, "example-checks" one use of each newer tool, "example-skills" three animated skills on three keys, "example-shop" a stall with the platform's shop screen, bought from and sold to by a script that clicks, "example-drops" a drop picked up and a chest that leaves loot, "example-buttons" two buttons on the screen, "example-strike" a sword attack that hits a crate and a creature, which leave loot, "example-raid" a fourth game: fight, pick up the loot, sell it, buy a key, open the gate, "example-potion" an item used from the backpack, "example-shoot" a bolt shot by a skill).

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYes
sectionNoall

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description reinforces the offline nature of the knowledge base and explains that hits come back as best matching sections, but does not discuss pagination, rate limits, or exact result shape.

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

Conciseness2/5

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

Purpose and usage are front-loaded, but the description is extremely long, especially the exhaustive enumeration of example IDs and their contents. That enumeration could be compressed or moved to documentation without losing the call-critical information.

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?

The description covers the knowledge-base scope, query syntax, and section choices well. However, with no output schema it only vaguely states that hits are 'best matching sections', and it leaves the limit parameter undocumented, so it is not fully complete for an agent that needs predictable results.

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?

With 0% schema description coverage, the description must carry parameter meaning. It explains query tokenization ('Chinese or English words separated by spaces') and lists the section values, including detailed examples content, but never explains the limit parameter.

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 — 'Full-text search of the offline knowledge base' — and enumerates the corpora it covers, distinguishing it from scene-authoring siblings. The examples section is clearly described as a distinct searchable corpus.

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

Usage Guidelines4/5

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

Gives a clear usage trigger: 'Use it before inventing a mechanic', because the platform usually already has a component. It does not explicitly compare itself with read_knowledge or search_node_docs, so the alternative-routing guidance is incomplete.

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

Deploy Server

Other Tools