Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ONE-MCP list all entities in the system"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the ONE Framework ERP — gives Claude autonomous access to explore your data model, run queries, and understand business logic.
npm installCopy .env.example to .env and fill in your instance details:
cp .env.example .envONE_URL=https://your-instance.oneerp.ro
ONE_API_KEY=your-api-key-hereThe project already has a .mcp.json file. Update it with your credentials, then restart Claude Code.
Or manually add a project-level MCP server:
// .mcp.json (project root)
{
"mcpServers": {
"one": {
"command": "npx",
"args": ["tsx", "src/index.ts"],
"cwd": "D:\\ONE-Projects\\MCP-ONE",
"env": {
"ONE_URL": "https://your-instance.oneerp.ro",
"ONE_API_KEY": "your-api-key"
}
}
}
}Related MCP server: Business Central MCP Workshop Server
Tool | Description |
| Server version + authenticated user |
| Execute FETCH queries (filter, link, aggregate) |
| Discover all entities in the system |
| Full schema: properties + relationships |
| Read a single record by entity name + key |
Tool | Description |
| Create a new record ⚠️ |
| Update an existing record ⚠️ |
Tool | Description |
| Workflow definitions + event bindings |
| Workflow source code + metadata |
| Run a workflow method with arguments |
No DELETE tool — the MCP does not expose a delete operation
API key permissions are inherited from the associated user's roles — ensure the user has only View + Create/Update access in ONE
All FETCH queries run under the security context of the authenticated user
Create/Update tools require explicit user confirmation (MCP permission model)
npm run dev # Run with tsx (stdio transport)
npm run build # Compile TypeScript
npm run typecheck # Type checking onlyCreate a new entity record. ⚠️ Requires Create permission on the entity.
Provide the entity name and a properties object with field values. Optionally include child entity records (nested creation).
Example: create a new catalog entry:
entityName: "ui_catalog"
properties: { "name": "my_catalog", "fetch": "FETCH ..." }
IMPORTANT: This creates real data. Double-check your values before submitting. There is NO delete functionality via this MCP — mistakes must be corrected manually.
| Name | Required | Description | Default |
|---|---|---|---|
| children | No | Optional. Map of child entity names to arrays of child records, each with 'entity_name' and 'properties'. Used when the entity has related child entities that should be created in the same transaction. Example: { "child_entity": [{ "entity_name": "child", "properties": {...} }] } | |
| entityName | Yes | The entity name to create (e.g., 'ui_catalog', 'user') | |
| properties | Yes | Key-value pairs of entity property names to their values. Required fields depend on the entity schema — use get_entity_schema first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It warns about requiring permission, creating real data, and having no delete functionality, which are critical operational traits.
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 compact and well-structured, with a warning, step-by-step guidance, an example, and a final caution. Every sentence contributes meaningful information with 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?
For a create tool with nested objects, the description covers prerequisites, usage, side effects, and a warning about irreversibility. It is sufficiently complete given the schema coverage and lack of an output schema.
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 documents all three parameters 100%, so the baseline is 3. The description adds a concrete example and clarifies nested child record creation, enhancing understanding beyond the schema alone.
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 entity record' with a specific verb and resource, distinguishing it from sibling tools like get_entity_record and update_entity_record. It also highlights nested creation as a unique feature.
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 clear usage instructions, including an example and the requirement for Create permission. It does not explicitly name alternatives or exclusion scenarios, but the context strongly implies when this tool should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a named workflow method with arguments. Workflows are server-side scripts that contain business logic. Use this to trigger actions, run calculations, or invoke custom processes.
Before executing, use list_workflows to discover available workflows and get_workflow to read their source code and understand what they do.
Arguments are passed as key-value pairs matching the workflow's parameter names.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Named arguments to pass to the workflow method. Keys must match the parameter names in the workflow's method signature. Values can be strings, numbers, booleans, or dates (ISO format). Example: { "nume": "Alex", "age": 30 } | |
| method | Yes | The workflow method to call. Typically 'main' for the default entry point. Check the workflow's source code (via get_workflow) for available methods. | main |
| workflowName | Yes | The name of the workflow to execute (e.g., 'AgeConcat', 'SystemCreateUserByName') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It mentions that workflows are 'server-side scripts that contain business logic' and that execution will 'trigger actions,' implying side effects, but it does not disclose whether changes are reversible, what permissions are required, or any potential consequences of running arbitrary scripts. This is minimal transparency for a potentially high-impact execution 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 compact—three sentences that immediately state the core action and use case. It front-loads the essential detail and provides useful context about server-side scripts without any fluff or redundancy. Every sentence serves a distinct purpose, making it a model of concise, structured documentation.
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 no output schema and no annotations, but the description does not mention what the tool returns, whether errors are possible, or any safety caveats about executing arbitrary server-side scripts. It does guide the caller to inspect workflows first, which is helpful, but the lack of behavioral consequences and result information leaves the context incomplete for a tool with this level of power.
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 100%, meaning all parameters are already documented in the input schema. The description adds a general note that arguments are 'key-value pairs matching the workflow's parameter names,' but this largely mirrors the schema's own description for args. There is no additional depth about workflowName or method beyond what the schema already provides, so the baseline score 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 opens with 'Execute a named workflow method with arguments,' clearly identifying the verb (execute), resource (workflow method), and scope (named). It then distinguishes from sibling tools by instructing to use list_workflows and get_workflow for discovery and inspection, making it unambiguous that this tool performs the actual execution. This fully clarifies its unique role among the siblings.
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 states when to use the tool: 'to trigger actions, run calculations, or invoke custom processes.' It also provides clear prerequisites: 'Before executing, use list_workflows to discover available workflows and get_workflow to read their source code.' This is strong guidance, though it does not explicitly state when not to use it or mention alternatives for read-only operations such as fetch_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a FETCH query against the ONE Framework instance. FETCH is a custom query language for retrieving, filtering, and aggregating data from one or more entities. Use this to: explore data, discover relationships, run reports, and understand the data model.
Syntax examples:
FETCH entity (key, name) LIMIT 10 — basic retrieval
FETCH entity (key, name) FILTER name CONTAINS "invoice" — filtered
FETCH invoice (key, total) { invoice_item TO invoice (key, product_name) } — with linked entities
The query is always executed under the security privileges of the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The FETCH query to execute. Must start with FETCH. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for behavioral disclosure. It provides valuable context by stating that queries always run under the authenticated user's security privileges and focusing on read-style operations. However, it does not describe the response format, pagination, error behavior, or potential performance implications, leaving notable gaps.
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 well-structured and front-loaded: purpose first, then concrete use cases, syntax examples, and a security note. Every sentence earns its place, and the example block is dense with necessary information for a custom query language.
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 complex custom-language tool, the description covers purpose, when to use, syntax, and security thoroughly. However, with no output schema, it does not specify the result shape, which is a moderate gap. Overall, it is complete enough for an agent to select and invoke the tool confidently.
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 schema covers the single query parameter at 100% baseline, but the description adds significant meaning through syntax examples and an explanation of what FETCH can do. This is essential for correctly constructing a query, going far beyond the schema's terse 'Must start with FETCH' requirement.
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 executes a FETCH query against the ONE Framework instance and defines the query language's capabilities: retrieving, filtering, and aggregating data. This distinguishes it from sibling tools like list_entities and get_entity_record by emphasizing a custom, flexible query language.
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 lists use cases: explore data, discover relationships, run reports, and understand the data model. It does not explicitly name alternatives or exclusion conditions, but the purpose and syntax examples make it obvious when to use this tool versus the simpler sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single entity record by its entity name and key (primary key). Returns the full record with all properties and child entities. Use this when you know exactly which record you need (e.g., entity 'user' with key 1).
To discover records, use fetch_query instead.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The primary key of the record to retrieve | |
| entityName | Yes | The name of the entity (e.g., 'user', 'invoice', 'ui_catalog') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return content ('full record with all properties and child entities'), which helps set expectations. However, it doesn't mention error behavior or access requirements, but for a read operation this level is 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?
Concise two-sentence paragraph, with the core action front-loaded and a relevant example. The alternative tool mention is integrated without clutter. Every sentence contributes 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?
For a simple retrieval tool with no output schema, the description covers the full return shape ('all properties and child entities') and use-case context. Sibling tools like fetch_query are referenced appropriately. No critical gaps remain.
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 100%, so the baseline is 3. The description adds a concrete example ('entity 'user' with key 1') and clarifies the key is a primary key, going slightly beyond the schema's own descriptions.
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 retrieves a single entity record using entity name and key, with explicit scope ('exactly which record you need'). It distinguishes itself by naming the alternative fetch_query for discovery, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides direct usage criteria: 'Use this when you know exactly which record you need' and explicitly points to fetch_query as the alternative for discovery. This gives the agent clear decision rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full schema of an entity: its properties (fields with types and constraints) and its relationships to other entities. Use this to understand what data an entity holds and how it connects to other entities.
Returns:
Properties: name, type, required flag, default value
Relationships: name, type (OneToMany, ManyToOne), foreign entity, cascading rules
| Name | Required | Description | Default |
|---|---|---|---|
| entityName | Yes | The exact name of the entity (e.g., 'user', 'invoice') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It details the return structure (properties and relationships) and implies a read-only operation via 'Get.' It does not discuss permissions or error scenarios, but for a read-only schema tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and uses a bulleted 'Returns' section to clearly list output fields without unnecessary prose. Every sentence contributes to understanding.
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 single-parameter schema retrieval tool with no output schema, the description fully explains the return values and the tool's purpose. It covers both the properties and relationships aspects, making it self-contained and 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 description coverage is 100% (the 'entityName' parameter already includes an example and clarification). The description adds no extra parameter-specific detail, so the baseline of 3 applies.
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 starts with a specific verb and resource: 'Get the full schema of an entity.' It clearly distinguishes itself from siblings like get_entity_record (which gets data) and list_entities (which lists names) by focusing on properties and relationships.
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 context: 'Use this to understand what data an entity holds and how it connects to other entities.' It does not explicitly name alternative tools or exclusion conditions, but the context is unambiguous for a schema query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the connected ONE Framework instance, including server version and the currently authenticated user. Use this to verify the connection is working and to see who you are authenticated as.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the read-only nature through 'Get information' and 'verify the connection', and explicitly mentions the authenticated user, adding useful context about what to expect. It does not explicitly state side-effect absence, but the 'get' semantics fully imply 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?
The description is two concise sentences, front-loaded with the primary action and key return values, followed by a practical use case. Every word 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?
For a zero-parameter, no-output-schema tool, the description fully covers what the tool does, what it returns, and when to use it. There is no missing critical context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description correctly omits any parameter details. The baseline for no parameters is 4, and the description adds no unnecessary filler.
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 'Get information' and the specific resource 'connected ONE Framework instance', listing the returned details (server version and authenticated user). This distinguishes it from sibling tools that focus on queries, workflows, or entities.
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 usage context: 'Use this to verify the connection is working and to see who you are authenticated as.' It gives a clear when-to-use but does not mention alternatives or exclusions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full source code and metadata of a workflow by its key (primary key). Use list_workflows first to find the workflow key you need.
Returns the workflow name, source module, and the full source code.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The primary key of the workflow to retrieve |
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 discloses the output contents (workflow name, source module, source code) but does not mention error behavior, auth requirements, or explicitly confirm this is a read-only operation. For a simple get, this is minimally 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?
Two sentences: the first states the primary action and target, the second explains the prerequisite and return value. No filler, front-loaded, and 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?
For a one-parameter retrieval tool with no output schema, the description covers the key input, how to obtain it, and what the response includes. It omits edge cases like not-found behavior, but given the tool's simplicity, it is reasonably 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 100% for the key parameter, but the description adds value by explaining the key is the workflow's primary key and advising to get it from list_workflows. This goes beyond the schema's property description, clarifying both meaning and acquisition of the parameter.
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 gets the full source code and metadata of a workflow by its primary key. It distinguishes from sibling tools by specifying 'full source code' and directing users to list_workflows first, which differentiates it from listing or executing workflows.
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 gives clear context: use list_workflows first to find the key, then use this tool to retrieve details. It implies this is for fetching a specific workflow rather than listing all, but doesn't explicitly state when not to use it or mention alternative tools like execute_workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all entities in the ONE Framework instance. Returns entity names, their display names (where available), and whether they are public/customizable. Use this to discover what data is available before diving into specific entities. Tip: After listing entities, use get_entity_schema to see the full structure of an entity.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of entities to return (default: 50) | |
| filter | No | Optional filter string — only return entities whose name contains this text (case-insensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It does disclose the return values and implies a non-destructive read operation, but doesn't explicitly mention authentication, rate limits, or pagination behavior. The mention that it returns 'whether they are public/customizable' adds useful context beyond a simple list.
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, each serving a purpose: what it does, what it returns, and how to proceed. It's front-loaded and free of fluff.
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 list tool with two optional parameters and no output schema, the description gives enough context: what it returns, when to use it, and a next-step pointer. It could mention the default limit or any permission requirements, but these are minor gaps.
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 fully documents the two parameters (limit and filter) with descriptions and defaults. The description doesn't add any parameter-specific guidance, so it relies on the schema. Baseline 3 is appropriate since coverage is 100%.
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 'List all entities' with a specific verb and resource, and enumerates the returned fields (names, display names, public/customizable). It distinguishes from siblings like get_entity_schema by framing this as discovery.
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 a clear use case: 'Use this to discover what data is available before diving into specific entities.' It also offers a tip to use get_entity_schema afterward, which is an explicit alternative for the next step. However, it doesn't state when not to use it relative to other siblings like fetch_query or list_workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all workflow definitions in the system, optionally with their event bindings. Each workflow may be bound to one or more entities and lifecycle events (onBeforeInsert, onAfterUpdate, etc.).
Use this to understand what business logic runs when data changes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum workflows to return (default: 50) | |
| entityFilter | No | Optional: only show workflows bound to this entity name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds useful context about workflow bindings and lifecycle events, but does not disclose potential side effects, authentication requirements, or response format details. Since this is a read-only listing, the lack of danger may be acceptable, but the description could be more explicit.
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: the first states what the tool does, the second gives the usage rationale. No wasted words or redundant information, and the key action 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 the tool's simplicity (2 optional params, no output schema), the description covers the main purpose and includes practical context about workflow bindings. It lacks an explicit statement of what the response contains (e.g., workflow names, IDs), but the schema and straightforward nature make this a minor gap.
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 100%, so the baseline is 3. The description mentions 'optionally with their event bindings' but does not elaborate on the limit or entityFilter parameters, relying on the schema for their meaning. It adds little 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 uses a specific verb ('List') with a clear resource ('all workflow definitions in the system') and adds scope ('optionally with their event bindings'). It distinguishes itself from sibling tools like get_workflow (single workflow) and execute_workflow (executes, not lists).
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 a clear use case: 'Use this to understand what business logic runs when data changes.' This tells the agent when to invoke the tool, though it does not explicitly mention alternatives or when not to use it. The context is enough for most selection scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing entity record. ⚠️ Requires Update permission on the entity.
Provide the entity name, primary key, and the properties to update. Only the properties you include will be changed — others remain unchanged. Optionally include child entity records.
IMPORTANT: This modifies real data. There is NO delete/undo via this MCP. Use get_entity_record first to see the current state before updating.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The primary key of the record to update | |
| children | No | Optional. Map of child entity names to arrays of child records. When updating children, include the full set of children you want to exist after the update (existing children not included may be removed). | |
| entityName | Yes | The entity name to update (e.g., 'ui_catalog', 'user') | |
| properties | Yes | Key-value pairs of entity property names to their new values. Only include the fields you want to change. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses the required Update permission, the fact that only included properties change, the full-replacement semantics for children, and the irreversible nature of the operation. This goes far beyond a simple 'update' statement.
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 concise and well-structured: a clear purpose line, a usage summary, and a prominent warning. Each sentence provides essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with nested objects and no output schema. The description covers permissions, partial updates, children replacement, and read-before-update. It doesn't mention what the tool returns (e.g., updated record or success message), which would normally be needed without an output schema, but it is otherwise quite 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 100% and the schema already describes each parameter. The description adds minimal parameter-specific value, mostly restating what the schema says. It does clarify the partial-update semantics for 'properties' but the schema already conveys that.
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 begins with a clear verb and resource: 'Update an existing entity record.' This distinguishes it from sibling tools like create_entity_record and get_entity_record by explicitly stating that it modifies an already-existing record.
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 advises using get_entity_record before updating and warns that there is no undo. While it doesn't explicitly say when not to use this tool, it provides clear context for safe usage and a concrete alternative for inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_entity_recordexecute_workflowfetch_queryget_entity_recordget_entity_schemaget_instance_infoget_workflowlist_entitieslist_workflowsupdate_entity_recordScored across 10 tools
Each tool targets a distinct action and resource: instance info, querying, entity metadata, entity records, and workflows. Even overlapping tools like fetch_query and get_entity_record are clearly differentiated by purpose (discovery vs. direct lookup).
Most tools follow a verb_noun pattern (get_, list_, create_, update_, execute_), but 'fetch_query' deviates from the get_/list_ convention. Entity-specific tools share a consistent 'get_entity_*' prefix, and workflow tools follow 'list/get/execute_workflow'.
With 10 tools, the set is well-scoped for the server's purpose: exploring the data model, querying data, managing entities, and executing workflows. No tool feels redundant, and the count supports a complete workflow without being bloated.
The tool surface covers metadata discovery, querying, record creation/update, and workflow execution. The explicit lack of delete functionality is a notable gap, but it is acknowledged and likely intentional for safety. Read and update paths are fully covered, so agents can accomplish most tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
