Skip to main content
Glama
FlexSim MCP Server

FlexSim MCP Server

by fateedit

delete_object

Removes a FlexSim object or model tree node; the operation is asynchronous (3-8 seconds), so retry the deletion later to confirm instead of checking immediately.

Instructions

如未先读操作指南,请先调用 get_guide。删除对象/节点。注意:删除是异步操作,3~8 秒后模型界面才生效;删除后不能立即用 get_node 判断是否成功(会误报残留),应稍后重试 delete_object 看是否返回 not found。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "object": "<object>"
    },
    "name": "delete_object"
  }
}

Input Schema

NameRequiredDescriptionDefault
objectYes对象/节点名

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden, and it delivers the key non-obvious behavior: deletion is asynchronous and only takes effect in the model UI after roughly 3–8 seconds, which invalidates naive verification via get_node. It does not state whether deletion is irreversible, whether dependent connections are removed, or what permission/state is required, so it falls short of a full behavioral picture for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded: the guide prerequisite comes first, then the purpose, then the async caveat and the verification pitfall. The caveat sentence is somewhat long and could be tightened, but every clause carries actionable information about timing and retry behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter destructive tool with no annotations and no output schema, the description covers the critical gaps: the prerequisite guide, asynchronous timing, and how to correctly verify success. It stops short of stating irreversibility or side effects on related objects/connections, which an agent performing a delete would reasonably want.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter (object) with 100% schema description coverage, so the schema already explains its meaning. The description adds no syntax, naming-convention, or identifier-format detail beyond what the schema provides, which is the baseline expectation at full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("删除对象/节点" – delete object/node) that is unambiguously distinct from siblings such as create_object, add_node and rename_node. An agent can identify the operation without inspecting the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit prerequisite (call get_guide first if the guide has not been read) and explicit when-not guidance: do not use get_node immediately afterwards because it will falsely report the node as still present. It also prescribes the correct follow-up (retry delete_object and look for not found), which routes the agent away from a misleading sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.