Which integrations are available for this server?

Provides tools for building Laravel applications, including creating controllers, models, middleware, services, and methods with type hints, and managing file structures and dependencies. Provides tools for building Vue.js components, including creating files with Vue SFC support, converting HTML to Stellify elements, and managing reactive refs and imports.

How do I use Stellify MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Stellify MCP Server Create a UserController with a store method" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Stellify MCP Server

Official

by Stellify-Software-Ltd

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Stellify MCP Server

npm version License: MIT

Model Context Protocol (MCP) server for Stellify - the AI-native code generation platform.

What is This?

This MCP server lets AI assistants (like Claude Desktop) interact with your Stellify projects to build Laravel and Vue.js applications incrementally. Instead of generating full code files at once, AI can:

Create file structures (classes, controllers, models, middleware, Vue components)
Add method signatures with type hints
Parse PHP/JavaScript code into structured JSON (statement-by-statement)
Convert HTML to Stellify elements in a single operation
Search existing code in your projects
Install reusable code from the global library
Build applications through natural conversation

Related MCP server: Laravel AI MCP Server

Quick Start

Prerequisites

Node.js 18 or higher
A Stellify account - Sign up at stellisoft.com
Claude Desktop (or another MCP-compatible AI client)

Installation

Install globally via npm:

npm install -g @stellisoft/stellify-mcp

Configuration

Get your Stellify API token:
- Log into Stellify
- Navigate to Settings → API Tokens
- Click "Create New Token"
- Copy your token
Configure Claude Desktop:
Edit your Claude Desktop configuration file:
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%\Claude\claude_desktop_config.json
- Linux: ~/.config/claude/claude_desktop_config.json
Add the Stellify MCP server:
```
{
  "mcpServers": {
    "stellify": {
      "command": "stellify-mcp",
      "env": {
        "STELLIFY_API_URL": "https://api.stellisoft.com/v1",
        "STELLIFY_API_TOKEN": "your-token-here"
      }
    }
  }
}
```
Restart Claude Desktop

That's it! The Stellify tools should now be available in Claude Desktop.

Usage

Once configured, you can talk to Claude naturally to build applications:

Example Conversations

Create a new controller:

"Create a UserController in my Stellify project"

Add methods:

"Add a method called 'store' that takes a Request parameter and returns a JsonResponse"

Implement method logic:

"Add this implementation to the store method:
$user = User::create($request->validated());
return response()->json($user, 201);"

Build a Vue component:

"Create a Counter component with an increment button"

Convert HTML to elements:

"Convert this HTML to Stellify elements:
<div class='container'><h1>Hello</h1><button>Click me</button></div>"

Search your codebase:

"Search for all controller files in my project"
"Find methods related to authentication"

Available Tools

Project & Directory Tools

`get_project`

Get the active Stellify project for the authenticated user. Call this first before any other operations.

Parameters: None

Returns:

uuid: Project UUID (needed for most operations)
name: Project name
directories: Array of {uuid, name} for existing directories

`get_directory`

Get a directory by UUID to see its contents.

Parameters:

uuid (required): The UUID of the directory

`create_directory`

Create a new directory for organizing files.

Parameters:

name (required): Directory name (e.g., "js", "css", "components")

File Tools

`create_file`

Create a new file in a Stellify project. This creates an empty file shell - no methods, statements, or template yet.

Parameters:

