coremodels
Server Details
Schema modeling in JSON, JSON-LD, and other formats with CoreModels platform.
- 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.8/5 across 9 of 9 tools scored. Lowest: 2.5/5.
Most tools have distinct purposes: export vs fetch vs get vs list vs search vs validate. However, there is some potential confusion between export_json_ld and export_jsonschema (both export but different formats) and between fetch_json_ld_import_profiles and fetch_json_schema_import_profiles (both fetch profiles but for different schemas). Descriptions clarify these differences, so overall disambiguation is good.
All tool names follow a consistent verb_noun pattern using lowercase and underscores (e.g., export_json_ld, search_nodes, list_projects). The naming style is uniform across the set, making it easy to predict tool functionality.
With 9 tools, the server is well-scoped for its purpose. Each tool serves a clear role in project data exploration and export, without unnecessary redundancy or overwhelming number.
The tool set covers reading, searching, exporting, and validating project data, but lacks any create, update, or delete operations. Given the domain, one might expect tools for importing or modifying project entities, but the focus appears to be on analysis and export, leaving notable gaps for full lifecycle management.
Available Tools
10 toolsexport_json_ldExport JSON-LDARead-onlyInspect
Export project data in JSON-LD format using a configured export profile.
Use fetch_json_ld_import_profiles first to discover the configTypeId. At least one of exportTypes/exportElements/exportTaxonomies/exportDataTypes must be true. Tree-based mode (graphBased=false) requires exactly one nodeId; graph-based mode allows multiple or none.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeIds | No | For tree-based export, exactly one root node id; for graph-based, optional | |
| spaceId | No | Optional space id to filter export data; empty = all spaces | |
| graphBased | No | true = graph-based (no root); false = tree-based (requires exactly one nodeId) | |
| exportTypes | No | ||
| configTypeId | Yes | JSON-LD export profile id (from fetch_json_ld_import_profiles) | |
| includeSpace | No | ||
| exportElements | No | ||
| graphProjectId | Yes | ||
| useDefaultType | No | ||
| exportDataTypes | No | ||
| exportTaxonomies | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, which is consistent with export being a read-only operation. The description adds behavioral details about graph-based vs tree-based modes and the requirement for at least one boolean flag, disclosing key constraints beyond annotations. However, it does not mention error handling or output format details.
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 sentences: purpose, prerequisite/constraint, mode rules. It is front-loaded and every sentence adds value without redundancy. Highly efficient.
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 a complex tool, the description covers key usage rules but fails to describe the output (e.g., that it returns JSON-LD content or a file reference). It is incomplete for an agent to fully understand all aspects without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (36%), with only 4 of 11 parameters having descriptions. The tool description compensates by explaining constraints (graphBased vs nodeIds, at least one boolean true) but leaves many boolean parameters (exportTypes, exportElements, etc.) without further explanation. The baseline is 3 due to partial compensation.
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 'Export project data in JSON-LD format using a configured export profile.' It clearly identifies the action (export), resource (project data), and format (JSON-LD), differentiating it from siblings like export_jsonschema and fetch_json_ld_import_profiles.
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: prerequisites ('Use fetch_json_ld_import_profiles first to discover the configTypeId'), required conditions ('At least one of... must be true'), and mode-specific behavior ('Tree-based mode requires exactly one nodeId; graph-based mode allows multiple or none'). This is comprehensive and directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_jsonschemaExport JSON SchemaCRead-onlyInspect
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?
The annotations already declare readOnlyHint=true. The description adds no behavioral context beyond stating the operation. No side effects, auth needs, or limitations are mentioned.
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, making it concise, but it lacks structure. It does not earn its place as it omits critical information. Under-specification is not conciseness.
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 has 4 parameters and no output schema, the description fails to explain required inputs, return value, or behavior variants. It is incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 50% schema description coverage, the description does not explain any of the four parameters. The description adds no meaning beyond the schema's limited descriptions for rootNodeId and configTypeId. This is inadequate.
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 ('export') and the output ('project data as a JSON Schema string'), distinguishing it from sibling tools like export_json_ld. The title reinforces this purpose.
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. The description lacks context on prerequisites, appropriate scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_shexExport ShExARead-onlyInspect
Export project data as a ShEx (Shape Expressions) schema string.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeIds | No | Optional type node ids to export; omit to export all types (optionally scoped to a space). | |
| spaceId | No | ||
| graphProjectId | Yes | ||
| includeCardinality | No | Whether to emit ShEx cardinality markers (?, *, +). Defaults to true. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds no extra behavioral context beyond 'Export' being a read operation. No contradiction, but no additional disclosure (e.g., limits, auth).
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?
Single sentence, front-loaded with verb and resource. No extraneous 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, but description specifies output is a 'ShEx schema string'. Missing details about return structure, error cases, or usage context. Adequate for a simple export 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 50% (nodeIds and includeCardinality have descriptions in schema). The tool description does not explain any parameters further. For low coverage, description should compensate but does not.
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 verb 'Export', resource 'project data', and output format 'ShEx schema string'. It distinguishes from sibling export tools (json, json-schema) by naming ShEx explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The description implies usage when ShEx output is needed but does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_json_ld_import_profilesFetch JSON-LD Import ProfilesBRead-onlyInspect
Fetch JSON-LD import/export profiles available for a project.
| Name | Required | Description | Default |
|---|---|---|---|
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description's 'Fetch' is consistent. However, the description does not add further behavioral context beyond what annotations provide, such as error handling, authentication needs, or data freshness. For a simple read tool, it is adequate but not enriched.
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 of nine words, perfectly front-loaded with the verb and resource. It contains no extraneous information, earning its place as a concise summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, readOnly annotation), the description provides the core purpose but omits details about parameter behavior and return structure. It is minimally complete but leaves gaps that could affect correct invocation, such as not specifying that the project ID is required.
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 one parameter (graphProjectId, required) with 0% description coverage. The description fails to mention this parameter or its role, relying on the implicit connection from 'for a project'. With low schema coverage, the description should compensate, but it does not, offering no added meaning 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 the verb 'Fetch' and the resource 'JSON-LD import/export profiles', with scope 'for a project'. It is specific enough to distinguish from sibling tools like export_json_ld (export) and fetch_json_schema_import_profiles (different schema). However, the name mentions 'import_profiles' while description includes 'import/export', causing slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as fetch_json_schema_import_profiles. There is no mention of prerequisites, constraints, or typical use cases. The description lacks any contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_json_schema_import_profilesFetch JSON Schema Import ProfilesBRead-onlyInspect
Fetch JSON Schema import/export profiles available for a project.
| Name | Required | Description | Default |
|---|---|---|---|
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be a safe read. The description adds little beyond confirming it fetches data; no additional behavioral context is provided.
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?
Description is a single sentence with no unnecessary words. It is concise and front-loaded, but could slightly expand on the parameter or usage without losing conciseness.
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 no output schema and a single undocumented parameter, the description is too sparse. It does not clarify the return format or the meaning of 'profiles', leaving significant gaps for an agent to infer.
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% and the description does not mention the sole parameter 'graphProjectId' or explain its meaning, leaving the agent with no guidance on how to provide the required input.
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 'Fetch JSON Schema import/export profiles available for a project.' It uses a specific verb 'Fetch' and resource, and distinguishes from siblings like 'export_jsonschema' and 'fetch_json_ld_import_profiles'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'fetch_json_ld_import_profiles' or 'export_jsonschema'. Only implies usage via the description.
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_groupsGet Mixins & Relation GroupsARead-onlyInspect
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?
The description adds value beyond the annotations by noting the return format: 'Returns compact positional arrays - see the "format" field for the layout.' This discloses behavioral traits not covered by the readOnlyHint annotation, aiding the agent in parsing the response.
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 concise sentences, each serving a distinct purpose: stating the function, providing usage guidance, and disclosing output format. It is front-loaded with the essential purpose and contains no extraneous 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 the tool's simplicity (one parameter, no output schema), the description fully covers what the tool does, when to use it, and key aspects of its output. It enables an agent to effectively decide to invoke it and understand the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (graphProjectId) with no description in the schema. The tool description provides no additional explanation of this parameter beyond its name and context. While the name is self-explanatory given the tool's purpose, the description does not explicitly add meaning beyond what the schema offers.
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 'Get the project schema: all mixin definitions and all relation-group definitions.' This specifies the verb (get) and the resource (project schema with specific components). It distinguishes from sibling tools like list_projects or get_project_summary.
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 to 'Use this once at the start of a session to discover the IDs needed by other tools,' providing clear when-to-use context. It does not explicitly state when not to use alternatives, but the guidance is sufficient and directly addresses a common workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_project_summaryGet Project SummaryARead-onlyInspect
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?
Beyond the readOnlyHint annotation, the description discloses a key behavioral trait: categories are omitted if they have more than 1000 nodes. This adds significant transparency about potential data incompleteness and offers a remediation path, exceeding annotation-only information.
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 long, front-loaded with the core function, and immediately follows with a critical limitation. Every sentence is necessary and adds value, with 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?
For a simple tool with one parameter and no output schema, the description covers the main behavior and a notable limitation. It does not mention preconditions (e.g., project existence) or error behaviors, but the provided detail is sufficient for most use cases.
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% and the tool description does not mention the single parameter 'graphProjectId'. It neither explains its purpose nor its format (e.g., a project identifier). The description fails to add any meaning beyond the schema's pattern constraint, leaving agents uninformed.
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 returns 'Labels and IDs of types, elements, and taxonomies', specifying the resource and output. It distinguishes itself from the sibling 'search_nodes' by noting when to use that tool instead, achieving high purpose clarity.
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 on when to use an alternative ('use search_nodes with the matching nodeType filter') when categories exceed 1000 nodes. It lacks mention of other siblings like 'list_projects', but the directive is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsList ProjectsARead-onlyInspect
List the user's CoreModels projects as [id,name,accessLevel] (see the response "format" field). Use a returned id as graphProjectId for other tools. Pass searchTerm to filter by name (case-insensitive substring). Set includePublicProjects=true to also include public projects. Paged: page is 1-based; increment page up to the returned totalPages to get all results.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page number. Increment to page through results up to totalPages. | |
| pageSize | No | ||
| searchTerm | No | Optional case-insensitive substring to filter projects by name. | |
| includePublicProjects | No | When true, public projects the user is not a member of are also included. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description's behavioral value is additive. It explains pagination behavior, case-insensitive substring filter, and inclusion of non-member public projects. Does not mention default pageSize or response structure beyond 'format' field, but sufficient.
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 serving a purpose: core function, usage of id, filtering/pagination details. Front-loaded with primary action. Could be slightly more concise, but no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and minimal annotations, description covers key aspects: pagination mechanism, filtering behavior, inclusion of public projects, and how to use results. Missing edge cases (e.g., what if page exceeds totalPages?), but complete for typical 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?
Schema description coverage is 75%, so baseline is 3. Description reinforces schema meanings (e.g., page is 1-based, searchTerm case-insensitive). Adds mention of 'format' field in response, which is not in schema, providing slight extra context. But overall does not significantly enhance 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?
Clearly states 'List the user's CoreModels projects' with specific fields [id,name,accessLevel]. Distinguishes from sibling tools that focus on export, import, or search 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?
Provides explicit guidance on using searchTerm for filtering, includePublicProjects for including public projects, and pagination (1-based page, increment up to totalPages). Mentions using returned id as graphProjectId for other tools. Lacks explicit when-not-to-use or alternatives, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_nodesSearch NodesARead-onlyInspect
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?
Exceeds annotation (readOnlyHint) by detailing response format ('compact positional arrays'), pagination behavior, and the exact substring matching rules for expression. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for introduction, filters, optional flags, and pagination. Every sentence adds value, no fluff. Concise yet comprehensive.
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, one required, and no output schema, the description covers all parameters, pagination, and hints at return format. Could elaborate on combining multiple filters, but it's sufficient.
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 has only 18% coverage (expression and pagingToken have descriptions). Description compensates fully by explaining each filter's purpose, enum values, and optional flags, adding substantial meaning beyond 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 specifies the action ('Search') and resource ('nodes in a CoreModels project') clearly. It is distinct from sibling tools which are export/import or summary tools, no other search tool exists.
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 states that filters must be provided and combine with AND, lists all filter parameters, and gives pagination step-by-step instructions. Lacks explicit when-not-to-use advice, but given siblings don't overlap, this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_jsonValidate JSONARead-onlyInspect
Validate a JSON document against a project's stored JSON Schema. The schema is regenerated from the project using the supplied configTypeId (the export profile id) and rootNodeId. Provide the JSON to validate as a serialized string.
| Name | Required | Description | Default |
|---|---|---|---|
| spaceId | No | Optional space id to scope the schema | |
| jsonString | Yes | The JSON document to validate, serialized as a string | |
| rootNodeId | Yes | Node id used as the root when generating the JSON Schema | |
| configTypeId | No | Profile id used to map mixins/relations to schema keywords | |
| graphProjectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with validation as a read operation. The description adds critical context: 'The schema is regenerated from the project using the supplied configTypeId and rootNodeId,' which is helpful. It does not describe error handling or response, but the read-only safety is clear.
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 brief and to the point: two sentences in the first paragraph for purpose, one sentence for regeneration context. No redundant information; every sentence earns its place.
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 description explains the validation process and key parameters but does not specify the result format (e.g., success/failure message, errors). Without an output schema, agents need to know how to interpret the outcome, which is missing.
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 80%, with most parameters described. The description adds meaning by explaining configTypeId and rootNodeId are used for schema regeneration. However, graphProjectId lacks a description in both schema and text, missing an opportunity to clarify its role.
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 'Validate a JSON document against a project's stored JSON Schema,' providing a specific verb (validate) and resource (JSON against schema). It distinguishes from sibling tools like export_json_ld or export_jsonschema by focusing on validation rather than export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (having a JSON to validate against a project schema) but lacks explicit guidance on when not to use or alternatives. It mentions providing JSON as a serialized string but does not compare with sibling tools for choosing this tool over others.
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!