A
licenseNot graded
qualityD
maintenanceEnables AI assistants to interact with Neo4j graph databases through natural language, supporting Cypher queries, schema management, data manipulation, and graph algorithms.
MIT
toro4n
by com.toro4n
Server Details
Draw, shape, and edit Neo4j graph data models in toro4n with your AI assistant.
Ownership verified
- Status
- Healthy
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
A4.2/5.0
Scored across 7 tools
Disambiguation5/5
Each tool targets a distinct verb+resource pair: create/edit/get/list/restore applied to models, versions, or the guide. The only adjacent pair, list_versions and restore_version, is clearly separated by action (read vs. write). No tool can plausibly be mistaken for another.
Naming Consistency5/5
All seven tools follow a strict snake_case verb_noun pattern (create_model, edit_model, get_model, list_models, list_versions, restore_version, get_modeling_guide). Singular/plural is used meaningfully (get_model vs list_models). No deviations.
Tool Count5/5
Seven tools is a tight, well-scoped surface for a graph-schema modeling server: create, read, edit, list, version history, restore, and the prerequisite guide. Nothing feels padded or missing at the count level.
Completeness3/5
Core modeling lifecycle (create, get, edit, list) plus versioning is covered, but there is no delete_model, so an agent cannot remove a model it created. Folders and sharing/permission management are surfaced in list_models output yet have no corresponding tools, leaving real dead ends.
Available Tools
7 toolscreate_modelCreate a modelAInspect
Creates a new graph data model in the user's toro4n account from nodes, relationships, and notes, lays it out automatically, and returns a link that opens it. Give each node a ref of your choice and use it in relationships and notes. Each model describes a Neo4j schema, not instance data. It holds nodes such as (:Customer), (:Order), or (:Router:Egress), and the relationships between them, such as (:Customer)-[:PLACED]->(:Order). No two nodes can have the same set of labels. Every relationship has a direction. Follow Neo4j's naming conventions: PascalCase for node labels, UPPER_SNAKE_CASE for relationship types, and camelCase for property keys. toro4n converts new names to these conventions. Labels and property keys keep runs of capitals, as in USB and IPAddress. Spaces, underscores, and hyphens always stay as written. Editing a node or relationship leaves its existing names unchanged. Each property has a key and can also have a property type, an example value, and uniqueness and existence constraints. On a node, the first property's example is shown as its caption, so put the most descriptive property first. Leave examples out unless you have realistic values. Read get_modeling_guide first and pass its guideCode. Always share the link with the user.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The model's name. | |
| nodes | Yes | ||
| notes | No | ||
| guideCode | No | The guideCode that get_modeling_guide returns. Required: call get_modeling_guide and read the guide before you create or edit a model. | |
| relationships | No |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-read-only, non-destructive, non-idempotent write, and the description layers on substantive behavior beyond them: the model is a schema not data, layout is automatic, a link is returned, new names are normalized to Neo4j conventions while explicitly edited names are left unchanged, duplicate label sets are rejected, and every relationship is directional. Those normalization and rejection rules are exactly the surprises an agent would otherwise hit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action, its return value, and the guide prerequisite are front-loaded, and most later sentences carry operational rules an agent needs. It is long, though, and the naming-convention and caption guidance reads like reference documentation that could be trimmed or moved to the guide it already mandates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter, deeply nested mutation with no output schema, the definition covers the important unknowns: what the return value is, the mandatory guide step, naming normalization, label-set uniqueness, caption ordering, and when to omit examples. Remaining gaps are minor, such as what happens on validation failure or whether repeated calls accumulate models.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description has to compensate, and it does contribute real meaning: refs are self-chosen handles reused in relationships and notes, properties are in display order and the first node property's example becomes the caption, and examples should be omitted unless realistic. The naming-convention rules (PascalCase labels, UPPER_SNAKE_CASE types, camelCase keys, preserved capital runs) explain how input values are transformed, which no schema field communicates.
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?
The opening sentence names a specific verb and resource ('Creates a new graph data model'), states its inputs (nodes, relationships, notes), notes it auto-lays-out the model, and says it returns a shareable link. It also states what the model represents (a Neo4j schema, not instance data), which cleanly separates it from edit_model/get_model without ambiguity.
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?
It gives explicit prerequisites and post-conditions: 'Read get_modeling_guide first and pass its guideCode' and 'Always share the link with the user.' What it does not do is explicitly route between create_model and edit_model (e.g. 'use edit_model to change an existing model'), so an agent must infer the create-vs-edit choice from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edit_modelEdit a modelADestructiveInspect
Edits an existing model with a list of changes, applied in order and all or nothing: add, update, or remove nodes, relationships, properties, and notes; rename or remove layers; or rename the model. Removing a node also removes its relationships. Removing a layer deletes its nodes and relationships, or moves them to the layer named in moveContentsTo; nodes that also belong to another layer stay there. Refer to existing items by their ids from get_model, and give new items a ref so that later changes in the same list can refer to them. New nodes are placed next to the nodes they connect to; set arrange to true to lay out the whole model again. Before your changes are applied, the model is saved as a version, so restore_version can undo them. Anyone who has the model open sees the changes right away, so when you're reviewing a model, propose your changes and make them only after the user agrees. Pass the guideCode from get_modeling_guide. Each model describes a Neo4j schema, not instance data. It holds nodes such as (:Customer), (:Order), or (:Router:Egress), and the relationships between them, such as (:Customer)-[:PLACED]->(:Order). No two nodes can have the same set of labels. Every relationship has a direction. Follow Neo4j's naming conventions: PascalCase for node labels, UPPER_SNAKE_CASE for relationship types, and camelCase for property keys. toro4n converts new names to these conventions. Labels and property keys keep runs of capitals, as in USB and IPAddress. Spaces, underscores, and hyphens always stay as written. Editing a node or relationship leaves its existing names unchanged. Each property has a key and can also have a property type, an example value, and uniqueness and existence constraints. On a node, the first property's example is shown as its caption, so put the most descriptive property first. Leave examples out unless you have realistic values.
| Name | Required | Description | Default |
|---|---|---|---|
| arrange | No | Set to true to lay out the whole model again, the way the Arrange button does: as few crossing relationships as possible, with nodes, relationship types, and notes spaced so that nothing overlaps. | |
| changes | Yes | ||
| modelId | Yes | The model's id, from list_models or from a model link. | |
| guideCode | No | The guideCode that get_modeling_guide returns. Required: call get_modeling_guide and read the guide before you create or edit a model. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive/non-idempotent, but the description adds what they cannot: changes are all-or-nothing and applied in order, deletions cascade (removing a node removes its relationships; removing a layer deletes its contents unless moveContentsTo is set, and shared nodes stay in their other layer), a version is saved before application, and other users see changes live. That is exactly the mutation-risk context an agent needs before calling a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well front-loaded: the operation and its atomicity come first, then id/ref semantics, undo, and collaboration, then domain context. It is long for a description, and the Neo4j naming-convention and schema-explainer sentences partly duplicate what get_modeling_guide is explicitly said to contain, so a few sentences don't fully earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 change variants and cascading deletes, the description covers atomicity, ordering, id/ref resolution, cascades, undo via versioning, and concurrency visibility. The main gap is that it never says what the call returns (e.g. ids of newly created nodes) and there is no output schema to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema coverage the schema already documents most fields, yet the description adds cross-parameter meaning the schema cannot express: a ref makes an item addressable by later changes in the same list, order of changes matters, arrange re-lays out the entire model, and the first node property becomes the caption so the most descriptive property should go first. Naming-convention rules (PascalCase/UPPER_SNAKE_CASE/camelCase, toro4n conversion) also guide value formatting beyond the schema's maxLength bounds.
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 ("Edits an existing model") and then enumerates exactly what the change list can do: add, update, or remove nodes, relationships, properties, and notes; rename or remove layers; rename the model. "Existing" cleanly separates it from the create_model sibling, and an agent can pick between them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit prerequisites and alternatives: pass guideCode from get_modeling_guide, refer to existing items by ids from get_model, use restore_version to undo, and proposes a review workflow ("propose your changes and make them only after the user agrees"). It also states when not to apply changes unilaterally, which is a genuine usage constraint rather than a restatement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_modelGet a modelARead-onlyIdempotentInspect
Returns a model's layers, nodes (id, labels, properties, layers, color), relationships (id, from, to, type, properties), and notes. Use these ids with edit_model.
| Name | Required | Description | Default |
|---|---|---|---|
| modelId | Yes | The model's id, from list_models or from a model link. |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds the useful behavioral detail that the tool returns a full graph payload (nodes, relationships, notes) rather than a summary, which is exactly the kind of context annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the returned payload and ending with the practical next step. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values and does so by enumerating node and relationship fields. Minor gap: nothing about behavior for very large models (truncation, pagination) or errors for invalid modelId.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the modelId parameter already documents itself as coming from list_models or a model link. The description adds nothing about the parameter, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('Returns') plus the resource ('a model') and enumerates the returned sub-structures (layers, nodes, relationships, notes) with their fields, which is far more informative than the title. It does not explicitly contrast itself with list_models, so an agent must infer that list_models is the summary view and get_model the detailed one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use these ids with edit_model' gives a downstream workflow pointer, which implies the read-then-edit pattern. But there is no guidance on when to call get_model instead of list_models, and no statement that edit_model should not be called before fetching ids.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_modeling_guideRead the modeling guideARead-onlyIdempotentInspect
Returns toro4n's guide to Neo4j graph data modeling: how to work with the user, how toro4n holds a model, naming, and when to use a node, a property, a label, a relationship, or an intermediate node. Read it before you design a model or review one. create_model and edit_model require the guideCode it returns.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds real value beyond them by disclosing the coupling contract: the returned guideCode is a required input for create_model and edit_model, which changes call sequencing. It stops short of describing the guide's size or format, which is why this is a 4 rather than a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the return value, then the reading trigger, then the downstream dependency. Every sentence carries distinct operational information — the guide's contents, the timing rule, and the guideCode contract — with no restatement of the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must describe the return value, and it does: the modeling guide plus a guideCode. It also frames the guide's topical sections, which is enough for a zero-parameter documentation tool. An agent knows what it will get, why it needs it, and what to do with the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so there are no parameters whose meaning could be clarified or obscured; the baseline for a no-parameter tool applies. The description correctly says nothing about inputs, which is consistent and avoids confusing an agent into hunting for optional filters.
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 ('Returns') and resource ('toro4n's guide to Neo4j graph data modeling'), then enumerates the guide's coverage: working with the user, holding a model, naming, and node/property/label/relationship/intermediate-node decisions. That level of enumeration lets an agent distinguish this documentation tool from every sibling (create_model, get_model, list_models, etc.) without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: 'Read it before you design a model or review one.' It also names the downstream dependency — create_model and edit_model require the guideCode this returns — which is effectively a prerequisite ordering rule, not just a suggestion. Nothing is left to inference about when this tool is the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_modelsList modelsARead-onlyIdempotentInspect
Lists the toro4n models the user has online, including models shared with them. For each model: its id, name, node count, the user's access (owner, editor, or viewer), the owner, the user's folder (if any), when it was last updated, and a link that opens it. An invited editor is listed as a viewer when the model already has as many editors as toro4n allows, or when the model is view-only because its owner is on the Free plan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real behavioral value beyond that: the access-level downgrade rule (an invited editor appears as viewer when the editor cap is hit or the owner is on the Free plan) prevents an agent from misreporting permissions, and the enumerated return fields describe what a call yields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose before the field enumeration and the access caveat. The field list is long but functional since there is no output schema; the only minor slack is that the access-downgrade sentence is dense enough to require a second read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description carries the burden of explaining results, and it does so by naming every returned field plus the access-level caveat. It omits ordering/pagination or result-count behavior, which is the main remaining gap for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description correctly offers no parameter guidance and instead spends its words on output semantics, which is the right allocation here.
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 ('Lists the toro4n models') plus scope ('the user has online, including models shared with them'). That scope cleanly separates it from get_model (single model) and list_versions (version history) without needing to open a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Scope is implied by 'models the user has online, including models shared with them', which tells the agent this is a per-user inventory rather than a global listing. However, it never names an alternative or states when to prefer get_model or list_versions, so the routing decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_versionsList earlier versionsARead-onlyIdempotentInspect
Lists a model's saved versions, newest first, with each version's number, when it was saved, and who made the changes. A version is saved before every change you make. If the model's owner is on the Free plan, only versions from the last 7 days are listed.
| Name | Required | Description | Default |
|---|---|---|---|
| modelId | Yes | The model's id, from list_models or from a model link. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value on top: result ordering, the fields returned per version, the save-before-every-change lifecycle, and a Free-plan 7-day retention limit. It doesn't mention pagination or result caps, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action, then the lifecycle note, then the plan caveat. Every sentence carries distinct information with no repetition of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately names the returned fields and ordering, and it flags the plan-based retention limit. The only gap is not saying whether results are paginated or capped, which matters for a history-listing tool.
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?
Only one parameter with 100% schema coverage, where the schema already says the id comes from list_models or a model link. The description adds no further semantics about modelId, so the baseline 3 applies.
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 ('Lists a model's saved versions') plus ordering ('newest first') and the fields returned, which cleanly separates it from get_model and restore_version. An agent can identify the tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the 'version is saved before every change' line, suggesting this is for reviewing history before a restore, but no explicit when-to-use vs get_model/list_models or when-not (e.g., to fetch current content use get_model) is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
restore_versionRestore an earlier versionADestructiveInspect
Restores the model to an earlier version, keeping its current name. To undo a change, restore the version saved just before it, as listed by list_versions.
| Name | Required | Description | Default |
|---|---|---|---|
| modelId | Yes | The model's id, from list_models or from a model link. | |
| version | Yes | The version number from list_versions. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral detail beyond annotations: the model keeps its current name after restoration, which an agent would otherwise have to guess. It does not spell out whether the overwritten state is retained as a new version, but the destructive hint already signals risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the core action and then the undo recipe. Every clause carries useful information with no repetition of the schema or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with annotations covering the destructive nature and no output schema, the description is nearly complete: it names the action, the name-retention behavior, and how to pick the right version. A slight gap is that it does not clarify whether the pre-restore state is preserved as a new version.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both modelId and version are documented in the schema, including that version comes from list_versions. The description's mention of list_versions reinforces the schema but does not add syntax or meaning beyond it, so the baseline of 3 is appropriate.
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?
The description uses the specific verb 'restores' with the resource 'the model' and target 'an earlier version,' and adds the non-obvious qualifier 'keeping its current name.' It also names list_versions as the source of the version number, clearly distinguishing this tool from edit_model or create_model.
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?
It gives explicit operational guidance for undoing a change: restore the version saved just before it, as listed by list_versions. This tells the agent both the scenario and the prerequisite source of the version number, though it does not explicitly state when not to use this tool versus edit_model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
create_model2 fields changed- added
Input schema / properties / nodes / items / properties / properties / items / properties / partOfKeyAdded value: +{ + "description": "Set to true on every property that together identifies the node or relationship, such as orderId and lineNo on an order line. toro4n exports one key constraint over all of them, REQUIRE (n.orderId, n.lineNo) IS NODE KEY (IS RELATIONSHIP KEY on a relationship): each must be present and the combination unique. Needs Neo4j Enterprise Edition or Aura. An element has one key.", + "type": "boolean" +} - added
Input schema / properties / relationships / items / properties / properties / items / properties / partOfKeyAdded value: +{ + "description": "Set to true on every property that together identifies the node or relationship, such as orderId and lineNo on an order line. toro4n exports one key constraint over all of them, REQUIRE (n.orderId, n.lineNo) IS NODE KEY (IS RELATIONSHIP KEY on a relationship): each must be present and the combination unique. Needs Neo4j Enterprise Edition or Aura. An element has one key.", + "type": "boolean" +}
- Changed
edit_model1 field changed- changed
Input schema / properties / changes / items / oneOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "action": { - "const": "add_node", - "type": "string" - }, - "color": { - "description": "Fill color as a hex code, such as #0a84ff. Omit it to use the model style.", - "maxLength": 40, - "type": "string" - }, - "labels": { - "description": "Node labels, such as [\"Customer\"] or [\"Router\", \"Egress\"]. No two nodes can have the same set of labels.", - "items": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "maxItems": 20, - "type": "array" - }, - "layers": { - "description": "Names of the layers the node belongs to. Any layer that doesn't exist yet is created.", - "items": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "properties": { - "description": "Properties in display order. On a node, the first property's example is shown as its caption.", - "items": { - "additionalProperties": false, - "properties": { - "example": { - "description": "An example value.", - "maxLength": 20000, - "type": "string" - }, - "key": { - "description": "Property key in camelCase, such as orderId. For an existing property, use the key exactly as get_model spells it.", - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "required": { - "description": "Set to true to add a property existence constraint (IS NOT NULL), which needs Neo4j Enterprise Edition or Aura.", - "type": "boolean" - }, - "type": { - "description": "The Neo4j property type, one of: STRING, INTEGER, FLOAT, BOOLEAN, DATE, ZONED DATETIME, LOCAL DATETIME, LIST<STRING>, POINT, DURATION, LIST<BOOLEAN>, LIST<DATE>, LIST<DURATION>, LIST<FLOAT>, LIST<INTEGER>, LIST<LOCAL DATETIME>, LIST<LOCAL TIME>, LIST<POINT>, LIST<UUID>, LIST<ZONED DATETIME>, LIST<ZONED TIME>, LOCAL TIME, UUID, VECTOR, ZONED TIME. Omit it if unknown.", - "maxLength": 100, - "type": "string" - }, - "unique": { - "description": "Set to true to add a property uniqueness constraint (IS UNIQUE).", - "type": "boolean" - } - }, - "required": [ - "key" - ], - "type": "object" - }, - "maxItems": 500, - "type": "array" - }, - "ref": { - "description": "A short name of your choosing, used to refer to the node later in this list.", - "maxLength": 100, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "labels" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "update_node", - "type": "string" - }, - "color": { - "anyOf": [ - { - "description": "Fill color as a hex code, such as #0a84ff.", - "maxLength": 40, - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Fill color as a hex code, or null to use the model style." - }, - "labels": { - "description": "Node labels, such as [\"Customer\"] or [\"Router\", \"Egress\"]. No two nodes can have the same set of labels.", - "items": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "maxItems": 20, - "type": "array" - }, - "layers": { - "description": "Names of the layers the node belongs to. Any layer that doesn't exist yet is created.", - "items": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "node": { - "description": "The node's id, or the ref of a node added earlier in this list.", - "maxLength": 100, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "node" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "remove_node", - "type": "string" - }, - "node": { - "description": "The node's id, or the ref of a node added earlier in this list.", - "maxLength": 100, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "node" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "add_relationship", - "type": "string" - }, - "from": { - "description": "The node's id, or the ref of a node added earlier in this list.", - "maxLength": 100, - "minLength": 1, - "type": "string" - }, - "properties": { - "description": "Properties in display order. On a node, the first property's example is shown as its caption.", - "items": { - "additionalProperties": false, - "properties": { - "example": { - "description": "An example value.", - "maxLength": 20000, - "type": "string" - }, - "key": { - "description": "Property key in camelCase, such as orderId. For an existing property, use the key exactly as get_model spells it.", - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "required": { - "description": "Set to true to add a property existence constraint (IS NOT NULL), which needs Neo4j Enterprise Edition or Aura.", - "type": "boolean" - }, - "type": { - "description": "The Neo4j property type, one of: STRING, INTEGER, FLOAT, BOOLEAN, DATE, ZONED DATETIME, LOCAL DATETIME, LIST<STRING>, POINT, DURATION, LIST<BOOLEAN>, LIST<DATE>, LIST<DURATION>, LIST<FLOAT>, LIST<INTEGER>, LIST<LOCAL DATETIME>, LIST<LOCAL TIME>, LIST<POINT>, LIST<UUID>, LIST<ZONED DATETIME>, LIST<ZONED TIME>, LOCAL TIME, UUID, VECTOR, ZONED TIME. Omit it if unknown.", - "maxLength": 100, - "type": "string" - }, - "unique": { - "description": "Set to true to add a property uniqueness constraint (IS UNIQUE).", - "type": "boolean" - } - }, - "required": [ - "key" - ], - "type": "object" - }, - "maxItems": 500, - "type": "array" - }, - "ref": { - "maxLength": 100, - "minLength": 1, - "type": "string" - }, - "to": { - "description": "The node's id, or the ref of a node added earlier in this list.", - "maxLength": 100, - "minLength": 1, - "type": "string" - }, - "type": { - "maxLength": 200, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "from", - "to", - "type" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "update_relationship", - "type": "string" - }, - "from": { - "description": "The node's id, or the ref of a node added earlier in this list.", - "maxLength": 100, - "minLength": 1, - "type": "string" - }, - "relationship": { - "description": "The relationship's id, or the ref of a relationship added earlier in this list.", - "maxLength": 100, - "minLength": 1, - "type": "string" - }, - "to": { - "description": "The node's id, or the ref of a node added earlier in this list.", - "maxLength": 100, - "minLength": 1, - "type": "string" - }, - "type": { - "maxLength": 200, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "relationship" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "remove_relationship", - "type": "string" - }, - "relationship": { - "description": "The relationship's id, or the ref of a relationship added earlier in this list.", - "maxLength": 100, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "relationship" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "set_property", - "type": "string" - }, - "example": { - "description": "An example value, or \"\" to clear it.", - "maxLength": 20000, - "type": "string" - }, - "key": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "on": { - "description": "The id or ref of the node or relationship the property belongs to.", - "maxLength": 100, - "minLength": 1, - "type": "string" - }, - "position": { - "description": "Move the property to the top or the bottom of the list. On a node, the top property's example is shown as its caption.", - "enum": [ - "first", - "last" - ], - "type": "string" - }, - "required": { - "type": "boolean" - }, - "type": { - "description": "A property type, or \"\" to clear it.", - "maxLength": 100, - "type": "string" - }, - "unique": { - "type": "boolean" - } - }, - "required": [ - "action", - "on", - "key" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "rename_property", - "type": "string" - }, - "key": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "newKey": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "on": { - "description": "The id or ref of the node or relationship the property belongs to.", - "maxLength": 100, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "on", - "key", - "newKey" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "remove_property", - "type": "string" - }, - "key": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "on": { - "description": "The id or ref of the node or relationship the property belongs to.", - "maxLength": 100, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "on", - "key" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "add_note", - "type": "string" - }, - "attachTo": { - "items": { - "maxLength": 100, - "minLength": 1, - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "color": { - "description": "Fill color as a hex code, such as #0a84ff. Omit it for a white note.", - "maxLength": 40, - "type": "string" - }, - "ref": { - "maxLength": 100, - "minLength": 1, - "type": "string" - }, - "text": { - "maxLength": 20000, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "text" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "update_note", - "type": "string" - }, - "attachTo": { - "description": "Ids or refs of the nodes and relationships to attach the note to, replacing its current attachments. Use [] to detach it from all of them.", - "items": { - "maxLength": 100, - "minLength": 1, - "type": "string" - }, - "maxItems": 50, - "type": "array" - }, - "color": { - "description": "Fill color as a hex code, such as #0a84ff.", - "maxLength": 40, - "type": "string" - }, - "note": { - "description": "The note's id, or the ref of a note added earlier in this list.", - "maxLength": 100, - "minLength": 1, - "type": "string" - }, - "text": { - "maxLength": 20000, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "note" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "remove_note", - "type": "string" - }, - "note": { - "maxLength": 100, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "note" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "remove_layer", - "type": "string" - }, - "layer": { - "description": "The layer's name, as listed by get_model.", - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "moveContentsTo": { - "description": "The name of the layer to move this layer's nodes and relationships to. Omit it to delete them instead. Nodes that also belong to another layer stay in that layer.", - "maxLength": 200, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "layer" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "rename_layer", - "type": "string" - }, - "layer": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "name": { - "maxLength": 200, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "layer", - "name" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "rename_model", - "type": "string" - }, - "name": { - "maxLength": 200, - "minLength": 1, - "type": "string" - } - }, - "required": [ - "action", - "name" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "action": { + "const": "add_node", + "type": "string" + }, + "color": { + "description": "Fill color as a hex code, such as #0a84ff. Omit it to use the model style.", + "maxLength": 40, + "type": "string" + }, + "labels": { + "description": "Node labels, such as [\"Customer\"] or [\"Router\", \"Egress\"]. No two nodes can have the same set of labels.", + "items": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "layers": { + "description": "Names of the layers the node belongs to. Any layer that doesn't exist yet is created.", + "items": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "properties": { + "description": "Properties in display order. On a node, the first property's example is shown as its caption.", + "items": { + "additionalProperties": false, + "properties": { + "example": { + "description": "An example value.", + "maxLength": 20000, + "type": "string" + }, + "key": { + "description": "Property key in camelCase, such as orderId. For an existing property, use the key exactly as get_model spells it.", + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "partOfKey": { + "description": "Set to true on every property that together identifies the node or relationship, such as orderId and lineNo on an order line. toro4n exports one key constraint over all of them, REQUIRE (n.orderId, n.lineNo) IS NODE KEY (IS RELATIONSHIP KEY on a relationship): each must be present and the combination unique. Needs Neo4j Enterprise Edition or Aura. An element has one key.", + "type": "boolean" + }, + "required": { + "description": "Set to true to add a property existence constraint (IS NOT NULL), which needs Neo4j Enterprise Edition or Aura.", + "type": "boolean" + }, + "type": { + "description": "The Neo4j property type, one of: STRING, INTEGER, FLOAT, BOOLEAN, DATE, ZONED DATETIME, LOCAL DATETIME, LIST<STRING>, POINT, DURATION, LIST<BOOLEAN>, LIST<DATE>, LIST<DURATION>, LIST<FLOAT>, LIST<INTEGER>, LIST<LOCAL DATETIME>, LIST<LOCAL TIME>, LIST<POINT>, LIST<UUID>, LIST<ZONED DATETIME>, LIST<ZONED TIME>, LOCAL TIME, UUID, VECTOR, ZONED TIME. Omit it if unknown.", + "maxLength": 100, + "type": "string" + }, + "unique": { + "description": "Set to true to add a property uniqueness constraint (IS UNIQUE).", + "type": "boolean" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "maxItems": 500, + "type": "array" + }, + "ref": { + "description": "A short name of your choosing, used to refer to the node later in this list.", + "maxLength": 100, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "labels" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "update_node", + "type": "string" + }, + "color": { + "anyOf": [ + { + "description": "Fill color as a hex code, such as #0a84ff.", + "maxLength": 40, + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Fill color as a hex code, or null to use the model style." + }, + "labels": { + "description": "Node labels, such as [\"Customer\"] or [\"Router\", \"Egress\"]. No two nodes can have the same set of labels.", + "items": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "maxItems": 20, + "type": "array" + }, + "layers": { + "description": "Names of the layers the node belongs to. Any layer that doesn't exist yet is created.", + "items": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "node": { + "description": "The node's id, or the ref of a node added earlier in this list.", + "maxLength": 100, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "node" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "remove_node", + "type": "string" + }, + "node": { + "description": "The node's id, or the ref of a node added earlier in this list.", + "maxLength": 100, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "node" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "add_relationship", + "type": "string" + }, + "from": { + "description": "The node's id, or the ref of a node added earlier in this list.", + "maxLength": 100, + "minLength": 1, + "type": "string" + }, + "properties": { + "description": "Properties in display order. On a node, the first property's example is shown as its caption.", + "items": { + "additionalProperties": false, + "properties": { + "example": { + "description": "An example value.", + "maxLength": 20000, + "type": "string" + }, + "key": { + "description": "Property key in camelCase, such as orderId. For an existing property, use the key exactly as get_model spells it.", + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "partOfKey": { + "description": "Set to true on every property that together identifies the node or relationship, such as orderId and lineNo on an order line. toro4n exports one key constraint over all of them, REQUIRE (n.orderId, n.lineNo) IS NODE KEY (IS RELATIONSHIP KEY on a relationship): each must be present and the combination unique. Needs Neo4j Enterprise Edition or Aura. An element has one key.", + "type": "boolean" + }, + "required": { + "description": "Set to true to add a property existence constraint (IS NOT NULL), which needs Neo4j Enterprise Edition or Aura.", + "type": "boolean" + }, + "type": { + "description": "The Neo4j property type, one of: STRING, INTEGER, FLOAT, BOOLEAN, DATE, ZONED DATETIME, LOCAL DATETIME, LIST<STRING>, POINT, DURATION, LIST<BOOLEAN>, LIST<DATE>, LIST<DURATION>, LIST<FLOAT>, LIST<INTEGER>, LIST<LOCAL DATETIME>, LIST<LOCAL TIME>, LIST<POINT>, LIST<UUID>, LIST<ZONED DATETIME>, LIST<ZONED TIME>, LOCAL TIME, UUID, VECTOR, ZONED TIME. Omit it if unknown.", + "maxLength": 100, + "type": "string" + }, + "unique": { + "description": "Set to true to add a property uniqueness constraint (IS UNIQUE).", + "type": "boolean" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "maxItems": 500, + "type": "array" + }, + "ref": { + "maxLength": 100, + "minLength": 1, + "type": "string" + }, + "to": { + "description": "The node's id, or the ref of a node added earlier in this list.", + "maxLength": 100, + "minLength": 1, + "type": "string" + }, + "type": { + "maxLength": 200, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "from", + "to", + "type" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "update_relationship", + "type": "string" + }, + "from": { + "description": "The node's id, or the ref of a node added earlier in this list.", + "maxLength": 100, + "minLength": 1, + "type": "string" + }, + "relationship": { + "description": "The relationship's id, or the ref of a relationship added earlier in this list.", + "maxLength": 100, + "minLength": 1, + "type": "string" + }, + "to": { + "description": "The node's id, or the ref of a node added earlier in this list.", + "maxLength": 100, + "minLength": 1, + "type": "string" + }, + "type": { + "maxLength": 200, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "relationship" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "remove_relationship", + "type": "string" + }, + "relationship": { + "description": "The relationship's id, or the ref of a relationship added earlier in this list.", + "maxLength": 100, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "relationship" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "set_property", + "type": "string" + }, + "example": { + "description": "An example value, or \"\" to clear it.", + "maxLength": 20000, + "type": "string" + }, + "key": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "on": { + "description": "The id or ref of the node or relationship the property belongs to.", + "maxLength": 100, + "minLength": 1, + "type": "string" + }, + "partOfKey": { + "type": "boolean" + }, + "position": { + "description": "Move the property to the top or the bottom of the list. On a node, the top property's example is shown as its caption.", + "enum": [ + "first", + "last" + ], + "type": "string" + }, + "required": { + "type": "boolean" + }, + "type": { + "description": "A property type, or \"\" to clear it.", + "maxLength": 100, + "type": "string" + }, + "unique": { + "type": "boolean" + } + }, + "required": [ + "action", + "on", + "key" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "rename_property", + "type": "string" + }, + "key": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "newKey": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "on": { + "description": "The id or ref of the node or relationship the property belongs to.", + "maxLength": 100, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "on", + "key", + "newKey" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "remove_property", + "type": "string" + }, + "key": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "on": { + "description": "The id or ref of the node or relationship the property belongs to.", + "maxLength": 100, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "on", + "key" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "add_note", + "type": "string" + }, + "attachTo": { + "items": { + "maxLength": 100, + "minLength": 1, + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "color": { + "description": "Fill color as a hex code, such as #0a84ff. Omit it for a white note.", + "maxLength": 40, + "type": "string" + }, + "ref": { + "maxLength": 100, + "minLength": 1, + "type": "string" + }, + "text": { + "maxLength": 20000, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "text" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "update_note", + "type": "string" + }, + "attachTo": { + "description": "Ids or refs of the nodes and relationships to attach the note to, replacing its current attachments. Use [] to detach it from all of them.", + "items": { + "maxLength": 100, + "minLength": 1, + "type": "string" + }, + "maxItems": 50, + "type": "array" + }, + "color": { + "description": "Fill color as a hex code, such as #0a84ff.", + "maxLength": 40, + "type": "string" + }, + "note": { + "description": "The note's id, or the ref of a note added earlier in this list.", + "maxLength": 100, + "minLength": 1, + "type": "string" + }, + "text": { + "maxLength": 20000, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "note" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "remove_note", + "type": "string" + }, + "note": { + "maxLength": 100, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "note" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "remove_layer", + "type": "string" + }, + "layer": { + "description": "The layer's name, as listed by get_model.", + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "moveContentsTo": { + "description": "The name of the layer to move this layer's nodes and relationships to. Omit it to delete them instead. Nodes that also belong to another layer stay in that layer.", + "maxLength": 200, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "layer" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "rename_layer", + "type": "string" + }, + "layer": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "name": { + "maxLength": 200, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "layer", + "name" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "rename_model", + "type": "string" + }, + "name": { + "maxLength": 200, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "action", + "name" + ], + "type": "object" + } +]
3 tool updates
- Changed
create_model1 field changed- added
Input schema / properties / guideCodeAdded value: +{ + "description": "The guideCode that get_modeling_guide returns. Required: call get_modeling_guide and read the guide before you create or edit a model.", + "maxLength": 100, + "type": "string" +}
- Changed
edit_model1 field changed- added
Input schema / properties / guideCodeAdded value: +{ + "description": "The guideCode that get_modeling_guide returns. Required: call get_modeling_guide and read the guide before you create or edit a model.", + "maxLength": 100, + "type": "string" +}
- Added
get_modeling_guide
6 tool updates
- First observed
create_model - First observed
edit_model - First observed
get_model - First observed
list_models - First observed
list_versions - First observed
restore_version
Related MCP Connectors
Generate, edit, and export data-architecture diagrams from your AI. Column lineage, PNG in chat.
Create, edit and organize hand-drawn diagrams (flowcharts, ER, architecture) from any AI agent.
Create and edit collaborative architecture diagrams with any AI assistant using the Trident 2D DSL.
Create and edit architecture diagrams from your AI agent; get an SVG and a live editable canvas.
Related MCP Servers
- FlicenseNot gradedqualityAmaintenanceEnables AI assistants to turn architecture and data into living, queryable knowledge graphs and generate 25 types of hand-drawn, auto-laid-out diagrams that remain editable. It supports natural-language revisions, architecture-aware styling, SVG/PNG export, and fully offline use without API keys.-
- FlicenseNot gradedqualityAmaintenanceEnables AI assistants in Cursor, Claude Code, and Windsurf to turn plain descriptions of components, actors, or data into auto-laid-out, editable hand-drawn diagrams across 25 types — including architecture, flowcharts, sequence diagrams, Gantt charts, and charts — with architecture-aware styling and natural-language revision. It can optionally persist a system as a version-controlled, queryable knowledge graph, and it runs fully offline with no API keys, exporting to SVG and PNG.-
- FlicenseNot gradedqualityAmaintenanceEnables AI coding assistants to turn natural-language architecture and data descriptions into editable, auto-laid-out hand-drawn diagrams across 25 types, with natural-language revisions, SVG/PNG export, and an optional queryable architecture knowledge graph, fully offline without API keys.-
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.