Loading ToolBench
MCP server for Loobric Core — tool-data sync for CNC manufacturing. Allows AI agents to read and assert tool catalog/instance records, manage tool sets, machines, and entries on a Loobric Server.
Strong domain-specific tool design with clear naming (verb_noun pattern), comprehensive schemas, and detailed descriptions. All 19 tools have explicit input schemas with typed parameters and descriptions. Tool names are action-oriented (list_, get_, create_, assert_, attach_, add_, remove_, query_). Descriptions average ~180 chars and explain WHAT, WHEN, and domain context well. However, output schemas are not documented in the source code, responses are inferred from API behavior rather than explicitly declared. Error handling guidance is minimal; tools lack recovery hints for common failure modes. Security considerations (provenance tracking, audit logging) are well-designed but not surfaced in tool descriptions for agent awareness.
Add tool record(s) to a tool set, keeping existing members and their numbers. Tools already in the set are skipped unless a number is claimed for them (which re-asserts it).
Assert a canonical field value on a record (tool instance, catalog, machine, tool set, or entry). Refuses to overwrite machine-measured (observed) values — measured data outranks agent assertions. The agent actor is recorded as the source.
Download media (3D model, drawing, image, etc.) from a URL and attach it to a tool record's canonical media. http(s) only — the server never reads local files. Downloads are capped at 50 MB.
Create a machine (CNC controller). Optionally assert its name and controller type.
Create a tool catalog record (a reusable type: nominal geometry, manufacturer, product code). The agent actor is recorded as the source. If client_data is sent without a client name, 'mcp' is injected — the server stores client_data only under a named client section.
Output schemas not documented in source code. Tool descriptions explain inputs but not return types, forcing LLMs to infer response structure from context.
No error recovery guidance in tool descriptions. Tools lack hints like 'If empty, call list_tool_table_entries' (present in list_tool_instance_records description but not systematized across tools).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Create a tool instance record (a physical tool). Optionally bind it to a catalog record (--from-catalog) or assert initial fields (name, geometry, etc.).
Create a tool set (a CAM-owned named collection). Optionally assert its name and initial members.
Get one machine by id, including its active setup (if any) and tool-table entries.
Get one tool catalog record by id.
Get one tool instance record, including every canonical field's provenance source (observed / asserted / derived / unknown).
Get one tool set by id, including its members and their claimed numbers.
Get one tool-table entry by id.
List machines — the physical CNC controllers the shop owns. Each machine may have an active ToolSet (a setup), a tool-table (entries), and a reconciliation view (ready/claims/notes).
List tool catalog records — reusable catalog-level types (nominal geometry, manufacturer, product code), independent of physical tools.
List the account's tool instance records — each one physical tool with canonical identity/geometry/status and per-field provenance. An EMPTY result does not mean the shop has no tools: machines may have reported tool-table entries that nobody has bound to records yet (a fresh controller sync looks exactly like that). When empty, also call list_tool_table_entries and tell the user both facts — 'no tool records defined; machine X reports N unbound entries' — and ask which they meant, rather than answering 'no tools'.
List ToolSets — CAM-owned named collections of tools. A member's number is a durable CLAIM (the T-number posted G-code will call); the machine relationship is a SETUP an operator activates (loobric use-set), never a set f
List tool-table entries — the controller's reported tool slots (number, offset, diameter, flutes, etc.). Entries are per-machine; a fresh sync looks like unbound entries with no tool record yet.
Query the audit log — the full provenance trail of who did what, when, and with what result. Filter by operation, entity type, entity id, result, user id; paginate with limit and offset.
Remove tool record(s) from a tool set, keeping the rest.
Pagination not documented for list tools. list_tool_instance_records, list_tool_catalog_records, list_tool_sets, list_machines, list_tool_table_entries, query_audit_logs accept no limit/offset parameters visible in schemas, risking unbounded result sets.
ObservedValueError exception in assert_field is not surfaced in tool description. LLMs will not know that measured values cannot be overwritten, leading to failed assertions without recovery guidance.
create_tool_catalog_record and create_tool_instance_record use generic 'fields' object parameter without enum constraints or detailed format specification. LLMs must infer valid field names from context.