Skip to main content
Glama
Sign In

Layerz

by cc.layerz.app
OverviewDiscussionsAdmin

List models

layerz_list_models
Read-onlyIdempotent

Lists the models the authenticated user can access, and the workspaces they belong to (workspaces[]: id, name, kind personal | team, role admin | member, plan, has_conventions). Each model carries workspace_id, can_write (owner, workspace member or editor guest), url, glyph and sharing: { shared, member_count, link_visibility }. q filters by name (case- and accent-insensitive substring, * wildcard), writable: true keeps owner/editor models only. A model-scoped key gets its bound model only.

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_list_models"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoName filter: case- and accent-insensitive substring ("swoop" matches "SWOOP - BP 2026", "homelior" matches "Homélior"); `*` is a wildcard, `%`, `_` and `&` are literal.
writableNoWhen true, only models the caller can edit (owner or editor).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / q / description
      Previous value: -"Name filter: case-insensitive substring (\"swoop\" matches \"SWOOP - BP 2026\"); `*` is a wildcard, `%`, `_` and `&` are literal."New value: +"Name filter: case- and accent-insensitive substring (\"swoop\" matches \"SWOOP - BP 2026\", \"homelior\" matches \"Homélior\"); `*` is a wildcard, `%`, `_` and `&` are literal."
  2. Changed2 schema fields changed
    • changedInput schema / properties / q / description
      Previous value: -"Optional name search filter. Substring, case-insensitive (e.g. \"swoop\" matches \"SWOOP - BP 2026\"). Use \"*\" as a wildcard; \"%\", \"_\" and \"&\" are literal."New value: +"Name filter: case-insensitive substring (\"swoop\" matches \"SWOOP - BP 2026\"); `*` is a wildcard, `%`, `_` and `&` are literal."
    • changedInput schema / properties / writable / description
      Previous value: -"When true, returns only models the caller can edit (owner or editor). Omit to return all accessible models."New value: +"When true, only models the caller can edit (owner or editor)."
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare a safe, idempotent read, and the description goes well beyond that: it defines what 'can_write' means (owner, workspace member or editor guest), spells out the per-model fields returned, and explains the auth-scoped-key behavior. This is exactly the permission and scope context an agent needs before calling.

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 purpose is front-loaded in the first clause, and every following sentence carries real information about return shape, filtering or auth scope. It is dense with parenthetical field lists, which makes it heavy to scan but not padded.

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?

There is no output schema, so the description must describe the return value, and it does so thoroughly with the workspaces, workspace_id, can_write, url, glyph and sharing fields. Combined with the filter and key-scope notes, an agent has everything needed to call it 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 100%, so both parameters are already fully documented, and the description mostly restates them ('q' filters by name, 'writable' keeps owner/editor models). It adds no syntax or edge-case detail beyond the schema, so the baseline 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?

The description opens with a specific verb and resource: it lists models the authenticated user can access plus their workspaces. It clearly distinguishes this from layerz_get_model (single model) and layerz_create_model by making the collection and access-scope explicit.

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?

It gives concrete filter conditions ('q' filters by name, 'writable: true' keeps owner/editor models only) and tells the agent that model-scoped keys return only the bound model. It does not explicitly route to a sibling such as layerz_get_model for fetching a single model, so the exclusions are implicit rather than stated.

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