Skip to main content
Glama
LBurny

CADPilot

by LBurny
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

recall_patterns

Read-onlyIdempotent

Search stored CAD workflows and code patterns by task keywords to find reusable steps before trial and error. Returns matching patterns with code or steps.

Instructions

Search the pattern memory for workflows or code like your task; do this before trial and error when your knowledge may not cover it.

Args:
    query: Keywords describing the task, e.g. "boolean cut holes cylinder".
    limit: Max results (default 3).

Returns: JSON list of matching patterns with code/steps.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.7.7
    • addedInput schema / properties / limit / maximum
      Added value: +50
    • addedInput schema / properties / limit / minimum
      Added value: +1
  2. First observedv0.4.0

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-openWorld and non-destructive, so the safety profile is covered. The description's only added behavioral content is the return shape ('JSON list with code/steps'), which largely duplicates the existing output schema, and it says nothing about memory scope or staleness.

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

Conciseness5/5

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

Front-loads the action and its timing rule, then cleanly separates Args and Returns. No filler sentences; each line conveys distinct information.

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?

Covers purpose, usage trigger, both parameters, and the return nature for a simple two-parameter read tool. The return description is partly redundant given the output schema, but nothing an agent needs to call it correctly is missing.

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 the load, and it does: query is defined as task keywords with a concrete example, and limit is explained as max results with its default. Only the upper bound (50) and format constraints are left to the schema.

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?

States a specific verb and resource: searching the pattern memory for workflows/code similar to the task. It is clearly distinguishable from save_pattern by intent (recall vs store), though it never names that sibling explicitly.

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?

Gives an explicit trigger: 'do this before trial and error when your knowledge may not cover it.' That is strong when-to-use guidance, but it offers no exclusions or named alternatives (e.g. save_pattern, operation_help) for routing.

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

Deploy Server

Other Tools