Skip to main content
Glama
Sign In

Layerz

by cc.layerz.app
OverviewDiscussionsAdmin

Validate model

layerz_validate_model
Read-onlyIdempotent

Runs the core model validator (structural / formula / timeline checks) without writing and returns { ok, error_count, warning_count, errors[], warnings[] }; each issue carries a code (e.g. UNKNOWN_UID, CIRCULAR_DEPENDENCY, INVALID_ROLE_CHILD, TIMELINE_MISMATCH), a message and item_uids. The write path auto-repairs some of these issues and enforces a few invariants this audit skips, so ok: true is a sanity signal rather than a write guarantee.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "layerz_validate_model"
  }
}

Input Schema

NameRequiredDescriptionDefault
model_idNoTarget model UUID. Required for user-scoped API keys; validated against the bound model for model-scoped keys.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / model_id / description
      Previous value: -"Target model UUID. Required for user-scoped API keys; ignored (or validated against scope) for model-scoped keys."New value: +"Target model UUID. Required for user-scoped API keys; validated against the bound model for model-scoped keys."
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context on top: it discloses the exact result envelope, the per-issue fields (`code`, `message`, `item_uids`), sample codes, and the important caveat that the write path repairs some of these issues and enforces invariants this audit skips, so `ok: true` is not a write guarantee. That caveat is the kind of behavioral detail annotations cannot carry; only the missing detail is any note on cost/scope (e.g. large-model runtime).

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?

Two sentences, front-loaded with the action and its non-writing nature, then the return shape, then the interpretive caveat. Every clause carries information an agent needs; there is no restatement of the title or filler.

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?

With no output schema, the description takes on the burden of describing the return value and does so precisely, including field names and issue codes. Combined with the write-path caveat, an agent has everything needed to call this and interpret the result 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 description coverage is 100% and the single `model_id` parameter is fully documented there, including the user-scoped vs model-scoped key behavior, so the description adds nothing about parameters and the baseline of 3 applies.

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 ('Runs the core model validator') and enumerates the check families it covers (structural / formula / timeline), which cleanly separates it from siblings like layerz_diff, layerz_patch, or layerz_read that also touch a model but do different work.

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 implied rather than stated: 'without writing' and the note that the write path auto-repairs some issues suggest this is a pre-write audit, but the description never says 'use before layerz_patch' or names any alternative, and it gives no explicit when-not conditions.

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

All Layerz toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources