The wquestions-mcp server lets you build and query a structured knowledge model of any domain using a fixed 7-axis framework (who, what, where, when, how much, which kind, how) — no custom schema required.
Explore the framework — Use list_axes to understand the 7 modeling axes and list_roles to see canonical typed role connectors.
Build a knowledge model — Add named entities to any axis (people, places, objects, times, magnitudes, categories) with add_entity, and optionally pre-register situation/verb types with define_verb (or let the server auto-register on first use).
Assert facts — Use assert_situation to record any real-world event or relationship by attaching role-labeled arguments; supports time-bounded facts via valid_from/valid_to.
Query the model — Use ask to fix some roles and retrieve others, filter by situation type, or query the model as it existed at a specific point in time.
Correct/update facts — Use correct to update a role on an existing situation in an append-only manner, preserving full history.
Inspect the universe — Use show_model to dump all entities and facts, including persistence metadata.
Try instant demos — Use load_example (e.g. the "spa" example) to load a prebuilt domain and start querying immediately.
Reset and start over — Use reset to clear the current universe and begin modeling a new domain.
Persist across sessions — The universe is saved to an append-only log (~/.wquestions/universe.jsonl by default) and automatically reloaded on restart; configurable via the WQUESTIONS_LOG env variable or disableable with WQUESTIONS_LOG=off.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wquestions-mcp Load the spa example and show me the model."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model any domain in 7 questions.
An MCP server that lets Claude Desktop (or any MCP client) build and query a knowledge model of anything — a spa, a barbershop, a clinic, a bank — using one fixed set of tools. No per-domain schema to write, ever.
Every domain today gets its own bespoke ontology or database schema: a CRM schema for sales, a clinical model for a clinic, a different one again for a bank or a taxi dispatcher. None of it transfers between domains, and none of it was designed for an LLM to reason over — each new domain means new modeling work before an AI can even start answering questions about it.
WQuestions replaces all of that with a single fixed index: 7 axes that any fact, in any domain, answers. Model a domain by asserting facts on those 7 axes; query it the same way no matter what the domain is.
Related MCP server: querywise-mcp
Axis | Question | Holds |
Q | who | agents |
O | what | objects, and reified situations (facts treated as things) |
L | where | places |
T | when | time points and intervals |
N | how much | magnitudes with a unit |
K | which / what kind | atemporal categories, types, states |
M | how | the predicates that connect Q/O/L/T/N/K to each other — structural, not a value axis |
Add this to your Claude Desktop config (claude_desktop_config.json) and
restart Claude Desktop:
{
"mcpServers": {
"wquestions": {
"command": "uvx",
"args": ["wquestions-mcp"]
}
}
}Prefer to run from source? Clone this repo and, from the repo root,
pip install -e . into a virtualenv (the engine is bundled — no other
package needed). Then point command/args at that venv's wquestions-mcp
script (e.g. command: ".../.venv/bin/wquestions-mcp", args: []) instead
of uvx.
Then ask Claude: "Load the spa example, then show me the model." See
DEMO.md for the full 30-second walkthrough.
Tool | Does |
| Describe the 7 axes |
| List canonical roles (who/what/where/... connectors), typed by domain and range |
| Create an individual on a value axis (Q, O, L, T, N, K); for the N axis pass |
| Register a situation type and its roles — optional, |
| Assert a fact: reify a situation and attach its roles |
| Correct/update a role on an existing situation by re-asserting it (append-only; |
| Query by projection — fix some roles, ask for others, optionally as of a point in time; pass |
| Dump the current universe: every entity and fact |
| Load a prebuilt demo universe ( |
| Clear the model and start a fresh universe |
The LLM client does the natural-language-to-structure step: it reads "Diego
cut Marco's hair at Barber Kings on 2025-06-11" and turns it into
role-labeled arguments (agente: diego, paciente: marco, lugar_de: barber_kings). The server never parses English — it takes those roles,
validates them against the 7-axis model, and runs ingest and query over the
wq engine. Same engine, same 10 tools, whether the domain behind them is a
spa or a barbershop.
By default the server persists your universe to an append-only log and reloads on restart, so a modeled domain survives across sessions — you never rebuild by hand. Nothing is ever overwritten; corrections are appended and the log is the source of truth.
Default location: ~/.wquestions/universe.jsonl.
Choose a file: set WQUESTIONS_LOG=/path/to/domain.jsonl. Point each domain
at its own file (e.g. one per MCP server entry in your client config) — a single
log holds one live universe at a time (a reset starts a fresh domain within it).
Turn it off (pure in-memory): WQUESTIONS_LOG=off.
show_model reports the active log path and how many events were replayed, so
you can confirm persistence is on.
The 7-axis model — why it's fixed, what each axis actually commits to, and how it holds up once you push on it — is worked out in full in WQuestions, the book this project comes from (Spanish). Start with Chapter 8, El espacio multidimensional for the axis model itself, or the table of contents.
Create an individual on a value axis (Q, O, L, T, N, or K).
| Name | Required | Description | Default |
|---|---|---|---|
| axis | Yes | ||
| label | No | ||
| entity_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. However, it only says 'Create an individual on a value axis', omitting details about idempotency, error handling, permissions, or whether the tool is destructive. The description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, given the lack of schema descriptions, it could be slightly longer to cover more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 3 parameters, no schema descriptions, and no annotations, the description is sparse. It does not explain return values (even though an output schema exists), prerequisites, or behavior for edge cases. The tool requires more context to be used correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It lists valid axis values, which helps for the 'axis' parameter, but provides no insight into 'entity_id' or 'label'. This is insufficient for understanding all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'individual on a value axis', and enumerates the valid axis values (Q, O, L, T, N, or K). This distinguishes it from sibling tools like list_axes or define_verb, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only states what the tool does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query by projection: fix some roles, ask for others. type filters to
situations whose type matches the given category id (auto-registered
verbs get the id action_<verb>). at (ISO) queries the model as it
was valid at that time.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | ||
| ask | No | ||
| type | No | ||
| fixed | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that type filters by category id and at enables temporal queries, but does not clarify whether the tool is read-only, affects state, or has other behavioral traits. Since no annotations are provided, the description carries the full burden and is only partially adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the key concept, but it is cryptic and could be more concise with clearer phrasing. Every sentence earns its place, but the second sentence is dense and hard to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, 0% schema coverage), the description is insufficient. It does not explain the projection concept fully, lacks examples, and does not reference the output schema. An agent would likely need additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 'type' and 'at' but leaves 'fixed' and 'ask' largely unexplained. The vague phrase 'fix some roles, ask for others' hints at their purpose but is insufficient for an agent to understand parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a query tool using projection, which distinguishes it from sibling tools like add_entity or assert_situation. However, it does not clearly explain what 'fix some roles, ask for others' means in practical terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies querying but does not mention conditions, prerequisites, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assert a fact: reify a situation for verb and attach its roles.
Each role value is an existing entity id or an inline {id, axis, label}.
valid_from/valid_to are ISO-8601, for facts that are only valid during
a time range.
| Name | Required | Description | Default |
|---|---|---|---|
| verb | Yes | ||
| extra | No | ||
| roles | Yes | ||
| valid_to | No | ||
| valid_from | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that roles can be IDs or inline objects and that valid_from/valid_to are ISO-8601. However, it does not specify behavior on invalid roles, whether duplicates are allowed, or if the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded and to the point. The first sentence gives the core action, the second adds essential details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, nested objects, output schema exists), the description covers the main functionality, role value types, and time constraints. It does not explain 'extra' but output schema handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining role values (existing entities or inline objects) and time format. However, the 'extra' parameter is not described, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'assert' and resource 'situation', clearly indicating the action of reifying a fact with roles. It distinguishes from siblings like add_entity (which adds entities) and define_verb (which defines verbs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it or not use it. It implies usage for asserting facts with temporal constraints, but no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a situation type (verb) and which roles it takes. Optional: assert_situation auto-registers unknown verbs permissively.
| Name | Required | Description | Default |
|---|---|---|---|
| verb | Yes | ||
| optional | No | ||
| obligatory | No | ||
| situation_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'register' without explaining side effects, what happens if the verb already exists, whether the tool is destructive, or any authorization needs. This is a significant gap for a tool that modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that efficiently convey the core purpose and a key optional note. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no schema descriptions, output schema exists but unmentioned), the description is too brief. It lacks details on return values, role structure, valid inputs, and behavioral constraints. The agent would likely need to guess about proper usage of optional/obligatory arrays.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond parameter names. It mentions 'which roles it takes' but does not explain the 'optional' and 'obligatory' arrays or their interaction. With 0% schema description coverage, the description should compensate but does not clarify parameter semantics beyond what the names imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Register a situation type (verb) and which roles it takes.' This is a clear, specific verb+resource definition. It also distinguishes from sibling tool 'assert_situation' by noting that assert_situation can auto-register unknown verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit alternative: 'Optional: assert_situation auto-registers unknown verbs permissively.' This tells agents when to use this tool (explicit registration) versus the sibling. However, it does not give any when-not-to-use advice or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 7 WQuestions axes (Q who, O what, L where, T when, N how-much, K which, M how) and what each is for.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It clearly states the tool lists axes and their purposes, implying a read-only operation with no side effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource. Every word is necessary, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no complex behavior. The description is sufficient for an agent to understand what it does and does not need additional detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema covers 100%. The description does not need to add parameter meaning. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists the 7 WQuestions axes and their purposes, which is a specific verb+resource. It clearly distinguishes from sibling tools like add_entity or ask, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving axis information but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, but the context is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the canonical roles with their typed signatures. Unknown roles are also allowed (liberal policy) — you may invent domain roles freely.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates that unknown roles are allowed (liberal policy), which is a behavioral trait. However, it does not explicitly state that the operation is read-only or describe any side effects, though 'list' implies non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and each sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description adequately explains the tool's function. It covers the key information about listing canonical roles and the liberal policy. Slightly lower because it does not explicitly state the return type, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so coverage is 100%. The description adds meaning by specifying what will be listed (canonical roles with typed signatures) and the policy on unknown roles, compensating for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'canonical roles with their typed signatures', which is specific and distinguishes it from siblings like list_axes. The addition about unknown roles and liberal policy further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of when to choose list_roles over siblings like list_axes or show_model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a prebuilt demo universe (e.g. "spa") to try queries instantly.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action (load) but does not disclose behavioral traits like whether it overwrites current state, requires authentication, or what the output schema contains. This is insufficient for a mutation-type tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core function without extraneous words. It earns its place, though it could include more detail about output or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no enums, has output schema), the description is adequate but incomplete: it does not describe return values despite an output schema existing. Behavioral aspects are also missing. A more complete description would cover what happens after loading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds one example value ('spa') to illustrate the 'name' parameter. However, it does not explain the parameter's meaning in depth (e.g., list of valid values, pattern, or purpose). It provides some added context but barely meets the baseline for zero-coverage parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a prebuilt demo universe and provides an example ('spa'). It uses specific verb 'load' and resource 'demo universe', which distinguishes it from sibling tools like add_entity or reset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to try queries instantly' implies a use case (quick testing), but there is no explicit guidance on when to use this tool versus alternatives (e.g., reset) or when not to use it. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the model and start a fresh empty universe.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly indicates a destructive reset action ('Clear the model'), which is appropriate for a zero-parameter tool. No annotations are present, so the description carries full burden and meets it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the essential action without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema present), the description is complete and covers the necessary information for an agent to understand what this tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100% (none to describe). The description adds no parameter information, but by baseline for zero-param tools, it is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Clear') and resource ('model'), and specifies the outcome ('start a fresh empty universe'). It distinguishes from siblings like add_entity or load_example which modify the universe incrementally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a fresh start is needed, but it does not explicitly provide when or when-not to use this tool versus alternatives like load_example or starting a new session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dump the current universe: entity/fact counts and every fact.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It accurately indicates the tool is a read operation ('dump') and describes the output content. However, it does not disclose potential performance implications for large universes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key purpose. Every word is meaningful with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema present), the description sufficiently explains what is returned. It could briefly mention that the dump includes all facts, which might be large, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. No parameter information is needed, and the description adds nothing beyond what the schema already provides (empty).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb 'dump' and resource 'current universe', and specifies what is included (entity/fact counts and every fact). It is distinct from sibling tools like add_entity or ask.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as list_axes or ask. The description only states what it does, not when it is appropriate to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_entityaskassert_situationdefine_verblist_axeslist_rolesload_exampleresetshow_modelScored across 9 tools
Each tool targets a distinct operation: adding entities, querying, asserting situations, defining verbs, listing axes/roles, loading examples, resetting, and showing the model. No overlap in functionality.
Most tools follow a verb_noun pattern (add_entity, assert_situation, define_verb, list_axes, etc.), but 'ask' and 'reset' are single verbs, introducing minor inconsistency.
9 tools is well-suited for a knowledge graph modeling server, covering core operations without being excessive or sparse.
Missing operations like updating or deleting specific entities or situations, and lacking targeted retrieval (e.g., get_entity by id) limit the completeness for a full lifecycle.
Ask questions in plain language, get answers from your business database. No SQL required.
Agentic CRM for service businesses — bookings, customers, WhatsApp, loyalty, invoicing.
Verified local businesses, bookable by AI agents: services, prices, availability and appointments.
Ask business questions in plain English. Get instant answers from your database, no SQL needed.
