kernelCAD

Look Up Authoring Skill

lookup_authoring_skill

Read-only

Return the kernelcad-authoring skill — conventions for writing .kcad.ts scripts (API surface, parameters, evaluation contract, common pitfalls) — in sections.

Call with NO arguments first: you get the quick-start (units, axes, the return rule, the rules that prevent most failures, the intent → API routing table, the "Before you finish" checklist) and an index of every section with a one-line summary (under 16k chars). Then pull what you need: { section: "<id>" } returns one section (e.g. "top-level-functions", "materials", "dfm-gates-print-readiness"); { query: "fillet after subtract" } returns the best-matching sections. { section: "all" } returns the full ~140k-char skill (SKILL.md plus its reference files) — only if your client accepts large responses.

Clients that list resources can also read kernelcad://skills/authoring (the SKILL.md core).

OUTPUT: { uri, mimeType, mode, text, sections? } — mode is index | section | search | all | not-found.

Input Schema

Name	Required	Description
`query`	No	Keywords to search section titles and bodies (e.g. "sweep along helix").
`topic`	No	Alias of section; also accepts a loose title such as 'materials' or 'cli commands'.
`section`	No	Section id from the index (e.g. 'top-level-functions'), or 'all' for the full skill.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 16, 2026

changedInput schema / properties / section / description

Previous value: -"Section id from the index (e.g. 'top-level-functions'), or 'all' for the full SKILL.md."New value: +"Section id from the index (e.g. 'top-level-functions'), or 'all' for the full skill."

Changed1 schema field changedOct 11, 2026

removedOutput schema / properties

Removed value: -{
-  "mimeType": {
-    "description": "MIME type of the returned body.",
-    "type": "string"
-  },
-  "mode": {
-    "description": "index | section | search | all | not-found.",
-    "type": "string"
-  },
-  "sections": {
-    "description": "Section ids returned in text (section and search modes).",
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  "text": {
-    "description": "The index + quick-start, the requested section(s), or the full SKILL.md body.",
-    "type": "string"
-  },
-  "uri": {
-    "description": "The authoring-skill resource URI.",
-    "type": "string"
-  }
-}

Changed6 schema fields changedSep 29, 2026

addedInput schema / properties / query

Added value: +{
+  "description": "Keywords to search section titles and bodies (e.g. \"sweep along helix\").",
+  "type": "string"
+}

addedInput schema / properties / section

Added value: +{
+  "description": "Section id from the index (e.g. 'top-level-functions'), or 'all' for the full SKILL.md.",
+  "type": "string"
+}

addedInput schema / properties / topic

Added value: +{
+  "description": "Alias of section; also accepts a loose title such as 'materials' or 'cli commands'.",
+  "type": "string"
+}

addedOutput schema / properties / mode

Added value: +{
+  "description": "index | section | search | all | not-found.",
+  "type": "string"
+}

addedOutput schema / properties / sections

Added value: +{
+  "description": "Section ids returned in text (section and search modes).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / properties / text / description

Previous value: -"The SKILL.md body."New value: +"The index + quick-start, the requested section(s), or the full SKILL.md body."

Changed1 schema field changedJun 15, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "mimeType": {
+      "description": "MIME type of the returned body.",
+      "type": "string"
+    },
+    "text": {
+      "description": "The SKILL.md body.",
+      "type": "string"
+    },
+    "uri": {
+      "description": "The authoring-skill resource URI.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedMay 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/destructive-safe behavior, and the description goes well beyond them: response-size expectations (index under 16k chars, full skill ~140k chars), the caveat that 'all' should only be used if the client accepts large responses, the exact mode values the response can take, and the resource URI alternative. This is rich operational context not derivable from structured fields.

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?

Front-loads the core purpose and the progressive-disclosure workflow, with the output-shape and resource notes trailing. Dense and mostly waste-free, though the OUTPUT line and resource mention are slightly redundant given an output schema exists.

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

Completeness5/5

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

For a read-only lookup tool with an output schema, annotations, and 100%-covered parameters, the description supplies everything an agent needs: what is returned, how to page through it, size limits, and fallback access paths. Nothing material 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 coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by explaining the no-argument default behavior, the special `section: "all"` value, the search-vs-section distinction, and worked examples ('fillet after subtract', 'top-level-functions'). It stops short of exhaustively documenting every section id — that is left to the returned index.

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 — returns the kernelcad-authoring skill, described precisely as conventions for writing .kcad.ts scripts (API surface, parameters, evaluation contract, pitfalls). The scope is unambiguous and distinct from lookup_api/lookup_cookbook/lookup_diagnostics, which cover different reference corpora.

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?

Explicitly prescribes the calling sequence: 'Call with NO arguments first' to get the quick-start and index, then pull specific sections via `{ section: "<id>" }`, search via `{ query: ... }`, or fetch everything via `{ section: "all" }`. It also names the resource-read alternative for clients that support it. This is genuine when/how-to-use guidance.

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

All kernelCAD tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.