Skip to main content
Glama
seayniclabs

Lathe

by seayniclabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

lathe_modules

Read-only

Lists enabled and missing media-processing modules, shows install commands and tool purposes, and returns settings for a named module.

Instructions

Which modules are on, which pieces are missing (with the install command), and what each tool does. Pass a module name for its settings too.

Input Schema

NameRequiredDescriptionDefault
moduleNo

Output Schema

NameRequiredDescriptionDefault
skillsYes
modulesYes
versionYes
homepageNohttps://github.com/seayniclabs/lathe
publisherNoSeaynic Labs
config_fileYes
working_dirYes
config_errorYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.4.1
    • addedOutput schema / $defs / SkillInfo
      Added value: +{
+  "properties": {
+    "description": {
+      "title": "Description",
+      "type": "string"
+    },
+    "license": {
+      "title": "License",
+      "type": "string"
+    },
+    "name": {
+      "title": "Name",
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "description",
+    "license"
+  ],
+  "title": "SkillInfo",
+  "type": "object"
+}
    • addedOutput schema / properties / homepage
      Added value: +{
+  "default": "https://github.com/seayniclabs/lathe",
+  "title": "Homepage",
+  "type": "string"
+}
    • addedOutput schema / properties / publisher
      Added value: +{
+  "default": "Seaynic Labs",
+  "title": "Publisher",
+  "type": "string"
+}
    • addedOutput schema / properties / skills
      Added value: +{
+  "items": {
+    "$ref": "#/$defs/SkillInfo"
+  },
+  "title": "Skills",
+  "type": "array"
+}
    • changedOutput schema / required
      Previous value: -[
-  "version",
-  "working_dir",
-  "config_file",
-  "config_error",
-  "modules"
-]New value: +[
+  "version",
+  "working_dir",
+  "config_file",
+  "config_error",
+  "modules",
+  "skills"
+]
  2. First observedv0.3.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing what the response contains: availability state, missing pieces together with their install commands, and tool descriptions. It stops short of noting anything about cost or freshness of the module list, but for a read-only introspection call this is solid.

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?

Two sentences, no filler, and the primary output (which modules are on) is front-loaded ahead of the optional-parameter note. The parenthetical about install commands earns its place by telling the agent the response is actionable.

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?

An output schema exists, so return values need not be spelled out here, and annotations cover the safety profile. The description still conveys the two invocation modes and the nature of the payload, which is everything an agent needs to call a one-optional-parameter introspection tool correctly.

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?

Schema coverage is 0% and the single `module` parameter has no description, so the description must carry the burden. It partially does, explaining that passing a module name returns that module's settings, which establishes the overview-vs-detail semantics. It does not say what form the name takes (must it match a name from the overview list? case sensitivity?), leaving a real 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 names a concrete resource (modules) and three specific outputs: enabled modules, missing pieces with install commands, and per-tool descriptions. That is enough to separate it from every sibling, which are all media conversion utilities. The phrasing is conversational rather than verb-first, but the scope is unambiguous.

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

Usage Guidelines3/5

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

Usage is only implied: the second sentence tells the agent to pass a module name to get settings, which implicitly contrasts the no-arg overview mode with the single-module mode. There is no guidance on when to reach for this tool (e.g., before calling other tools, or when a tool fails due to a missing dependency), and no exclusions.

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