directory (required): UUID of the directory (get from get_project directories array)
name (required): File name without extension (e.g., "Counter", "UserController")
type (required): File type - "class", "model", "controller", "middleware", or "js"
extension (optional): File extension. Use "vue" for Vue components.
namespace (optional): PHP namespace (e.g., "App\Services\"). Only for PHP files.
includes (optional): Array of fully-qualified class names to import (e.g., ["App\\Models\\User", "Illuminate\\Http\\Request"]). Stellify will resolve these to file UUIDs, fetching from Laravel API or vendor directory if needed.

Directory selection: Match the directory to your file's purpose. If the directory doesn't exist, create it first with create_directory.

File Type	Directory	Namespace
Controllers	`controllers`	`App\Http\Controllers\`
Models	`models`	`App\Models\`
Services	`services`	`App\Services\`
Middleware	`middleware`	`App\Http\Middleware\`
Vue/JS	`js`	N/A

Example workflow:

create_file → creates empty shell, returns file UUID
create_statement + add_statement_code → add variables/imports
create_method + add_method_body → add functions
html_to_elements → create template elements (for Vue)
save_file → finalize with all UUIDs wired together

Auto-dependency creation (when auto_create_dependencies: true):

When you create a file with code like:

<?php
namespace App\Http\Controllers;

use App\Models\User;
use Illuminate\Http\Request;

class UserController extends Controller
{
    public function store(Request $request)
    {
        $user = User::create($request->validated());
        return response()->json($user);
    }
}

Stellify will:

Parse use statements to find dependencies (User, Request, Socialite)
Check Application DB for framework classes → find cached classes
For core Laravel classes → fetch from api.laravel.com
For vendor packages (Socialite, Spatie, etc.) → read from vendor/ directory
Create missing App classes → create User model file
Wire up the file's includes array with all dependency UUIDs

Supported sources:

Laravel API - Core Illuminate\* classes fetched from api.laravel.com
Vendor packages - Laravel\Socialite\*, Laravel\Cashier\*, Spatie\*, Livewire\*, etc. read directly from your vendor/ directory using PHP-Parser

The response includes a dependencies report showing what was created/resolved and from which source.

`get_file`

Get a file by UUID with all its metadata, methods, and statements.

Parameters:

uuid (required): UUID of the file

`save_file`

Save/update a file with its full configuration. This finalizes the file after create_file.

Parameters:

uuid (required): UUID of the file
name (required): File name (without extension)
type (required): File type ("js", "class", "controller", "model", "middleware")
extension (optional): File extension ("vue" for Vue SFCs)
template (optional): Array of root element UUIDs for Vue <template> section
data (optional): Array of METHOD UUIDs only (functions)
statements (optional): Array of STATEMENT UUIDs (imports, variables, refs)
includes (optional): Array of file UUIDs to import

Important: data = method UUIDs only, statements = statement UUIDs (code outside methods)

`search_files`

Search for files in the project by name or type.

Parameters:

name (optional): File name pattern to search for
type (optional): File type filter

Method Tools

`create_method`

Create a method signature in a file (without implementation).

Parameters:

file (required): UUID of the file to add the method to
name (required): Method name (e.g., "increment", "store", "handleClick")
visibility (optional): "public", "protected", or "private" (PHP only, default: "public")
is_static (optional): Whether the method is static (PHP only, default: false)
returnType (optional): Return type (e.g., "int", "string", "void")
parameters (optional): Array of {name, type} objects

`add_method_body`

Parse and add code to a method body. Stellify parses the code into structured JSON statements.

Parameters:

file_uuid (required): UUID of the file containing the method
method_uuid (required): UUID of the method to add code to
code (required): Code for the method body (just the statements, no function declaration)

Example:

code: "return $a + $b;"

`search_methods`

Search for methods in the project by name or within a specific file.

Parameters:

name (optional): Method name to search for (supports wildcards)
file_uuid (optional): Filter results to a specific file

Statement Tools

`create_statement`

Create an empty statement in a file. This is step 1 of 2 - you must call add_statement_code next.

Parameters:

file (optional): UUID of the file to add the statement to
method (optional): UUID of the method to add the statement to (for method body statements)

Use cases:

PHP: Class properties, use statements, constants
JS/Vue: Variable declarations, imports, reactive refs

`add_statement_code`

Add code to an existing statement. This is step 2 of 2 - call after create_statement.

Parameters:

file_uuid (required): UUID of the file containing the statement
statement_uuid (required): UUID of the statement to add code to
code (required): The code to add

Examples:

code: "use Illuminate\\Http\\Request;"
code: "const count = ref(0);"
code: "import { ref } from 'vue';"

`get_statement`

Get a statement by UUID with its clauses (code tokens).

Parameters:

uuid (required): The UUID of the statement

Route Tools

`create_route`

Create a new route/page in a Stellify project.

Parameters:

project_id (required): The UUID of the Stellify project
name (required): Route/page name (e.g., "Home", "Counter", "About")
path (required): URL path (e.g., "/", "/counter", "/about")
method (required): HTTP method ("GET", "POST", "PUT", "DELETE", "PATCH")
type (optional): Route type - "web" for pages, "api" for API endpoints (default: "web")
data (optional): Additional route data

`get_route`

Get a route/page by UUID.

Parameters:

uuid (required): The UUID of the route

`search_routes`

Search for routes/pages in the project by name.

Parameters:

search (optional): Search term to match route names
type (optional): Filter by route type ("web" or "api")
per_page (optional): Results per page (default: 10)

Views & Blade Templates

Stellify stores Blade views as elements instead of files. The root element's name field maps to the view name:

Element with name="notes.index" → view('notes.index', $data)
Element with name="layouts.app" → @extends('layouts.app')
Element with name="components.card" → <x-card>

Use update_element to set the name on a root element after creating it with html_to_elements.

Convention for reusable templates: Attach layouts, components, and partials to a template route (e.g., /template/app-layout, /template/card) to keep them organized and editable.

Element Tools (UI Components)

`create_element`

Create a new UI element. Provide either page (route UUID) for root elements, or parent (element UUID) for child elements.

Parameters:

type (required): Element type - one of:
- HTML5: s-wrapper, s-input, s-form, s-svg, s-shape, s-media, s-iframe
- Components: s-transition, s-freestyle, s-motion
- Blade: s-directive
- Shadcn/ui: s-chart, s-table, s-combobox, s-accordion, s-calendar, s-contiguous
page (optional): UUID of the page/route (for root elements)
parent (optional): UUID of the parent element (for child elements)

Using s-directive for Blade Conditionals:

s-directive elements output Blade directives (like @if, @foreach, @endif). They are sibling elements — they don't wrap children. To conditionally render content:

Create an s-directive element with a statement for the opening directive (e.g., @if(...))
Create the content element(s) as the next sibling(s)
Create another s-directive element with a statement for the closing directive (e.g., @endif)

Example — conditionally showing an image:

// 1. Create statement for @if
create_statement_with_code({
  file: "<file-uuid>",
  code: "@if($item->featured_image)"
})

// 2. Create opening directive element and set its statement
create_element({ type: "s-directive", page: "<route-uuid>" })
update_element({ uuid: "<if-directive-uuid>", data: { "statement": "<if-statement-uuid>" } })

// 3. Create the image as the next sibling
html_to_elements({ page: "<route-uuid>", elements: "<img class=\"w-full\" />" })
// Then update with dynamic src:
update_element({ uuid: "<img-uuid>", data: { "srcField": "featured_image" } })

// 4. Create statement for @endif
create_statement_with_code({ file: "<file-uuid>", code: "@endif" })

// 5. Create closing directive element
create_element({ type: "s-directive", page: "<route-uuid>" })
update_element({ uuid: "<endif-directive-uuid>", data: { "statement": "<endif-statement-uuid>" } })

The three elements render in order as siblings:

@if($item->featured_image)
<img class="w-full" src="{{ $item->featured_image }}" />
@endif

Using s-directive for Loops:

// 1. Create @foreach directive
create_statement_with_code({ file: "<file-uuid>", code: "@foreach($posts as $item)" })
create_element({ type: "s-directive", page: "<route-uuid>" })
update_element({ uuid: "<foreach-uuid>", data: { "statement": "<foreach-statement-uuid>" } })

// 2. Create loop content (article with dynamic fields)
html_to_elements({ page: "<route-uuid>", elements: "<article><h2></h2><p></p></article>" })
// Update elements to use loop item fields:
update_element({ uuid: "<h2-uuid>", data: { "textField": "title" } })  // → {{ $item->title }}
update_element({ uuid: "<p-uuid>", data: { "textField": "excerpt" } }) // → {{ $item->excerpt }}

// 3. Create @endforeach directive
create_statement_with_code({ file: "<file-uuid>", code: "@endforeach" })
create_element({ type: "s-directive", page: "<route-uuid>" })
update_element({ uuid: "<endforeach-uuid>", data: { "statement": "<endforeach-statement-uuid>" } })

Loop Item Attributes: Inside @foreach loops, use these attributes on elements to reference $item:

textField: "fieldName" → outputs {{ $item->fieldName }}
hrefField: "fieldName" → outputs href="{{ $item->fieldName }}"
srcField: "fieldName" → outputs src="{{ $item->fieldName }}"
hrefExpression: "{{ route('posts.show', $item->slug) }}" → for complex expressions
srcExpression, altExpression → same pattern for other attributes

`update_element`

Update an existing UI element.

Parameters:

uuid (required): UUID of the element to update
data (required): Object with HTML attributes and Stellify fields

Standard HTML attributes: placeholder, href, src, type, etc.

Stellify fields:

name: Element name in editor
type: Element type
locked: Prevent editing (boolean)
tag: HTML tag (div, input, button, etc.)
classes: CSS classes array ["class1", "class2"]
text: Static text content
statements: Array of statement UUIDs for dynamic Blade content

Loop item fields (for elements inside @foreach loops, references $item):

textField: Field name → outputs {{ $item->fieldName }}
hrefField: Field name → outputs href="{{ $item->fieldName }}"
srcField: Field name → outputs src="{{ $item->fieldName }}"

Expression attributes (for complex Blade expressions):

hrefExpression: Full Blade expression for href (e.g., "{{ route('posts.show', $item->slug) }}")
srcExpression: Full Blade expression for src
altExpression: Full Blade expression for alt

Event handlers (set value to method UUID):

click: @click
submit: @submit
change: @change
input: @input
focus: @focus
blur: @blur
keydown: @keydown
keyup: @keyup
mouseenter: @mouseenter
mouseleave: @mouseleave

`get_element`

Get a single element by UUID.

Parameters:

uuid (required): UUID of the element

`get_element_tree`

Get an element with all its descendants as a hierarchical tree structure.

Parameters:

uuid (required): UUID of the root element

`delete_element`

Delete an element and all its children (CASCADE).

Parameters:

uuid (required): UUID of the element to delete

`search_elements`

Search for elements in the project.

Parameters:

search (optional): Search query to match element name, type, or content
type (optional): Filter by element type
include_metadata (optional): Include additional metadata (default: false)
per_page (optional): Results per page, 1-100 (default: 20)

`html_to_elements`

Convert HTML to Stellify elements in ONE operation. This is the fastest way to build interfaces!

Parameters:

elements (required): HTML string to convert
page (optional): Route UUID to attach elements to. Omit for Vue components.
selection (optional): Parent element UUID to attach to (alternative to page)
file (optional): Vue component file UUID. Pass this to auto-wire @click handlers to method UUIDs.
test (optional): If true, returns structure without creating elements

⚠️ CRITICAL: Multiple Root Elements

When passing HTML with multiple root-level elements (e.g., <header>, <main>, <footer>), only the FIRST root element gets attached to the route via routeParent. Other elements are created but become orphaned (not attached to the route).

Wrong approach (causes orphaned elements):

html_to_elements(page: routeUUID, elements: "<header>...</header><main>...</main><footer>...</footer>")
// Result: Only <header> is attached to the route. <main> and <footer> are orphaned!

Correct approach (make separate calls for each root element):

// Call 1: Header
html_to_elements(page: routeUUID, elements: "<header>...</header>")

// Call 2: Main content
html_to_elements(page: routeUUID, elements: "<main>...</main>")

// Call 3: Footer
html_to_elements(page: routeUUID, elements: "<footer>...</footer>")

Features:

Parses HTML structure
Creates all elements with proper nesting
Preserves attributes, classes, text content
Auto-detects Vue bindings ({{ variable }}) and creates linked statements
Returns element UUIDs for use in save_file template array

Element type mapping:

button, input, textarea, select → s-input
div, span, p, section, etc. → s-wrapper
form → s-form
img, video, audio → s-media

Global Library Tools

`list_globals`

List all global files in the Application database. Globals are reusable, curated code that can be installed into tenant projects.

Parameters: None

`get_global`

Get a global file with all its methods, statements, and clauses.

Parameters:

uuid (required): UUID of the global file

`install_global`

Install a global file from the Application database into a tenant project.

Parameters:

file_uuid (required): UUID of the global file to install
directory_uuid (required): UUID of the directory to install into

`search_global_methods`

Search for methods across the Application database (global/framework methods).

Parameters:

query (required): Search query to find methods by name

Module Tools

Modules are named collections of related global files that can be installed together.

`list_modules`

List all available modules.

Parameters: None

`get_module`

Get a module with all its files.

Parameters:

uuid (required): UUID of the module

`create_module`

Create a new module to group related global files.

Parameters:

name (required): Unique name for the module (e.g., "laravel-sanctum-auth")
description (optional): Description of what the module provides
version (optional): Version string (default: "1.0.0")
tags (optional): Tags for categorization (e.g., ["auth", "api", "sanctum"])

`add_file_to_module`

Add a global file to a module.

Parameters:

module_uuid (required): UUID of the module
file_uuid (required): UUID of the global file to add
order (optional): Installation order (auto-increments if not specified)

`install_module`

Install all files from a module into a tenant project.

Parameters:

module_uuid (required): UUID of the module to install
directory_uuid (required): UUID of the directory to install files into

How Stellify Works

Stellify stores your application code as structured JSON in a database, not text files. This architecture enables:

Surgical precision: AI modifies specific methods without touching other code
Query your codebase like data: Find all methods that use a specific class
Instant refactoring: Rename a method across your entire application instantly
Version control at the statement level: Track changes to individual code statements
AI-native development: Give AI granular access without worrying about breaking existing code
Auto-dependency resolution: Framework classes are automatically fetched from Laravel API docs

When you build with Stellify through this MCP server, code is parsed into structured data and can be assembled back into executable code when you deploy.

Dependency Resolution

When you use auto_create_dependencies, Stellify resolves dependencies in this order:

Tenant Database - Check if the class exists in your project
Application Database - Check the global library of pre-defined classes
Laravel API Docs - For core Illuminate\* classes, fetch from api.laravel.com
Vendor Directory - For installed packages, read directly from vendor/

Supported Package Sources

Source	Namespaces	Method
Laravel API	`Illuminate\*`	Fetches from api.laravel.com
Vendor	`Laravel\Socialite\*`	Reads from vendor/laravel/socialite
Vendor	`Laravel\Cashier\*`	Reads from vendor/laravel/cashier
Vendor	`Laravel\Sanctum\*`	Reads from vendor/laravel/sanctum
Vendor	`Laravel\Passport\*`	Reads from vendor/laravel/passport
Vendor	`Spatie\*`	Reads from vendor/spatie/* packages
Vendor	`Livewire\*`	Reads from vendor/livewire/livewire
Vendor	`Inertia\*`	Reads from vendor/inertiajs/inertia-laravel

For vendor packages, Stellify uses PHP-Parser to extract the actual method signatures from your installed package version - ensuring accuracy with your specific dependencies.

Code Structure

Directory
  └── File
        └── Method
              ├── Parameters (Clauses)
              └── Statements
                    └── Clauses / Language Tokens

Each piece of code is broken down into:

Directory: Organizational container for files
File: Contains methods and file metadata
Method: Function with parameters and body statements
Statement: A single line/statement of code
Clause: Leaf node (variable, string, number, etc.)
Language Token: System-defined keywords and symbols (reusable)

Workflows

PHP Controller Workflow

get_project → Find directory UUID
create_file → type='controller', name='UserController'
create_method → name='store', parameters=[{name:'request', type:'Request'}]
add_method_body → code='return response()->json($request->all());'

Vue Component Workflow

get_project → Find the 'js' directory UUID
create_file → type='js', extension='vue' in js directory
Create statements for imports and data:
- create_statement + add_statement_code: "import { ref } from 'vue';"
- create_statement + add_statement_code: "const count = ref(0);"
create_method + add_method_body → Create functions
html_to_elements → Convert template HTML to elements
update_element → Wire event handlers (click → method UUID)
save_file → Finalize with:
- extension: 'vue'
- template: [rootElementUuid]
- data: [methodUuid] (METHOD UUIDs only)
- statements: [importStmtUuid, refStmtUuid] (STATEMENT UUIDs)

Development

Watch mode (auto-rebuild on changes):

npm run watch

Manual build:

npm run build

Troubleshooting

"STELLIFY_API_TOKEN environment variable is required"

Make sure your .env file exists and contains your API token.

"Connection refused" or API errors

Verify your API token is valid
Check that STELLIFY_API_URL is correct
Test the API directly: curl -H "Authorization: Bearer YOUR_TOKEN" https://stellisoft.com/api/v1/file/search

Claude Desktop doesn't see the tools

Verify the configuration file path is correct for your OS
Check that the Stellify API token is valid
Restart Claude Desktop completely (Quit, not just close window)
Check Claude Desktop logs for error messages

TypeScript errors during build

rm -rf node_modules package-lock.json
npm install
npm run build

Installation issues

# Clear npm cache and reinstall
npm cache clean --force
npm uninstall -g @stellisoft/stellify-mcp
npm install -g @stellisoft/stellify-mcp

Architecture

Claude Desktop (AI)
       ↓ (stdio)
Stellify MCP Server (Node.js)
       ↓ (HTTPS)
Stellify API (Laravel)
       ↓
Database (Structured Code)

The MCP server is a thin client that:

Exposes tools to Claude
Translates tool calls to API requests
Returns formatted responses

Contributing

We welcome contributions! Please see our contributing guidelines and feel free to submit pull requests.

Support

For issues or questions:

GitHub Issues: Report a bug or request a feature
Email: support@stellisoft.com
Documentation: https://stellisoft.com/docs
Discord: Join our community (coming soon)

About Stellify

Stellify is building the future of AI-native software development. By storing code as structured data instead of text files, we enable a new paradigm where AI and humans collaborate seamlessly to build better software, faster.

Learn more at stellisoft.com

License

MIT License - see LICENSE file for details

Built with love by the Stellify team

Available Tools

50 tools

add_method_bodyA

Append code to an existing method. Use this when you need to ADD MORE code to a method that already has statements.

For new methods: Use create_method with the body parameter instead - it creates the method with code in one call.

Nested code is handled correctly. The parser tracks brace/bracket/paren depth and only splits on semicolons at the top level. Arrow functions with block bodies, computed properties, and other nested constructs work as single statements.

Pass 'types' to specify TypeScript types for variables declared in the code.

IMPORTANT: This APPENDS to existing method statements. To REPLACE a method's code entirely:

Create a NEW method with create_method (with body parameter)
Update the file's 'data' array to include new method UUID (remove old one)
Update any element click handlers to reference the new method UUID
Delete the old method with delete_method

ParametersJSON Schema

Name	Required	Description
`file`	Yes	UUID of the file containing the method
`method`	Yes	UUID of the method to add code to
`code`	Yes	PHP code for the method body (just the statements, no function declaration). Example: "return $a + $b;"
`types`	No	Map of variable names to their base TypeScript types (e.g., { "result": "Todo" }). The assembler infers full types from code structure.

TDQS

A4.9/5.0

Behavior5/5

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

No annotations provided, so the description carries full burden. It discloses appending behavior, nested code handling (brace depth), and contrasts with replacement scenario. No contradictions with annotations.

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?

Well-structured with clear sections and front-loaded purpose. Slightly verbose with the replacement steps, but each sentence adds value. Minor conciseness improvement possible.

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?

Despite no output schema, the description covers all necessary context: when to use, behavior, parameter details, and alternative workflows. Complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds significant value: for 'code' it specifies PHP code, statements only, and provides an example; for 'types' it explains map of variable names and assembler inference. Enhances schema meaning.

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 explicitly states 'Append code to an existing method' with a specific verb and resource. It distinguishes itself from sibling tools like 'create_method' which is for new methods, making the purpose clear and unique.

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?

Provides explicit when-to-use (adding more code to an existing method) and when-not-to-use (new methods should use 'create_method'). Also offers a detailed alternative for replacing code entirely, giving complete guidance.

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

add_statement_codeA

Add code to an existing statement. This is step 2 of 2 - call this AFTER create_statement.

ALTERNATIVE: Use create_statement_with_code for a single-call approach that combines both steps.

The statement must already exist (created via create_statement). This parses and stores the code.

Examples:

PHP: "use Illuminate\Http\Request;" or "private $items = [];"
JS/Vue: "const count = ref(0);" or "import { ref } from 'vue';"

ParametersJSON Schema

Name	Required	Description
`file`	Yes	UUID of the file containing the statement
`statement`	Yes	UUID of the statement to add code to
`code`	Yes	The code to add (e.g., "const count = ref(0);")

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are present, so the description must cover behavioral traits. It mentions 'This parses and stores the code,' which indicates a write operation, but lacks details on validation, error handling, or reversibility. Adequate but not comprehensive.

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?

The description is concise with only a few sentences, includes examples, and is well-structured with clear sections for purpose, alternative, and examples.

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?

Given the lack of annotations and output schema, the description covers the tool's purpose, sequence, alternative, and examples. However, it does not specify return values or error scenarios, which would enhance completeness.

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 the baseline is 3. The description provides example code values but adds no additional meaning for the 'file' and 'statement' parameters beyond what the schema states (UUIDs).

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 clearly states 'Add code to an existing statement' and identifies it as step 2 of 2 after create_statement, distinguishing it from the sibling tool create_statement_with_code.

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 instructs to call after create_statement and provides an alternative (create_statement_with_code) for a single-call approach. Also notes the statement must already exist.

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

analyze_attributesA

Analyze PHP 8 attribute usage across a Stellify project. Useful for auditing, finding missing attributes, and searching attribute values.

Three modes:

usage (default): List all attributes used in the project with counts
- Optional: file_type to filter (e.g., "model", "controller")
- Returns: attribute names, counts, and files using each
missing: Find files of a specific type missing a required attribute
- Required: file_type (e.g., "model", "class")
- Required: attribute name (e.g., "Fillable", "FailOnUnknownFields")
- Returns: files missing vs having the attribute
search: Find files where an attribute contains a specific value
- Required: attribute name
- Optional: value to search for in attribute args
- Optional: file_type to filter
- Returns: matching files with their attribute values

Example queries:

"Find every FormRequest missing FailOnUnknownFields": mode=missing, file_type=class, attribute=FailOnUnknownFields
"Find models where 'email' is fillable": mode=search, attribute=Fillable, value=email
"List all attributes used": mode=usage

ParametersJSON Schema

Name	Required	Description
`mode`	No	Analysis mode: "usage" (list all attributes), "missing" (find files missing an attribute), "search" (find files with specific attribute value). Default: usage.
`file_type`	No	Filter by file type (e.g., "model", "controller", "class", "middleware").
`attribute`	No	Attribute name to analyze (required for "missing" and "search" modes).
`value`	No	Value to search for in attribute arguments (for "search" mode).

TDQS

A4.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It explains modes and outputs but does not explicitly state that the tool is read-only or mention any side effects, rate limits, or security requirements. While analysis suggests no destructive behavior, the description lacks explicit transparency.

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?

The description is well-structured with clear headings for each mode, bullet points for outputs, and inline examples. It is information-dense yet concise, with no fluff or redundant sentences. Every sentence serves a purpose.

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?

Given the complexity (3 modes, 4 params) and no output schema, the description thoroughly covers all return values per mode, parameter dependencies, and provides example queries. It is complete enough for an agent to correctly invoke the tool in various use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 4 parameters have schema descriptions (100% coverage). The description adds substantial value by explaining which parameters are required per mode, how they interact, and providing concrete examples of values (e.g., 'Fillable', 'email'). This goes well beyond the schema.

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 clearly states the tool analyzes PHP 8 attribute usage across a Stellify project. It defines three distinct modes with specific purposes and provides example queries, making the tool's purpose unambiguous and distinguishable from siblings like search_attributes.

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?

The description explicitly details when to use each mode and gives example mappings from natural language to parameters. However, it does not compare against sibling tools or specify when not to use this tool, missing a chance to fully differentiate from search_attributes.

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

analyze_performanceC

Analyze execution performance from logs. Types: full, slow_methods, high_query_methods, high_memory_methods, failure_rates, trend.

ParametersJSON Schema

Name	Required	Description
`type`	No	Type of analysis to run (default: full)
`days`	No	Number of days to analyze (default: 7)
`limit`	No	Maximum results for specific queries (default: 10)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether the tool is read-only, requires permissions, or has side effects. It only states the analysis types.

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 description is very concise with one sentence and a list. It is front-loaded with the main action but the list could be better integrated. However, it is efficient.

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

Completeness2/5

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

The description does not explain what the tool returns (e.g., report format, data structure) nor any timing or side effects. Given the tool complexity and the presence of multiple analysis types, more detail is needed.

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%, so the parameter details are already documented. The description redundantly lists the options but adds minimal extra value beyond 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?

The description clearly states the tool analyzes execution performance from logs and lists the available analysis types. It distinguishes from sibling tools like analyze_attributes and analyze_quality by focusing on performance logs, though not explicitly differentiating.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, nor any context on prerequisites or exclusions. The description lacks any usage recommendations.

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

analyze_qualityB

Analyze Laravel code for quality issues. Types: full, relationships, fillables, casts, routes. Returns actionable suggestions.

ParametersJSON Schema

Name	Required	Description	Default
`type`	No	Type of analysis to run (default: full)

TDQS

B3.4/5.0

Behavior3/5

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

The description mentions 'Returns actionable suggestions,' giving some idea of output, but with no annotations, it lacks details on side effects, permissions, or behavior in edge cases. For a read-only analysis tool, this is acceptable but not thorough.

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 description is a concise single sentence that covers the tool's purpose and lists types efficiently. It is front-loaded and to the point, earning its place without extra fluff.

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

Completeness3/5

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

Given the tool's low complexity (single optional parameter, no output schema), the description is mostly adequate. However, it omits details like what constitutes a 'quality issue' or how suggestions are structured, leaving some ambiguity for an agent.

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?

The single parameter 'type' is fully described in the schema with an enum list. The description reiterates these values without adding new meaning. Baseline 3 is appropriate since schema coverage is 100% and no additional semantic information is provided.

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 clearly states the tool analyzes Laravel code for quality issues and lists five analysis types. However, it does not explicitly differentiate itself from sibling tools like analyze_attributes or analyze_performance, missing a chance to reduce ambiguity.

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?

The description implies use when a quality analysis is needed for a Laravel project but provides no guidance on when to use this tool versus alternatives, nor any prerequisites or conditions for usage.

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

broadcast_element_commandA

Push real-time UI updates via WebSocket. Use for SHOW/DISPLAY/DEMONSTRATE requests.

Actions: update (modify element), create (ephemeral element), batch (multiple updates), delete.

Changes are EPHEMERAL (not saved). For persistent changes, use update_element or html_to_elements.

ParametersJSON Schema

Name	Required	Description
`action`	Yes	The type of command to broadcast
`element`	No	UUID of the element to modify (required for update, delete, create)
`changes`	No	Object containing attribute changes (e.g., { classes: ["bg-blue-500"], text: "Hello" })
`updates`	No	Array of updates for batch action: [{ element: "uuid", changes: {...} }]

TDQS

A4.4/5.0

Behavior4/5

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

Discloses that changes are EPHEMERAL (not saved), a critical behavioral trait. No annotations are provided, but the description covers the key aspect. However, it could mention more about side effects or scope of broadcast (all clients) which is implied by WebSocket.

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?

Extremely concise: three sentences plus a bulleted list of actions. Front-loaded with core purpose and usage. Every sentence is informative with no redundancy.

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?

Given no output schema and no annotations, the description provides essential context: ephemeral nature, usage scenarios, and differentiation from persistent tools. It could mention error handling or broadcast scope, but overall it is adequate for this simple broadcast tool.

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 baseline is 3. The description provides contextual categorization of actions (update, create, batch, delete) but does not add significant detail beyond what the schema already describes for each parameter.

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 clearly states the tool pushes real-time UI updates via WebSocket and is for SHOW/DISPLAY/DEMONSTRATE requests. It lists specific actions and distinguishes from persistent update tools, making the purpose unambiguous.

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 says 'Use for SHOW/DISPLAY/DEMONSTRATE requests' and contrasts with persistent changes by naming alternatives (update_element, html_to_elements), providing clear when-to-use and when-not-to-use guidance.

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

create_directoryA

Create a new directory for organizing files.

Common directories:

'js' for JavaScript/Vue files
'css' for stylesheets
'components' for reusable components

IMPORTANT: Check existing directories first using get_project and get_directory before creating new ones.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Directory name (e.g., "js", "css", "components")

TDQS

A4.4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Warns about checking existence but does not disclose error handling, permissions, side effects, or default location. Moderate transparency.

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?

Three short paragraphs: purpose, examples, important note. No fluff, every sentence earns its place.

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?

Simple tool with one parameter and no output schema; description explains purpose, gives usage examples, and provides a critical precondition. Could mention synchronization or error handling but overall complete.

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 has one parameter with example names; description adds context with common directories list, enhancing meaning beyond the schema. Baseline 3 with added value.

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 the verb 'create' and resource 'directory' explicitly. Gives concrete examples of directories. Distinguishes from siblings like create_file by focusing on directories.

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?

Provides explicit instruction to check existing directories first using get_project and get_directory, naming alternatives and preventing duplicate creation.

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

create_elementB

Create a UI element. Provide page (route UUID) for root elements, or parent (element UUID) for children.

ParametersJSON Schema

Name	Required	Description
`type`	Yes	Element type - must be one of the valid Stellify element types
`page`	No	UUID of the page/route to add the element to (for root elements)
`parent`	No	UUID of the parent element (for child elements)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must reveal behavioral traits. It only says 'Create a UI element' without mentioning side effects, permissions, idempotency, or return values.

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?

The description is extremely concise with two sentences, front-loading the purpose. Every word is necessary with no fluff.

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

Completeness3/5

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

Given 3 parameters, no output schema, and no annotations, the description explains the core purpose and parameter logic but lacks details on return values, error handling, or prerequisites for element creation.

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%, with each parameter described. The description adds value by explaining the conditional usage of page and parent, but does not add much beyond the schema.

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 clearly states 'Create a UI element', specifying the verb and resource. It distinguishes between root and child elements by indicating which parameter to use, differentiating it from sibling tools like update_element or delete_element.

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

Usage Guidelines2/5

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

The description explains when to use page vs parent parameters but provides no guidance on when to use this tool over alternatives (e.g., update_element) or when not to use it.

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

create_fileA

Create an empty file shell in a Stellify project. Returns file UUID.

For PHP: type='class', 'model', 'controller', or 'middleware'. For Vue: type='js', extension='vue'. Auto-creates app.js and template route.

Pass 'includes' array for framework class dependencies (auto-resolved to UUIDs). Use 'models' array in save_file for project models.

IMPORTANT - Check appJs response for Vue components:

If appJs.action_required === "create_or_select_mount_file": No mount file exists. You MUST ask the user if they want to create a new app.js mount file before proceeding.
If appJs.action_required === "register_component": Mount file exists but component isn't registered. Call save_file on the mount file to add the component UUID to its includes array.

ParametersJSON Schema

Name	Required	Description
`directory`	Yes	The UUID of the directory to create the file in (get from get_project directories array)
`name`	Yes	File name without extension (e.g., "Counter", "UserController")
`type`	Yes	Type of file: "js" for JavaScript/Vue, others for PHP
`extension`	No	File extension. Use "vue" for Vue components, omit for PHP files.
`namespace`	No	PHP namespace (e.g., "App\Services\"). Only for PHP files.
`includes`	No	Array of namespace strings to include as dependencies (e.g., ["App\Models\User", "Illuminate\Support\Facades\Hash"]). These are resolved to UUIDs automatically.
`module`	No	Optional module name to group this file with related code (e.g., "blog-posts", "user-auth"). Module is auto-created if it doesn't exist.
`attributes`	No	PHP 8 class-level attributes (e.g., ["Fillable(['name', 'email'])"], ["ObservedBy(UserObserver::class)"]). Use search_attributes tool to find available attributes.

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Discloses that it creates an empty shell, returns UUID, auto-creates app.js for Vue, and details conditional actions based on appJs response. Could mention side effects like auto-creation, but overall good for no annotations.

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?

Well-structured with clear paragraphs and a bold IMPORTANT section. Front-loaded with main purpose. Though lengthy, each part adds value; could be slightly more concise but remains clear and informative.

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?

Given 8 parameters, 3 required, no output schema, and complex Vue behavior, the description is comprehensive. It explains Vue appJs response handling and references other tools (save_file, search_attributes). No gaps left for an AI agent to misuse.

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%, baseline 3. Description adds context: explains type for PHP vs Vue, auto-resolving includes, namespace usage, and appJs handling. Adds meaningful usage examples beyond schema definitions.

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 clearly states the tool creates an 'empty file shell' in a Stellify project and returns a file UUID. It distinguishes from sibling tools like create_directory and create_element by specifying it's for files and providing details for PHP and Vue.

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?

Provides clear guidance on file types (PHP: class/model/controller/middleware; Vue: type='js', extension='vue') and explains auto-creation of app.js and template route. Includes an IMPORTANT section for checking appJs response. Missing explicit when-not-to-use or mention of alternatives but still strong.

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

create_methodB

Create a method in a file. Pass 'body' to include implementation. Async auto-detected from await. For significant methods, include context fields.

ParametersJSON Schema

Name	Required	Description
`file`	Yes	UUID of the file to add the method to
`name`	Yes	Method name (e.g., "increment", "store", "handleClick")
`visibility`	No	Method visibility (PHP only)
`is_static`	No	Static method (PHP only)
`is_async`	No	Async method (JS/Vue). Auto-detected if body contains await.
`returnType`	No	Return type (e.g., "int", "string", "void", "object")
`nullable`	No	Nullable return type (e.g., ?object)
`parameters`	No	Method parameters (created as clauses). Include datatype for TypeScript annotations.
`body`	No	Method body code. Auto-parses statements.
`summary`	No	Context: What this method does
`rationale`	No	Context: Why built this way
`references`	No	Context: Related entities [{uuid, type, relationship, note}]
`decisions`	No	Context: Design decisions
`attributes`	No	PHP 8 attributes for the method (e.g., ["Route(\"/api/users\")"], ["Middleware(\"auth\")"]). Use search_attributes tool to find available attributes.

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations provided, the description must disclose behavioral traits. It mentions async auto-detection and suggests including context for significant methods, but it does not cover what happens on conflict, required permissions, return values, or side effects. Adequate but incomplete for a 14-parameter mutation tool.

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?

Three sentences, front-loaded with the core purpose. Every sentence adds value: 'Create a method in a file' (purpose), 'Pass body to include implementation' (key param), 'Async auto-detected...' (behavioral hint). No unnecessary words.

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

Completeness2/5

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

Despite 14 parameters, no output schema, and sibling tools like 'add_method_body' and 'save_method', the description fails to explain the relationship between these tools or the full lifecycle. It does not mention that 'create_method' might create a stub and that 'add_method_body' is for adding body later, leading to potential confusion.

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 baseline is 3. The description adds marginal value by explaining when to use 'body' (to include implementation) and the auto-detection of 'is_async', but these are minor additions. It does not explain the context fields in detail beyond 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?

The description clearly states the action is to create a method in a file and mentions key aspects like passing body and async detection. It is specific enough to differentiate from broader tools like 'create_statement', though it does not explicitly name alternatives.

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

Usage Guidelines2/5

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

The description gives some guidance on when to include body and context fields, but it does not provide any guidance on when to use this tool versus siblings like 'add_method_body' or 'save_method'. No exclusions or when-not-to-use information is given.

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

create_resourcesA

Scaffold Model, Controller, Service, and Migration. Routes are NOT auto-wired - use create_route after.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Resource name in PascalCase (e.g., "User", "BlogPost", "OrderItem")
`fields`	No	Array of field definitions for the model and migration
`relationships`	No	Array of relationship definitions
`controller`	No	Create controller with CRUD actions (default: true)
`service`	No	Create service class for business logic (default: false)
`migration`	No	Create database migration (default: true)
`routes`	No	Create API routes (default: true)
`soft_deletes`	No	Add soft delete support to model and migration (default: false)
`api`	No	Generate API-style responses (default: true). Set to FALSE for SSR/Blade pages (controllers return views). Set to TRUE for API endpoints (controllers return JSON).

TDQS

A3.9/5.0

Behavior3/5

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

No annotations exist, so the description carries full burden. It discloses that multiple files are created and that routes require an extra step, but lacks details on potential side effects (e.g., overwriting existing files), prerequisites, or error handling.

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?

The description is a single, well-structured sentence that front-loads the main action and immediately clarifies a critical limitation. No extraneous words.

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

Completeness3/5

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

For a tool with 9 parameters and no output schema, the description is minimal. It does not explain what the agent should expect after execution (e.g., success message, file paths) or highlight default behaviors (e.g., soft_deletes default false). The schema descriptions fill some gaps, but overall completeness is moderate.

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% with detailed parameter descriptions, so baseline is 3. The description does not add additional meaning to any parameter; it only summarizes the tool's action. This is adequate given the schema richness.

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 explicitly states 'Scaffold Model, Controller, Service, and Migration', clearly specifying what the tool does. It distinguishes from siblings like 'create_route' by noting that routes are not auto-wired, making the purpose unambiguous.

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?

The description provides clear guidance: 'Routes are NOT auto-wired - use create_route after.' This tells the agent when not to rely solely on this tool and directs to an alternative. However, it does not elaborate on other scenarios where this tool should or should not be used.

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

create_routeA

Create a route/page. For API routes, you MUST pass BOTH controller AND controller_method UUIDs to wire execution.

IMPORTANT: Both 'controller' (file UUID) and 'controller_method' (method UUID) are required together for API routes to execute code. Without both, the route won't run any code.

Route params like {id} auto-inject into controller method parameters when names match.

ParametersJSON Schema

Name	Required	Description	Default
`project_id`	Yes	The UUID of the Stellify project
`name`	Yes	Route/page name (e.g., "Home", "Counter", "notes.index")
`path`	Yes	URL path (e.g., "/", "/counter", "/api/notes")
`method`	Yes	HTTP method	GET
`type`	No	Route type: "web" for pages, "api" for API endpoints, "channels" for WebSocket channels, "view" for Blade views	web
`controller`	No	UUID of the controller file. MUST be provided together with controller_method for API routes to execute code.
`controller_method`	No	UUID of the method to execute. MUST be provided together with controller for API routes to execute code.
`data`	No	Additional route data (title, description, element UUIDs)
`module`	No	Optional module name to group this route with related code (e.g., "blog-posts", "user-auth"). Module is auto-created if it doesn't exist.

TDQS

A4.9/5.0

Behavior5/5

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

Without annotations, the description fully discloses critical behavior: that without both controller fields, the route won't execute any code. It also explains the auto-injection behavior, leaving no hidden surprises.

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?

Well-structured with three concise paragraphs: purpose, critical requirement, and a helpful detail about route params. No extraneous information; every sentence adds value.

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?

Given 9 parameters (4 required) and no output schema, the description covers key behavioral aspects. However, it could mention default behavior for web routes or what happens if controller_method is provided without controller, but overall it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema provides 100% coverage with descriptions, but the description adds significant value by clarifying the dependency between controller and controller_method and explaining how route params map to method parameters, going beyond schema details.

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 clearly states it creates a route/page, distinguishes between regular routes and API routes requiring both controller and controller_method, and contrasts with sibling tools like delete_route or save_route.

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 instructs that for API routes, both 'controller' and 'controller_method' UUIDs are required. Also explains automatic injection of route params like {id} into method parameters, providing clear when-to-use guidance.

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

create_statementA

Create empty statement (step 1 of 2). Call add_statement_code next. Prefer create_statement_with_code for single call.

ParametersJSON Schema

Name	Required	Description	Default
`file`	No	UUID of the file to add the statement to
`method`	No	UUID of the method to add the statement to (for method body statements)

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavioral traits. It states it creates an empty statement, which implies mutation, but does not describe potential errors, permissions, or return behavior. The step-1 context is helpful, but lack of output schema or details on side effects limits transparency.

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?

Three sentences with zero wasted words. Front-loaded with the core action, then immediately provides usage context. Highly efficient.

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?

For a simple tool with two parameters and no output schema, the description covers the purpose and usage flow adequately. It lacks information about the return value or error handling, but the step-by-step context compensates. Almost complete.

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 the input schema already describes the two parameters. The description adds no extra meaning beyond what is in the schema, meeting the baseline but not exceeding it.

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 clearly states it creates an empty statement and distinguishes it from the sibling tool create_statement_with_code by noting it's step 1 of a two-step process. It uses specific verb and resource.

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 says when to use this tool (step 1 of 2) and when to prefer the alternative (create_statement_with_code for single call). Also instructs to call add_statement_code next, providing clear step-by-step guidance.

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

create_statement_with_codeA

Create a statement with code in one call. Preferred over two-step create_statement + add_statement_code.

Pass 'types' to specify TypeScript types for variables. The assembler infers the full type from code structure:

ref([]) + type "Todo" → outputs const todos: Ref<Todo[]>
ref(0) + type "number" → outputs const count: Ref<number>
reactive({}) + type "State" → outputs const state: State

ParametersJSON Schema

Name	Required	Description
`file`	Yes	UUID of the file to add the statement to
`code`	Yes	The code for the statement (e.g., "const count = ref(0);")
`method`	No	UUID of the method to add the statement to (optional, for method body statements)
`types`	No	Map of variable names to their base TypeScript types (e.g., { "todos": "Todo", "count": "number" }). The assembler infers Ref<>, arrays, etc. from the code structure.

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the tool's write behavior (creates a statement) and explains the types inference mechanism with concrete examples. However, it does not mention return values, error conditions, or side effects.

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 description is concise, front-loaded with the main purpose, and uses bulleted examples effectively. It avoids fluff, though it could be slightly more structured (e.g., a separate note on optional parameters).

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?

Given the tool's complexity (4 parameters, optional nested object, no output schema), the description covers the core functionality and the important types inference feature. It lacks details on return values or error handling, but overall it is sufficiently complete for an agent to invoke correctly.

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 covers all parameters (100%), and the description adds value for 'types' by explaining how the assembler infers full TypeScript types from code structure, with examples. Other parameters (file, code, method) rely on schema descriptions but are clear enough.

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 clearly states the tool's function: 'Create a statement with code in one call.' It distinguishes from siblings by explicitly noting it's 'Preferred over two-step create_statement + add_statement_code,' providing a specific verb-resource relationship.

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?

The description gives clear usage guidance by highlighting when to use this tool instead of the two-step alternative. It also explains when to pass 'types' and provides examples, though it does not explicitly state when not to use it.

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

delete_elementA

Delete an element and all its children (CASCADE). Returns the count of deleted elements.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	UUID of the element to delete

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the CASCADE behavior and return value (count), which is more than minimal for a delete operation. However, it does not mention error handling, irreversibility, or permission requirements.

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?

The description is extremely concise, consisting of two sentences with no wasted words. It is front-loaded with the core action and key details.

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?

Despite lacking an output schema and annotations, the description adequately covers the primary behavior (cascade delete, return count). It does not address error cases or edge conditions, but for a single-parameter tool, it is reasonably complete.

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?

The description does not add meaning beyond the input schema, which already describes the 'uuid' parameter as 'UUID of the element to delete'. Schema coverage is 100%, so the baseline is 3; no additional parameter detail is provided.

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 clearly states the action (delete), the resource (element), and key behavior (cascading deletion, returns count). It distinguishes from sibling tools like delete_file or delete_method by specifying 'element' and the CASCADE effect.

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?

The description implies use for deleting elements, but provides no explicit guidance on when to use this vs alternatives, no prerequisites, and no when-not-to-use information. It meets the minimum viability for implied usage but lacks explicit context.

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

delete_fileA

Delete a file from the project by UUID. This permanently removes the file and all its methods/statements.

WARNING: This is destructive and cannot be undone. Make sure the file is not referenced elsewhere before deleting.

ParametersJSON Schema

Name	Required	Description	Default
`directory`	Yes	UUID of the directory containing the file (get from get_project directories array or get_file response)
`uuid`	Yes	UUID of the file to delete

TDQS

A4.4/5.0

Behavior5/5

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

No annotations are provided, but the description fully carries the burden by explicitly stating the tool is destructive, irreversible, and removes associated methods/statements. The warning about checking references adds transparency.

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?

Extremely concise: two sentences effectively convey purpose, scope, and critical warnings. No redundant information; every sentence serves a purpose.

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?

For a destructive tool with no output schema, the description adequately covers behavior, side effects, and prerequisites. Minor gap: no mention of return value or error scenarios, but deletion tools typically return nothing.

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?

Input schema has 100% coverage with descriptive parameter details (e.g., how to obtain directory UUID). The description adds no additional parameter semantics beyond the schema, so baseline score of 3 is appropriate.

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?

Clearly states the action (delete), resource (file), and identification method (by UUID). It also specifies the scope of deletion (removes methods/statements), distinguishing it from sibling delete tools for other entities.

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?

Includes a warning about destructiveness and irreversibility, advising to check references before deletion. However, it does not explicitly compare with alternatives like delete_element or delete_method for cases where only parts of the file need removal.

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

delete_methodA

Delete a method from a file by UUID. This permanently removes the method and all its code. Requires both the file UUID and method UUID.

ParametersJSON Schema

Name	Required	Description	Default
`file`	Yes	UUID of the file containing the method (required)
`uuid`	Yes	UUID of the method to delete

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It warns that the method and its code are 'permanently removed', which is crucial for a destructive operation. However, it omits other behaviors like error handling or idempotency.

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 concise sentences with no redundant information. The description is front-loaded with the key action and effect.

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

Completeness2/5

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

No output schema is provided, and the description does not mention return values, error conditions, or what happens if the UUIDs are invalid. For a deletion tool, these gaps reduce completeness.

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% with clear parameter descriptions. The description reiterates that both UUIDs are required, adding minimal extra value beyond the schema.

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 clearly states the action ('Delete'), the resource ('method'), and scope ('from a file by UUID'). It also mentions the permanent removal, which distinguishes it from sibling tools like delete_element or delete_statement.

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?

The description lists required parameters but does not explicitly state when to use this tool versus siblings (e.g., delete_statement). It implies context (delete a method) but lacks alternatives or exclusion criteria.

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

delete_routeA

Delete a route/page from the project by UUID. This permanently removes the route.

WARNING: This is destructive and cannot be undone. Any elements attached to this route will be deleted also.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	UUID of the route to delete

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses that the action is destructive, permanent, and cascades to attached elements, providing critical behavioral context beyond the schema.

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?

The description is two concise sentences plus a warning, front-loading the key action and then providing essential caution, with no extraneous content.

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 simple single-parameter deletion tool with no output schema, the description sufficiently covers the action, side effects, and permanence, making the tool's behavior fully predictable.

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%, and the description only reiterates the uuid parameter's role, adding no new semantic detail beyond what the schema already specifies.

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 clearly states the tool deletes a route/page by UUID, with a specific verb and resource, distinguishing it from sibling tools like create_route or get_route.

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?

The description does not explicitly specify when to use this tool vs alternatives or any prerequisites, though the destructive nature implies careful consideration. No exclusion criteria or alternative tool suggestions are provided.

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

delete_settingA

Delete a setting profile from the tenant's settings table.

WARNING: This permanently removes the entire setting profile and all its values. This cannot be undone.

EXAMPLE: { "name": "vote" }

This removes the "vote" setting profile entirely.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Setting profile name to delete

TDQS

A4/5.0

Behavior5/5

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

The description explicitly warns that deletion is permanent and irreversible, disclosing key behavioral consequences beyond the schema. With no annotations, this transparency is critical.

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?

Concise and well-structured: purpose stated first, then warning, then example. Every sentence adds value with no redundancy.

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?

Given one parameter and no output schema, the description covers essential aspects: what it does, the irreversible effect, and an example. Missing post-deletion behavior but sufficient for the tool's simplicity.

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 baseline is 3. The description adds an example but does not substantially enrich parameter meaning beyond the schema's own description.

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 clearly states it deletes a setting profile, using specific verb and resource, and distinguishes from siblings like get_setting or save_setting.

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

Usage Guidelines2/5

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

The description provides a warning and example but does not specify when to use this tool versus alternative deletion tools (e.g., delete_element, delete_file) or mention prerequisites.

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

delete_statementB

Delete a statement from a file by UUID. This permanently removes the statement (import, variable, ref, etc.).

ParametersJSON Schema

Name	Required	Description
`file`	Yes	UUID of the file containing the statement
`method`	Yes	UUID of the method containing the statement (use "file" for file-level statements)
`uuid`	Yes	UUID of the statement to delete

TDQS

B3.4/5.0

Behavior2/5

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

The description only notes that deletion is permanent; with no annotations, it lacks disclosure of side effects (e.g., cascading deletes), permission requirements, or error conditions.

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?

The description is concise with two front-loaded sentences, conveying essential information without unnecessary words.

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

Completeness2/5

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

For a destructive tool with no output schema, the description omits return behavior, error handling, and usage context, leaving the agent underinformed.

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?

The schema covers all three parameters with descriptions, and the tool description adds value by clarifying the 'method' parameter usage ('use "file" for file-level statements') and giving examples of statement types.

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 clearly states the action 'Delete a statement from a file by UUID' and specifies it 'permanently removes the statement (import, variable, ref, etc.)', effectively distinguishing it from sibling tools like delete_element, delete_file, etc.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool vs alternatives such as delete_element or delete_method, nor are there any prerequisites or exclusions mentioned.

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

get_assembled_codeA

Get the assembled source code for a file. Returns the actual Vue SFC or PHP class as it would be rendered.

Use this after save_file to verify the component was built correctly:

Check that all methods are included
Verify @click handlers are wired to methods
Confirm imports and reactive state are present
Spot any missing pieces before deployment

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	UUID of the file to get assembled code for

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided; description clarifies it returns processed code rather than raw file, but lacks details on side effects (e.g., does it trigger compilation?) or performance impact. Still, it adequately discloses its behavior for verification purposes.

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 plus a concise bulleted list; front-loaded with purpose and efficient use of words, no redundancy.

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?

Given no output schema, the description returns the expected content type (Vue SFC or PHP class) and hints at its structure, which is sufficient for a verification tool. Could mention if there are limitations or size constraints.

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 covers the 'uuid' parameter with a description; the tool description adds minimal extra meaning beyond 'UUID of the file', so baseline score 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 clearly states the tool retrieves assembled source code for a file, specifically Vue SFC or PHP class as rendered, distinguishing it from sibling get tools that likely return raw file contents.

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 advises using after save_file for verification, with a bulleted checklist of what to check, providing strong contextual usage guidance.

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

get_directoryA

Get a directory by UUID to see its contents.

Use this to inspect directories returned by get_project. The project's data array contains directory UUIDs. Returns the directory name and list of files/subdirectories inside it.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	The UUID of the directory to retrieve

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It indicates the return value (name and contents) but does not explicitly state that the operation is read-only or discuss any side effects, permissions, or error conditions.

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?

The description is three sentences long, front-loading the core purpose and efficiently providing usage context and return info without unnecessary detail.

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?

For a simple get tool with one parameter and no output schema, the description covers the essential aspects: action, usage context, and return value. Minor gaps like error handling do not detract significantly.

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?

With 100% schema coverage, the parameter 'uuid' is already described in the input schema. The description adds no additional meaning beyond the schema's definition.

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 clearly states 'Get a directory by UUID to see its contents,' specifying the verb and resource. It differentiates from sibling tools like get_file and get_project by focusing on directory contents.

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?

The description provides context: 'Use this to inspect directories returned by get_project.' It implies the tool's use case without explicitly stating when not to use it, but the guidance is sufficient for an agent.

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

get_elementA

Get a single element by UUID. Returns the element data with all its attributes.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	UUID of the element to retrieve

TDQS

A3.6/5.0

Behavior3/5

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

Without annotations, the description adequately indicates a read operation returning element data. However, it doesn't disclose any potential side effects, auth needs, or limitations beyond what is implicit.

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, no wasted words, front-loaded with the core purpose. Efficient and clear.

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?

For a simple tool with one parameter and no output schema, the description adequately explains the action and return value. It covers the essentials, but could mention related elements (e.g., 'see also search_elements').

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?

With 100% schema coverage, the description adds minimal value beyond repeating the UUID parameter. It doesn't elaborate on format or constraints.

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 clearly states the tool gets a single element by UUID and returns its data with all attributes. It distinguishes from siblings like get_element_tree and search_elements.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives like search_elements or get_element_tree. No explicit when-not or alternative suggestions.

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

get_element_treeB

Get an element with all its descendants (children, grandchildren, etc.) as a hierarchical tree structure.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	UUID of the root element

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, and the description discloses only the return structure (hierarchical tree). It does not mention performance implications for large trees, read-only nature, or any side effects. The description carries the full burden but is sparse.

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?

A single, clear sentence with no redundant words. It is concise and front-loaded. Could slightly expand on return structure, but not necessary.

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

Completeness3/5

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

For a simple retrieval tool with one parameter and no output schema, the description is adequate but lacks usage context and behavioral details. It is minimally complete.

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?

One parameter (uuid) with schema description 'UUID of the root element'. Schema coverage is 100%, so the description adds no extra meaning. Baseline 3 is appropriate.

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 clearly states the verb 'Get' and the resource 'element with all its descendants as a hierarchical tree structure'. It distinguishes from sibling tools like 'get_element' which likely retrieves a single element.

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?

No explicit guidance on when to use this tool vs alternatives. The sibling list includes 'get_element', but the description does not mention it or provide comparison criteria. Usage is implied but not clarified.

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

get_fileA

Get a file by UUID with all its metadata, methods, and statements.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	UUID of the file to retrieve

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided. Description discloses return includes metadata, methods, and statements, but does not mention side effects, permissions, or limitations. Adequate but not rich.

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?

Single, efficient sentence that front-loads the action and resource. No wasted words.

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?

No output schema, but description enumerates returned items (metadata, methods, statements). Complete enough for a simple get tool. Could mention error conditions but not necessary.

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% and the parameter 'uuid' is fully described. Description adds 'by UUID' which is already in schema. Baseline 3 is appropriate.

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?

Description clearly states verb 'get', resource 'file by UUID', and scope 'all its metadata, methods, and statements'. Distinguishes from sibling getters like get_element and get_method.

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?

No explicit when-to-use or alternatives. Usage is implied: use when you need a file's full details. Sibling context provides some differentiation but lacks explicit guidance.

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

get_methodA

Get a method by UUID. Returns the method data including its parameters and body.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	UUID of the method to retrieve

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided; description only says returns method data including parameters and body. Lacks details on error handling, auth requirements, or side effects. Minimal disclosure.

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 short sentences, front-loaded with action and identifier. No wasted words.

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?

For a simple getter with one parameter and no output schema, description covers key return fields (parameters and body). Missing some potential fields and error states, but adequate.

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 has 100% coverage for the single parameter. Description adds context about return data but not about the parameter itself. Baseline score appropriate as description adds minor value beyond schema.

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?

Clearly states the action (Get), resource (method), and identifier (UUID). Distinguishes from sibling tools like create_method, delete_method, search_methods.

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?

Description does not explicitly state when to use this tool vs alternatives like search_methods. Context suggests it's for retrieving a specific method by UUID, but no guidance on exclusions or prerequisites.

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

get_patternA

Get a UI pattern checklist (accordion, modal, tabs, dropdown, toast). Returns best practices and common pitfalls.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Pattern name (e.g., "accordion", "modal", "tabs", "dropdown", "toast")

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so the description must fully convey behavior. It states the tool returns a checklist (read operation), but does not disclose error conditions, authentication requirements, or whether modifications are possible. Adequate but not thorough.

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?

A single, front-loaded sentence that states the purpose and returns exactly what is needed. No wasted words.

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?

For a simple tool with one required parameter and no output schema, the description is largely complete. It tells what the tool returns and lists valid inputs. Minor gaps: no mention of read-only nature or prerequisites.

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% with a description that includes examples. The tool description reiterates the pattern names, adding no new semantic information beyond the schema. Baseline of 3 is appropriate.

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 clearly states the specific verb 'Get' and resource 'UI pattern checklist', listing concrete pattern names (accordion, modal, tabs, dropdown, toast) and what it returns (best practices and common pitfalls). This distinguishes it from sibling tools like list_patterns or get_element.

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?

The description implies usage when needing a checklist for specific UI patterns, but provides no explicit guidance on when not to use it or alternatives. Sibling tools like list_patterns exist, but no comparison or exclusion is given.

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

get_projectA

Get active project. Returns uuid, name, branches, and directories array.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior3/5

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

Without annotations, the description carries the burden. It indicates a read operation and lists outputs, but does not disclose potential errors, side effects, or access requirements. Adequate for a simple getter.

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?

Single sentence, front-loaded with the action 'Get active project', no excess words. Every part adds value.

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?

For a no-parameter tool, the description covers what the tool does and what it returns. It could be improved by clarifying 'active project' meaning or potential failure modes, but is sufficient for a simple read.

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?

With no parameters and 100% schema coverage, baseline is 3. The description adds no parameter-specific info but does explain return values, which is not directly parameter semantics.

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 clearly states the tool retrieves the active project and lists specific return fields (uuid, name, branches, directories). This distinguishes it from sibling getters like get_directory or get_file.

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

Usage Guidelines2/5

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

No guidance on when to use this tool over alternatives such as get_element or get_route. The description does not mention prerequisites or context (e.g., needing an active project).

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

get_routeA

Get a route/page by UUID. Returns route details including name, path, and attached elements.

Use this to look up a route you created or to find existing routes in the project.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	The UUID of the route to retrieve

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must cover behavioral traits. It mentions return fields but does not disclose error behavior (e.g., if UUID not found), auth requirements, or side effects. For a read operation, this is adequate but not thorough.

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 concise sentences with front-loaded purpose and clear structure. Every sentence adds value without redundancy.

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?

For a simple lookup tool with one parameter and no output schema, the description is relatively complete. It specifies the input and output context. However, it could mention what happens on failure or provide a note about the UUID format.

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?

The input schema has 100% description coverage for the single 'uuid' parameter. The description adds that the tool retrieves 'by UUID' and lists return fields, but these are not additional parameter semantics beyond what the schema already provides.

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 uses specific verb 'Get' and resource 'route/page by UUID'. It clearly states the action and what is returned (name, path, attached elements). The mention of lookup by UUID distinguishes it from sibling search_routes.

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?

The description provides clear context: 'Use this to look up a route you created or to find existing routes in the project.' It implies when to use but does not explicitly exclude alternatives like search_routes.

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

get_settingA

Get a setting profile by name. Returns key-value pairs accessible via config() in code.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Setting profile name (e.g., "app", "database", "mail", or custom names like "vote")

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description should disclose more behavioral traits. It explains return format and usage in code but does not explicitly state that it is read-only or mention any prerequisites.

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?

The description is two concise sentences with no superfluous information, making it efficient and easy to parse.

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 simple getter tool with one parameter and no output schema, the description adequately covers the purpose, input, and return value, making it complete.

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?

The input schema has 100% description coverage and the tool description adds context by clarifying that the setting profile contains key-value pairs accessible via config() in code.

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 clearly states the tool retrieves a setting profile by name and returns key-value pairs used in code. It distinguishes from sibling tools like delete_setting and save_setting.

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?

The description implies usage when needing a setting by name but does not explicitly state when to use this tool over alternatives or provide exclusions.

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

get_statementA

Get a statement by UUID. Returns the statement data including its clauses (code tokens).

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	The UUID of the statement to retrieve

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description must carry the burden. It mentions the return includes clauses but does not disclose permissions, error conditions, side effects, or confirm it's read-only. Adequate but limited.

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, clear and front-loaded. No wasted words. The description efficiently conveys the tool's function and return content.

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?

Given low complexity (one parameter, no output schema), the description is fairly complete. It explains what it does and what it returns. Could mention read-only nature but not essential.

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% for the single parameter 'uuid'. The description repeats the purpose without adding extra meaning beyond the schema. Baseline 3 is appropriate.

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?

Description clearly states it gets a statement by UUID and returns data including clauses. Verb 'get' and resource 'statement' are specific, and it distinguishes from sibling tools like create_statement, delete_statement, etc.

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?

The description implies retrieval usage but does not explicitly state when to use versus alternatives. No guidance on when not to use or mention of alternative tools.

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

get_stellify_framework_apiA

Get Stellify Framework API reference with full type signatures. Import from "stellify-framework".

Returns composables (useForm, useAuth, etc.) with options/returns, utilities (Http, Collection, etc.) with methods/staticMethods, and validation rules.

Each item includes summary, type signatures, and JSDoc descriptions. Collection is iterable with v-for.

ParametersJSON Schema

Name	Required	Description	Default
`module`	No	Optional: specific module to get API for (e.g., "useForm", "Http", "rules"). Omit to get full API.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description details the return content: composables with options/returns, utilities with methods/staticMethods, and validation rules. It also mentions that each item includes summary, type signatures, and JSDoc descriptions, and that Collection is iterable with v-for. This provides good behavioral insight.

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?

The description is three sentences, front-loaded with the main purpose and import, followed by return types and item details. Every sentence adds value, with no fluff.

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?

Given the simple parameter schema and lack of output schema, the description adequately explains what the tool returns and its structure. It could mention the return format but is sufficiently complete for its complexity.

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%, and the description adds value by listing example module names (useAuth, Collection) that complement the schema's examples, giving the agent a concrete understanding of the optional parameter.

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 clearly states the tool retrieves the Stellify Framework API reference with full type signatures. It specifies the imported package and lists return types (composables, utilities, validation rules), distinguishing it from sibling tools that deal with project elements.

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?

The description implies usage for framework API reference but does not explicitly state when to use this tool versus alternatives like get_method or get_file. No exclusions or when-not guidance provided.

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

html_to_elementsA

Convert HTML to Stellify elements.

IMPORTANT - Choose the right approach:

For SSR/Blade Pages (WordPress imports, static content, layouts):

MUST pass 'page' (route UUID) - elements attach to the route for server-side rendering
This is the most common use case

For Vue Components (client-side interactivity):

Omit 'page' - elements are standalone, referenced by file's template array
Returns UUIDs to use in save_file's template array

Where elements go:

Pass 'page' (route UUID): Elements attached to the route for SSR rendering
Pass 'selection' (element UUID): Elements attached as children of existing element
Omit both: Elements are standalone (Vue components only) - use returned UUIDs in save_file's template array

⚠️ CRITICAL: Multiple Root Elements Limitation When HTML contains multiple root-level elements (e.g., , , ), only the FIRST root element gets attached to the route. Other elements become orphaned!

WRONG: html_to_elements(page: routeUUID, elements: "<header>...</header><main>...</main><footer>...</footer>") → Only attaches to route. and are orphaned!

CORRECT: Make separate calls for each root element:

html_to_elements(page: routeUUID, elements: "<header>...</header>")
html_to_elements(page: routeUUID, elements: "<main>...</main>")
html_to_elements(page: routeUUID, elements: "<footer>...</footer>")

OR wrap all elements in a single container div.

@click auto-wiring: Pass 'file' UUID to auto-resolve @click="methodName" handlers. Methods must exist in the file first.

Blade Syntax Handling: For SSR/Blade pages, do NOT pass raw Blade expressions in text or attributes. The HTML parser stores them literally which causes rendering issues. Instead:

For static HTML: Pass clean HTML without Blade syntax, then use update_element to add dynamic behavior
For loop content: After creating elements, use update_element with:
- textField, hrefField, srcField for simple field access (outputs {{ $item->field }})
- hrefExpression, srcExpression, altExpression for paths with prefixes or complex expressions
- statements array with statement UUIDs for text content with Blade code
For conditionals: Use s-directive elements as siblings (see update_element docs)

IMPORTANT - Links with path prefixes: hrefField outputs ONLY the field value with no prefix. There is NO hrefPrefix attribute. For links like /post/my-slug, use hrefExpression: "/post/{{ $item->slug }}" instead.

Loop variable: Inside @foreach loops created with s-directive, the default loop variable is $item. Use textField: "title" to output {{ $item->title }}.

Prefer SVG icons over emoji (encoding issues).

ParametersJSON Schema

Name	Required	Description
`elements`	Yes	HTML string to convert
`page`	No	Route UUID to attach elements to. REQUIRED for SSR/Blade pages (WordPress imports, static content, layouts). Only omit for Vue component templates.
`selection`	No	Parent element UUID to attach to (alternative to page). Use when adding children to existing elements.
`file`	No	Vue component file UUID. Pass this to auto-wire @click handlers to method UUIDs.
`test`	No	If true, returns structure without creating elements

TDQS

A4.7/5.0

Behavior5/5

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

Discloses critical behaviors: only first root element attaches, Blade syntax issues, @click auto-wiring setup, hrefField limitations, loop variable defaults, and test mode behavior. Given no annotations, the description fully carries the burden of transparency.

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?

Though lengthy, the description is well-structured with headings, bold warnings, and bullet points. It front-loads the main purpose and critical information. Some redundancy exists, but it remains readable and informative for the complexity.

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 multiple use cases and provides necessary details for correct usage despite no output schema. Mentions return of UUIDs for Vue components and structure in test mode. Lacks exact return format but sufficient for an agent to infer.

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% with basic descriptions, but the description adds significant context for each parameter (e.g., page required for SSR, selection for parent-child, file for auto-wiring, test for dry run). Goes beyond schema with examples and edge cases.

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 clearly states 'Convert HTML to Stellify elements', which is a specific verb+resource. It distinguishes from sibling tools like create_element by detailing conversion from HTML and explaining different contexts (SSR vs Vue).

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?

Provides explicit guidance on when to use each approach (SSR/Blade vs Vue components), when to pass page, selection, or omit, and warns against common mistakes like multiple root elements and Blade syntax handling. Includes alternatives for links and directives.

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

install_packageA

Install a foundation package into the current project. Creates routes and other resources defined in the package manifest.

Returns success with installed counts, or error with code:

PACKAGE_NOT_FOUND: Package name doesn't exist
PACKAGE_NOT_INSTALLABLE: Package is disabled
ALREADY_INSTALLED: Package routes already exist in project
UNKNOWN_MANIFEST_KEY: Package requires newer platform version
INSTALL_FAILED: Transaction failed

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Package name (e.g., "file-uploads")

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description effectively discloses behavior: installation process, resource creation, return value, and detailed error codes covering various failure modes.

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 description is fairly concise with two clear paragraphs: one for purpose/effect and one for return/errors. The error list is somewhat long but adds value.

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?

Given the simplicity of the tool (1 param, no output schema), the description covers the main aspects: what it does, what it returns, and possible errors. Missing prerequisites but adequate.

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?

The description adds context about the package type ('foundation package') but the single parameter 'name' is already fully described in the schema with an example. Schema coverage is 100%, so baseline 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 clearly states the tool installs a foundation package and creates routes/resources, distinguishing it from sibling tools like create_route or create_resources which are more granular.

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?

The description provides error codes that imply when the tool should not be used (e.g., if package not found or already installed), but lacks explicit guidance on when to use this tool versus alternatives.

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

list_patternsA

List all available UI pattern checklists.

Returns an array of pattern names and descriptions. Use this to discover what patterns are available before building UI components.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

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

No annotations are provided, but the description fully discloses behavior: it lists patterns and returns an array of names and descriptions. It correctly implies a read-only, non-destructive operation with no hidden side effects.

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?

The description is three short sentences with no redundant information. It front-loads the purpose and adds usage guidance efficiently.

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?

Given no parameters and no output schema, the description fully covers what the tool does, its return format, and when to use it. No additional context is necessary.

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?

The input schema has zero parameters with 100% coverage. The description does not need to add parameter meanings. Baseline for 0 parameters is 4, and the description does not detract.

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 states it lists all available UI pattern checklists and returns pattern names and descriptions. This clearly distinguishes it from sibling tools like get_pattern (single pattern) and save_pattern (create/update).

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?

The description advises using it 'to discover what patterns are available before building UI components,' which provides clear context. While it does not explicitly mention when not to use it or list alternatives, the usage context is adequate.

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

request_capabilityA

Log a missing framework-level capability. Creates a ticket in the Stellify backlog.

ParametersJSON Schema

Name	Required	Description
`capability`	Yes	Short name for the capability (e.g., "websocket-support", "s3-uploads", "social-oauth")
`description`	Yes	Detailed description of what capability is needed
`use_case`	Yes	The user requirement that triggered this request
`workaround`	No	Any temporary workaround, or "blocked" if none exists
`priority`	No	Suggested priority based on user need (default: medium)

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the core action (logging and ticket creation) but does not mention side effects, authentication needs, rate limits, or what happens after creation. Adequate for a simple logging tool but could add more context.

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, no unnecessary words. The description is front-loaded with the primary verb 'Log' and immediately explains the outcome. Every word earns its place.

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

Completeness3/5

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

Given low complexity and no output schema, the description is minimally adequate. However, it does not mention return values (e.g., ticket ID) or confirmation, which would improve completeness for agent invocation.

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?

Input schema has 100% description coverage for all 5 parameters, so the schema already documents each parameter. The description adds no additional meaning beyond what the schema provides, meeting the baseline of 3.

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 clearly states the tool logs a missing framework-level capability and creates a ticket in the Stellify backlog. The verb 'Log' and the action 'Creates a ticket' are specific and distinguish it from sibling tools, which focus on code manipulation.

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

Usage Guidelines2/5

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

The description implies usage when a capability is missing but provides no explicit guidance on when to use versus alternatives, no exclusions, and no context about prerequisites or situations where it should not be used.

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

run_codeA

Execute a method in sandboxed environment. Requires file and method UUIDs. Returns output, success, error, and optional benchmark data.

ParametersJSON Schema

Name	Required	Description
`file`	Yes	UUID of the file containing the method to run (required)
`method`	Yes	UUID of the method to execute (required)
`args`	No	Arguments to pass to the method
`timeout`	No	Execution timeout in seconds (default: 30, max: 60)
`benchmark`	No	Enable benchmarking to measure execution time and memory usage

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It mentions the sandboxed environment and typical return fields (output, success, error, benchmark), which adds some safety context. However, it omits side effects, authorization requirements, rate limits, and whether the execution modifies state, leaving notable gaps for an agent.

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?

The description is extremely concise at two sentences, front-loading the core action ('Execute a method in sandboxed environment') and then listing required inputs and outputs. Every sentence is necessary and wastes no words.

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

Completeness3/5

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

Given the complexity of a code execution tool with 5 parameters and no output schema, the description provides basic context (sandbox, return fields) but lacks detail on output structure, error handling, asynchronous behavior, and side effects. It covers the essentials but could be more thorough for an AI agent to invoke it correctly without additional context.

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 the input schema already describes all parameters. The description adds no new semantic information about parameters beyond restating that file and method UUIDs are required and mentioning optional benchmark data, which is already in the schema. Baseline 3 applies as the schema does the heavy lifting.

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 clearly states the tool executes a method in a sandboxed environment, using specific verb-execute and resource-method. It distinguishes from siblings by focusing on execution rather than creation, editing, or analysis, which are covered by other tools like add_method_body or analyze_performance.

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?

The description implies when to use the tool (to run code) but does not provide explicit exclusions or alternatives. It lacks guidance on when not to use it or how it compares to related tools like get_method for non-execution retrieval. The context is clear but minimal.

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

save_directoryA

Update an existing directory. Use this to rename or modify directory properties.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	UUID of the directory to update
`name`	No	New directory name

TDQS

A3.9/5.0

Behavior3/5

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

No annotations; description indicates a non-destructive update but omits details on error handling, authorization, or side effects. Adequate for a simple update tool.

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 concise sentences with no fluff. Every sentence is purposeful and front-loaded.

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

Completeness3/5

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

No output schema; description doesn't mention return value or constraints. Adequate for a simple update but lacks full context for agent decision-making.

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 baseline is 3. Description adds minimal context ('rename or modify directory properties') but doesn't enhance parameter meaning beyond the schema.

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?

Explicitly states 'Update an existing directory' with specific verb and resource. Distinguishes from siblings like create_directory and get_directory.

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?

Provides clear usage context: 'Use this to rename or modify directory properties.' Lacks explicit when-not or alternatives, but context is clear.

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

save_fileA

Finalize a file. Full replacement - call get_file first to update existing files.

Required: uuid, name, type. For significant changes, include context fields: summary, rationale, references, decisions.

ParametersJSON Schema

Name	Required	Description
`uuid`	Yes	UUID of the file to save
`name`	Yes	File name (without extension)
`type`	Yes	File type: "js" for JavaScript/Vue, others for PHP
`extension`	No	File extension: "vue" for Vue SFCs, "js" for JavaScript
`template`	No	Root element UUIDs for Vue <template>
`data`	No	Method UUIDs (from create_method)
`statements`	No	Statement UUIDs (imports, variables, refs)
`includes`	No	File UUIDs for local imports (e.g., Vue components imported by app.js) AND framework class UUIDs/namespaces. CRITICAL: For JS mount files, add imported Vue component UUIDs here or they won't be bundled. Use models array for project models.
`models`	No	Project model UUIDs (auto-namespaced). Do NOT duplicate in includes.
`frameworkImports`	No	Stellify framework modules to import (e.g., ["Http", "Form", "Collection"]). Auto-generates: import { Http, Form, Collection } from 'stellify-framework';
`summary`	No	Context: What this file does and why it exists
`rationale`	No	Context: Why it was built this way
`references`	No	Context: Related entities [{uuid, type, relationship, note}]
`decisions`	No	Context: Design decisions
`attributes`	No	PHP 8 class-level attributes (e.g., ["Fillable(['name', 'email'])"], ["ObservedBy(UserObserver::class)"]). Use search_attributes tool to find available attributes.

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavior. It states 'Full replacement' but does not detail side effects, destructive impact, permissions, or error states. The description is minimal on behavioral traits.

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?

Three concise sentences, front-loaded with purpose and requirement. No unnecessary words, efficient communication.

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

Completeness2/5

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

Given 15 parameters and no output schema, the description provides only a high-level summary. It does not explain parameter interplay (e.g., includes vs models) or workflow beyond 'call get_file first'. Incomplete for complex usage.

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 baseline is 3. Description reiterates required fields and context fields but adds little new meaning beyond the schema's detailed parameter descriptions.

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?

Clearly states 'Finalize a file. Full replacement', indicating the specific action and semantics. Distinguishes from create_file by noting to call get_file first for updates.

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?

Explicitly advises to call get_file first for updating existing files, and lists required fields. However, does not explicitly contrast with alternatives like create_file or provide negative use cases.

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

save_methodA

Update a method's properties. Use add_method_body to append code.

For significant changes, include context fields: summary, rationale, references, decisions.

ParametersJSON Schema

Name	Required	Description
`uuid`	Yes	UUID of the method to update
`name`	No	Method name
`visibility`	No	Method visibility (PHP only)
`is_static`	No	Whether the method is static (PHP only)
`returnType`	No	Return type (e.g., "int", "string", "void", "object")
`nullable`	No	Whether the return type is nullable
`parameters`	No	Array of parameter clause UUIDs
`data`	No	Array of statement UUIDs that form the method body. Use to reorder or remove statements.
`is_async`	No	Whether the method is async (JavaScript/Vue only). Set to true for methods that use await.
`summary`	No	Context: Brief description of what this method does
`rationale`	No	Context: Why it was built this way
`references`	No	Context: Links to related entities [{uuid, type, relationship, note}]
`decisions`	No	Context: Design decisions made
`attributes`	No	PHP 8 attributes for the method (e.g., ["Route(\"/api/users\")"], ["Middleware(\"auth\")"]). Use search_attributes tool to find available attributes.

TDQS

A4.2/5.0

Behavior2/5

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

With no annotations, the description carries full burden but does not disclose side effects, auth requirements, or whether updates are partial/replacement. Missing key behavioral details.

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, each purposeful. No fluff, front-loaded with purpose and alternatives, then guidance. Highly efficient.

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?

For a tool with 14 fully described parameters and no output schema, the description provides adequate context (when to use context fields, alternative tool). Nearly complete, missing only minor behavioral details.

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 has 100% coverage, but description adds value by explaining when to include context fields and differentiating body update vs. add_method_body, enhancing parameter understanding.

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 clearly states 'Update a method's properties', which is a specific verb+resource. It distinguishes from sibling tool 'add_method_body' by mentioning an alternative for appending code.

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 tells when to use add_method_body instead, and advises including context fields for 'significant changes', providing clear usage context.

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

save_patternB

Save or update a UI pattern checklist.

Use this to add new patterns or update existing ones based on lessons learned.

EXAMPLE: { "name": "accordion", "description": "Collapsible content panels", "checklist": [ "Use v-show for visibility toggle", "Store open state as boolean" ], "example": "const panels = ref([...]);" }

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Pattern name (e.g., "accordion", "modal")
`description`	Yes	Brief description of the pattern
`checklist`	Yes	Array of checklist items - best practices and things to remember
`example`	No	Optional code example

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description must cover behavioral traits. It indicates a write operation (save/update) and gives an example, but does not disclose side effects like overwriting behavior, concurrency, or requirements (e.g., pattern existence for updates).

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 description is concise with two sentences and a helpful example. The purpose is front-loaded, but the example could be slightly shorter without losing meaning.

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

Completeness3/5

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

Given no output schema, the description explains purpose and provides an example, but does not mention return values or error conditions. For a save/update tool, this information would be useful for complete understanding.

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 baseline is 3. The description includes an example that shows usage but does not add significant explanation beyond what the schema already provides for each parameter.

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 clearly states the tool saves or updates a UI pattern checklist, with a verb-resource combo. It doesn't explicitly distinguish from siblings like get_pattern or list_patterns, but the purpose is evident.

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?

The description says to use it for adding new or updating existing patterns, providing a clear use case. However, it does not specify when not to use it or mention alternatives, leaving some ambiguity.

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

save_routeA

Update a route/page. Wire to controller with both controller and controller_method UUIDs. For significant routes, include context fields.

ParametersJSON Schema

Name	Required	Description
`uuid`	Yes	UUID of the route to update
`controller`	No	Controller file UUID. Requires controller_method.
`controller_method`	No	Method UUID. Requires controller.
`path`	No	URL path (e.g., "/api/notes")
`name`	No	Route name
`type`	No
`method`	No
`middleware`	No
`public`	No	Public route (no auth)
`summary`	No	Context: What this endpoint does
`rationale`	No	Context: Why built this way
`references`	No	Context: Related entities [{uuid, type, relationship, note}]
`decisions`	No	Context: Design decisions

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It labels the tool as an update but does not describe what happens to unspecified fields, error conditions, or idempotency. This leaves significant gaps for a mutation tool.

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?

The description is two sentences with no fluff, front-loading the purpose and immediately following with actionable usage details. Every sentence earns its place.

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

Completeness3/5

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

Given 13 parameters and no output schema or annotations, the description addresses update semantics and a few parameter constraints, but omits return value, error handling, and partial update behavior, leaving moderate gaps for a complex tool.

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?

The description adds meaning beyond the schema by highlighting the joint requirement for 'controller' and 'controller_method' and the notion of 'significant routes' needing context fields. This compensates for the remaining 23% schema coverage 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 clearly states 'Update a route/page' as the verb and resource, distinguishing it from 'create_route' among siblings. However, it could be more precise by explicitly contrasting with creation or other operations.

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 provides specific guidance: wire to controller with both UUIDs, and include context fields for significant routes. This helps the agent know prerequisites and optional fields, though it lacks explicit when-not-to-use context against alternatives like 'create_route'.

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

save_settingA

Create or update a setting profile. Data is merged with existing values. Access via config('name.key') in code.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Setting profile name (e.g., "app", "vote", "features")
`data`	Yes	Key-value pairs for the setting (e.g., { "salt": "secret", "enabled": true })

TDQS

A4.5/5.0

Behavior4/5

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

Discloses merging semantics (data is merged, not overwritten) and access method. No annotations, so carries full burden; could mention idempotency or return value but still solid.

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?

Three sentences, no waste. Front-loaded purpose, then behavior, then usage hint. Ideal for quick scanning.

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?

Adequate for a simple create/update tool with no output schema. Covers purpose, behavior, and access. Lacks return value or error conditions but not critical for basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description adds meaningful context beyond schema: merging behavior and config() access pattern. Schema has 100% coverage, but description enriches understanding of how parameters interact.

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?

Clear verb+resource: 'Create or update a setting profile.' Distinguishes from sibling tools (delete_setting, get_setting) by being the sole create/update tool.

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?

Mentions merging behavior and access pattern via config(). Implicitly distinguishes from delete and get siblings, but lacks explicit when-to-use vs. when-not-to guidance.

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

save_statementB

Update an existing statement. Use this to modify statement properties after creation.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	UUID of the statement to update
`data`	No	Statement data to update

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It indicates mutation ('Update'), but omits critical details: whether the operation is idempotent, partial vs full update, error handling for non-existent uuid, authorization requirements, or side effects. The description is too brief to ensure safe agent invocation.

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?

The description is extremely concise (two short sentences) and front-loaded with the action. Every word is relevant; there is no redundancy or unnecessary elaboration.

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

Completeness2/5

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

Given no output schema, the description should inform about return values (e.g., updated statement or success status) or error behavior. It does not. For a mutation with 2 parameters and nested objects, the description is incomplete, lacking confirmation of success or failure states.

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?

Both parameters are described in the input schema (100% coverage). The description adds no new meaning; it merely restates the schema's 'Statement data to update' for the 'data' parameter. For the 'uuid' parameter, the description doesn't provide additional context (e.g., where to find it). With high schema coverage, baseline is 3, and the description adds no extra value.

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 clearly states 'Update an existing statement', which identifies the verb (update) and resource (statement). It implicitly distinguishes from 'create_statement' and 'delete_statement', though it doesn't explicitly name siblings. The phrase 'modify statement properties after creation' reinforces the update purpose.

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?

The description implies usage for modifications ('after creation'), but does not explicitly state when not to use (e.g., for new statements use 'create_statement'). It lacks prerequisites (e.g., statement must exist) and does not offer alternatives among siblings.

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

search_attributesA

Search for available PHP 8 attributes in Laravel. Returns attribute suggestions with descriptions, namespaces, targets (class/method/property/parameter), and expected arguments.

Use this before adding attributes to files or methods to find the correct attribute name and syntax.

Three modes of operation:

List categories (no params): Returns all available attribute categories
- Call with no arguments to discover categories like "eloquent", "queue", "routing"
List category attributes (category only): Returns all attributes in a category
- Example: category="eloquent" → returns Fillable, Hidden, ObservedBy, etc.
Search by query (query provided): Searches attribute names
- Example: query="fill" → finds Fillable attribute
- Can combine with category to search within a specific category

ParametersJSON Schema

Name	Required	Description
`query`	No	Search term to match against attribute names (e.g., "fillable", "middleware", "tries"). Optional - omit to list categories or all attributes in a category.
`category`	No	Filter to a specific category (e.g., "eloquent", "queue", "routing", "console", "container", "request", "testing", "resource", "factory"). When provided without query, returns all attributes in that category.
`target`	No	Filter attributes by where they can be applied. Default: returns all.

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries full behavioral disclosure burden. It describes three modes, return contents (suggestions with descriptions, namespaces, targets, arguments), and implies no side effects. It does not cover error handling or limitations but is adequate for a read-only search tool.

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?

The description is well-structured with a clear lead sentence, followed by a usage note and a list of modes. Every sentence adds value, there is no fluff, and it's appropriately concise for the complexity.

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?

Given three optional parameters and no output schema, the description completely covers behavior, return content, and usage modes with examples. It leaves no major ambiguity for an agent to invoke it correctly.

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 baseline is 3. The description adds significant meaning by explaining three modes of operation based on parameter combinations (no params, category only, query with optional category) and provides examples, which goes beyond the schema's individual parameter descriptions.

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 clearly states it 'Search[es] for available PHP 8 attributes in Laravel' and returns specific details (descriptions, namespaces, targets, arguments). It distinguishes from siblings like analyze_attributes and search_elements by focusing on attribute discovery with a specific domain (Laravel) and return structure.

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?

The description explicitly advises 'Use this before adding attributes to files or methods' and outlines three modes of operation, providing strong context. It does not explicitly mention when not to use or compare to alternatives, but the usage scenario is clear.

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

search_elementsA

Search for elements in the project. Useful for finding elements by name, type, or content.

Note: To reorder elements, use update_element to modify the parent element's 'data' array with the new order of child UUIDs.

ParametersJSON Schema

Name	Required	Description
`search`	No	Search query to match against element name, type, or content
`type`	No	Filter by element type (e.g., s-wrapper, s-input)
`include_metadata`	No	Include additional metadata
`per_page`	No	Results per page (1-100)

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does not explicitly state that the tool is read-only, nor does it mention any side effects, authentication requirements, or potential performance costs. The agent is left to infer safety from the tool name and context.

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?

The description is extremely concise: two sentences plus a short note. It front-loads the core purpose and includes a helpful note on a related action. Every sentence adds value without redundancy.

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

Completeness3/5

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

Given the tool has four parameters, no output schema, and no annotations, the description is somewhat sparse. It explains the search purpose and mentions a hint about reordering, but it does not describe the return format, pagination behavior, or what happens when no results are found. The note, while helpful, is slightly tangential to the main function.

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?

All four parameters are described in the input schema with 100% coverage. The description adds a brief clarification that the search query matches against 'name, type, or content,' which reinforces the schema but does not meaningfully extend beyond it. Baseline score of 3 is appropriate.

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 clearly states the tool's purpose: 'Search for elements in the project. Useful for finding elements by name, type, or content.' It identifies the specific verb (search) and resource (elements), and distinguishes it from sibling search tools for other resource types (e.g., search_files, search_methods).

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?

The description provides a clear usage guideline by mentioning an alternative action: 'To reorder elements, use update_element to modify the parent element's 'data' array.' This tells when not to use this tool. However, it does not explicitly compare with other search tools or provide scenarios for when to use this tool over them, though the sibling list implies differentiation.

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

search_filesB

Search for files in the project by name or type

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	File name pattern to search for
`type`	No	File type to filter by (class, model, controller, middleware)

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states 'search', which implies read-only, but does not mention safety, scope, pagination, or side effects. For a search tool, this is insufficient transparency.

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

Conciseness3/5

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

The description is a single sentence with no fluff, but it is too terse for a tool lacking annotations. It earns its place but sacrifices detail for brevity.

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

Completeness2/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 should clarify return values (e.g., file paths, content). It does not, leaving a significant gap. The tool is simple, but completeness is lacking.

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%, so baseline is 3. The description adds 'by name or type' which aligns with the parameters but does not elaborate on format, pattern matching, or examples. No additional semantic value beyond the schema.

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 clearly states 'Search for files in the project by name or type', specifying a distinct verb ('search'), resource ('files'), scope ('in the project'), and criteria ('name or type'). This differentiates well from sibling search tools like search_attributes or search_elements.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or when not to use it, leaving the agent to infer usage solely from the purpose.

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

search_methodsA

Search for methods in the project by name or within a specific file

ParametersJSON Schema

Name	Required	Description	Default
`name`	No	Method name to search for (supports wildcards)
`file_uuid`	No	Optional: filter results to a specific file

TDQS

A3.5/5.0

Behavior3/5

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

Annotations are absent, so the description must disclose behavioral traits. It correctly implies a read-only operation, but does not describe limitations, scope of search (e.g., whole project vs. workspace), or return characteristics. Adequate but not rich.

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?

Single sentence, no redundancy, every word carries meaning. Front-loaded with the core purpose. Highly efficient.

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

Completeness3/5

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

The tool is simple with two optional parameters, but the absence of an output schema means the description should hint at what is returned. It does not specify whether results include method names, locations, or full details. Slightly incomplete.

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 the description adds no new meaning beyond what the schema already provides (name with wildcards, optional file filter). The description essentially restates the schema descriptions, meeting the baseline but not compensating.

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 clearly states the verb 'search' and the resource 'methods', with specific scoping 'by name or within a specific file'. It implicitly distinguishes from sibling search tools targeting different resources (e.g., search_elements, search_files).

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like search_attributes or search_routes. The description does not provide when-not-to-use or recommend alternatives, which is a gap given the many sibling search tools.

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

search_routesA

Search for routes/pages in the project by name. Use this to find existing routes before creating new ones.

Returns paginated results with route details including UUID, name, path, and type. Use the returned UUID with html_to_elements (page parameter) or get_route for full details.

ParametersJSON Schema

Name	Required	Description
`search`	No	Search term to match route names (e.g., "Counter", "Home")
`type`	No	Filter by route type: "web" for pages, "api" for endpoints, "channels" for WebSocket channels, "view" for Blade views
`per_page`	No	Results per page (default: 10)

TDQS

A4.5/5.0

Behavior4/5

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

The description discloses that the tool returns paginated results with specific fields (UUID, name, path, type) and implies a read-only search operation. However, it does not explicitly state that it is non-destructive or mention any authentication or rate-limit requirements, though such details are less critical for a search tool.

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?

The description is three sentences long, each serving a distinct purpose: stating the tool's function, describing its output, and providing next-step guidance. No words are wasted, and the information is efficiently front-loaded.

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?

Despite the absence of annotations and output schema, the description fully informs the agent: what the tool does, when to use it, what it returns (including key fields), and how to leverage the results with other tools. This is complete for the tool's complexity level.

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?

The input schema already provides clear descriptions for all three parameters (search, type, per_page), achieving 100% coverage. The description does not add additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate.

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 clearly states the tool searches for routes/pages by name, with the explicit purpose of finding existing routes before creating new ones. This specific verb+resource combination distinguishes it from sibling tools like create_route, get_route, and delete_route.

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?

The description provides explicit when-to-use guidance ('Use this to find existing routes before creating new ones') and tells how to use the results with sibling tools html_to_elements and get_route, effectively preventing duplicate routes and enabling further actions.

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

update_elementA

Update a UI element. Data object: tag, classes, text, event handlers (method UUIDs), classBindings. Set 'name' on root elements to create Blade views (e.g., name="notes.index" for view('notes.index')).

For elements inside @foreach loops (SSR/Blade): Use these attributes to reference the loop variable (defaults to $item):

textField: Field name for text content → outputs {{ $item->fieldName }}
hrefField: Field name for href → outputs href="{{ $item->fieldName }}" (field value ONLY, no prefix)
srcField: Field name for src → outputs src="{{ $item->fieldName }}"

For hrefs with path prefixes (IMPORTANT): hrefField outputs ONLY the field value. There is NO hrefPrefix attribute. For links like /post/slug-here, you MUST use hrefExpression:

hrefExpression: "/post/{{ $item->slug }}" → outputs href="/post/{{ $item->slug }}"
hrefExpression: "/category/{{ $item->slug }}" → outputs href="/category/{{ $item->slug }}"

For complex Blade expressions in attributes: Use expression attributes when you need more than simple field access:

hrefExpression: Blade expression for href → outputs href="..." with the expression
srcExpression: Blade expression for src → outputs src="..." with the expression
altExpression: Blade expression for alt → outputs alt="..." with the expression

Examples:

Path prefix: hrefExpression: "/post/{{ $item->slug }}"
Route helper: hrefExpression: "{{ route('posts.show', $item->slug) }}"

For Blade text content: Use the statements array with statement UUIDs containing Blade code. The statement's code property will be output directly for Blade to evaluate.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	UUID of the element to update
`data`	Yes	HTML attributes and Stellify fields (tag, classes, text, classBindings, click, submit). Context fields: summary, rationale, references, decisions.

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully bears the burden of behavioral transparency. It discloses critical behaviors: setting 'name' creates Blade views, field attributes for foreach loops, hrefField outputs only the field value without prefix, and expression attributes are needed for complex Blade expressions. No contradictions exist.

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 description is wellstructured with clear headings and focused sections for different scenarios (foreach loops, href prefixes, complex expressions). While comprehensive, some repetition occurs (e.g., expression attributes for href, src, alt), but overall it is concise for the complexity involved.

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?

Given the tool's complexity (nested data object, Bladespecific behaviors, no output schema), the description covers the main use cases thoroughly. It explains field attributes, expression attributes, and statements for Blade text. However, it omits error handling, validation details, and return behavior, which mildly reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for both parameters (uuid and data), but the description adds substantial semantics: it details data object fields (tag, classes, text, event handlers, classBindings) and explains Bladespecific attributes and behaviors for loops and expressions. This goes far beyond the schema and is highly valuable.

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 clearly states 'Update a UI element' and distinguishes this from create_element and delete_element by specifying fields like 'uuid' for updating and emphasizing modifications to existing elements. It provides a specific verb and resource.

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?

The description offers extensive guidance on when to use specific attributes (textField, hrefField, expressions) and conditions (foreach loops, href prefixes). It implicitly advises against using hrefField for prefixed paths and recommends hrefExpression instead. However, it lacks explicit 'when-not-to-use' or direct sibling comparisons.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation3/5

Many tools have overlapping purposes (e.g., multiple ways to create methods/statements), and the sheer number of similar names can cause confusion. However, detailed descriptions help differentiate them.

Naming Consistency3/5

Most tools follow a verb_noun pattern (e.g., create_element, delete_file), but there are inconsistent outliers like 'html_to_elements' and varying verb forms (add vs create).

Tool Count3/5

With 50 tools, the set is very large. While the comprehensive scope justifies the count, it borders on overwhelming and may exceed typical MCP server expectations.

Completeness4/5

The tool set covers a wide range of development needs: file management, UI elements, routes, methods, analysis, performance, attributes, packages, and patterns. Only minor gaps like deployment or testing are missing.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Oolkin
com.oolkin
AI colleagues that keep your standards, your project and their reasoning between sessions
Knowledge & Memory Project Management Developer Tools
1
2ools B
app.2ools
Build, version, review, and export websites, web apps, and games from a conversation.
Developer Tools CI/CD & DevOps Content Management Systems
812
GitHub
io.github.github
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Version Control Developer Tools CI/CD & DevOps
1232,671
JustDeploy
ai.justdeploy
Deploy and manage your apps, databases, storage, and scheduled jobs from your AI agent
Cloud Platforms CI/CD & DevOps App Automation
2

Related MCP Servers

Webasyst MCP Server
Developer Tools App Automation Code Execution
emmy-design
A
license
C
quality
F
maintenance
Enables AI-assisted development for Webasyst framework projects, including creating and managing apps, plugins, themes, and configurations through natural language commands.
Updated 3 months ago (2026-05-20 09:27 UTC)
38
19
7
MIT
Laravel AI MCP Server
Documentation Access Developer Tools Code Analysis
pujandan
F
license
A
quality
D
maintenance
Provides AI assistants with direct access to Laravel documentation, coding rules, and implementation templates stored locally. It enables searching documentation, retrieving design system guides, and accessing domain-specific code examples to streamline Laravel development.
Updated 6 months ago (2026-02-24 14:23 UTC)
8
MCP AI Chat Server
CRM Project Management
fawazbayureksa
F
license
Not graded
quality
D
maintenance
A Laravel-based AI-powered chat interface for business management operations, enabling users to execute tasks like creating customers and updating task statuses through natural language conversations.
Updated 9 months ago (2025-12-07 15:33 UTC)
laravel-artisan-mcp
Shell Access Developer Tools Command Line
entanglr
A
license
Not graded
quality
C
maintenance
Enables secure execution of Laravel Artisan commands through AI assistants, allowing controlled management of Laravel projects via natural language.
Updated a year ago (2025-04-24 19:50 UTC)
6
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Stellify-Software-Ltd/stellify-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server