FreeCAD Tutor MCP

Overview Schema Source Related Servers Discussions Admin

find_ui_command

Read-onlyIdempotent

Search live FreeCAD commands to locate menu paths, toolbars, shortcuts, and diagnose why a UI button is greyed out; filter by workbench and limit results.

Instructions

Search live FreeCAD commands for menu paths, toolbars, shortcuts, and why a button is greyed out.

Args: query: Keyword such as 'Pad', 'Fillet', 'Sketch', or 'TechDraw'. workbench_filter: Optional command prefix filter (e.g. 'PartDesign', 'Sketcher'). limit: Max results (1-50).

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": {
      "query": "<query>"
    },
    "name": "find_ui_command"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`workbench_filter`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 14, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds that results come from 'live' command state, which implies results vary with current UI/workbench context. It does not cover ordering, matching semantics, or why some commands may be absent, which limits it to a modest addition.

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?

The capability sentence is front-loaded and the args block is compact with one line per parameter. Given 0% schema coverage, the per-parameter lines earn their place. Slight redundancy between 'workbench_filter' naming and its restatement, but nothing wasteful.

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?

With only three parameters, an output schema present, and rich annotations, the description covers purpose, triggers, and all parameter meanings including a range constraint. Remaining omissions (match semantics, result ordering) are minor for a read-only lookup tool.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: 'query' is a keyword with concrete examples, 'workbench_filter' is described as a command prefix filter with example prefixes, and 'limit' is bounded 1-50 (a constraint absent from the schema, which only shows default 15). It does not specify matching behavior (partial vs exact, case sensitivity), leaving one gap.

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

Purpose4/5

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

The description gives a specific verb and resource ('Search live FreeCAD commands') and enumerates what the search surfaces: menu paths, toolbars, shortcuts, and disabled-button reasons. This is unambiguous and readable without opening the schema. It stops short of naming a sibling (e.g. highlight_ui_element), so it does not fully satisfy the differentiation criterion for a 5.

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

Usage Guidelines4/5

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

'why a button is greyed out' is an explicit problem-solving trigger, and the menu-path/toolbar/shortcut framing tells the agent this is a discovery/lookup tool rather than an action tool. No exclusions or alternative tools are named, so the guidance is clear context without routing.

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

Deploy Server