query_knowledge
Explain trading concepts, definitions, relationships, comparisons and when signals work or fail using Michael's knowledge graph. This is the first tool for a general knowledge question, including which indicators complement RSI and when to avoid combining them. Start with op=ask, the complete question in q, hops=1 and limit=5. Keep related clauses together; do not run a search for each clause. Read the summaries and edge reasons before deciding on another call. Answer once the requested explanation and cautions are supported. A follow-up must address a specific missing fact: get an already-returned node for its details, or read one relevant KB section. Do not gather extra context, enumerate neighbors, check the signal catalogue or measure signals merely to expand a conceptual answer. If evidence remains insufficient, say what is unknown instead of repeatedly rephrasing searches. This guidance does not replace validation required for an actual strategy or a requested graph exploration. Explicit glossary, document and browsing requests go directly to the corresponding KB tool without a preliminary graph call. Runtime signal selection belongs to the signal catalogue; measured firing rates and durations belong to query_signal_behavior; current market regime belongs to get_market_regime. These are separate user intents, not mandatory steps for an explanation. Mangrove product policy belongs to query_product_facts. Reuse evidence and node IDs already returned in this conversation. Ops: stats (the counts and the complete vocabulary every filter accepts -- call it when you do not already know the filter values), find (search BY WORDS, optionally by kind/role/status/requires/param -- param finds every signal taking a parameter of that name), ask (search BY MEANING -- give it the question in ordinary words; use this when you would otherwise answer from memory, e.g. 'how far should the stop go', 'what works in a sideways market'; hops is capped at 3), get (one node in full: formula, inputs, params, outputs, warmup), neighbors (one hop: what reads this, or what this depends on; filter by relation, relation_category, primitive or why), walk (the whole neighbourhood out to a radius, as nodes plus edges -- for 'everything around X' rather than one hop at a time), outputs (search the VALUES: which are bounded, which are in given units, what produces an output called X), path (the one shortest route between two nodes), paths (every simple route between two nodes -- use when the shortest route is not the explanatory one), ancestors (the classes a node belongs to, transitively), descendants (everything under a class, transitively), under (everything contained in a node by subject, whatever primitive it is -- e.g. a whole knowledge-base chapter). NEVER GUESS a node id or name for get/neighbors/outputs/path/walk/paths/ancestors/descendants/under: call find (or ask) only if you do not already have an ID from a tool result -- ids look like 'procedure:signal-rsi-bullish-divergence', not 'rsi_divergence'. A get that misses returns candidates; fetch one only if it is relevant to a fact still needed for the answer. Signal rows carry signal_type from the catalog: TRIGGER is an occurrence, FILTER is a condition that can remain true across bars. A boolean output does not make a signal a TRIGGER; read its signal_type rather than infer its role from its name or output. Class and role are different questions: kind='momentum' is what a computation measures, role='trigger' is the part it plays.
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": {
"op": "<op>"
},
"name": "query_knowledge"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | The search text, in ordinary words. | |
| op | Yes | Which question you are asking. | |
| to | No | path, paths: the destination node. | |
| why | No | neighbors, walk, ask: keep only edges whose own stated reason matches these words -- the same relation can carry different claims. | |
| hops | No | ask: how far to walk from each match. 0 restricts it to retrieval. Capped at 3; a higher value raises ValueError naming the cap. | |
| kind | No | The class: what a computation measures. | |
| role | No | The part a signal plays in a strategy. | |
| limit | No | Maximum results. | |
| param | No | find: a parameter name -- every signal that takes it. | |
| seeds | No | ask: how many top matches to expand from before re-ranking. | |
| units | No | The unit an output is measured in. | |
| radius | No | walk: how many hops out the neighbourhood reaches. Capped at 3; for anything wider call neighbors or path instead of a bigger radius. | |
| status | No | Whether the thing is current or withdrawn. | |
| bounded | No | outputs: only values with a fixed range. | |
| relation | No | neighbors: follow only this one relation. | |
| requires | No | An input column it needs. | |
| direction | No | neighbors: in = what reads this, out = what this depends on. | both |
| max_depth | No | path, paths: how long a route may be. path defaults to 6; paths defaults to 4 and is capped at 4 -- past that almost every extra route is a detour through a hub rather than an explanation. | |
| max_nodes | No | walk: stop expanding once this many nodes are collected. | |
| primitive | No | neighbors: keep only neighbours of this node primitive, e.g. Procedure or Concept. | |
| relations | No | path, paths, ask: follow only these relations. | |
| sibling_hops | No | paths: include routes that pass through a shared parent (both nodes are, say, Signal) rather than a direct connection. Off by default -- those routes are usually not the explanation. | |
| relation_category | No | neighbors: follow only edges of this whole relation category (structural, descriptive, associative, meta) -- see stats for the list. |