@nesso-how/mcp 0.1.0-alpha.34 → 0.1.0-alpha.35
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -10,13 +10,13 @@
|
|
|
10
10
|
"slug": "guides/concepts-and-inspector",
|
|
11
11
|
"title": "Concepts & Inspector",
|
|
12
12
|
"description": "Adding concepts, drawing typed relations, and using the Inspector to enrich nodes with definitions, examples, notes, and images.",
|
|
13
|
-
"markdown": "The canvas is the centre of Nesso. **Concepts** are nodes; **typed relations** are edges. The **Inspector** is the right-hand panel where you enrich whatever you've got selected.\n\n## Adding concepts\n\n- **Double-click** empty canvas to add a concept at the pointer.\n- **`N`** adds a concept at the viewport centre.\n- **Right-click** empty canvas and choose **Add concept here** to add one at the cursor.\n- New concepts open in edit mode. Type the label and press `Enter` to commit, `Esc` to cancel.\n- **Double-click** a concept to rename it inline.\n\nAn empty graph shows a centered **\"Your first concept\"** hint; the double-click still works through it.\n\nConcepts you add are stored locally in IndexedDB. Switch graphs from the sidebar; create new graphs from the **Graphs** list.\n\n## Drawing relations\n\nDrag from a node's right edge (`out` handle) to another node's left edge (`in` handle). On release, a **relation picker** opens, grouped by category. Pick the relation type and the edge is created.\n\n- Drag-to-self is ignored, so you can't accidentally create self-loops.\n- The connection line previews with the same quadratic geometry the final edge uses.\n- Edge type can be changed any time from the Inspector when an edge is selected.\n\nSee the [relation types reference](../../reference/relation-types/) for the full list, semantic meaning, and
|
|
13
|
+
"markdown": "The canvas is the centre of Nesso. **Concepts** are nodes; **typed relations** are edges. The **Inspector** is the right-hand panel where you enrich whatever you've got selected.\n\n## Adding concepts\n\n- **Double-click** empty canvas to add a concept at the pointer.\n- **`N`** adds a concept at the viewport centre.\n- **Right-click** empty canvas and choose **Add concept here** to add one at the cursor.\n- New concepts open in edit mode. Type the label and press `Enter` to commit, `Esc` to cancel.\n- **Double-click** a concept to rename it inline.\n\nAn empty graph shows a centered **\"Your first concept\"** hint; the double-click still works through it.\n\nConcepts you add are stored locally in IndexedDB. Switch graphs from the sidebar; create new graphs from the **Graphs** list.\n\n## Drawing relations\n\nDrag from a node's right edge (`out` handle) to another node's left edge (`in` handle). On release, a **relation picker** opens, grouped by category. Pick the relation type and the edge is created.\n\n- Drag-to-self is ignored, so you can't accidentally create self-loops.\n- The connection line previews with the same quadratic geometry the final edge uses.\n- Edge type can be changed any time from the Inspector when an edge is selected.\n\nSee the [relation types reference](../../reference/relation-types/) for the full list, semantic meaning, and type properties. Per-type line style and glyph come from `@nesso-how/vocab-learning`; edge encoding density is under [Display options](#display-options-sidebar) below.\n\n## Selecting and editing\n\n- **Click** a node or edge to select it. The Inspector reflects the selection.\n- **Hold `⌘` / `Ctrl` and click** to toggle additional items into the selection.\n- **Drag on empty canvas** to marquee-select multiple items.\n- **`⌘A` / `Ctrl+A`** selects every concept and relation in the graph.\n- **Right-click** a concept, relation, or empty canvas for a context menu of the relevant actions (copy/cut/duplicate/delete a concept; flip / delete a relation; paste / add concept / center·fit on the canvas). To change a relation's type, select the edge and pick a new type in the Inspector.\n- **`Del`** or **`Backspace`** deletes the selection (one relation, one concept, or every concept in a marquee). Edges attached to a deleted concept go with it. Delete is also on the right-click menu and the Inspector's action toolbar.\n- **`⌘C` / `Ctrl+C`** copies the selection. Copying concepts also copies relations between them; copying a relation includes its two endpoints. **`⌘X` / `Ctrl+X`** cuts: it copies the selection and removes it in one step. **`⌘V` / `Ctrl+V`** pastes the clipboard with a small offset (right-click **Paste** drops it at the cursor instead). **`⌘D` / `Ctrl+D`** duplicates the selection in place without touching the clipboard. These also live on the right-click menu and the Inspector toolbar.\n- **Arrow keys** nudge a selected concept; **Shift + arrows** move it in larger steps.\n- **`⌘Z` / `Ctrl+Z`** undoes structural edits; **`⌘⇧Z` / `Ctrl+Shift+Z`** redoes. History has 50 steps and resets when you switch or import a graph.\n\n## The Inspector\n\nThe Inspector docks on the **right**, full height between the top bar and the status bar. Its header has a **collapse** control that shrinks it to a slim **rail** (keeping the selection plus a vertical action toolbar) and a **close** control; a docked bottom **action toolbar** offers copy / cut / duplicate / delete for a concept, or flip / delete for a relation.\n\nWhen a concept is selected it shows, top to bottom:\n\n- **Image + title:** the title edits inline (`Enter` commits, `Esc` reverts); the image button opens Commons search (see below).\n- **Memory** _(collapsible):_ the FSRS schedule, read-only — when due, stability (in days), last self-rating, review count (with lapses), and time since the last review.\n- **Definition**, **Examples**, **Notes** — see below.\n- **Relations** _(collapsible):_ outgoing and incoming edges, each connected concept shown with the relation glyph in a chip and the type on the right (incoming dimmed). Click a row to jump to that concept; change a relation's type by selecting the edge.\n\n### Notes fields\n\nThree free-text fields that travel with the concept and feed both the AI mentor and [Review](./review-mode/):\n\n- **Definition:** a one-sentence-ish explanation in your own words.\n- **Examples:** one per line. Press `Shift+Enter` or use the **Add** button to add a new line; press `Backspace` in an empty example to remove that line (unless it's the only one).\n- **Notes:** anything else: caveats, sources, mnemonics.\n\nIn Review, definition and examples appear when you **Reveal** a card so you can check your recall. The AI mentor uses the same fields in its graph snapshot and focal-neighbour context when a concept is selected.\n\n### Concept image\n\nPress the picture icon to open the **Wikimedia Commons search**. The query auto-fills from the concept title and runs immediately; pick any result to attach a 200-px thumbnail to the concept. The image shows in the Inspector, on reveal in Review mode, and is included as context for the AI mentor.\n\nThe image link and Commons description URL are persisted with the graph, so attribution is preserved on export.\n\n## Display options (sidebar)\n\n**Sidebar → Display** controls how the **active graph** is rendered: heatmap overlay, edge encoding density, curve style, and auto flip. Choices are saved **with the graph** in IndexedDB (and included in JSON export). New graphs start from the app defaults until you change them.\n\nWhen **Display → Curve** is set to **Arc**, **Auto flip** (on by default) bends relations toward the side that avoids overlapping nodes, flipping when the target is above the source on the right, or below on the left, and updates live while you drag concepts. **Flip curve** in the Inspector is **Off | Auto | On** while auto flip is on: **Auto** follows layout, **Off** / **On** pin a manual bend on that edge. With auto flip off for that graph, the control is **Off | On** only.\n\n## When an edge is selected\n\nThe Inspector shows the relation as a chip with its category colour and a dropdown of every relation type. Picking a new type updates the edge in place; the graph keeps its endpoints and identity.\n\n## Status bar and search\n\n- The **status bar** along the bottom shows the concept and relation counts. Its right side carries undo / redo, zoom out / in, and center·fit; the **Socrates** entry sits on the left.\n- **`⌘K` / `Ctrl+K`** opens a fuzzy search palette over concept titles. `Enter` selects and recenters the viewport; `Esc` closes.\n\n## Edge encoding density\n\nEdges carry three visual channels: colour (category), line style, and glyph. Crank this down for large or printed graphs from **Sidebar → Display → Edges**:\n\n- **Full:** colour + style + glyph (default).\n- **Category:** colour only.\n- **Minimal:** plain line, no encoding.\n\nSymmetric relations (similarity, opposition) never render an arrowhead regardless of encoding."
|
|
14
14
|
},
|
|
15
15
|
{
|
|
16
16
|
"slug": "guides/embedding-graphs",
|
|
17
17
|
"title": "Embedding graphs",
|
|
18
18
|
"description": "Render Nesso knowledge graphs in your own React app with @nesso-how/graph.",
|
|
19
|
-
"markdown": "The [`@nesso-how/graph`](https://www.npmjs.com/package/@nesso-how/graph) package is an embeddable React component for rendering Nesso knowledge graphs: the same visual style (categories, glyphs, edge curves) used by the app, available for docs, blog posts, or any React surface.\n\n## Install\n\n```bash\nnpm install @nesso-how/graph @xyflow/react react react-dom\n```\n\n`@xyflow/react`, `react`, and `react-dom` are peer dependencies. Install versions matching the ranges declared in the package's `peerDependencies`.\n\n## Basic usage\n\n```tsx\nimport { NessoGraph } from '@nesso-how/graph'\nimport '@xyflow/react/dist/style.css'\n;<NessoGraph nodes={nodes} edges={edges} style={{ width: '100%', height: 400 }} />\n```\n\nBy default the graph renders read-only (no drag, connect, or selection) using the same category colors, glyphs, and edge encoding as the app. Pass a full `
|
|
19
|
+
"markdown": "The [`@nesso-how/graph`](https://www.npmjs.com/package/@nesso-how/graph) package is an embeddable React component for rendering Nesso knowledge graphs: the same visual style (categories, glyphs, edge curves) used by the app, available for docs, blog posts, or any React surface.\n\n## Install\n\n```bash\nnpm install @nesso-how/graph @xyflow/react react react-dom\n```\n\n`@xyflow/react`, `react`, and `react-dom` are peer dependencies. Install versions matching the ranges declared in the package's `peerDependencies`.\n\n## Basic usage\n\n```tsx\nimport { NessoGraph } from '@nesso-how/graph'\nimport '@xyflow/react/dist/style.css'\n;<NessoGraph nodes={nodes} edges={edges} style={{ width: '100%', height: 400 }} />\n```\n\nBy default the graph renders read-only (no drag, connect, or selection) using the same category colors, glyphs, and edge encoding as the app. Pass a full `NessoGraphDocument` via `graph` instead of `nodes`/`edges` if you have one (e.g. JSON from `deserialize` in `@nesso-how/vocab-learning`). FSRS review fields are not in the file — embeds show an empty heatmap unless you merge review state yourself.\n\n## Display options\n\n`display` controls how edges and categories are drawn:\n\n```tsx\n<NessoGraph\n nodes={nodes}\n edges={edges}\n display={{ edgeEncoding: 'full', curveStyle: 'straight', showHeatmap: false }}\n/>\n```\n\n`palette` selects one of the category color palettes available in the app's settings. Embeds use hex colors from `PALETTES` (`categoryColorMode: 'palette'`, the default). Host apps that set `--cat-*` CSS variables (like Nesso itself) pass `categoryColorMode=\"css\"`.\n\nOptional `getRelationLabel` localizes edge labels; `isItemSelected` syncs selection with an external store.\n\n## Interactivity\n\n`nodesDraggable`, `nodesConnectable`, and `elementsSelectable` are all `false`/read-only by default, so turn on what you need. How you provide nodes determines who owns their state:\n\n- **`nodes`/`edges`** (_controlled_): you own the state, so also pass `onNodesChange`/`onEdgesChange`/`onConnect` to apply the resulting changes (e.g. when positions live in your own store, like the main app does).\n- **`defaultNodes`/`defaultEdges`** (_uncontrolled_): React Flow seeds its state once from these and manages drag, connect, and selection internally, with nothing else to wire up. The right choice for a self-contained embed.\n\n```tsx\n<NessoGraph\n defaultNodes={nodes}\n defaultEdges={edges}\n nodesDraggable\n style={{ width: '100%', height: 400 }}\n/>\n```\n\n## Escape hatch\n\nAny [`ReactFlow`](https://reactflow.dev/api-reference/react-flow) prop not listed above can be passed through `reactFlowProps`, for example to hide the attribution badge or disable double-click-to-zoom:\n\n```tsx\n<NessoGraph\n nodes={nodes}\n edges={edges}\n reactFlowProps={{ proOptions: { hideAttribution: true }, zoomOnDoubleClick: false }}\n/>\n```"
|
|
20
20
|
},
|
|
21
21
|
{
|
|
22
22
|
"slug": "guides/getting-started",
|
|
@@ -28,7 +28,7 @@
|
|
|
28
28
|
"slug": "guides/mcp-integration",
|
|
29
29
|
"title": "MCP",
|
|
30
30
|
"description": "Connect Nesso to Claude, Cursor, or any MCP-compatible AI client.",
|
|
31
|
-
"markdown": "The `@nesso-how/mcp` package is a [Model Context Protocol](https://modelcontextprotocol.io/) server that gives AI clients access to Nesso documentation and the full relation-type vocabulary. Once connected, models can answer questions about how Nesso works and use the correct relation names when you build graphs yourself in the app or in JSON.\n\n## Setup\n\n### Claude Desktop\n\nOpen `claude_desktop_config.json`. On macOS it lives at `~/Library/Application Support/Claude/claude_desktop_config.json`; on Windows at `%APPDATA%\\Claude\\claude_desktop_config.json`.\n\nAdd a `nesso` entry under `mcpServers`:\n\n```json\n{\n \"mcpServers\": {\n \"nesso\": {\n \"command\": \"npx\",\n \"args\": [\"-y\", \"@nesso-how/mcp\"]\n }\n }\n}\n```\n\nSave the file and restart Claude Desktop. The Nesso tools will be available to the model automatically.\n\n### Cursor\n\nOpen **Settings -> MCP** and add a new server with command `npx` and args `[\"-y\", \"@nesso-how/mcp\"]`.\n\n### Other MCP clients\n\nAny client that speaks the stdio MCP transport works. Run `npx -y @nesso-how/mcp` as the server command. No other configuration is required.\n\n## What it can do\n\nOnce connected, you can ask your AI client things like:\n\n- \"What relation types does Nesso support?\" (uses `get_relation_types`)\n- \"Show me the Nesso getting started guide\" (uses `get_nesso_docs`)\n\nYou can build graphs in [app.nesso.how](https://app.nesso.how) yourself, or ask the model to generate a graph as a JSON file and import it via **Graph menu → Import JSON**. Use `get_relation_types` to make sure the model picks valid relation names.\n\n## Tools reference\n\n### `get_nesso_docs`\n\nFetches documentation pages from this site. Call it without a `slug` to get a table of contents, or with a slug (e.g. `\"guides/getting-started\"`) to get the full page content.\n\n### `get_relation_types`\n\nReturns the complete list of relation types
|
|
31
|
+
"markdown": "The `@nesso-how/mcp` package is a [Model Context Protocol](https://modelcontextprotocol.io/) server that gives AI clients access to Nesso documentation and the full relation-type vocabulary. Once connected, models can answer questions about how Nesso works and use the correct relation names when you build graphs yourself in the app or in JSON.\n\n## Setup\n\n### Claude Desktop\n\nOpen `claude_desktop_config.json`. On macOS it lives at `~/Library/Application Support/Claude/claude_desktop_config.json`; on Windows at `%APPDATA%\\Claude\\claude_desktop_config.json`.\n\nAdd a `nesso` entry under `mcpServers`:\n\n```json\n{\n \"mcpServers\": {\n \"nesso\": {\n \"command\": \"npx\",\n \"args\": [\"-y\", \"@nesso-how/mcp\"]\n }\n }\n}\n```\n\nSave the file and restart Claude Desktop. The Nesso tools will be available to the model automatically.\n\n### Cursor\n\nOpen **Settings -> MCP** and add a new server with command `npx` and args `[\"-y\", \"@nesso-how/mcp\"]`.\n\n### Other MCP clients\n\nAny client that speaks the stdio MCP transport works. Run `npx -y @nesso-how/mcp` as the server command. No other configuration is required.\n\n## What it can do\n\nOnce connected, you can ask your AI client things like:\n\n- \"What relation types does Nesso support?\" (uses `get_relation_types`)\n- \"Show me the Nesso getting started guide\" (uses `get_nesso_docs`)\n\nYou can build graphs in [app.nesso.how](https://app.nesso.how) yourself, or ask the model to generate a graph as a JSON file and import it via **Graph menu → Import JSON**. Use `get_relation_types` to make sure the model picks valid relation names.\n\n## Tools reference\n\n### `get_nesso_docs`\n\nFetches documentation pages from this site. Call it without a `slug` to get a table of contents, or with a slug (e.g. `\"guides/getting-started\"`) to get the full page content.\n\n### `get_relation_types`\n\nReturns the complete list of relation types grouped by category id (`taxonomic`, `structural`, … from `RELATION_CATEGORIES` in `@nesso-how/vocab-learning`), with line style, symmetry, and type properties (transitive, inverse, strength, polarity, cardinality). Use this whenever you need valid type names for graph JSON or explanations for the learner."
|
|
32
32
|
},
|
|
33
33
|
{
|
|
34
34
|
"slug": "guides/review-mode",
|
|
@@ -46,7 +46,7 @@
|
|
|
46
46
|
"slug": "reference/relation-types",
|
|
47
47
|
"title": "Relation types",
|
|
48
48
|
"description": "The 52 semantic relation types across 8 categories in Nesso.",
|
|
49
|
-
"markdown": "In Nesso, every edge carries a **semantic type**: a named relation describing how two concepts are connected, with semantic coefficients reserved for graph-analysis algorithms (future work, no algorithm currently consumes them). The vocabulary is fixed at 52 types across 8 categories, drawn from prior work in knowledge representation, lexical semantics, temporal logic, and signed-network theory.\n\n:::note\nThis set and its coefficients are a starting point. Both the types and their coefficient values will evolve as real graphs accumulate, edge cases surface, and the analysis algorithms that consume the coefficients get built out. Treat them as a considered first cut, not a final spec.\n:::\n\n## Coefficients\n\nEach relation type declares the coefficients below. They define the contract that graph-analysis algorithms will consume; closing the enum guarantees every type comes with them, where a user-defined type would arrive without and stay analytically opaque.\n\n- **Transitive (T)**: `Y` (strict), `N` (none), or `weak` (transitivity with decay; algorithms may discount per step).\n- **Inverse (I)**: the canonical inverse type in the set; `self` for symmetric relations. Asymmetric relations declare it explicitly so traversal is first-class in both directions. The explicit-inverse design follows knowledge-graph embedding work <a id=\"cite-1\" href=\"#ref-1\">[1]</a>, which lists symmetry, antisymmetry, inversion, and composition as the four properties a good relation set should support.\n- **Strength (S)**: per-type semantic weight in `0..1`. Encodes how \"tight\" the relation is in general (e.g. `defines` 0.90 vs `similar-to` 0.40), not how sure the user is about a specific edge. The idea that different relation types carry different semantic distance comes from lexical-taxonomy weighting schemes <a id=\"cite-2\" href=\"#ref-2\">[2]</a>, <a id=\"cite-3\" href=\"#ref-3\">[3]</a>.\n- **Polarity (P)**: `+1` positive effect, `-1` antagonistic, `0` neutral/structural. From signed-network theory <a id=\"cite-4\" href=\"#ref-4\">[4]</a>: with polarity, the graph becomes a signed network where balance and cycle-sign analyses can apply.\n- **Cardinality (C)**: expected mapping pattern, always declared. One of `1-1`, `1-N`, `N-1`, `N-N` (no a-priori constraint). Setting this consistently lets algorithms flag structural anomalies (e.g. two competing `defines` edges into the same term).\n\n## Categories\n\nEach category answers a specific question about the relation. Grouping the types by question makes the vocabulary easier to navigate when authoring a graph, and lets graph-analysis algorithms compare and aggregate at category level instead of only per individual type.\n\n### Taxonomic\n\n_What kind of thing is it?_\n\n| Type | Label | I | T | S | P | C |\n| -------------- | ------------ | -------------- | --- | ---- | --- | --- |\n| `subtype-of` | subtype of | `has-subtype` | Y | 0.90 | 0 | N-1 |\n| `has-subtype` | has subtype | `subtype-of` | Y | 0.90 | 0 | 1-N |\n| `instance-of` | instance of | `has-instance` | N | 0.95 | 0 | N-1 |\n| `has-instance` | has instance | `instance-of` | N | 0.95 | 0 | 1-N |\n\nTaxonomic relations answer the simplest question you can ask about a concept: what kind of thing is it? Nesso splits the answer into two layers that look alike at a glance but behave very differently under reasoning. The class-vs-instance distinction mirrors OWL/RDFS <a id=\"cite-5\" href=\"#ref-5\">[5]</a>: `subtype-of` corresponds to `rdfs:subClassOf` (one class refines another, as a sparrow refines bird), while `instance-of` corresponds to `rdf:type` (an individual belongs to a class, as Tweety belongs to sparrow). Inheritance flows freely through the subtype chain, but instances are leaves: Tweety is a sparrow and through that a bird, yet Tweety is not itself \"a kind of\" anything.\n\n### Structural\n\n_What is it made of or composed from?_\n\n| Type | Label | I | T | S | P | C |\n| ---------- | -------- | ---------- | ---- | ---- | --- | --- |\n| `part-of` | part of | `contains` | Y | 0.85 | 0 | N-1 |\n| `contains` | contains | `part-of` | Y | 0.85 | 0 | 1-N |\n| `made-of` | made of | `composes` | weak | 0.75 | 0 | N-N |\n| `composes` | composes | `made-of` | weak | 0.75 | 0 | N-N |\n\nStructural relations describe how a thing decomposes into its parts. The category covers two patterns. `part-of` and its inverse `contains` capture discrete structural decomposition: an engine is part of a car, a paragraph is part of a chapter, and transitivity flows cleanly through the chain. `made-of` and `composes` capture material or substantive composition instead: water is made of hydrogen and oxygen, a chair is made of wood. Transitivity there is only weak, because what something is made of doesn't always propagate in a meaningful way (a chair made of wood, made of cellulose, made of carbon, made of atoms dilutes the relationship as the chain grows).\n\n### Causal\n\n_What does it do or prevent?_\n\n| Type | Label | I | T | S | P | C |\n| -------------- | ------------ | -------------- | ---- | ---- | --- | --- |\n| `causes` | causes | `caused-by` | N | 0.85 | +1 | N-N |\n| `caused-by` | caused by | `causes` | N | 0.85 | +1 | N-N |\n| `produces` | produces | `produced-by` | N | 0.70 | +1 | N-N |\n| `produced-by` | produced by | `produces` | N | 0.70 | +1 | N-N |\n| `enables` | enables | `enabled-by` | weak | 0.60 | +1 | N-N |\n| `enabled-by` | enabled by | `enables` | weak | 0.60 | +1 | N-N |\n| `prevents` | prevents | `prevented-by` | N | 0.85 | −1 | N-N |\n| `prevented-by` | prevented by | `prevents` | N | 0.85 | −1 | N-N |\n| `triggers` | triggers | `triggered-by` | N | 0.70 | +1 | N-N |\n| `triggered-by` | triggered by | `triggers` | N | 0.70 | +1 | N-N |\n| `inhibits` | inhibits | `inhibited-by` | N | 0.55 | −1 | N-N |\n| `inhibited-by` | inhibited by | `inhibits` | N | 0.55 | −1 | N-N |\n| `disables` | disables | `disabled-by` | weak | 0.60 | −1 | N-N |\n| `disabled-by` | disabled by | `disables` | weak | 0.60 | −1 | N-N |\n| `consumes` | consumes | `consumed-by` | N | 0.65 | −1 | N-N |\n| `consumed-by` | consumed by | `consumes` | N | 0.65 | −1 | N-N |\n| `delays` | delays | `delayed-by` | weak | 0.55 | −1 | N-N |\n| `delayed-by` | delayed by | `delays` | weak | 0.55 | −1 | N-N |\n\nCausal is the largest category in Nesso, because causation in the real world doesn't come in a single flavor. On the positive side, `causes` describes direct generation of an outcome, `triggers` describes the initiation of something that then plays out on its own (a spark triggers an explosion), and `enables` describes making something possible without forcing it. The negative side mirrors this: `prevents` is total blockage, `inhibits` is partial reduction, and `disables` is switching off a capacity or function. Intensity and mechanism live at the type level rather than as per-edge weights, so choosing between `inhibits` and `prevents` is a semantic decision about what is actually happening, not about how confident the author is.\n\n`consumes` and `delays` round out the category. `consumes` captures resource destruction, which is causal rather than dependency-flavored: it is distinct from `uses`, where the resource survives the interaction. `delays` carries negative polarity because slowing or postponing an outcome hinders it, even though nothing is destroyed.\n\n### Dependency\n\n_What does it need or serve?_\n\n| Type | Label | I | T | S | P | C |\n| ------------- | ----------- | ------------- | ---- | ---- | --- | --- |\n| `requires` | requires | `required-by` | Y | 0.85 | 0 | N-N |\n| `required-by` | required by | `requires` | Y | 0.85 | 0 | N-N |\n| `uses` | uses | `used-by` | weak | 0.50 | 0 | N-N |\n| `used-by` | used by | `uses` | weak | 0.50 | 0 | N-N |\n| `used-for` | used for | `purpose-of` | N | 0.55 | +1 | N-N |\n| `purpose-of` | purpose of | `used-for` | N | 0.55 | +1 | N-N |\n\nDependency relations capture what a concept _needs_ rather than what causes it. A car requires an engine to function, but the engine doesn't cause the car, and that difference shows up in how the graph traverses these edges. `requires` and `required-by` are the hard form, where the dependency is essential and transitivity is strict: if A requires B and B requires C, A also requires C. `uses` and `used-by` are softer, capturing a working relationship that doesn't necessarily imply the user can't survive without it, so transitivity decays through the chain. `used-for` and `purpose-of` are teleological: they point at the goal or function a thing serves (a hammer is used for driving nails). Cardinality there stays open at N-N, since one tool can serve many purposes and many tools can share a single purpose.\n\n### Temporal\n\n_When or where does it happen?_\n\n| Type | Label | I | T | S | P | C |\n| ---------------- | -------------- | ---------------- | --- | ---- | --- | --- |\n| `precedes` | precedes | `follows` | Y | 0.50 | 0 | N-N |\n| `follows` | follows | `precedes` | Y | 0.50 | 0 | N-N |\n| `occurs-in` | occurs in | `has-occurrence` | Y | 0.40 | 0 | N-1 |\n| `has-occurrence` | has occurrence | `occurs-in` | Y | 0.40 | 0 | 1-N |\n| `during` | during | `spans` | Y | 0.55 | 0 | N-1 |\n| `spans` | spans | `during` | Y | 0.55 | 0 | 1-N |\n| `overlaps-with` | overlaps with | self (symmetric) | N | 0.45 | 0 | N-N |\n| `derives-from` | derives from | `gives-rise-to` | Y | 0.70 | 0 | N-1 |\n| `gives-rise-to` | gives rise to | `derives-from` | Y | 0.70 | 0 | 1-N |\n\nTemporal relations describe when things happen relative to each other and how an event sits inside a larger period. Allen's interval algebra <a id=\"cite-6\" href=\"#ref-6\">[6]</a> inspires the containment pair: `during` and `spans` model intervals nested inside other intervals (the medieval period spans roughly a thousand years, and Charlemagne's reign was during it). `occurs-in` and its inverse work at a different scale, pinning a quasi-point event to the period it falls inside (the moon landing occurs in 1969). `precedes` and `follows` cover plain sequence without nesting, and `overlaps-with` is the symmetric case for two intervals that share a stretch of time without one containing the other.\n\n`derives-from` and `gives-rise-to` are not just about chronology, they capture genealogical descent: a transformative continuity where something becomes something else over time. Languages, species, and ideas all have lineages of this kind. The relation is close to `caused-by` but distinct, because causation is direct influence without requiring the cause to _become_ the effect. It is also distinct from taxonomic `subtype-of`, which is a snapshot of class membership rather than a historical claim. Italian derives from Latin, but Italian is not a subtype of Latin in the modern sense.\n\n### Opposition\n\n_What does it contrast with?_\n\n| Type | Label | I | T | S | P | C |\n| ---------------- | -------------- | ---------------- | --- | ---- | --- | --- |\n| `contrasts-with` | contrasts with | self (symmetric) | N | 0.50 | −1 | N-N |\n| `opposite-of` | opposite of | self (symmetric) | N | 0.80 | −1 | 1-1 |\n\nOpposition is the category for concepts that stand against each other. The two types differ in strength. `contrasts-with` is the weaker form, where two concepts highlight each other by sitting at different points on some dimension (warm contrasts with cool, North contrasts with South). `opposite-of` is the canonical, often binary opposite (alive is the opposite of dead, true is the opposite of false), and its cardinality is 1-1 because a canonical opposite is unique. Both are symmetric: if A is the opposite of B, then B is the opposite of A by definition.\n\n### Similarity\n\n_What is it like?_\n\n| Type | Label | I | T | S | P | C |\n| -------------- | ------------ | ---------------- | ---- | ---- | --- | --- |\n| `similar-to` | similar to | self (symmetric) | weak | 0.40 | +1 | N-N |\n| `analogous-to` | analogous to | self (symmetric) | N | 0.30 | +1 | N-N |\n\nThe similarity category includes two related but distinct relations. `similar-to` is the looser one, where two concepts share enough properties to be grouped together (lions are similar to tigers). `analogous-to` is more structural: the two concepts aren't necessarily alike in their properties, but their roles or relationships mirror each other (an electron orbiting an atom is analogous to a planet orbiting the sun). Both are symmetric, and both carry positive polarity because finding similarity or analogy is usually a constructive move in reasoning.\n\n### Epistemic\n\n_How do we know?_\n\n| Type | Label | I | T | S | P | C |\n| -------------- | ------------ | ---------------- | ---- | ---- | --- | --- |\n| `supports` | supports | `supported-by` | weak | 0.70 | +1 | N-N |\n| `supported-by` | supported by | `supports` | weak | 0.70 | +1 | N-N |\n| `contradicts` | contradicts | self (symmetric) | N | 0.75 | −1 | N-N |\n| `explains` | explains | `explained-by` | weak | 0.80 | 0 | N-N |\n| `explained-by` | explained by | `explains` | weak | 0.80 | 0 | N-N |\n| `defines` | defines | `defined-by` | N | 0.90 | 0 | 1-1 |\n| `defined-by` | defined by | `defines` | N | 0.90 | 0 | 1-1 |\n\nThe epistemic category is where Nesso models reasoning about claims rather than facts about the world. `supports` and `supported-by` connect a piece of evidence to the claim it bolsters; `explains` and `explained-by` connect an explanans (the explanatory account) to its explanandum (what is being explained). Both pairs are asymmetric, because evidence points to a claim and an explanation is not equivalent to what it explains.\n\n`defines` is the most rigid relation in this category. It goes from the defining expression (the _definiens_) to the term being defined (the _definiendum_): in \"F = ma defines force\", the equation is the definiens and `force` is the definiendum. Cardinality 1-1 enforces a single canonical definition per term, so two competing `defines` edges into the same concept signal a real ambiguity worth resolving.\n\n`contradicts` is the only symmetric relation in the category, because logical incompatibility goes both ways: if A contradicts B, then B equally contradicts A. This distinguishes it from `supports` and `explains`, which always point in a particular direction.\n\n## References\n\n1. <a id=\"ref-1\"></a>Sun, Z., Deng, Z.-H., Nie, J.-Y., and Tang, J. [_RotatE: Knowledge Graph Embedding by Relational Rotation in Complex Space_](https://arxiv.org/abs/1902.10197). ICLR, 2019. [↑](#cite-1)\n2. <a id=\"ref-2\"></a>Sussna, M. [_Word sense disambiguation for free-text indexing using a massive semantic network_](https://doi.org/10.1145/170088.170106). CIKM '93, 1993. [↑](#cite-2)\n3. <a id=\"ref-3\"></a>Jiang, J. J. and Conrath, D. W. [_Semantic similarity based on corpus statistics and lexical taxonomy_](https://arxiv.org/abs/cmp-lg/9709008). ROCLING X, 1997. [↑](#cite-3)\n4. <a id=\"ref-4\"></a>Cartwright, D. and Harary, F. [_Structural balance: A generalization of Heider's theory_](https://doi.org/10.1037/h0046049). Psychological Review, 63(5):277–293, 1956. [↑](#cite-4)\n5. <a id=\"ref-5\"></a>W3C. [_OWL 2 Web Ontology Language Primer (Second Edition)_](https://www.w3.org/TR/owl2-primer/). 2012. [↑](#cite-5)\n6. <a id=\"ref-6\"></a>Allen, J. F. [_Maintaining knowledge about temporal intervals_](https://doi.org/10.1145/182.358434). Communications of the ACM, 26(11):832–843, 1983. [↑](#cite-6)"
|
|
49
|
+
"markdown": "In Nesso, every edge carries a **semantic type**: a named relation describing how two concepts are connected, with type properties reserved for graph-analysis algorithms (future work, no algorithm currently consumes them). The vocabulary is fixed at 52 types across 8 categories, drawn from prior work in knowledge representation, lexical semantics, temporal logic, and signed-network theory.\n\n:::note[About this vocabulary]\nThese 52 relation types are one slice of `@nesso-how/vocab-learning`, which also defines node parameters (FSRS), display settings, and category palettes. Graph JSON files declare their vocabulary via `vocabulary.id` and `vocabulary.version`; the envelope format (`@nesso-how/schema`) is vocabulary-agnostic. The types and their property values are a considered first cut — both will evolve as real graphs accumulate and the analysis algorithms that consume them get built out.\n:::\n\n## Properties\n\nEach relation type declares the properties below. They define the contract that graph-analysis algorithms will consume; closing the enum guarantees every type comes with them, where a user-defined type would arrive without and stay analytically opaque.\n\n- **Transitive (T)**: `Y` (strict), `N` (none), or `weak` (transitivity with decay; algorithms may discount per step).\n- **Inverse (I)**: the canonical inverse type in the set; `self` for symmetric relations. Asymmetric relations declare it explicitly so traversal is first-class in both directions. The explicit-inverse design follows knowledge-graph embedding work <a id=\"cite-1\" href=\"#ref-1\">[1]</a>, which lists symmetry, antisymmetry, inversion, and composition as the four properties a good relation set should support.\n- **Strength (S)**: per-type semantic weight in `0..1`. Encodes how \"tight\" the relation is in general (e.g. `defines` 0.90 vs `similar-to` 0.40), not how sure the user is about a specific edge. The idea that different relation types carry different semantic distance comes from lexical-taxonomy weighting schemes <a id=\"cite-2\" href=\"#ref-2\">[2]</a>, <a id=\"cite-3\" href=\"#ref-3\">[3]</a>.\n- **Polarity (P)**: `+1` positive effect, `-1` antagonistic, `0` neutral/structural. From signed-network theory <a id=\"cite-4\" href=\"#ref-4\">[4]</a>: with polarity, the graph becomes a signed network where balance and cycle-sign analyses can apply.\n- **Cardinality (C)**: expected mapping pattern, always declared. One of `1-1`, `1-N`, `N-1`, `N-N` (no a-priori constraint). Setting this consistently lets algorithms flag structural anomalies (e.g. two competing `defines` edges into the same term).\n\n## Categories\n\nEach category answers a specific question about the relation. Grouping the types by question makes the vocabulary easier to navigate when authoring a graph, and lets graph-analysis algorithms compare and aggregate at category level instead of only per individual type.\n\n### Taxonomic\n\n_What kind of thing is it?_\n\n| Type | Label | I | T | S | P | C |\n| -------------- | ------------ | -------------- | --- | ---- | --- | --- |\n| `subtype-of` | subtype of | `has-subtype` | Y | 0.90 | 0 | N-1 |\n| `has-subtype` | has subtype | `subtype-of` | Y | 0.90 | 0 | 1-N |\n| `instance-of` | instance of | `has-instance` | N | 0.95 | 0 | N-1 |\n| `has-instance` | has instance | `instance-of` | N | 0.95 | 0 | 1-N |\n\nTaxonomic relations answer the simplest question you can ask about a concept: what kind of thing is it? Nesso splits the answer into two layers that look alike at a glance but behave very differently under reasoning. The class-vs-instance distinction mirrors OWL/RDFS <a id=\"cite-5\" href=\"#ref-5\">[5]</a>: `subtype-of` corresponds to `rdfs:subClassOf` (one class refines another, as a sparrow refines bird), while `instance-of` corresponds to `rdf:type` (an individual belongs to a class, as Tweety belongs to sparrow). Inheritance flows freely through the subtype chain, but instances are leaves: Tweety is a sparrow and through that a bird, yet Tweety is not itself \"a kind of\" anything.\n\n### Structural\n\n_What is it made of or composed from?_\n\n| Type | Label | I | T | S | P | C |\n| ---------- | -------- | ---------- | ---- | ---- | --- | --- |\n| `part-of` | part of | `contains` | Y | 0.85 | 0 | N-1 |\n| `contains` | contains | `part-of` | Y | 0.85 | 0 | 1-N |\n| `made-of` | made of | `composes` | weak | 0.75 | 0 | N-N |\n| `composes` | composes | `made-of` | weak | 0.75 | 0 | N-N |\n\nStructural relations describe how a thing decomposes into its parts. The category covers two patterns. `part-of` and its inverse `contains` capture discrete structural decomposition: an engine is part of a car, a paragraph is part of a chapter, and transitivity flows cleanly through the chain. `made-of` and `composes` capture material or substantive composition instead: water is made of hydrogen and oxygen, a chair is made of wood. Transitivity there is only weak, because what something is made of doesn't always propagate in a meaningful way (a chair made of wood, made of cellulose, made of carbon, made of atoms dilutes the relationship as the chain grows).\n\n### Causal\n\n_What does it do or prevent?_\n\n| Type | Label | I | T | S | P | C |\n| -------------- | ------------ | -------------- | ---- | ---- | --- | --- |\n| `causes` | causes | `caused-by` | N | 0.85 | +1 | N-N |\n| `caused-by` | caused by | `causes` | N | 0.85 | +1 | N-N |\n| `produces` | produces | `produced-by` | N | 0.70 | +1 | N-N |\n| `produced-by` | produced by | `produces` | N | 0.70 | +1 | N-N |\n| `enables` | enables | `enabled-by` | weak | 0.60 | +1 | N-N |\n| `enabled-by` | enabled by | `enables` | weak | 0.60 | +1 | N-N |\n| `prevents` | prevents | `prevented-by` | N | 0.85 | −1 | N-N |\n| `prevented-by` | prevented by | `prevents` | N | 0.85 | −1 | N-N |\n| `triggers` | triggers | `triggered-by` | N | 0.70 | +1 | N-N |\n| `triggered-by` | triggered by | `triggers` | N | 0.70 | +1 | N-N |\n| `inhibits` | inhibits | `inhibited-by` | N | 0.55 | −1 | N-N |\n| `inhibited-by` | inhibited by | `inhibits` | N | 0.55 | −1 | N-N |\n| `disables` | disables | `disabled-by` | weak | 0.60 | −1 | N-N |\n| `disabled-by` | disabled by | `disables` | weak | 0.60 | −1 | N-N |\n| `consumes` | consumes | `consumed-by` | N | 0.65 | −1 | N-N |\n| `consumed-by` | consumed by | `consumes` | N | 0.65 | −1 | N-N |\n| `delays` | delays | `delayed-by` | weak | 0.55 | −1 | N-N |\n| `delayed-by` | delayed by | `delays` | weak | 0.55 | −1 | N-N |\n\nCausal is the largest category in Nesso, because causation in the real world doesn't come in a single flavor. On the positive side, `causes` describes direct generation of an outcome, `triggers` describes the initiation of something that then plays out on its own (a spark triggers an explosion), and `enables` describes making something possible without forcing it. The negative side mirrors this: `prevents` is total blockage, `inhibits` is partial reduction, and `disables` is switching off a capacity or function. Intensity and mechanism live at the type level rather than as per-edge weights, so choosing between `inhibits` and `prevents` is a semantic decision about what is actually happening, not about how confident the author is.\n\n`consumes` and `delays` round out the category. `consumes` captures resource destruction, which is causal rather than dependency-flavored: it is distinct from `uses`, where the resource survives the interaction. `delays` carries negative polarity because slowing or postponing an outcome hinders it, even though nothing is destroyed.\n\n### Dependency\n\n_What does it need or serve?_\n\n| Type | Label | I | T | S | P | C |\n| ------------- | ----------- | ------------- | ---- | ---- | --- | --- |\n| `requires` | requires | `required-by` | Y | 0.85 | 0 | N-N |\n| `required-by` | required by | `requires` | Y | 0.85 | 0 | N-N |\n| `uses` | uses | `used-by` | weak | 0.50 | 0 | N-N |\n| `used-by` | used by | `uses` | weak | 0.50 | 0 | N-N |\n| `used-for` | used for | `purpose-of` | N | 0.55 | +1 | N-N |\n| `purpose-of` | purpose of | `used-for` | N | 0.55 | +1 | N-N |\n\nDependency relations capture what a concept _needs_ rather than what causes it. A car requires an engine to function, but the engine doesn't cause the car, and that difference shows up in how the graph traverses these edges. `requires` and `required-by` are the hard form, where the dependency is essential and transitivity is strict: if A requires B and B requires C, A also requires C. `uses` and `used-by` are softer, capturing a working relationship that doesn't necessarily imply the user can't survive without it, so transitivity decays through the chain. `used-for` and `purpose-of` are teleological: they point at the goal or function a thing serves (a hammer is used for driving nails). Cardinality there stays open at N-N, since one tool can serve many purposes and many tools can share a single purpose.\n\n### Temporal\n\n_When or where does it happen?_\n\n| Type | Label | I | T | S | P | C |\n| ---------------- | -------------- | ---------------- | --- | ---- | --- | --- |\n| `precedes` | precedes | `follows` | Y | 0.50 | 0 | N-N |\n| `follows` | follows | `precedes` | Y | 0.50 | 0 | N-N |\n| `occurs-in` | occurs in | `has-occurrence` | Y | 0.40 | 0 | N-1 |\n| `has-occurrence` | has occurrence | `occurs-in` | Y | 0.40 | 0 | 1-N |\n| `during` | during | `spans` | Y | 0.55 | 0 | N-1 |\n| `spans` | spans | `during` | Y | 0.55 | 0 | 1-N |\n| `overlaps-with` | overlaps with | self (symmetric) | N | 0.45 | 0 | N-N |\n| `derives-from` | derives from | `gives-rise-to` | Y | 0.70 | 0 | N-1 |\n| `gives-rise-to` | gives rise to | `derives-from` | Y | 0.70 | 0 | 1-N |\n\nTemporal relations describe when things happen relative to each other and how an event sits inside a larger period. Allen's interval algebra <a id=\"cite-6\" href=\"#ref-6\">[6]</a> inspires the containment pair: `during` and `spans` model intervals nested inside other intervals (the medieval period spans roughly a thousand years, and Charlemagne's reign was during it). `occurs-in` and its inverse work at a different scale, pinning a quasi-point event to the period it falls inside (the moon landing occurs in 1969). `precedes` and `follows` cover plain sequence without nesting, and `overlaps-with` is the symmetric case for two intervals that share a stretch of time without one containing the other.\n\n`derives-from` and `gives-rise-to` are not just about chronology, they capture genealogical descent: a transformative continuity where something becomes something else over time. Languages, species, and ideas all have lineages of this kind. The relation is close to `caused-by` but distinct, because causation is direct influence without requiring the cause to _become_ the effect. It is also distinct from taxonomic `subtype-of`, which is a snapshot of class membership rather than a historical claim. Italian derives from Latin, but Italian is not a subtype of Latin in the modern sense.\n\n### Opposition\n\n_What does it contrast with?_\n\n| Type | Label | I | T | S | P | C |\n| ---------------- | -------------- | ---------------- | --- | ---- | --- | --- |\n| `contrasts-with` | contrasts with | self (symmetric) | N | 0.50 | −1 | N-N |\n| `opposite-of` | opposite of | self (symmetric) | N | 0.80 | −1 | 1-1 |\n\nOpposition is the category for concepts that stand against each other. The two types differ in strength. `contrasts-with` is the weaker form, where two concepts highlight each other by sitting at different points on some dimension (warm contrasts with cool, North contrasts with South). `opposite-of` is the canonical, often binary opposite (alive is the opposite of dead, true is the opposite of false), and its cardinality is 1-1 because a canonical opposite is unique. Both are symmetric: if A is the opposite of B, then B is the opposite of A by definition.\n\n### Similarity\n\n_What is it like?_\n\n| Type | Label | I | T | S | P | C |\n| -------------- | ------------ | ---------------- | ---- | ---- | --- | --- |\n| `similar-to` | similar to | self (symmetric) | weak | 0.40 | +1 | N-N |\n| `analogous-to` | analogous to | self (symmetric) | N | 0.30 | +1 | N-N |\n\nThe similarity category includes two related but distinct relations. `similar-to` is the looser one, where two concepts share enough properties to be grouped together (lions are similar to tigers). `analogous-to` is more structural: the two concepts aren't necessarily alike in their properties, but their roles or relationships mirror each other (an electron orbiting an atom is analogous to a planet orbiting the sun). Both are symmetric, and both carry positive polarity because finding similarity or analogy is usually a constructive move in reasoning.\n\n### Epistemic\n\n_How do we know?_\n\n| Type | Label | I | T | S | P | C |\n| -------------- | ------------ | ---------------- | ---- | ---- | --- | --- |\n| `supports` | supports | `supported-by` | weak | 0.70 | +1 | N-N |\n| `supported-by` | supported by | `supports` | weak | 0.70 | +1 | N-N |\n| `contradicts` | contradicts | self (symmetric) | N | 0.75 | −1 | N-N |\n| `explains` | explains | `explained-by` | weak | 0.80 | 0 | N-N |\n| `explained-by` | explained by | `explains` | weak | 0.80 | 0 | N-N |\n| `defines` | defines | `defined-by` | N | 0.90 | 0 | 1-1 |\n| `defined-by` | defined by | `defines` | N | 0.90 | 0 | 1-1 |\n\nThe epistemic category is where Nesso models reasoning about claims rather than facts about the world. `supports` and `supported-by` connect a piece of evidence to the claim it bolsters; `explains` and `explained-by` connect an explanans (the explanatory account) to its explanandum (what is being explained). Both pairs are asymmetric, because evidence points to a claim and an explanation is not equivalent to what it explains.\n\n`defines` is the most rigid relation in this category. It goes from the defining expression (the _definiens_) to the term being defined (the _definiendum_): in \"F = ma defines force\", the equation is the definiens and `force` is the definiendum. Cardinality 1-1 enforces a single canonical definition per term, so two competing `defines` edges into the same concept signal a real ambiguity worth resolving.\n\n`contradicts` is the only symmetric relation in the category, because logical incompatibility goes both ways: if A contradicts B, then B equally contradicts A. This distinguishes it from `supports` and `explains`, which always point in a particular direction.\n\n## References\n\n1. <a id=\"ref-1\"></a>Sun, Z., Deng, Z.-H., Nie, J.-Y., and Tang, J. [_RotatE: Knowledge Graph Embedding by Relational Rotation in Complex Space_](https://arxiv.org/abs/1902.10197). ICLR, 2019. [↑](#cite-1)\n2. <a id=\"ref-2\"></a>Sussna, M. [_Word sense disambiguation for free-text indexing using a massive semantic network_](https://doi.org/10.1145/170088.170106). CIKM '93, 1993. [↑](#cite-2)\n3. <a id=\"ref-3\"></a>Jiang, J. J. and Conrath, D. W. [_Semantic similarity based on corpus statistics and lexical taxonomy_](https://arxiv.org/abs/cmp-lg/9709008). ROCLING X, 1997. [↑](#cite-3)\n4. <a id=\"ref-4\"></a>Cartwright, D. and Harary, F. [_Structural balance: A generalization of Heider's theory_](https://doi.org/10.1037/h0046049). Psychological Review, 63(5):277–293, 1956. [↑](#cite-4)\n5. <a id=\"ref-5\"></a>W3C. [_OWL 2 Web Ontology Language Primer (Second Edition)_](https://www.w3.org/TR/owl2-primer/). 2012. [↑](#cite-5)\n6. <a id=\"ref-6\"></a>Allen, J. F. [_Maintaining knowledge about temporal intervals_](https://doi.org/10.1145/182.358434). Communications of the ACM, 26(11):832–843, 1983. [↑](#cite-6)"
|
|
50
50
|
}
|
|
51
51
|
]
|
|
52
52
|
}
|
|
@@ -1,16 +1,15 @@
|
|
|
1
1
|
import * as z from 'zod/v4';
|
|
2
|
-
import { RELATION_TYPES,
|
|
2
|
+
import { RELATION_TYPES, RELATION_CATEGORIES } from '@nesso-how/vocab-learning';
|
|
3
3
|
export function registerGetRelationTypes(server) {
|
|
4
4
|
server.registerTool('get_relation_types', {
|
|
5
5
|
description: 'Returns all 52 semantic relation types supported by Nesso, grouped by 8 categories. ' +
|
|
6
|
-
'Each type carries
|
|
6
|
+
'Each type carries type properties (transitive, inverse, strength, polarity, cardinality) ' +
|
|
7
7
|
'in addition to its visual encoding. ' +
|
|
8
8
|
'Use this when you need valid relation type names for graph JSON or explanations for the user.',
|
|
9
9
|
inputSchema: z.object({}),
|
|
10
10
|
}, async () => {
|
|
11
|
-
const result =
|
|
12
|
-
category:
|
|
13
|
-
question: catDef.subtitle,
|
|
11
|
+
const result = RELATION_CATEGORIES.map((cat) => ({
|
|
12
|
+
category: cat,
|
|
14
13
|
types: Object.entries(RELATION_TYPES)
|
|
15
14
|
.filter(([, def]) => def.cat === cat)
|
|
16
15
|
.map(([name, def]) => ({
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@nesso-how/mcp",
|
|
3
|
-
"version": "0.1.0-alpha.
|
|
3
|
+
"version": "0.1.0-alpha.35",
|
|
4
4
|
"description": "MCP server exposing Nesso knowledge graph tools to LLM clients",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"repository": {
|
|
@@ -22,7 +22,7 @@
|
|
|
22
22
|
"dependencies": {
|
|
23
23
|
"zod": "^4.4.3",
|
|
24
24
|
"@modelcontextprotocol/server": "^2.0.0-alpha.2",
|
|
25
|
-
"@nesso-how/vocab-learning": "0.1.0-alpha.
|
|
25
|
+
"@nesso-how/vocab-learning": "0.1.0-alpha.35"
|
|
26
26
|
},
|
|
27
27
|
"devDependencies": {
|
|
28
28
|
"@types/node": "^22.0.0",
|