CoreModels
Server Details
CoreModels schema editor: nodes, mixins, relations, JSON Schema import/export. Sign-in required.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.5/5 across 14 of 14 tools scored. Lowest: 1.3/5.
Each tool has a distinct purpose: create, read, update, delete operations for nodes, mixins, and relations are clearly separated. Bulk creation is isolated from single-node creation, and schema exploration tools are distinct from mutation tools.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_node, get_mixins_and_relation_groups, remove_relation). No mixed conventions or vague verbs.
14 tools is well-scoped for a data modeling server, covering core CRUD, schema management, and bulk operations without being excessive or minimal.
The tool set covers create, read, and delete for nodes, mixins, and relations, and update for nodes, but lacks update operations for mixin values and relations, and a delete mixin type tool. These are minor gaps that agents can work around by recreating.
Available Tools
14 toolsbulk_createAInspect
Create multiple nodes, relations, and mixin values in one atomic operation.
When to use:
Creating more than one node.
Any creation that includes relations and/or mixins.
For a single node with no relations/mixins, prefer create_node.
Required ids come from:
get_mixins_and_relation_groups: relationGroupId, mixinId, and each mixin column id.
get_project_summary or search_nodes (nodeType=Space): spaceIds, plus any existing nodeIds you want to reference.
Relation endpoints (fromNodeId / toNodeId) may be either:
ids of nodes created elsewhere in this same payload, or
ids of nodes already in the project.
Limitations:
Cannot create AttributeMixin. Use create_mixin_value for those.
| Name | Required | Description | Default |
|---|---|---|---|
| bulkCreateDto | Yes | ||
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral aspects: atomicity, limitations (cannot create AttributeMixin), and endpoint flexibility. It doesn't mention error behavior or output, but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, front-loaded purpose, and each sentence is informative. Slightly long but justified given complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and no annotations, the description covers key aspects: purpose, usage guidance, ID sources, and limitations. Missing return value info, but otherwise complete for a complex bulk operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the bulkCreateDto structure (nodes, mixins, relations) and guides ID sources for parameters, though it doesn't detail graphProjectId or every nested field individually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates multiple nodes, relations, and mixin values atomically, distinguishing it from individual creation tools like create_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section specifies scenarios (multiple nodes, relations/mixins) and provides an alternative for single nodes. Also clarifies where required IDs come from and limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_mixin_typeAInspect
Create a new mixin type. Check existing mixins first with get_mixins_and_relation_groups to avoid duplicates. Mixins are reusable property sets applicable to any node.
| Name | Required | Description | Default |
|---|---|---|---|
| mixinTypeDto | Yes | ||
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions creation and defines mixins as reusable property sets, but does not cover permissions, side effects, or reversibility. This is adequate but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words: purpose, usage guideline, and conceptual explanation. Each sentence adds value, and the structure is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested input schema and lack of output schema, the description provides essential context: what a mixin type is and the prerequisite check. It omits potential errors or return format, but overall is sufficiently complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%—the description adds no parameter-specific meaning beyond what the schema already defines. The schema itself is detailed, but the description misses an opportunity to clarify how parameters like graphProjectId relate to the creation context. Baseline 3 applies due to schema's self-explanatory nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new mixin type.' It uses a specific verb (create) and resource (mixin type), distinguishing it from siblings like get_mixins_and_relation_groups (to check existing) and create_mixin_value (create values, not types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to 'Check existing mixins first with get_mixins_and_relation_groups to avoid duplicates.' This provides clear when-to-use guidance and names the relevant sibling tool for precondition checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_mixin_valueAInspect
Create a mixin value for a node. mixinId and column ids come from get_mixins_and_relation_groups. A node can have multiple mixins; each mixin can have multiple columns.
| Name | Required | Description | Default |
|---|---|---|---|
| graphProjectId | Yes | ||
| mixinCreateDto | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It indicates creation but does not mention idempotency, error conditions, authorization needs, or side effects (e.g., overwriting). The statement 'A node can have multiple mixins' offers limited context but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and includes essential context without extraneous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested objects and no output schema. The description explains the source of IDs and multiplicity but lacks information about return values, error handling, or what constitutes a successful creation. Given the complexity, it is moderately complete but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains descriptions for mixinId and mixinColumns, providing meaning beyond names. The description reinforces the source of these IDs. With schema description coverage at 0% (though some descriptions exist), the description adds minimal extra value, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a mixin value for a node', specifying the verb and resource. It distinguishes from sibling tools like create_mixin_type by mentioning that mixinId and column ids come from get_mixins_and_relation_groups, and it explains multiplicity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises where to obtain mixinId and column ids, which guides the user on prerequisites. It does not provide explicit conditions for when to use or avoid this tool vs alternatives like bulk_create, but the guidance is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_nodeBInspect
Create a new node. Empty/omitted spaceIds = default space; MUST be empty when nodeType is 'Space'.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeCreateDto | Yes | ||
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only mentions a constraint on spaceIds. It does not indicate whether the operation is idempotent, what happens on duplicate IDs, authentication requirements, rate limits, or whether the created node is returned. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences). The first sentence states the purpose, the second adds a constraint. While efficient, it lacks any additional structure like output description, example, or note about idempotency. Being concise is positive, but under-specification reduces its helpfulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a nested object parameter with 4 subfields and no annotations or output schema, the description should provide more context. It only covers one special case (spaceIds when nodeType is Space). It omits behavior on success, error handling, the purpose of the optional id field, and how it compares to bulk_create. Overall incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the burden. It adds meaning only for the spaceIds parameter (specific constraint when nodeType is Space). It does not clarify graphProjectId, label, id (optional UUID), or the meaning of nodeType values beyond the enum. The nested object's purpose is largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new node' which is a clear verb+resource. It also adds specific constraints about spaceIds and nodeType, helping distinguish from sibling creation tools like create_relation or bulk_create. However, it does not elaborate on what a node represents or differentiate further among the many creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Empty/omitted spaceIds = default space; MUST be empty when nodeType is Space.' This helps in specific scenarios. However, it does not explicitly state when to prefer this tool over alternatives like bulk_create or create_mixin_type, relying on naming convention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_relationBInspect
Create a directed relation fromNodeId → toNodeId. relationGroupId is the relation template; list templates with get_mixins_and_relation_groups.
| Name | Required | Description | Default |
|---|---|---|---|
| relation | Yes | ||
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states creation and directionality, but lacks details on side effects, permissions, idempotency, or error conditions (e.g., duplicate key or missing node).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with relevant information; no extraneous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a creation tool with no output schema and nested object parameters, the description omits prerequisites (e.g., nodes and relation group must exist), error handling, and post-conditions, making it incomplete for safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must explain parameters. It mentions 'fromNodeId', 'toNodeId', and 'relationGroupId' but does not explain 'id' or 'graphProjectId', leaving critical fields undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specifically states 'Create a directed relation fromNodeId → toNodeId' with a clear verb and resource, and distinguishes from siblings like 'create_node' and 'bulk_create' by referencing 'relationGroupId' and 'list templates with get_mixins_and_relation_groups'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indirectly suggests when to use another tool ('list templates with get_mixins_and_relation_groups') but does not explicitly state when to use this tool versus alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_jsonschemaCInspect
Export project data as a JSON Schema string.
| Name | Required | Description | Default |
|---|---|---|---|
| spaceId | No | ||
| rootNodeId | No | Optional root node id; empty/omitted to export without a fixed root. | |
| configTypeId | No | Export profile id used for the JSON Schema export. | |
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states 'Export' but does not clarify whether the operation is read-only, what happens with missing optional parameters, or any side effects. Essential details like permissions or rate limits are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. However, it is too brief and omits crucial details, making it not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not hint at return format or behavior. It also fails to clarify which parameters are required or optional, leaving the agent without enough context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% with two parameters described. The tool description itself adds no parameter explanation beyond the schema, missing the opportunity to clarify spaceId and graphProjectId. Thus it adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export' and resource 'project data' with output format 'JSON Schema string'. However, it does not differentiate this tool from siblings like import_jsonschema or other export tools, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mixins_and_relation_groupsAInspect
Get the project schema: all mixin definitions and all relation-group definitions.
Use this once at the start of a session to discover the IDs needed by other tools (mixinId, columnId, relationGroupId). Returns compact positional arrays - see the "format" field for the layout.
| Name | Required | Description | Default |
|---|---|---|---|
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that results are compact positional arrays and directs to the 'format' field for layout. It doesn't explicitly state it's read-only or mention side effects, but the 'get' prefix implies no mutation. Minor gap: no mention of potential rate limits or data size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each adding essential information: what it does, when to use it, and what the output looks like. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema. The description explains the output format (compact positional arrays, format field) and usage context. However, it could briefly clarify what 'mixinId, columnId, relationGroupId' map to in the output. For a simple discovery tool, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The one parameter (graphProjectId) has no description in the schema, and the tool description does not explain its meaning or format. Schema description coverage is 0%, but the description adds no value for this parameter. The pattern from the schema is available, but the description should at least state it's the project ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the project schema (mixin and relation-group definitions) and highlights its role in discovering IDs for other tools. The verb 'Get' and resource 'project schema' are specific. It distinguishes itself from sibling CRUD tools by being read-only and foundational.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool once at the start of a session to discover IDs needed by other tools. This provides clear when-to-use guidance and context for its role in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_project_summaryAInspect
Labels and IDs of types, elements, and taxonomies in the project. A category is omitted when it has more than 1000 nodes - use search_nodes with the matching nodeType filter to enumerate it.
| Name | Required | Description | Default |
|---|---|---|---|
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the omission behavior for categories over 1000 nodes, which is a key behavioral trait. With no annotations, this adds significant transparency, though more details on response format would improve it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First states purpose, second adds crucial limitation and alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations. Description explains purpose and limitation but omits response structure, error conditions, or other contextual details. Adequate for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain the graphProjectId parameter beyond its existence. The parameter's meaning and usage are left to inference from the name and pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns 'Labels and IDs of types, elements, and taxonomies in the project.' It distinguishes from siblings by specifying the condition of omitted categories and directing to search_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use the tool and when to switch to an alternative: 'A category is omitted when it has more than 1000 nodes - use search_nodes with the matching nodeType filter to enumerate it.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
import_jsonschemaCInspect
Imports a JSON Schema into a space
| Name | Required | Description | Default |
|---|---|---|---|
| importDto | Yes | ||
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'imports' but does not disclose behavioral traits such as whether it overwrites existing schemas, side effects, authentication needs, or error handling. With no annotations, the description carries the full burden but provides minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core action. However, it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested parameters, no output schema, no annotations), the description is insufficiently complete. It does not explain return values, success/failure indicators, or how the tool behaves within a space context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the two required parameters (graphProjectId, importDto) beyond what is in the input schema. Schema description coverage is 0%, and the description fails to explain the nested structure or the purpose of the customFileUrl. The schema's own description for customFileUrl is the only guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (imports) and the resource (JSON Schema) and destination (space), distinguishing it from the sibling export_jsonschema. However, it lacks specificity about the mechanism (using a file URL) and the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., bulk_create for other data types). The description does not mention prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_mixin_valueAInspect
Remove one or more mixin column values from a node. mixinId and column ids come from get_mixins_and_relation_groups. This does not delete the mixin definition itself.
| Name | Required | Description | Default |
|---|---|---|---|
| graphProjectId | Yes | ||
| mixinRemoveDto | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. It states the removal of values and clarifies that the mixin definition is not deleted, but lacks details on permissions, reversibility, or side effects, leaving some ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff: the action, the source of parameters, and a clarifying exclusion. Each sentence earns its place, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is adequate but not fully complete. It explains the core action and parameter sources, but omits details about graphProjectId, response format, and error conditions, which are needed for a comprehensive understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by noting that mixinId and mixinColumnsIds come from get_mixins_and_relation_groups, but it does not explain graphProjectId or targetNodeId, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('one or more mixin column values from a node'), and distinguishes itself from siblings like create_mixin_value and create_mixin_type by clarifying it does not delete the mixin definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear guidance on where to obtain the mixinId and column ids (from get_mixins_and_relation_groups), which is a prerequisite. However, it does not explicitly state when not to use this tool or list alternatives, but context from siblings is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_nodeDInspect
Suspend a node.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | ||
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It uses 'suspend' which is ambiguous and likely contradictory to the removal intent. It omits details on reversibility, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, which is too short to be useful. It sacrifices clarity for brevity, making it inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain the effect of suspension versus removal, but it does not. The tool's behavior is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning to the parameters 'nodeId' and 'graphProjectId'. Their purpose or expected values are not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Suspend a node' introduces a verb inconsistent with the tool name 'remove_node', which implies deletion. It does not distinguish from sibling tools like 'remove_mixin_value' or 'update_node'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_relationCInspect
Remove a relation between two nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| relation | Yes | ||
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'remove', which implies destruction but does not disclose side effects, required permissions, or reversibility. The burden falls entirely on the description, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it is too brief and lacks necessary detail, making it acceptable but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters including a nested object and no output schema, the description does not explain prerequisites, consequences, or return values. It is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema coverage is 0%, meaning no descriptions exist for parameters. The tool description adds no meaning beyond the schema, leaving the agent without clarity on param purposes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'a relation between two nodes', which is specific and distinguishes it from sibling tools like remove_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like remove_node or remove_mixin_value. The description does not provide any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_nodesAInspect
Search nodes in a CoreModels project. Returns compact positional arrays; the response "format" field describes the layout.
Filters (provide at least one; they combine with AND):
nodeIds: exact id lookup
nodeType: one of Element, Type, Taxonomy, Exemplar, Component, Space, Tag, Mixin
expression: partial substring match on the node label (plain text, no wildcards)
spaceIds: restrict to specific spaces
Optional flags: includeRelations, includeMixins, sortAttr, sortDesc, pageSize.
Pagination:
First call: omit pagingToken.
If the response has a pagingToken, more pages exist. Repeat the same call with that exact token to get the next page.
If the response has no pagingToken, this was the last page.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeIds | No | ||
| nodeType | No | ||
| pageSize | No | ||
| sortAttr | No | ||
| sortDesc | No | ||
| spaceIds | No | ||
| expression | No | Partial substring match against the node label. Plain text only - no wildcards, no regex, no '*', '%', '_' or '?' characters; the literal characters are matched as-is. | |
| pagingToken | No | Pagination token from the previous response. Always use the latest one. | |
| includeMixins | No | ||
| graphProjectId | Yes | ||
| includeRelations | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the output format (compact positional arrays with a 'format' field) and pagination behavior. It does not cover auth or rate limits, but for a search tool, the key behaviors are well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-paragraph but well-structured: overview, filters, optional flags, pagination. It is front-loaded with the main purpose and details are organized. Could be slightly more concise, but no unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description provides substantial context: search behavior, pagination, parameter details, and output format hint. It does not detail the exact response fields, but that is perhaps expected for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18%, so the description must compensate. It does so thoroughly, explaining all parameters (nodeIds, nodeType, expression, spaceIds, optional flags) with details like expression being a partial substring match with no wildcards, which is beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search nodes in a CoreModels project' and explains the output format (compact positional arrays). It is distinct from sibling tools like create, update, remove, etc., which are all CRUD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires at least one filter and explains AND combination, lists available filters, and provides pagination instructions. While it does not explicitly state when not to use, the context of siblings makes it clear this is the search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_nodeAInspect
Update an existing node's label and/or its space assignments. Omitted fields are unchanged. spaceIds replaces (not merges) existing assignments; empty array = default space. At least one of label or spaceIds must be provided.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeUpdateDto | Yes | ||
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: that spaceIds replacement semantics, empty array means default space, and partial updates. It does not mention permissions or error handling but covers essential mutation behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each necessary: first states purpose, second explains update behavior, third adds constraints. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description covers the tool’s behavior adequately. It describes update semantics and constraints but does not mention error conditions or return values. For a simple mutation tool, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the semantics of spaceIds (replaces, not merges, empty array = default space) and the requirement to provide at least one of label or spaceIds. This adds crucial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'node,' specifying that it updates label and/or space assignments. This distinguishes it from sibling tools like 'create_node' and 'remove_node'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage constraints: omitted fields unchanged, spaceIds replaces rather than merges, and at least one of label or spaceIds must be provided. However, it does not explicitly compare against alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!