What can you do with this server?

This server is an MCP toolset for offloading code analysis, generation, and creative tasks to a local or remote LLM, saving Claude's context for higher-level work. * Code analysis & quality: analyze single or multi-file code quality, project structure, dependencies, database queries, n8n workflows, and architecture with actionable recommendations. * Security auditing: run comprehensive security audits with OWASP checks, WordPress-specific vulnerability scanning, and cross-file data-flow analysis. * Integration & debugging: compare file integrations, diff method signatures, trace execution paths, find pattern usage, and detect unused files, CSS, circular dependencies, or version conflicts. * Code generation & refactoring: convert JavaScript to TypeScript, generate unit tests, suggest refactorings, create responsive components, and generate project documentation. * WordPress tooling: generate complete plugins/themes, convert static HTML sites to WordPress themes, and run plugin/theme readiness and audit checks. * Creative tasks: generate 2D arcade games, interactive text adventures, and pure CSS art. * Custom prompts: send arbitrary tasks with optional file context via the custom_prompt fallback tool. * System utilities: list available functions, run health checks, resolve file paths, and inspect or clear the analysis cache.

Which integrations are available for this server?

Generates pure CSS art and animations through creative project functions Creates complete playable HTML5 games and responsive HTML components with accessibility features Performs deep code analysis, quality assessment, security auditing, and generates comprehensive unit tests for JavaScript files Generates professional documentation and beautiful project structure trees in markdown format Analyzes Node.js projects including dependency analysis, circular dependency detection, and unused import identification Conducts security audits and vulnerability scanning with OWASP compliance checking Generates comprehensive unit tests and analyzes React components for quality and best practices Converts JavaScript files to TypeScript with strict mode and type safety implementation Creates complete WordPress plugins with custom post types and admin interfaces, and performs security audits on WordPress themes

How do I use Houtini-lm?

1. Click on "Deploy 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., "@Houtini-lm analyze the security of my React app at C:/projects/my-app" 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.

de en es ja ko ru zh

Houtini-lm

by houtini-ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Houtini LM (@houtini/lm) - Offload Work from Claude Code to a Local LLM, OpenAI GPT-5/6, a Router or a Cheaper Cloud Model

npm version MCP Registry License: Apache 2.0 Known Vulnerabilities

Houtini LM is an MCP server that lets Claude (or any MCP client) hand bounded work to another model - a local LLM on your GPU, OpenAI's latest GPT models, a LiteLLM router, OpenRouter or a cheap cloud API - while you carry on working in the AI platform you already like. It cuts your token bill, and it gives you a second model to review your code whenever you want one.

Quick Navigation
What's new | Why use it | Install | How it handles different models | What to hand over | Tools | Reading the footer | Configuration | Endpoints | The manual

I built this because I kept leaving Claude Code running overnight on big refactors and the token bill was painful. A huge chunk of that spend went on bounded tasks any decent model handles fine - generating boilerplate, code review, commit messages, format conversion, the sort of work that doesn't need Claude's reasoning or its tool access.

So Claude stays the architect, doing the planning, the multi-file changes and the judgement calls, and houtini-lm passes the drafting to whatever model you've got running. That could be Qwen on a GPU box under your desk, GPT-5 or GPT-6 straight from OpenAI, a model behind a LiteLLM router, one of OpenRouter's 300+ models or DeepSeek at pennies per million tokens. Claude QAs everything that comes back.

I wrote a full walkthrough of why I built this and how I use it day to day if you'd like the longer story.

What's new in 3.3

houtini-lm now speaks to far more than a local GPU. Point it at OpenAI directly and GPT-5, GPT-6 and the o-series reasoning models work without any router in between. They reject parameters every open model accepts (max_tokens, temperature), so houtini-lm sends them max_completion_tokens only, learns a model's output cap from its own error when the endpoint doesn't report it, and leaves the image, speech and moderation models out of the list. Point it at a LiteLLM router and it reads which real model sits behind each alias, along with that model's true context window and output cap, so a mixed fleet of local and hosted models is sized and profiled correctly. Thinking is now your call (auto, off or on), there's a Docker guide built from a working deployment, and the manual has a page per job. The changelog has the detail.

Related MCP server: LMStudio-MCP

Why use houtini-lm?

The bottom line before we go deep: you keep your favourite AI platform, and you stop paying frontier prices for work that doesn't need a frontier model.

The obvious win is cost. When Claude delegates a review with code_task_files, the source files are read by the houtini-lm process and sent straight to the other model, so they never enter Claude's context window at all. Claude sends a short tool call and reads back a short answer. I benchmarked this on real TypeScript source files:

Task	Claude reads it directly	Delegated	Saved
Code review (1,352 lines)	14,466 tokens	769 tokens	95%
Architecture review (2,022 lines)	20,014 tokens	983 tokens	95%
External repo review (581 lines)	5,344 tokens	741 tokens	86%
Code explanation (833 lines)	8,678 tokens	744 tokens	91%

That averages out at 93.3% saved across the session. To be fair, small tasks like a one-line question or a commit message don't save much, because the tool call overhead (around 250 tokens) is about the same size as the answer. Anything that involves reading files, which is most of a real coding session, pays for itself straight away. You can run the same benchmark against your own setup with LM_STUDIO_URL=http://your-server:1234 node scripts/benchmark.mjs.

The less obvious win is a second opinion. A different model reads your code with different blind spots, and it costs you next to nothing to ask. As it happens, the 3.3.0 release of this repo is a decent example: I had Claude point houtini-lm at gpt-6-astra (through my LiteLLM router) and ask it to review the release's own 14,000-token diff. It came back with three real bugs - a router probe that cached a temporary 429 as a permanent "not a router", an output cap that got overwritten, and a race in the model list cache - and all three were fixed before the release shipped. Two of the three new test files were drafted the same way, then reviewed by Claude before commit.

Code review is where this pays off hardest, because reviews are exactly the bounded, read-a-lot-write-a-little work that a cheaper model does well. From there the list keeps growing: test stubs, docstrings, commit messages, changelog drafts, format conversion, mock data, type definitions, embeddings for a RAG pipeline, a quick sanity check on a regex, brainstorming three approaches before Claude commits to one, and so on.

The trade-off is wall-clock time. Local inference is typically 3-30x slower than a frontier model, so delegation wins on bounded, self-contained tasks rather than everything. A local model keeps your code private and costs nothing per token, a cloud model is cheap, and neither touches your Claude quota or its rate limits.

How it works

Claude Code, Claude Desktop, Cursor... (orchestrator)
   |
   |-- Reasoning, planning, architecture, tool use --> your main AI platform
   |
   +-- Bounded grunt work --> houtini-lm --HTTP/SSE--> any OpenAI-compatible endpoint
       . Code review & second opinions       LM Studio, Ollama, vLLM, SGLang, llama.cpp
       . Test stubs & boilerplate            LiteLLM routers
       . Commit messages & docs              OpenRouter (300+ models)
       . Format conversion & mock data       DeepSeek, Groq, Cerebras, OpenAI...
       . Embeddings for RAG pipelines

Claude's the architect, the other model's the drafter, and Claude checks everything that comes back.

Install

You'll need Node 22.5 or newer and an OpenAI-compatible endpoint: LM Studio, Ollama, vLLM, SGLang, a LiteLLM router, or a cloud API key for OpenAI, DeepSeek, Groq and the like. In Claude Code, with LM Studio running on the same machine, it's one command:

claude mcp add houtini-lm -- npx -y @houtini/lm

That's it. LM Studio listens on localhost:1234 by default, which is where houtini-lm looks first, so Claude can start delegating straight away. Anywhere else, set the URL (and a key, if the endpoint needs one):

claude mcp add houtini-lm \
  -e HOUTINI_LM_ENDPOINT_URL=http://192.168.1.50:1234 \
  -e HOUTINI_LM_API_KEY=your-key-if-needed \
  -- npx -y @houtini/lm

OpenAI works the same way. Pin the model you want, because OpenAI lists dozens and they all score the same in routing:

claude mcp add houtini-lm \
  -e HOUTINI_LM_ENDPOINT_URL=https://api.openai.com \
  -e HOUTINI_LM_API_KEY=sk-... \
  -e HOUTINI_LM_MODEL=gpt-5.2 \
  -e HOUTINI_LM_SERIALISE=0 \
  -- npx -y @houtini/lm

Installing houtini-lm walks through every route: a GPU on another machine, OpenAI and other cloud APIs, OpenRouter, a LiteLLM router, Claude Desktop and other MCP clients, plus how to check it worked and how to update. If you'd rather run it in a container, Running houtini-lm in Docker covers both a plain docker run -i and serving it over HTTP behind Docker's MCP Gateway. New to local models altogether? Start with Getting started, which covers which models fit on 16, 32, 64, 96 or 128 GB of VRAM.

To check everything's wired up, ask Claude to run houtini-lm's discover tool. It tells you the version, which endpoint it found, which model is active and how big its context window is.

How houtini-lm handles different models

No two open source LLMs are the same. They differ in context window, output cap, prompt template, whether they think before they answer and how much of that they report, so a lot of houtini-lm's code is about working out what it's talking to and adjusting for it. How houtini-lm handles different models has the full detail, and here's the short version.

At startup houtini-lm asks your server for every model it has, loaded and downloaded, and looks each one up on HuggingFace for its architecture, licence and chat template, caching the lot in SQLite so later startups are instant. For the families I know well (Qwen, Nemotron, Granite, LLaMA, GLM, GPT-OSS, DeepSeek, Gemma, Kimi and OpenAI's hosted GPT models) there's a curated profile, and each family gets its own temperature, output constraints and think-block handling, while OpenAI's hosted reasoning models (GPT-5/6, o-series) are sent only the parameters they accept. Run list_models and you get the whole picture:

Loaded models (ready to use):

  nvidia/nemotron-3-nano
    type: llm, arch: nemotron_h_moe, quant: Q4_K_M, format: gguf
    context: 200,082 (max 1,048,576), by: nvidia
    Capabilities: tool_use
    NVIDIA Nemotron: compact reasoning model optimised for step-by-step logic
    Best for: analysis tasks, code bug-finding, math/science questions
    HuggingFace: text-generation, 1.7M downloads, MIT licence

Available models (downloaded, not loaded):

  qwen3-coder-30b-a3b-instruct
    type: llm, arch: qwen3moe, quant: BF16, context: 262,144
    Qwen3 Coder: code-specialised model with agentic capabilities
    Best for: code generation, code review, test stubs, refactoring
    HuggingFace: text-generation, 12.9K downloads, Apache-2.0

Output budgets come from the model each call is actually sent to. Leave max_tokens unset and the call gets 25% of that model's context window, never more than its declared output cap or the room left beside your prompt, so a hosted model doesn't get sent a request it'll reject. There's a floor too, because MCP clients habitually pass tiny caps like 256 that strangle reasoning models mid-thought, so anything under 4,096 is ignored unless you set HOUTINI_LM_MIN_TOKENS=0.

Thinking is your decision, through HOUTINI_LM_THINKING. The default, auto, switches thinking off for models detected as supporting the toggle (Qwen3, Gemma 4, Nemotron, DeepSeek R1, GLM-4, gpt-oss), which suits Claude doing the reasoning and the other model doing the drafting. off forces that on every call, which you need when a backend serves a thinking model under a name detection can't recognise. on forces thinking on, which is worth it for bug-hunting or checking an argument, at the cost of time and tokens. Whichever you choose, houtini-lm inflates the output budget for thinking models and strips any <think> blocks from the answer, so the reasoning doesn't leave you with an empty reply.

With several models available, houtini-lm scores each against the task type and picks the best, and it suggests a better model rather than swapping one in, since loading a model takes minutes. On a big catalogue every unknown model scores the same and the first listed wins, so pin one with HOUTINI_LM_MODEL, or pass model on an individual call.

Point it at a LiteLLM router and it reads /model/info as well, which tells it the real model behind each alias (my local alias is qwen3.6-27b) and, for hosted models, the true context window and output cap. Each alias is then profiled and sized as the model it actually is, the TTS, image and video models a router lists by the dozen are filtered out, and rate-limit errors are retried with backoff. Calls are queued one at a time by default, because a single GPU can only serve one request anyway; OpenRouter skips the queue, and for OpenAI, a router or a batching backend like vLLM you can turn it off with HOUTINI_LM_SERIALISE=0.

What to hand over

The best candidates are bounded and well defined, with a clear input and a clear output:

Task	Why it works on another model
Code review	Paste the full source (or pass the paths), ask for bugs
A second opinion on a plan	Doesn't commit to anything, costs next to nothing
Generate test stubs	Source in, tests out
Explain a function	Summarisation doesn't need tool access
Draft commit messages	Diff in, message out
Convert formats	JSON to YAML, snake_case to camelCase
Generate mock data	Schema in, data out
Write type definitions	Source in, types out
Structured JSON output	Grammar-constrained, valid by construction
Text embeddings	Semantic search, RAG pipelines

Anything that needs reasoning across the codebase, tool access or multi-step orchestration stays on Claude: architectural decisions, reading and writing files, running tests and interpreting the results, multi-file refactoring plans and anything that has to call other tools. The tool descriptions are written to nudge Claude into planning delegation at the start of a big task, rather than only using it when it happens to remember.

The tools

There are eight of them. The full parameter reference is in The tools, in depth.

Tool	What it's for
`chat`	The workhorse. Send a task, get an answer.
`custom_prompt`	System, context and instruction kept separate, which consistently beats stuffing everything into one message on local models. I tested this properly one weekend with the same batch of review tasks run both ways, and the three-part version won every round.
`code_task`	Code analysis with a code-tuned system prompt and per-family temperature.
`code_task_files`	Like `code_task`, but houtini-lm reads the files from disk itself, so the source never passes through Claude's context. Unreadable files are reported inline rather than sinking the call, and a pre-flight estimator refuses inputs that measured data says would time out.
`embed`	Text embeddings via `/v1/embeddings` (Nomic Embed is a solid choice).
`discover`	Health check: endpoint, active model, context window, output cap, and measured speed once there's a real call to measure.
`list_models`	Everything on the server, loaded and downloaded, with profiles.
`stats`	Session and lifetime offload totals and per-model performance, without the model catalogue.

The inference tools (chat, custom_prompt, code_task, code_task_files) all take an optional model to pin the call, max_tokens, and sampling controls (temperature, seed, stop, top_p, top_k, repeat_penalty, frequency_penalty, presence_penalty). chat and custom_prompt also take a json_schema, which forces the answer to conform to a JSON Schema; on LM Studio that's grammar-based sampling, so there's no hoping the model remembers to close its brackets:

{
  "json_schema": {
    "name": "code_review",
    "schema": {
      "type": "object",
      "properties": {
        "issues": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "line": { "type": "number" },
              "severity": { "type": "string" },
              "description": { "type": "string" }
            },
            "required": ["line", "severity", "description"]
          }
        }
      },
      "required": ["issues"]
    }
  }
}

If you're driving houtini-lm from your own scripts rather than from Claude, set HOUTINI_LM_STRUCTURED=1 and each inference result also carries a structuredContent block (the answer, model, tokens, timing, quality flags) to read as JSON. Leave it off for Claude Code, which shows the model only that block when it's present (the tools page has the story).

Reading the footer

Every response ends with a footer computed from the SSE stream itself:

---
Model: nvidia/nemotron-3-nano | 279→303 tokens (12 reasoning / 291 visible) | TTFT: 485ms, 58.0 tok/s, 5.2s
📊 First measured call on nvidia/nemotron-3-nano: 58.0 tok/s, 485ms to first token - use this to gauge whether to delegate longer tasks.
💰 Offloaded - this session: 4,283 tokens / 7 calls · lifetime: 147,432 tokens / 213 calls

The first-call line appears once per model per session, and it's a benchmark from a real task rather than a synthetic warm-up. The 💰 line updates every call, and it counts the tokens the other model handled (its prompt and completion, reasoning included), which is work Claude didn't do rather than a measure of Claude tokens saved; the benchmark above is the honest measure of that. When a model reports its reasoning tokens, the token count splits into reasoning and visible, so you can see when a thinking model is burning budget on hidden reasoning.

When something went wrong, a quality line says so: TRUNCATED for a partial result (a stalled connection gives you what arrived rather than a timeout error), hit-max-tokens when the budget ran out, think-blocks-stripped when reasoning was removed and tokens-estimated when the server didn't report usage. Clean output gets no quality line at all.

Per-model speed and token counts persist in ~/.houtini-lm/model-cache.db, so discover shows your measured tok/s and time to first token from the first call of a new session, and stats gives you the lifetime totals. That data is specific to your workstation on purpose, because delegation decisions should reflect your hardware rather than somebody else's benchmark. In practice, Claude delegates more the longer a session runs; after about 5,000 offloaded tokens it starts hunting for more work to push over.

Getting good results

Qwen, Llama, Nemotron and GLM score brilliantly on coding benchmarks now, and the gap between a good and a bad result is almost always the prompt rather than the model. I've spent a fair bit of time on this, and the short version goes like this. Send complete code, because local models make up details when the input is truncated, so send the whole function rather than a snippet with ... in the middle. Be explicit about the output format ("return a JSON array"), since smaller models need it. Give the model a specific persona ("expert Rust developer who cares about memory safety" does noticeably better than "helpful assistant"), state what not to do as well as what to do, and for code generation include the imports, types and signatures around the function body.

Keep long jobs in chunks, too. Most MCP clients time a tool call out at around 60 seconds, and although houtini-lm sends a progress notification on every streamed chunk to keep the clock reset, not every client or gateway passes those through. Calls of roughly 500-900 output tokens finish comfortably inside the limit. The craft of delegation goes much deeper, including the verbatim-echo pattern I use for fixes.

Check your install

npm run shakedown

scripts/shakedown.mjs runs seven of the eight tools end to end (everything except stats) and prints a table of real TTFT, tok/s, token counts and reasoning split for each call. It takes under a minute on a decent rig:

Summary

   7/7 steps passed on LM Studio, model=nvidia/nemotron-3-nano

| Tool              | OK  | TTFT (ms) | tok/s  | Tokens in→out        | Reasoning | Notes
| chat              | ✅  |      891  |   36.9 | 48→104               |        —  | answered
| custom_prompt     | ✅  |      872  |   43.9 | 170→333              |        —  | 5 valid items
| code_task         | ✅  |      857  |   41.6 | 180→189              |        —  | tests generated
| code_task_files   | ✅  |   11028   |   39.5 | 6891→3000            |        —  | cross-referenced
| embed             | ✅  |      —    |     —  | —                    |        —  | 768-dim vector

   Tokens offloaded: 10,915 (prompt: 7,289, completion: 3,626, reasoning: 0)

If you'd rather have a quality review than latency numbers, paste SHAKEDOWN.md into a Claude session with houtini-lm attached and Claude will drive the same steps and write you a report on the output as well as the speed.

Configuration

Most setups need only the first two or three of these. The full list, including the file-access and queuing controls, is in Configuration.

Variable	Default	What it does
`HOUTINI_LM_ENDPOINT_URL`	`http://localhost:1234`	Base URL of the OpenAI-compatible API, without `/v1`.
`HOUTINI_LM_API_KEY`	(none)	Bearer token for authenticated endpoints.
`HOUTINI_LM_MODEL`	(auto-detect)	The model calls use unless they name one. Pin it on routers and big catalogues.
`HOUTINI_LM_THINKING`	`auto`	`auto`, `off` or `on` - see Thinking: auto, off or on.
`HOUTINI_LM_SERIALISE`	`1`	Set to `0` for cloud APIs like OpenAI, routers in front of cloud models, and backends that batch natively (vLLM, SGLang).
`HOUTINI_LM_MIN_TOKENS`	`4096`	Floor for caller-supplied `max_tokens`. Set to `0` to honour any value.

Compatible endpoints

Anything that speaks the OpenAI /v1/chat/completions API will work:

What	URL	Notes
LM Studio	`http://localhost:1234`	Default, zero config, rich metadata via its v0 API. Setup guide
Ollama	`http://localhost:11434`	Thinking models (qwen3, deepseek-r1) handled via Ollama's `delta.reasoning` channel. Setup guide
vLLM	`http://localhost:8000`	Native OpenAI API. Setup guide
SGLang	`http://localhost:30000`	Good for repeated-context work. See Getting started
LiteLLM router	`http://localhost:4000`	Auto-detected: aliases resolved, real limits read, non-chat models filtered, 429 backoff
llama.cpp	`http://localhost:8080`	Server mode
OpenAI	`https://api.openai.com`	GPT-5, GPT-6 and the o-series sent only the parameters they accept; image, speech and moderation models left out of the list. Pin a model
OpenRouter	`https://openrouter.ai/api`	300+ models, auto-detected, parallel requests allowed
DeepSeek	`https://api.deepseek.com`	Very cheap per token
Groq	`https://api.groq.com/openai`	Fast
Cerebras	`https://api.cerebras.ai`	Very fast
Any OpenAI-compatible API	Any URL	Set the URL and API key

The manual

This README is the overview, and the depth lives in these pages:

Page	What's in it
Installing houtini-lm	Every install route: local, remote GPU, cloud, OpenRouter, LiteLLM, Claude Desktop, other clients, and updating
Running houtini-lm in Docker	`docker run -i`, or served over HTTP behind Docker's MCP Gateway, with the traps we measured
How houtini-lm handles different models	Discovery, profiles, thinking (auto, off or on), output budgets, routing, LiteLLM routers, models that reject parameters
Configuration	Every environment variable, per-call settings, and where state lives
The tools, in depth	All eight tools: the parameters, reading the footer, the max_tokens floor
The craft of delegation	What to hand off and how to brief it, the verbatim-echo pattern, micro-chunking, reasoning-model budgets
Troubleshooting	Symptom > cause > fix for empty responses, timeouts, context-length 400s, queuing and routers
Getting started	Local models from zero: LM Studio or Docker, what small models are good at, which fit your VRAM
LM Studio, Ollama and vLLM setup	Backend guides, each with the traps that cause silent failures
Shakedown test	The end-to-end check, as a script or as a prompt for Claude
Developer guide	Architecture, contributing, release process

Development

git clone https://github.com/houtini-ai/houtini-lm.git
cd houtini-lm
npm install
npm test             # build + unit tests
npm run shakedown    # end-to-end self-test against a live endpoint

DEVELOPER.md covers the architecture, the reasoning-model pipeline, backend detection, the SQLite performance cache and how to add new tools or backends. If you find a model family houtini-lm handles badly, open an issue with the discover output and I'll take a look.

Good luck, and let me know how you get on!

Licence

Apache-2.0

Available Tools

34 tools

analyze_code_qualityA

Analyze code quality including complexity, maintainability, and best practices adherence

WORKFLOW: Perfect for understanding complex code, identifying issues, and technical debt assessment TIP: Use Desktop Commander to read files, then pass content here for analysis SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of analysis to perform	comprehensive
`code`	No	The code to analyze (for single-file analysis)
`filePath`	No	Path to single file to analyze
`files`	No	Array of specific file paths (for multi-file analysis)
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`projectPath`	No	Path to project root (for multi-file analysis)

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool 'SAVES: Claude context for strategic decisions' which adds useful behavioral context about state persistence. However, it doesn't disclose important behavioral traits like whether this is a read-only analysis, computational requirements, potential side effects, or error handling for the analysis operation.

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 appropriately sized with three distinct sections (main description, WORKFLOW, TIP, SAVES) that are front-loaded with the core purpose. Each section adds value, though the 'SAVES' section could be more integrated with the main description rather than appearing as an afterthought. Overall efficient with minimal waste.

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 (8 parameters, no output schema, no annotations), the description provides adequate but incomplete coverage. It explains the purpose and usage context well but doesn't address important contextual aspects like what the analysis output looks like, limitations of the analysis, error conditions, or how to interpret results. For a tool with this many parameters and no output schema, more completeness would be expected.

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 description coverage, the baseline is 3. The description doesn't add any parameter-specific information beyond what's already documented in the schema. It mentions general analysis aspects but doesn't explain how parameters like analysisDepth, analysisType, or the file selection parameters (code, filePath, files, projectPath) relate to each other or should be used together.

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 code quality with specific aspects (complexity, maintainability, best practices adherence), which provides a specific verb+resource. However, it doesn't explicitly differentiate from sibling tools like analyze_single_file or analyze_project_structure, which appear to have overlapping functionality. The purpose is clear but lacks sibling differentiation.

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 with the 'WORKFLOW' section stating it's perfect for understanding complex code, identifying issues, and technical debt assessment. The 'TIP' section offers practical guidance to use Desktop Commander first. However, it doesn't explicitly state when NOT to use this tool or name alternatives among siblings, so it falls short of a perfect score.

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

analyze_database_queriesA

Analyze database queries for performance, security, and best practices in code files or entire projects

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of database analysis to perform	comprehensive
`code`	No	The code to analyze for database queries (for single-file analysis)
`context`	No	Database and framework context for specialized analysis
`filePath`	No	Path to single file to analyze for database queries
`files`	No	Array of specific file paths (for multi-file analysis)
`language`	No	Programming language	php
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`projectPath`	No	Path to project root (for multi-file database analysis)

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden of behavioral disclosure. It mentions the tool 'SAVES: Claude context for strategic decisions' which adds useful behavioral context about state persistence. However, it doesn't disclose other important traits like whether this is a read-only analysis tool, potential performance impact, error handling, or output format expectations. The description adds some value but leaves significant behavioral aspects unspecified.

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 efficiently structured with clear sections (purpose, workflow, tip, saves) using minimal sentences. Each section adds value: the first states purpose, the second provides usage context, the third gives a practical tip, and the fourth discloses behavioral trait. However, the formatting with all-caps headings could be more polished, and the workflow section could be integrated more smoothly.

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 complexity (9 parameters, no output schema, no annotations), the description provides adequate but incomplete coverage. It explains the purpose and basic workflow well, but doesn't address important contextual aspects like what the analysis output looks like, error conditions, or how different parameters interact. For a tool with this many parameters and no output schema, more completeness would be expected regarding what users can expect from the analysis results.

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 schema already documents all 9 parameters thoroughly with descriptions, defaults, and enums. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions analyzing 'code files or entire projects' which aligns with the filePath/projectPath parameters but doesn't provide additional semantic context. Baseline 3 is appropriate when schema does the heavy lifting.

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 database queries for performance, security, and best practices in code files or projects. It specifies the resource (database queries) and scope (code files/projects) with specific analysis dimensions. However, it doesn't explicitly differentiate from siblings like 'analyze_code_quality' or 'security_audit' which might overlap in analyzing code or security aspects.

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 for usage: 'Perfect for understanding complex code, identifying issues, and technical debt assessment' and includes a workflow tip to use Desktop Commander for file reading. It implies this tool is for database-specific analysis in code, but doesn't explicitly state when to use alternatives like 'analyze_code_quality' for non-database code analysis or 'security_audit' for broader security checks.

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

analyze_dependenciesA

Analyze code dependencies including circular references, unused imports, version conflicts, and coupling issues

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of dependency analysis detail	detailed
`analysisType`	No	Type of dependency analysis to perform	comprehensive
`checkDevDependencies`	No	Include devDependencies in analysis
`code`	No	The code to analyze for dependencies (single-file analysis)
`filePath`	No	Path to single file to analyze for dependencies
`files`	No	Array of specific file paths for dependency analysis
`ignorePatterns`	No	Patterns to ignore (e.g., ["node_modules", "*.test.js"])
`includePackageJson`	No	Include package.json analysis for version conflicts
`language`	No	Programming language for language-specific dependency patterns	javascript
`maxDepth`	No	Maximum directory depth for dependency discovery (1-5)
`projectPath`	No	Path to project root for comprehensive dependency analysis

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool 'SAVES: Claude context for strategic decisions' which is valuable behavioral information about state retention. However, it doesn't disclose important behavioral traits like whether this is a read-only analysis vs. potentially modifying code, performance characteristics, error handling, or output format. For an 11-parameter analysis tool with no annotations, more behavioral context would be helpful.

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 uses a structured format with sections (WORKFLOW, TIP, SAVES) which helps organization. However, it includes some redundant information - the first sentence already covers the purpose, and the WORKFLOW section partially repeats this. The 'SAVES' section adds unique value but could be more integrated. Overall, it's reasonably concise but not perfectly front-loaded or streamlined.

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 (11 parameters, no output schema, no annotations), the description provides adequate but not complete context. It explains the purpose and gives usage guidance but doesn't describe what the analysis output looks like or important behavioral constraints. For a sophisticated dependency analysis tool with many configuration options, more information about expected outputs and analysis limitations would be helpful.

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 schema already documents all 11 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'single-file analysis' which aligns with the 'code' parameter description, but this doesn't provide additional semantic value. With complete schema coverage, the baseline score of 3 is appropriate.

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 code dependencies and lists specific aspects (circular references, unused imports, version conflicts, coupling issues). It distinguishes from siblings like analyze_code_quality or analyze_single_file by focusing specifically on dependency relationships rather than general code quality or single-file analysis. However, it doesn't explicitly differentiate from analyze_project_structure which might overlap in scope.

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 about when to use this tool: 'Perfect for understanding complex code, identifying issues, and technical debt assessment.' It also offers a workflow tip: 'Use Desktop Commander to read files, then pass content here for analysis.' This gives practical guidance on how to prepare inputs. However, it doesn't explicitly state when NOT to use this tool or mention specific alternatives among the many sibling tools.

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

analyze_n8n_workflowB

Analyze and optimize n8n workflow JSON for efficiency, error handling, and best practices

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of analysis to perform	comprehensive
`code`	No	The code to analyze (for single-file analysis)
`filePath`	No	Path to single file to analyze
`files`	No	Array of specific file paths (for multi-file analysis)
`includeCredentialCheck`	No	Check for exposed credentials
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`optimizationFocus`	No	Primary optimization focus	all
`projectPath`	No	Path to project root (for multi-file analysis)
`suggestAlternativeNodes`	No	Suggest alternative node configurations
`workflow`	No	n8n workflow JSON object

TDQS

B3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions analysis and optimization but doesn't describe what the tool actually does behaviorally: Does it return suggestions? Generate reports? Modify the workflow? What are the performance characteristics or limitations? The 'SAVES' hint about 'Claude context for strategic decisions' is vague and doesn't clarify the tool's behavior. This leaves significant gaps in understanding how the tool operates.

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 uses a bulleted format with sections (WORKFLOW, TIP, SAVES) which provides some structure. However, it's somewhat verbose with marketing-like language ('Perfect for understanding complex code') that doesn't add concrete value. The 'SAVES' section is particularly vague and doesn't clearly explain tool behavior. While not excessively long, some sentences don't earn their place in helping an agent understand the tool.

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 the complexity (12 parameters, nested objects) and absence of both annotations and output schema, the description is insufficiently complete. It doesn't explain what the tool returns, how optimizations are suggested, what format results come in, or any behavioral constraints. For a tool with this many parameters and no structured output documentation, the description should provide more complete context about the tool's operation and results.

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, so all parameters are documented in the schema itself. The tool description doesn't add any meaningful parameter semantics beyond what's already in the schema. It mentions 'n8n workflow JSON' which corresponds to the 'workflow' parameter, but this is already clear from the schema. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.

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's purpose: 'Analyze and optimize n8n workflow JSON for efficiency, error handling, and best practices.' This specifies the verb (analyze/optimize), resource (n8n workflow JSON), and scope (efficiency, error handling, best practices). However, it doesn't explicitly differentiate from sibling tools like 'analyze_code_quality' or 'analyze_single_file' which might have overlapping functionality.

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 some usage context in the 'TIP' section: 'Use Desktop Commander to read files, then pass content here for analysis.' This implies a workflow but doesn't explicitly state when to use this tool versus alternatives like 'analyze_single_file' or 'analyze_project_structure.' The 'WORKFLOW' section suggests it's for 'understanding complex code, identifying issues, and technical debt assessment' but doesn't provide clear exclusions or comparisons to siblings.

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

analyze_project_structureB

Analyze complete project structure and architecture with actionable strategic recommendations

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of analysis to perform	comprehensive
`code`	No	The code to analyze (for single-file analysis)
`filePath`	No	Path to single file to analyze
`files`	No	Array of specific file paths (for multi-file analysis)
`focusAreas`	No	Areas to focus on: architecture, dependencies, complexity, patterns
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth to analyze (1-5)
`projectPath`	No	Absolute path to project root

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the tool 'SAVES: Claude context for strategic decisions,' it doesn't describe critical behaviors like whether this is a read-only analysis or if it modifies files, what permissions are required, potential rate limits, or what the output format looks like. For a complex analysis tool with 9 parameters, this leaves significant gaps in understanding how it behaves.

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 efficiently structured with clear sections (main description, WORKFLOW, TIP, SAVES) and uses bullet-like formatting. Each sentence adds value, though the 'SAVES' section could be more clearly integrated. It's appropriately sized for a complex tool without unnecessary verbosity.

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 complexity (9 parameters, no annotations, no output schema), the description provides good purpose and usage context but lacks critical behavioral information. The absence of output schema means the description should ideally explain what kind of analysis results to expect, but it only mentions 'actionable strategic recommendations' without detailing the format or scope of outputs.

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 schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly with descriptions, defaults, and enums. The description adds no additional parameter information beyond what's in the schema, making the baseline score of 3 appropriate since the schema does the heavy lifting for parameter documentation.

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 'complete project structure and architecture' and provides 'actionable strategic recommendations,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'analyze_code_quality' or 'analyze_single_file,' which appear to have overlapping purposes in code analysis.

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 with 'WORKFLOW: Perfect for understanding complex code, identifying issues, and technical debt assessment' and 'TIP: Use Desktop Commander to read files, then pass content here for analysis,' giving practical guidance on when and how to use it. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools.

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

analyze_single_fileA

Analyze code structure, quality, patterns, and provide actionable recommendations for individual files or entire projects

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of analysis to perform	comprehensive
`code`	No	The code to analyze (for single-file analysis)
`context`	No	Optional context for framework-specific analysis
`filePath`	No	Path to single file to analyze
`files`	No	Array of specific file paths (for multi-file analysis)
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`projectPath`	No	Path to project root (for multi-file analysis)

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It mentions the tool 'SAVES: Claude context for strategic decisions' which adds behavioral context about persistence, but doesn't disclose other important traits like whether this is a read-only analysis, computational cost, rate limits, or authentication requirements for a tool with 9 parameters.

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 uses a structured format with sections (DESCRIPTION, WORKFLOW, TIP, SAVES) which is helpful, but contains some redundancy and could be more front-loaded. The opening sentence is comprehensive but could be more concise, and the sections could be better integrated.

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 complex tool with 9 parameters, no annotations, and no output schema, the description provides reasonable context about purpose and workflow but lacks details about return values, error conditions, or limitations. The mention of saving Claude context is helpful but insufficient for full 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?

With 100% schema description coverage, the schema already documents all 9 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, though it implies the tool handles both single-file and multi-file analysis through its opening statement.

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 code for structure, quality, patterns and provides recommendations, specifying it works for individual files or entire projects. However, it doesn't explicitly differentiate from sibling tools like 'analyze_code_quality' or 'analyze_project_structure', which appear to offer overlapping functionality.

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 usage context with 'WORKFLOW' and 'TIP' sections, indicating it's for understanding complex code, identifying issues, and technical debt assessment, and suggesting to use Desktop Commander first. However, it doesn't explicitly state when NOT to use this tool or when to choose specific sibling alternatives.

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

analyze_wordpress_securityB

Comprehensive WordPress security analysis for plugins, themes, and core implementations with OWASP and WordPress-specific vulnerability detection

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of security analysis detail	detailed
`analysisType`	No	Type of security analysis to perform	comprehensive
`auditDatabaseQueries`	No	Audit database queries for SQL injection vulnerabilities
`checkCapabilities`	No	Analyze WordPress capability and role management
`code`	No	The WordPress code to analyze (for single-file analysis)
`filePath`	No	Path to single WordPress file to analyze
`files`	No	Array of specific file paths (for multi-file analysis)
`includeOwaspTop10`	No	Include OWASP Top 10 vulnerability checks
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`projectPath`	No	Path to WordPress plugin/theme root (for multi-file analysis)
`wpType`	No	WordPress component type	plugin
`wpVersion`	No	Target WordPress version for compatibility checks	6.4

TDQS

B3/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but offers limited behavioral insight. It mentions 'SAVES: Claude context for strategic decisions,' hinting at state retention, but doesn't disclose critical traits like whether it's read-only/destructive, performance characteristics, error handling, or output format. For a complex 12-parameter tool with no annotations, this is inadequate.

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 uses a bullet-like structure with sections (DESCRIPTION, WORKFLOW, TIP, SAVES), which is somewhat organized but not optimally front-loaded. Some sentences like 'Perfect for understanding complex code' are vague and don't earn their place efficiently. It could be more streamlined for a tool with rich schema documentation.

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 high complexity (12 parameters, no output schema, no annotations), the description is incomplete. It lacks crucial context: no explanation of return values, error conditions, or behavioral constraints. The 'SAVES' hint is insufficient for a tool that likely produces detailed security reports. With no output schema, the description should compensate more.

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 parameters are well-documented in the schema itself. The description adds no specific parameter semantics beyond implying analysis of 'plugins, themes, and core' (related to 'wpType') and 'OWASP' (related to 'analysisType' and 'includeOwaspTop10'). Baseline 3 is appropriate 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs 'WordPress security analysis for plugins, themes, and core implementations with OWASP and WordPress-specific vulnerability detection,' which is a specific verb+resource combination. It distinguishes from siblings like 'analyze_code_quality' or 'security_audit' by specifying WordPress and OWASP focus, but doesn't explicitly differentiate from 'audit_wordpress_plugin' or 'audit_wordpress_theme' beyond mentioning broader scope.

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 implied usage context with 'WORKFLOW: Perfect for understanding complex code, identifying issues, and technical debt assessment' and 'TIP: Use Desktop Commander to read files, then pass content here for analysis,' suggesting it's for post-file-reading analysis. However, it lacks explicit when-to-use vs. alternatives like 'audit_wordpress_plugin' or 'analyze_single_file,' and no exclusions are stated.

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

arcade_gameB

Generate complete playable 2D arcade games using HTML5 Canvas with player controls, enemies, and game mechanics

WORKFLOW: Ideal for creating production-ready code, tests, and documentation TIP: Generate unlimited iterations locally, then review with Claude SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of game complexity	detailed
`analysisType`	No	Type of game generation to perform	comprehensive
`code`	No	Existing game code to enhance (for single-game analysis)
`controls`	No	Control scheme	hybrid
`difficulty`	No	Game difficulty level	medium
`features`	No	Game features to include
`filePath`	No	Path to existing game file to enhance
`files`	No	Array of specific game files (for multi-game analysis)
`gameType`	No	Type of arcade game to generate	shooter
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for game file discovery (1-3)
`projectPath`	No	Path to project root (for multi-game generation)
`theme`	No	Visual theme for the game	retro

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions generating 'production-ready code, tests, and documentation' and saving 'Claude context for strategic decisions,' it doesn't address critical behavioral aspects like whether this is a read-only or write operation, what permissions are needed, whether it creates files or modifies existing ones, error handling, or rate limits. The description provides some context but leaves significant gaps for a tool with 13 parameters.

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 appropriately sized and well-structured with clear sections (main description, WORKFLOW, TIP, SAVES). Each sentence adds value, though the 'SAVES' section could be more clearly integrated. It's front-loaded with the core purpose, making it easy to understand quickly without unnecessary verbosity.

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 complexity (13 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose, workflow, and strategic context but lacks details about behavioral traits, output format, error handling, and specific usage boundaries. For a tool of this complexity without annotations or output schema, the description should provide more comprehensive guidance to be fully 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 schema description coverage is 100%, so the schema already documents all 13 parameters thoroughly with descriptions and enums. The description adds no specific parameter information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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's purpose: 'Generate complete playable 2D arcade games using HTML5 Canvas with player controls, enemies, and game mechanics.' This specifies the verb ('Generate'), resource ('2D arcade games'), and key components. However, it doesn't explicitly differentiate from sibling tools like 'create_text_adventure' or 'css_art_generator' which are also creative generation tools.

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 implied usage guidance through the 'WORKFLOW' and 'TIP' sections, suggesting it's 'Ideal for creating production-ready code, tests, and documentation' and recommending 'Generate unlimited iterations locally, then review with Claude.' However, it doesn't explicitly state when to use this tool versus alternatives like 'create_text_adventure' or when not to use it, nor does it mention prerequisites.

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

audit_wordpress_pluginB

Comprehensive WordPress plugin audit - chains multiple analysis steps for security, performance, dependencies, and code quality

ParametersJSON Schema

Name	Required	Description	Default
`auditDepth`	No	Depth of audit analysis	comprehensive
`auditType`	No	Type of audit focus	full-audit
`includeSteps`	No	Analysis steps to include in audit
`maxDepth`	No	Maximum directory depth for analysis (1-5)
`phpVersion`	No	Target PHP version for compatibility checks	8.0
`projectPath`	Yes	Path to WordPress plugin root directory
`wpVersion`	No	Target WordPress version for compatibility checks	6.4

TDQS

B3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool 'chains multiple analysis steps' and 'SAVES: Claude context for strategic decisions,' which provides some behavioral context about workflow integration and state management. However, it doesn't disclose critical behavioral traits like whether this is a read-only analysis or makes changes, what permissions are required, whether it's resource-intensive, or what happens to the analysis results. For a complex 7-parameter audit tool with no annotations, this is insufficient.

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 uses a bullet-point-like structure with sections (WORKFLOW, TIP, SAVES) but is somewhat verbose. Sentences like 'Comprehensive WordPress plugin audit - chains multiple analysis steps for security, performance, dependencies, and code quality' are front-loaded with key information, but the additional sections could be more tightly integrated. Some phrases like 'Perfect for understanding complex code' are somewhat redundant with the purpose statement.

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 complex audit tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the audit produces (no output schema means the description should indicate the type of results), doesn't cover behavioral aspects like error handling or performance characteristics, and provides minimal guidance on parameter usage despite the comprehensive schema. The workflow tip is helpful but doesn't compensate for the overall gaps.

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 schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly with descriptions, defaults, and enums. The description adds no specific parameter information beyond implying the audit covers 'security, performance, dependencies, and code quality' (which maps to some auditType enum values). It doesn't provide additional context about parameter interactions, constraints, or usage patterns beyond what's in 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 performs a 'comprehensive WordPress plugin audit' that 'chains multiple analysis steps for security, performance, dependencies, and code quality.' This specifies the verb (audit), resource (WordPress plugin), and scope (multiple analysis areas). However, it doesn't explicitly differentiate from sibling tools like 'analyze_wordpress_security' or 'wordpress_plugin_readiness' beyond mentioning its comprehensive nature.

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 some implied usage guidance: 'Perfect for understanding complex code, identifying issues, and technical debt assessment' and 'TIP: Use Desktop Commander to read files, then pass content here for analysis.' This suggests when the tool is appropriate and provides a workflow tip. However, it doesn't explicitly state when to use this versus alternatives like 'analyze_wordpress_security' or 'security_audit,' nor does it provide exclusion criteria or prerequisites beyond the workflow suggestion.

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

audit_wordpress_themeA

Comprehensive WordPress theme audit - chains multiple analysis steps for security, performance, accessibility, SEO, and code quality

ParametersJSON Schema

Name	Required	Description	Default
`auditDepth`	No	Depth of audit analysis	comprehensive
`auditType`	No	Type of audit focus	full-audit
`checkAccessibility`	No	Include detailed accessibility audit
`includeSteps`	No	Analysis steps to include in theme audit
`maxDepth`	No	Maximum directory depth for analysis (1-5)
`phpVersion`	No	Target PHP version for compatibility checks	8.0
`projectPath`	Yes	Path to WordPress theme root directory
`themeType`	No	Type of WordPress theme	classic
`wpVersion`	No	Target WordPress version for compatibility checks	6.4

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool 'chains multiple analysis steps' and 'saves Claude context for strategic decisions,' which adds useful operational context. However, it doesn't disclose critical behavioral traits like whether this is a read-only analysis or makes changes, execution time expectations, resource requirements, or error handling for the complex 9-parameter operation.

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 uses a bullet-like structure with section headers (WORKFLOW, TIP, SAVES) which improves scannability. However, some phrasing like 'Comprehensive WordPress theme audit' is redundant with the tool name, and the four separate statements could be more tightly integrated. The information density is moderate but not optimally 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?

For a complex 9-parameter tool with no annotations and no output schema, the description provides adequate but incomplete context. It covers the purpose, workflow, and strategic value, but lacks critical information about what the audit actually returns, how results are structured, error conditions, or performance characteristics. The schema handles parameter documentation well, but the description doesn't compensate for the missing output and behavioral 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 description coverage is 100%, so the schema already documents all 9 parameters thoroughly with descriptions, defaults, and enums. The description adds no specific parameter information beyond the generic mention of 'security, performance, accessibility, SEO, and code quality' analysis. This meets the baseline of 3 when schema does the heavy lifting, but adds minimal value beyond what's already in structured fields.

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 performs a 'comprehensive WordPress theme audit' that 'chains multiple analysis steps for security, performance, accessibility, SEO, and code quality.' This specifies both the verb (audit) and resource (WordPress theme) with scope details. However, it doesn't explicitly differentiate from sibling tools like 'audit_wordpress_plugin' or 'analyze_wordpress_security' beyond mentioning theme focus.

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 good contextual guidance: 'Perfect for understanding complex code, identifying issues, and technical debt assessment' and 'Use Desktop Commander to read files, then pass content here for analysis.' This gives clear when-to-use context and workflow prerequisites. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among siblings.

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

clear_analysis_cacheA

Clear the multi-file analysis cache for a specific file or all files

WORKFLOW: System diagnostics and function discovery TIP: Start with health_check, use list_functions to explore capabilities SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	No	Optional: specific file to clear from cache

TDQS

A3.9/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 discloses the tool's purpose (clearing cache) and workflow context, but lacks details on behavioral traits like side effects (e.g., performance impact after clearing), permissions needed, or error handling. The 'SAVES' note hints at strategic use but doesn't clarify operational behavior.

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 front-loaded with the core purpose in the first line, followed by structured sections (WORKFLOW, TIP, SAVES). Each sentence adds value, but the formatting with all-caps labels is slightly verbose. It efficiently conveys key information 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?

Given 1 parameter with full schema coverage and no output schema, the description provides good context: purpose, usage guidelines, and workflow integration. It compensates for the lack of annotations with practical tips. However, it could be more complete by detailing behavioral aspects like cache regeneration or performance implications.

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 the parameter 'filePath' documented as 'Optional: specific file to clear from cache.' The description adds minimal value beyond the schema by mentioning 'for a specific file or all files,' which aligns with the optional parameter. Baseline 3 is appropriate as the schema already fully describes the 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 action ('Clear') and resource ('multi-file analysis cache') with optional scope ('for a specific file or all files'). It distinguishes itself from siblings like 'get_cache_statistics' by focusing on cache clearing rather than retrieval. However, it doesn't explicitly differentiate from all potential cache-related tools beyond the listed siblings.

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 includes explicit workflow guidance: 'Start with health_check, use list_functions to explore capabilities' and 'SAVES: Claude context for strategic decisions.' It provides clear when-to-use context ('System diagnostics and function discovery') and mentions alternative tools (health_check, list_functions) for related tasks.

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

compare_integrationA

Compare integration between multiple files to identify mismatches, missing imports, and compatibility issues. Returns actionable fixes with line numbers.

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of integration analysis to perform	integration
`code`	No	The code to analyze (for single-file analysis)
`filePath`	No	Path to single file to analyze
`files`	No	Array of absolute file paths to analyze
`focus`	No	Specific areas to focus on: method_compatibility, namespace_dependencies, data_flow, missing_connections
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`projectPath`	No	Path to project root (for multi-file analysis)

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It does reveal some behavioral traits: the tool returns 'actionable fixes with line numbers' and 'saves Claude context for strategic decisions.' However, it doesn't disclose important behavioral aspects like whether this is a read-only vs. write operation, performance characteristics, error handling, or authentication requirements. The description adds some value but leaves significant gaps for a tool with 9 parameters.

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 uses a structured format with sections (DESCRIPTION, WORKFLOW, TIP, SAVES), which is helpful. However, some sections like 'SAVES: Claude context for strategic decisions' feel somewhat marketing-oriented rather than essential tool documentation. The core purpose is front-loaded, but the overall structure could be more focused on pure tool functionality.

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 (9 parameters, no annotations, no output schema), the description is moderately complete. It explains the tool's purpose and provides usage guidance, but doesn't adequately address the behavioral aspects needed for a complex analysis tool. The lack of output schema means the description should ideally explain what the tool returns, which it does partially ('Returns actionable fixes with line numbers'), but not comprehensively.

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 description coverage, the baseline is 3 even without parameter information in the description. The description doesn't add any meaningful parameter semantics beyond what's already documented in the schema. It mentions analyzing 'multiple files' which aligns with the 'files' parameter, but provides no additional context about parameter usage, relationships, or best practices.

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's purpose: 'Compare integration between multiple files to identify mismatches, missing imports, and compatibility issues. Returns actionable fixes with line numbers.' It specifies the verb (compare), resource (integration between multiple files), and key outcomes (identify issues, return fixes). However, it doesn't explicitly differentiate from sibling tools like 'analyze_dependencies' or 'analyze_project_structure' which might have overlapping functionality.

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 for when to use this tool: 'Perfect for understanding complex code, identifying issues, and technical debt assessment' and 'Use Desktop Commander to read files, then pass content here for analysis.' This gives practical workflow guidance. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the many sibling tools, which would be needed for a perfect score.

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

convert_to_typescriptB

Convert JavaScript code to TypeScript with comprehensive type annotations and modern best practices

WORKFLOW: Ideal for creating production-ready code, tests, and documentation TIP: Generate unlimited iterations locally, then review with Claude SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`addTypeGuards`	No	Add type guard functions for runtime type checking
`analysisDepth`	No	Level of conversion detail	comprehensive
`analysisType`	No	Type of conversion to perform	comprehensive
`code`	No	JavaScript code to convert (for single-file conversion)
`filePath`	No	Path to single JavaScript file to convert
`files`	No	Array of specific JavaScript file paths to convert
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`module`	No	Module system	ESNext
`preserveComments`	No	Preserve original comments and add TSDoc
`projectPath`	No	Path to project root (for multi-file conversion)
`strict`	No	Use strict TypeScript mode
`target`	No	TypeScript compilation target	ES2020
`useEnums`	No	Use enums for fixed value sets
`useInterfaces`	No	Prefer interfaces over type aliases

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the tool's purpose and some workflow tips, it doesn't describe important behavioral traits like whether this is a read-only analysis or a code-modification operation, what permissions might be required, whether it creates new files or modifies existing ones, error handling, or rate limits. The 'SAVES' section mentions Claude context but doesn't clarify the tool's actual behavior.

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 well-structured with clear sections (purpose, workflow, tip, saves) and uses bullet-like formatting. It's appropriately sized at 4 sentences, though the 'SAVES' section feels somewhat disconnected from the core tool description and could be more integrated.

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 complex tool with 14 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (converted code? success status? error messages?), doesn't clarify the behavioral implications of a code conversion tool, and provides minimal guidance on when and how to use it effectively given the many configuration options.

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 description coverage, the schema already documents all 14 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. It mentions 'comprehensive type annotations' which aligns with some parameters but doesn't provide additional semantic context about how parameters interact or affect the conversion process.

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's purpose: converting JavaScript code to TypeScript with comprehensive type annotations and modern best practices. It specifies the verb ('convert') and resource ('JavaScript code'), but doesn't explicitly differentiate from sibling tools like 'analyze_single_file' or 'suggest_refactoring' which might have overlapping functionality.

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 some implied usage context through the 'WORKFLOW' and 'TIP' sections, suggesting it's ideal for production-ready code and recommending local iterations. However, it doesn't explicitly state when to use this tool versus alternatives like 'suggest_refactoring' or 'analyze_code_quality', nor does it provide clear exclusions or prerequisites.

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

count_filesC

Analyze directory structure and generate markdown directory tree with file and folder counts

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of analysis to perform	comprehensive
`code`	No	The code to analyze (for single-file analysis)
`filePath`	No	Path to single file to analyze
`files`	No	Array of specific file paths (for multi-file analysis)
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for discovery (1-10)
`projectPath`	No	Path to directory root to analyze

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 mentions generating markdown output and saving Claude context, but lacks critical behavioral details: whether this is a read-only or mutating operation, what permissions are needed, how large projects are handled, error conditions, or performance characteristics. For a tool with 8 parameters and no annotations, this is insufficient disclosure.

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

Conciseness2/5

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

The description is structured but not front-loaded efficiently. The core purpose is stated first, but the 'WORKFLOW,' 'TIP,' and 'SAVES' sections contain marketing-like language that doesn't add essential operational information. Sentences like 'Perfect for understanding complex code' and 'SAVES: Claude context for strategic decisions' don't earn their place in a tool description.

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 the tool's complexity (8 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the output looks like (beyond 'markdown directory tree'), doesn't address error handling or constraints, and provides minimal behavioral context. For a tool that appears to perform structural analysis, this leaves significant gaps for an AI 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?

Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain relationships between parameters like 'projectPath' vs 'filePath' vs 'files'). Baseline 3 is appropriate when schema does the heavy lifting.

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's purpose: 'Analyze directory structure and generate markdown directory tree with file and folder counts.' This is a specific verb+resource combination (analyze structure, generate tree with counts). However, it doesn't explicitly differentiate from sibling tools like 'analyze_project_structure' or 'analyze_single_file,' which appear related.

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 some usage context through 'WORKFLOW' and 'TIP' sections, suggesting it's for understanding complex code and technical debt, and recommending using Desktop Commander first. However, it doesn't explicitly state when to use this tool versus alternatives like 'analyze_project_structure' or 'analyze_single_file,' leaving usage somewhat implied rather than clearly defined.

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

create_text_adventureA

Generate complete interactive text adventure games with branching storylines, inventory systems, and multiple endings

WORKFLOW: Ideal for creating production-ready code, tests, and documentation TIP: Generate unlimited iterations locally, then review with Claude SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`code`	No	Existing adventure code to enhance (for single-file analysis)
`complexity`	No	Adventure complexity level	intermediate
`features`	No	Adventure features to include
`filePath`	No	Path to existing adventure file to enhance
`files`	No	Array of specific adventure files to analyze/enhance
`length`	No	Expected adventure length	medium
`maxDepth`	No	Maximum directory depth for adventure file discovery (1-5)
`playerClass`	No	Player character class/type	custom
`projectPath`	No	Path to project root where adventure will be created
`theme`	No	Adventure theme	fantasy

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool can 'enhance' existing code and suggests iterative local generation, which adds useful context about its generative and enhancement capabilities. However, it doesn't disclose important behavioral traits like whether it creates new files, modifies existing ones, requires specific permissions, or has rate limits.

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 appropriately sized with four concise sentences that each serve a distinct purpose: stating the core functionality, ideal use case, workflow tip, and context saving. It's front-loaded with the main purpose. The only minor issue is the formatting with all-caps section headers that slightly disrupt flow.

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 complex 10-parameter tool with no annotations and no output schema, the description provides adequate but incomplete context. It covers the generative purpose and workflow but lacks details about what the tool actually returns, error conditions, or the scope of 'production-ready' outputs. The schema handles parameter documentation well, but behavioral aspects remain under-specified.

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 schema already documents all 10 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'enhance' existing code which aligns with the 'code' and 'filePath' parameters, but provides no additional syntax, format, or usage details for parameters.

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 with specific verbs ('generate complete interactive text adventure games') and resources ('games with branching storylines, inventory systems, and multiple endings'). It distinguishes itself from sibling tools like 'arcade_game' by specifying text-based adventures with narrative complexity rather than graphical arcade games.

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 for when to use this tool ('Ideal for creating production-ready code, tests, and documentation') and includes workflow tips ('Generate unlimited iterations locally, then review with Claude'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among sibling tools for different types of game generation.

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

css_art_generatorB

Create pure CSS drawings, animations, and interactive art with no images required - just clever CSS techniques

WORKFLOW: Ideal for creating production-ready code, tests, and documentation TIP: Generate unlimited iterations locally, then review with Claude SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of art complexity	detailed
`analysisType`	No	Type of art generation to perform	comprehensive
`animationStyle`	No	Animation style (if applicable)	smooth
`artType`	No	Type of CSS art to create	drawing
`code`	No	Existing CSS art code to enhance (for single-art analysis)
`colorScheme`	No	Color palette for the art	vibrant
`complexity`	No	Art complexity level	intermediate
`filePath`	No	Path to existing CSS art file to enhance
`files`	No	Array of specific CSS art files (for multi-art analysis)
`language`	No	Programming language	css
`maxDepth`	No	Maximum directory depth for art file discovery (1-3)
`projectPath`	No	Working directory for CSS art project (e.g., C:\dev\css-art)
`responsive`	No	Make art responsive to screen size
`techniques`	No	CSS techniques to showcase
`theme`	No	Art theme or subject	modern

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 carries the full burden of behavioral disclosure. While it mentions the tool creates CSS art and suggests a workflow for iteration and review, it doesn't disclose critical behavioral traits such as whether it generates new files, modifies existing ones, requires specific permissions, has rate limits, or what the output looks like (e.g., code snippets, files). For a tool with 15 parameters and no annotations, this is a significant gap in 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 structured into brief sections (main description, WORKFLOW, TIP, SAVES), which is somewhat organized. However, it includes extraneous content like 'Claude context for strategic decisions' that doesn't directly clarify the tool's function, and the sections are more like notes than a cohesive description. It's not overly verbose but could be more focused and front-loaded with essential information.

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 the tool's complexity (15 parameters, no output schema, no annotations), the description is incomplete. It lacks details on what the tool actually produces (e.g., code output, file creation), behavioral aspects, and how parameters influence the output. While it sets a creative context, it doesn't provide enough information for an agent to fully understand the tool's operation and results, making it inadequate for such a multifaceted 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 description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no specific parameter information beyond the general context of CSS art creation. It implies parameters relate to art types, complexity, and techniques but doesn't explain individual parameters or their interactions. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.

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's purpose: 'Create pure CSS drawings, animations, and interactive art with no images required - just clever CSS techniques.' It specifies the verb ('create') and resource ('CSS drawings, animations, and interactive art'), and distinguishes it from sibling tools by focusing on CSS art generation rather than analysis, conversion, or other code-related tasks. However, it doesn't explicitly differentiate from all siblings beyond the general domain focus.

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 some implied usage context through the 'WORKFLOW', 'TIP', and 'SAVES' sections, suggesting it's ideal for production-ready code and strategic decisions with Claude. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., vs. 'generate_responsive_component' or other creative tools), and doesn't mention prerequisites or exclusions. The guidance is helpful but not comprehensive.

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

custom_promptC

Universal fallback executor for any custom prompt with optional file context. Uses dynamic token allocation based on your loaded model - can handle everything from quick tasks to comprehensive multi-file analysis. The Swiss Army knife when no other specialized function matches your needs.

WORKFLOW: Flexible analysis and generation for any development task TIP: Provide clear instructions for any analysis or generation task SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of analysis to perform	general
`code`	No	The code to analyze (for single-file analysis)
`context`	No	Optional structured context object for the task
`filePath`	No	Path to single file to analyze
`files`	No	Array of specific file paths to include as context
`language`	No	Programming language (if applicable)	text
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`projectPath`	No	Path to project root (for multi-file analysis)
`prompt`	Yes	The custom prompt/task to send to local LLM
`working_directory`	No	Working directory context (defaults to current working directory)

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'dynamic token allocation based on your loaded model' and 'can handle everything from quick tasks to comprehensive multi-file analysis', which gives some context about scalability and resource usage. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, potential side effects, performance characteristics, error handling, or what 'Saves: Claude context for strategic decisions' actually means operationally.

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

Conciseness2/5

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

The description is poorly structured with mixed messaging. It starts with a tagline, then has WORKFLOW, TIP, and SAVES sections that feel disconnected. The 'Swiss Army knife' metaphor is repeated unnecessarily. Sentences like 'Uses dynamic token allocation based on your loaded model - can handle everything from quick tasks to comprehensive multi-file analysis' are verbose and could be more direct. The structure doesn't front-load the most critical information effectively.

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 complex tool with 11 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool actually returns, how errors are handled, what 'Claude context' saving means, or the relationship between the many file-related parameters (code, filePath, files, projectPath, working_directory). Given the tool's apparent complexity as a general-purpose executor, more complete guidance about its behavior and limitations 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?

With 100% schema description coverage, the baseline is 3. The description doesn't add meaningful parameter semantics beyond what's already in the schema. It mentions 'optional file context' which aligns with parameters like files, filePath, and projectPath, but doesn't explain when to use which parameter or how they interact. The schema already documents all 11 parameters thoroughly with descriptions and enums.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states this is a 'Universal fallback executor for any custom prompt with optional file context' and 'Swiss Army knife when no other specialized function matches your needs', which gives a general sense of purpose. However, it's vague about the specific action - it mentions 'analysis and generation' but doesn't clearly distinguish this from sibling tools like analyze_code_quality or generate_unit_tests. The purpose is understandable but lacks specificity about what makes this tool unique.

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 about when to use this tool: 'when no other specialized function matches your needs' and as a 'Universal fallback executor'. It implies this should be used when sibling tools don't fit the task. However, it doesn't explicitly state when NOT to use it or provide specific examples of alternatives among the many sibling tools listed.

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

diff_method_signaturesC

Compare method signatures between caller and callee to identify parameter mismatches and provide actionable fixes

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of analysis to perform	comprehensive
`calledClass`	No	Class name containing the called method
`callingFile`	No	Absolute path to file containing the method call
`code`	No	The code to analyze (for single-file analysis)
`filePath`	No	Path to single file to analyze
`files`	No	Array of specific file paths (for multi-file analysis)
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`methodName`	No	Name of the method to check
`projectPath`	No	Path to project root (for multi-file analysis)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'saves Claude context for strategic decisions' which hints at statefulness, but doesn't describe what the tool actually returns (output format), whether it modifies anything, performance characteristics, error conditions, or authentication needs. For an 11-parameter analysis tool with no annotations, this is inadequate.

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

Conciseness2/5

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

The description uses a fragmented structure with separate sections (WORKFLOW, TIP, SAVES) that aren't well-integrated. The 'SAVES: Claude context for strategic decisions' sentence doesn't clearly relate to the tool's core functionality and feels like wasted space. The description could be more cohesive and front-loaded with essential information.

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 complex 11-parameter tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (crucial for an analysis tool), doesn't clarify the relationships between the many input options, and provides minimal behavioral context. The 'saves Claude context' hint is vague and doesn't compensate for the missing output information.

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 schema already documents all 11 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline is 3 when schema does the heavy lifting, though the description could have explained relationships between parameters like 'code' vs 'filePath' vs 'files'.

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's purpose: 'Compare method signatures between caller and callee to identify parameter mismatches and provide actionable fixes.' This specifies the verb (compare), resource (method signatures), and outcome (identify mismatches, provide fixes). However, it doesn't explicitly differentiate from sibling tools like 'analyze_single_file' or 'list_functions' which might overlap in code analysis.

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 some usage context with 'WORKFLOW: Perfect for understanding complex code, identifying issues, and technical debt assessment' and 'TIP: Use Desktop Commander to read files, then pass content here for analysis.' This implies when to use it (for code understanding/technical debt) and a workflow tip, but doesn't explicitly state when NOT to use it or name alternatives among the many sibling tools.

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

find_pattern_usageB

Find usage of specific patterns across multiple files in a project. Supports regex patterns with intelligent context analysis.

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of analysis to perform	comprehensive
`code`	No	The code to analyze (for single-file analysis)
`filePath`	No	Path to single file to analyze
`files`	No	Array of specific file paths (for multi-file analysis)
`includeContext`	No	Number of context lines to include (0-10)
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`patterns`	Yes	Patterns to search for (regex supported)
`projectPath`	No	Absolute path to project root directory

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 carries the full burden of behavioral disclosure. It mentions 'intelligent context analysis' and 'SAVES: Claude context for strategic decisions,' which hints at caching or state retention, but it doesn't clarify critical behaviors like whether this is a read-only operation, if it modifies files, performance characteristics, or error handling. For a tool with 10 parameters and no annotations, this leaves significant gaps in understanding how the tool behaves.

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 structured with sections like 'WORKFLOW', 'TIP', and 'SAVES', which adds organization but includes some redundant or vague elements (e.g., 'SAVES: Claude context for strategic decisions' is unclear). It's moderately concise at 4 sentences, but phrases like 'Perfect for understanding complex code' could be more precise. Overall, it's adequately sized but not optimally front-loaded or waste-free.

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 the tool's complexity (10 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., read/write nature, side effects), output format, error cases, and how it differs from siblings. While it covers basic purpose and some usage tips, it doesn't provide enough context for an agent to confidently invoke this tool without trial and error, especially for a multi-file analysis 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?

The schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds minimal parameter semantics beyond the schema: it implies regex support for patterns and context analysis, but doesn't explain interactions between parameters (e.g., how 'code' vs. 'filePath' vs. 'files' are prioritized). Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.

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's purpose: 'Find usage of specific patterns across multiple files in a project. Supports regex patterns with intelligent context analysis.' This specifies the verb ('find'), resource ('usage of specific patterns'), and scope ('across multiple files in a project'). However, it doesn't explicitly differentiate from sibling tools like 'analyze_single_file' or 'analyze_project_structure', which reduces the score from a 5.

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 some implied usage guidance: 'Perfect for understanding complex code, identifying issues, and technical debt assessment' and 'Use Desktop Commander to read files, then pass content here for analysis.' This suggests contexts like code analysis and technical debt, but it doesn't explicitly state when to use this tool versus alternatives (e.g., 'analyze_single_file' for single files or 'analyze_code_quality' for broader quality checks). The guidance is helpful but not comprehensive.

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

find_unused_cssA

Analyze CSS usage and identify unused selectors for performance optimization. Supports both URL analysis and local file analysis.

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of CSS analysis to perform	comprehensive
`code`	No	CSS code to analyze (for single-code analysis)
`cssPath`	No	Path to CSS file to analyze
`filePath`	No	Path to CSS file to analyze
`files`	No	Specific HTML/CSS file paths to analyze
`htmlPath`	No	Path to HTML file to check CSS usage against
`ignorePseudoSelectors`	No	Ignore pseudo-selectors like :hover, :focus
`includeMediaQueries`	No	Include media query analysis
`language`	No	File language (css, html)	css
`maxDepth`	No	Maximum directory depth for file discovery
`projectPath`	No	Path to project directory containing HTML/CSS files
`url`	No	URL to analyze for CSS usage (single page)

TDQS

A3.7/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 of behavioral disclosure. It mentions that the tool 'Supports both URL analysis and local file analysis,' which adds useful context about input methods. However, it lacks details on behavioral traits like whether the analysis is read-only or has side effects, performance characteristics, or error handling. The 'SAVES: Claude context for strategic decisions' hint is vague and does not clarify operational behavior.

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 structured into sections (e.g., 'WORKFLOW:', 'TIP:', 'SAVES:'), which aids readability, but it includes vague or promotional phrases like 'Perfect for understanding complex code' and 'SAVES: Claude context for strategic decisions' that do not earn their place in a tool definition. The core purpose is front-loaded, but the additional sentences could be more focused on practical guidance.

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 (13 parameters, no annotations, no output schema), the description is moderately complete. It covers the tool's purpose and basic usage context but lacks details on behavioral traits, output format, or error handling. The schema provides full parameter documentation, but without annotations or output schema, the description should do more to explain how the tool behaves and what results to expect.

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 schema already documents all 13 parameters thoroughly. The description adds no specific parameter information beyond implying support for 'URL analysis and local file analysis,' which loosely relates to parameters like url, cssPath, and projectPath. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description provides minimal additional semantic 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?

The description clearly states the tool's purpose: 'Analyze CSS usage and identify unused selectors for performance optimization.' It specifies the verb ('analyze' and 'identify'), the resource ('CSS usage' and 'unused selectors'), and the goal ('performance optimization'). It also distinguishes from siblings by focusing specifically on CSS analysis, unlike broader tools like analyze_code_quality or analyze_project_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 provides clear context for when to use this tool: 'Perfect for understanding complex code, identifying issues, and technical debt assessment.' It also offers a workflow tip: 'Use Desktop Commander to read files, then pass content here for analysis.' However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as find_unused_files or analyze_single_file, for different scenarios.

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

find_unused_filesB

Identify genuinely unused TypeScript/JavaScript files in complex projects with dynamic loading patterns

WORKFLOW: System diagnostics and function discovery TIP: Start with health_check, use list_functions to explore capabilities SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	comprehensive
`analysisType`	No	Type of analysis to perform	comprehensive
`analyzeComments`	No	Check for commented-out imports
`code`	No	The code to analyze (for single-file analysis)
`entryPoints`	No	Entry point files to start dependency traversal
`excludePatterns`	No	File patterns to exclude from analysis
`filePath`	No	Path to single file to analyze
`files`	No	Array of specific file paths (for multi-file analysis)
`includeDevArtifacts`	No	Whether to flag potential dev artifacts
`language`	No	Programming language	typescript
`maxDepth`	No	Maximum directory depth for discovery (1-5)
`projectPath`	No	Absolute path to project root

TDQS

B3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'System diagnostics and function discovery' and 'SAVES: Claude context for strategic decisions', which hints at analysis behavior and context preservation, but doesn't detail what 'genuinely unused' means, how results are returned, whether it's read-only or has side effects, or performance characteristics. For a complex analysis tool with 12 parameters, this leaves significant behavioral gaps.

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 uses a fragmented structure with separate lines for 'WORKFLOW', 'TIP', and 'SAVES', which is somewhat organized but not optimally front-loaded. The first line clearly states the purpose, but the additional lines could be more integrated. It's reasonably concise but could be more cohesive in presentation.

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 the tool's complexity (12 parameters, no annotations, no output schema), the description is insufficient. It lacks details on what the tool returns, how 'unused' is determined, error handling, or performance implications. The workflow tips add some context, but for a sophisticated analysis tool, this leaves too many unknowns for effective agent use.

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 schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any specific parameter information beyond what's in the schema (e.g., it doesn't explain how 'analysisDepth' differs from 'analysisType' or clarify parameter interactions). With high schema coverage, the baseline is 3, and the description doesn't compensate with additional semantic context.

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's purpose: 'Identify genuinely unused TypeScript/JavaScript files in complex projects with dynamic loading patterns.' This specifies the verb ('identify'), resource ('unused TypeScript/JavaScript files'), and context ('complex projects with dynamic loading patterns'). However, it doesn't explicitly differentiate from sibling tools like 'find_unused_css' or 'analyze_dependencies' beyond the language focus.

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 includes workflow tips ('Start with health_check, use list_functions to explore capabilities') which imply a recommended sequence, but it doesn't explicitly state when to use this tool versus alternatives like 'analyze_dependencies' or 'find_unused_css'. The guidance is helpful but lacks clear boundaries or exclusions for sibling tools.

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

generate_project_documentationC

Generate comprehensive project documentation based on codebase analysis with intelligent file discovery and structured output

WORKFLOW: Ideal for creating production-ready code, tests, and documentation TIP: Generate unlimited iterations locally, then review with Claude SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of analysis to perform	comprehensive
`code`	No	The code to analyze (for single-file analysis)
`docStyle`	No	Documentation style to use	markdown
`filePath`	No	Path to single file to analyze
`files`	No	Array of specific file paths (for multi-file analysis)
`focusAreas`	No	Areas to focus on: api, architecture, setup, contributing
`includeExamples`	No	Include usage examples in documentation
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for discovery (1-5)
`projectPath`	No	Absolute path to project root directory

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'intelligent file discovery' and 'structured output' but doesn't describe what the tool actually returns, whether it modifies files, what permissions are needed, or any rate limits. For a complex tool with 11 parameters and no output schema, this leaves significant behavioral gaps unexplained.

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

Conciseness2/5

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

The description is poorly structured with unclear sectioning ('WORKFLOW:', 'TIP:', 'SAVES:') that doesn't flow logically. The 'SAVES: Claude context for strategic decisions' sentence adds questionable value. While not overly verbose, the organization is confusing and some content feels tangential rather than essential to understanding the tool's function.

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 complex documentation generation tool with 11 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the output looks like, whether files are created/modified, error conditions, or how the 'intelligent file discovery' actually works. The tool's complexity demands more complete behavioral and output context than provided.

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 all parameters are documented in the schema. The description doesn't add any specific parameter information beyond what's in the schema. It mentions 'codebase analysis' which aligns with parameters like 'projectPath' and 'analysisType', but provides no additional syntax, format, or interaction details. The baseline 3 is appropriate when the schema does the heavy lifting.

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's purpose: 'Generate comprehensive project documentation based on codebase analysis with intelligent file discovery and structured output.' This specifies the verb ('generate'), resource ('project documentation'), and method ('codebase analysis'). However, it doesn't explicitly differentiate from sibling tools like 'analyze_project_structure' or 'analyze_single_file', which prevents a perfect score.

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 includes some usage context: 'WORKFLOW: Ideal for creating production-ready code, tests, and documentation' and 'TIP: Generate unlimited iterations locally, then review with Claude.' This implies when to use it (for documentation generation in development workflows) but doesn't explicitly state when NOT to use it or name alternatives among the many sibling tools. The guidance is helpful but incomplete.

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

generate_responsive_componentA

Generate responsive, accessible HTML/CSS components with modern best practices

WORKFLOW: Ideal for creating production-ready code, tests, and documentation TIP: Generate unlimited iterations locally, then review with Claude SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`accessible`	No	Include accessibility features
`animations`	No	Include animations
`context`	No	Rich context object with brand information, design references, content, colors, typography, and technical requirements
`darkMode`	No	Include dark mode support
`designSystem`	No	Design system to follow	custom
`framework`	No	Framework to use	vanilla
`name`	Yes	Component name
`responsive`	No	Make component responsive
`saveDirectory`	No	Directory to save the component project (e.g., "C:\dev\my-project"). If not provided, user will be prompted to specify location.
`type`	Yes	Component type

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions generating 'production-ready code' and saving 'Claude context for strategic decisions,' which adds some context about output quality and persistence. However, it lacks details on permissions, rate limits, or what 'saves' entails operationally, leaving 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.

Conciseness4/5

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

The description is front-loaded with the core purpose and uses bullet-like sections (WORKFLOW, TIP, SAVES) for efficient structuring. Each sentence adds value, but 'SAVES: Claude context for strategic decisions' is somewhat vague and could be more precise.

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 complexity (10 parameters, no output schema, no annotations), the description is moderately complete. It covers purpose and usage but lacks details on output format, error handling, or integration with the generated code, which are important for a code-generation 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 description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain how 'context' integrates with other params). Baseline 3 is appropriate 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates HTML/CSS components with responsive and accessible features, which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'css_art_generator' or 'generate_wordpress_plugin' that might also generate code, so it misses the highest score.

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 for when to use this tool ('Ideal for creating production-ready code, tests, and documentation') and includes a tip about workflow ('Generate unlimited iterations locally, then review with Claude'). It doesn't explicitly state when not to use it or name alternatives among siblings, so it's not a perfect 5.

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

generate_unit_testsC

Generate comprehensive unit tests for code with framework-specific patterns and complete coverage strategies

WORKFLOW: Ideal for creating production-ready code, tests, and documentation TIP: Generate unlimited iterations locally, then review with Claude SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`code`	No	The code to generate tests for (for single-file analysis)
`context`	No	Optional context for framework-specific testing patterns
`coverageTarget`	No	Test coverage target level	comprehensive
`filePath`	No	Path to single file to generate tests for
`files`	No	Array of specific file paths (for multi-file test generation)
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`projectPath`	No	Path to project root (for multi-file test generation)
`testFramework`	No	Testing framework to use (jest, mocha, pytest, phpunit, etc.)	jest

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 the full burden of behavioral disclosure. While it mentions 'framework-specific patterns' and 'coverage strategies,' it doesn't describe key behaviors like whether this is a read-only analysis or a generative operation that creates files, what permissions are needed, error handling, or output format. The 'SAVES' note about 'Claude context for strategic decisions' adds minimal context but leaves major gaps for a tool with 9 parameters.

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

Conciseness2/5

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

The description is structured into sections but includes extraneous content that doesn't directly aid tool selection. Sentences like 'WORKFLOW: Ideal for creating production-ready code, tests, and documentation' and 'TIP: Generate unlimited iterations locally, then review with Claude' are workflow advice rather than tool description. This adds bulk without clarifying the tool's core function or usage.

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 the complexity (9 parameters, no annotations, no output schema), the description is incomplete. It lacks critical information such as what the tool outputs (e.g., generated test code, file paths, success/failure indicators), behavioral details like side effects (e.g., file creation), and error conditions. The sections provided are more about workflow tips than completing the tool's contextual picture.

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 schema already documents all 9 parameters thoroughly. The description doesn't add any specific parameter semantics beyond what's in the schema (e.g., it doesn't explain how 'coverageTarget' values map to test generation or how 'context' object should be structured). Baseline 3 is appropriate when the schema does the heavy lifting.

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's purpose: 'Generate comprehensive unit tests for code with framework-specific patterns and complete coverage strategies.' This specifies the verb ('generate'), resource ('unit tests'), and key characteristics ('framework-specific patterns', 'complete coverage'). However, it doesn't explicitly differentiate from sibling tools like 'analyze_code_quality' or 'suggest_refactoring' which might also involve testing aspects.

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 some implied usage context through sections like 'WORKFLOW' and 'TIP', suggesting it's 'ideal for creating production-ready code, tests, and documentation' and for 'unlimited iterations locally.' However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'analyze_code_quality' for quality checks or 'suggest_refactoring' for code improvements), and doesn't specify prerequisites or exclusions.

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

generate_wordpress_pluginB

Generate a complete WordPress plugin structure with all necessary files and best practices

WORKFLOW: Ideal for creating production-ready code, tests, and documentation TIP: Generate unlimited iterations locally, then review with Claude SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of plugin generation detail	comprehensive
`analysisType`	No	Type of plugin generation to perform	comprehensive
`code`	No	Existing plugin code to analyze (for single-file analysis)
`description`	Yes	Plugin description
`features`	Yes	List of features to include
`filePath`	No	Path to existing plugin file to analyze
`files`	No	Array of specific plugin files to analyze (for multi-file analysis)
`includeAdmin`	No	Include admin interface
`includeAjax`	No	Include AJAX handlers
`includeDatabase`	No	Include database tables
`includeGutenberg`	No	Include Gutenberg blocks
`includeRest`	No	Include REST API endpoints
`language`	No	Programming language (PHP for WordPress)	php
`maxDepth`	No	Maximum directory depth for plugin analysis (1-5)
`name`	Yes	Plugin name
`phpVersion`	No	Minimum PHP version	7.4
`prefix`	Yes	Plugin prefix for functions and classes (e.g., "wp_my_plugin")
`projectPath`	No	Path to existing plugin project root (for multi-file analysis)
`textDomain`	No	Text domain for internationalization
`wpVersion`	No	Minimum WordPress version	6.0

TDQS

B3.1/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. While it mentions 'production-ready code, tests, and documentation' and hints at iterative use, it lacks critical details such as whether this is a read-only or write operation, potential side effects (e.g., file creation), performance considerations, or error handling. For a complex tool with 20 parameters, this is a significant gap.

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 structured into clear sections (main description, WORKFLOW, TIP, SAVES) and is relatively concise at four short lines. However, 'SAVES: Claude context for strategic decisions' is somewhat vague and could be more directly relevant, slightly reducing efficiency.

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 the tool's complexity (20 parameters, no annotations, no output schema), the description is incomplete. It lacks details on what the tool returns, error conditions, or behavioral constraints. While it provides high-level workflow tips, it doesn't adequately cover the operational context needed for a tool of this scope, especially without annotations to fill in gaps.

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%, meaning all parameters are documented in the schema itself. The description doesn't add any specific parameter information beyond what's in the schema, such as explaining how 'features' or 'prefix' should be formatted. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to heavily.

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's purpose: 'Generate a complete WordPress plugin structure with all necessary files and best practices.' This specifies the verb ('generate') and resource ('WordPress plugin structure'), making it clear what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'audit_wordpress_plugin' or 'wordpress_plugin_readiness,' which prevents a perfect score.

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 some usage context with 'WORKFLOW: Ideal for creating production-ready code, tests, and documentation' and 'TIP: Generate unlimited iterations locally, then review with Claude,' which implies when to use it. However, it doesn't explicitly state when not to use it or mention alternatives among the many sibling tools, leaving room for ambiguity.

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

get_cache_statisticsA

Get statistics about the current analysis cache

WORKFLOW: System diagnostics and function discovery TIP: Start with health_check, use list_functions to explore capabilities SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool is for 'system diagnostics' and that it 'SAVES: Claude context for strategic decisions' which provides useful behavioral context about its purpose and output usage. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, what specific statistics are returned, or any performance characteristics.

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 well-structured with clear sections (main description, WORKFLOW, TIP, SAVES) and each sentence adds value. It's appropriately sized for a diagnostic tool, though the 'SAVES' section could be more specific about what context is saved. No wasted words, but not perfectly front-loaded since the workflow guidance comes after the main purpose.

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 diagnostic tool with no parameters, no annotations, and no output schema, the description provides reasonable context about purpose and workflow. However, it doesn't explain what specific statistics are returned or what format they come in, which is important for a statistics-gathering tool. The 'SAVES' hint is useful but vague about what exactly gets saved to context.

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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter requirements. The description appropriately doesn't discuss parameters since none exist. The baseline for 0 parameters with high schema coverage is 4, as the description correctly focuses on other aspects rather than parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Get statistics about the current analysis cache' which provides a clear verb ('Get') and resource ('analysis cache'), but it doesn't distinguish this tool from its siblings like 'health_check' or 'list_functions' which also provide diagnostic information. The purpose is understandable but lacks differentiation from similar tools.

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 includes explicit workflow guidance: 'WORKFLOW: System diagnostics and function discovery' and 'TIP: Start with health_check, use list_functions to explore capabilities.' This provides clear context about when to use this tool (as part of diagnostics) and suggests a sequence with other tools. However, it doesn't explicitly state when NOT to use this tool or name direct alternatives.

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

health_checkA

Check if LM Studio is running and responding

WORKFLOW: System diagnostics and function discovery TIP: Start with health_check, use list_functions to explore capabilities SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`detailed`	No	Include detailed information about the loaded model and server status

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool checks if LM Studio is 'running and responding' which implies a read-only diagnostic operation. However, it doesn't disclose important behavioral details like what specific response format to expect, whether there are rate limits, or what happens if LM Studio is not running. The 'SAVES' section mentions it 'saves Claude context for strategic decisions' which adds some useful behavioral context.

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 structured with clear sections (main purpose, WORKFLOW, TIP, SAVES) but contains some redundancy. The 'TIP' section essentially repeats the workflow guidance. The 'SAVES' section adds value but could be more integrated. While appropriately sized, not every sentence earns its place equally.

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 this is a simple diagnostic tool with one optional parameter (100% schema coverage) and no output schema, the description provides adequate context. It explains the purpose, provides clear workflow guidance, and adds behavioral context about saving Claude context. For a tool of this complexity, the description is reasonably complete, though it could benefit from more detail about the expected response 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, with the single parameter 'detailed' well-documented in the schema itself. The description doesn't add any additional parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.

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's purpose: 'Check if LM Studio is running and responding.' This is a specific verb ('Check') and resource ('LM Studio') combination. However, it doesn't explicitly distinguish this from sibling tools like 'list_functions' or 'get_cache_statistics' that might also provide system status information.

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 usage guidance: 'Start with health_check, use list_functions to explore capabilities.' This clearly indicates when to use this tool (first in workflow) and mentions an alternative tool ('list_functions') for different purposes. The 'WORKFLOW' section reinforces this strategic positioning.

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

list_functionsA

List all available Houtini LM functions with usage information

WORKFLOW: System diagnostics and function discovery TIP: Start with health_check, use list_functions to explore capabilities SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description
`category`	No	Filter by category (analyze, generate, system, custom, fun)
`detailed`	No	Include detailed information about each function
`includeExamples`	No	Include usage examples for each function

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool 'SAVES: Claude context for strategic decisions', which adds valuable behavioral context about output persistence. However, it doesn't describe other important behaviors like whether this is a read-only operation, potential rate limits, or what format the returned information takes.

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 efficiently structured with clear sections (main description, WORKFLOW, TIP, SAVES) that are front-loaded with the core purpose. While slightly longer than minimal, every sentence serves a distinct purpose in guiding usage and understanding behavior.

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 3 parameters, 100% schema coverage, and no output schema, the description provides good contextual completeness. It explains the tool's purpose, when to use it, workflow positioning, and adds behavioral context about saving Claude context. The main gap is lack of information about the return format, but given the tool's relatively simple discovery function, this is acceptable.

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 schema already fully documents all three parameters (category, detailed, includeExamples). The description doesn't add any additional parameter semantics beyond what's in the schema, so it meets the baseline expectation but doesn't provide extra 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?

The description clearly states the verb 'List' and the resource 'all available Houtini LM functions with usage information', making the purpose specific and actionable. It distinguishes this tool from its many siblings by focusing on function discovery rather than analysis, generation, or other specialized operations.

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 explicitly provides usage guidance in the 'WORKFLOW' and 'TIP' sections: it states this tool is for 'System diagnostics and function discovery', advises to 'Start with health_check' first, and then 'use list_functions to explore capabilities'. This gives clear context for when and how 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.

resolve_pathC

Analyze a file system path and suggest correct MCP parameters

WORKFLOW: System diagnostics and function discovery TIP: Start with health_check, use list_functions to explore capabilities SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	File system path to analyze (file or directory)
`suggestions`	No	Include parameter suggestions and usage examples

TDQS

C2.8/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. It mentions 'SAVES: Claude context for strategic decisions,' which hints at state retention or caching behavior, but it doesn't disclose critical traits like whether it's read-only, has side effects, rate limits, or error handling. For a tool with no annotations, this leaves significant behavioral gaps.

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

Conciseness2/5

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

The description is structured with bullet points but includes extraneous information like 'SAVES: Claude context for strategic decisions' that doesn't directly clarify the tool's function. It's not front-loaded with core purpose, and some sentences (e.g., the TIP) could be more integrated. It feels cluttered rather than concise.

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 annotations and no output schema, the description is incomplete. It lacks details on what the analysis outputs, how suggestions are formatted, or error cases. For a tool with 2 parameters and behavioral uncertainty, it should provide more context to compensate for the missing structured data.

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 schema already documents both parameters ('path' and 'suggestions') well. The description adds no additional meaning beyond what's in the schema, such as examples of path formats or what 'suggestions' entail. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool 'Analyze a file system path and suggest correct MCP parameters,' which provides a clear verb ('Analyze') and resource ('file system path'), but it's vague about what 'suggest correct MCP parameters' entails and doesn't distinguish it from sibling tools like 'analyze_project_structure' or 'trace_execution_path.' It lacks specificity in how it differs from other analysis tools in the list.

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 includes explicit usage guidance: 'WORKFLOW: System diagnostics and function discovery' and 'TIP: Start with health_check, use list_functions to explore capabilities.' This provides clear context on when to use it (as part of diagnostics) and references alternatives (health_check, list_functions), though it doesn't explicitly state when not to use it or compare it to all sibling tools.

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

security_auditB

Perform comprehensive security audit across entire project, analyzing data flows, authentication chains, and cross-file vulnerabilities with OWASP compliance checking

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of analysis to perform	comprehensive
`auditDepth`	No	Depth of security audit	standard
`code`	No	The code to analyze for security issues (for single-file analysis)
`filePath`	No	Path to single file to analyze for security vulnerabilities
`files`	No	Array of specific file paths (for multi-file analysis)
`focusAreas`	No	Specific areas to focus on: authentication, data-flow, input-validation, authorization
`includeOwasp`	No	Include OWASP Top 10 checks
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`projectPath`	No	Absolute path to project root directory
`projectType`	No	Project type for specific security checks	generic

TDQS

B3/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'SAVES: Claude context for strategic decisions' which hints at statefulness or caching behavior, but doesn't describe what the tool actually returns (results format, severity levels, recommendations), performance characteristics, error conditions, or authentication requirements. For a complex security analysis tool with 12 parameters, this leaves significant behavioral gaps.

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 uses a bullet-point structure with WORKFLOW, TIP, and SAVES sections which improves readability, but contains redundant elements. 'Perfect for understanding complex code, identifying issues, and technical debt assessment' repeats the purpose rather than adding new information. The TIP section provides workflow advice but could be more concise. Overall, some sentences don't earn their place in a tool description.

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 complex security analysis tool with 12 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (critical for an analysis tool), doesn't describe error handling or performance expectations, and provides minimal guidance on parameter selection despite the many options. The mention of saving context is helpful but insufficient to compensate for the missing behavioral 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 description coverage is 100%, so the schema already documents all 12 parameters thoroughly with descriptions, defaults, and enums. The description adds no specific parameter information beyond the general mention of 'analyzing data flows, authentication chains, and cross-file vulnerabilities with OWASP compliance checking' which loosely maps to some parameters like 'focusAreas' and 'includeOwasp'. This meets the baseline for high schema coverage but doesn't add meaningful 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 performs a 'comprehensive security audit across entire project' with specific analysis areas (data flows, authentication chains, cross-file vulnerabilities, OWASP compliance). It distinguishes from siblings like 'analyze_single_file' by emphasizing cross-file analysis and project-wide scope. However, it doesn't explicitly differentiate from 'analyze_wordpress_security' or 'audit_wordpress_plugin' which might have overlapping security focus.

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 some usage context with 'WORKFLOW: Perfect for understanding complex code, identifying issues, and technical debt assessment' and 'TIP: Use Desktop Commander to read files, then pass content here for analysis.' This implies when to use it (complex code analysis) and suggests a workflow, but doesn't explicitly state when NOT to use it or mention specific alternatives among the many sibling tools for simpler analyses.

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

suggest_refactoringC

Analyze code and suggest refactoring improvements with project-specific patterns (handles both single and multi-file)

WORKFLOW: Ideal for creating production-ready code, tests, and documentation TIP: Generate unlimited iterations locally, then review with Claude SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of refactoring to focus on	comprehensive
`code`	No	The code to analyze for refactoring (for single-file analysis)
`context`	No	Optional context for project-specific refactoring
`filePath`	No	Path to single file to refactor
`files`	No	Array of specific file paths (for multi-file analysis)
`focusAreas`	No	Areas to focus on for refactoring
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`projectPath`	No	Path to project root (for multi-file refactoring analysis)

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 the full burden of behavioral disclosure. It mentions that the tool 'handles both single and multi-file' analysis and includes workflow tips, but fails to describe critical behavioral traits such as whether this is a read-only analysis or if it modifies code, what permissions or authentication might be needed, rate limits, error handling, or what the output looks like. For a complex 10-parameter tool with no annotations, this is a significant gap.

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

Conciseness2/5

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

The description is structured with sections like 'WORKFLOW', 'TIP', and 'SAVES', but it's not front-loaded with core functionality—the first sentence is clear, but subsequent sections add tangential advice rather than essential tool behavior. Sentences like 'SAVES: Claude context for strategic decisions' are vague and don't earn their place in a tool description, making it feel cluttered and inefficient for an AI agent.

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 the tool's complexity (10 parameters, no annotations, no output schema), the description is incomplete. It lacks information on behavioral traits, output format, error conditions, and how it differs from sibling tools. While it covers purpose and some usage context, it doesn't provide enough detail for an AI agent to confidently select and invoke this tool in a production environment, especially compared to related siblings like 'analyze_code_quality'.

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 schema already documents all 10 parameters thoroughly with descriptions, defaults, and enums. The description adds no specific parameter information beyond implying support for 'single and multi-file' analysis, which loosely relates to parameters like 'code', 'filePath', 'files', and 'projectPath'. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't add meaningful semantic value beyond what's in the structured data.

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's purpose: 'Analyze code and suggest refactoring improvements with project-specific patterns (handles both single and multi-file)'. It specifies the verb ('analyze and suggest'), resource ('code'), and scope ('single and multi-file'). However, it doesn't explicitly differentiate from siblings like 'analyze_code_quality' or 'analyze_single_file', which appear related but have different focuses.

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 includes a 'WORKFLOW' section that implies usage context ('Ideal for creating production-ready code, tests, and documentation') and a 'TIP' with practical advice ('Generate unlimited iterations locally, then review with Claude'). However, it lacks explicit guidance on when to use this tool versus alternatives like 'analyze_code_quality' or 'analyze_single_file', and doesn't mention exclusions or prerequisites for use.

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

trace_execution_pathA

Trace execution path through multiple files starting from an entry point. Shows complete call flow with intelligent analysis and architectural insights.

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	detailed
`analysisType`	No	Type of analysis to perform	comprehensive
`code`	No	The code to analyze (for single-file analysis)
`entryPoint`	Yes	Entry point like ClassName::methodName or functionName
`filePath`	No	Path to single file to analyze
`files`	No	Array of specific file paths (for multi-file analysis)
`language`	No	Programming language	javascript
`maxDepth`	No	Maximum directory depth for multi-file discovery (1-5)
`projectPath`	No	Path to project root (for multi-file analysis)
`showParameters`	No	Include parameter information in trace
`traceDepth`	No	Maximum depth to trace (1-10)

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'intelligent analysis and architectural insights' and 'SAVES: Claude context for strategic decisions' which adds useful context about the tool's analytical nature and output usage. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, computational cost, time requirements, error conditions, or output format details.

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 uses a structured format with sections (WORKFLOW, TIP, SAVES) which helps organization, but contains some redundant phrasing. 'Shows complete call flow with intelligent analysis and architectural insights' could be more concise. The three-section format is helpful but not perfectly streamlined - each sentence earns its place but could be more tightly written.

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 complex 11-parameter analysis tool with no annotations and no output schema, the description provides adequate but incomplete context. It explains the tool's purpose and typical workflow well, but lacks crucial information about what the output looks like, error handling, performance characteristics, and limitations. Given the tool's complexity and absence of structured behavioral annotations, the description should do more to compensate.

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 schema already documents all 11 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema - it doesn't explain relationships between parameters like 'code' vs 'files' vs 'projectPath', or provide examples of valid 'entryPoint' formats. This meets the baseline for high schema coverage but 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 the tool's purpose: 'Trace execution path through multiple files starting from an entry point' with specific verbs (trace, shows) and resources (execution path, call flow). It distinguishes from siblings like 'analyze_single_file' by emphasizing multi-file analysis, but doesn't explicitly contrast with all similar tools like 'analyze_dependencies' or 'list_functions'.

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 usage context with 'WORKFLOW: Perfect for understanding complex code, identifying issues, and technical debt assessment' and 'TIP: Use Desktop Commander to read files, then pass content here for analysis.' This gives practical guidance on when to use it (complex code analysis) and a prerequisite step. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools.

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

wordpress_plugin_readinessB

Comprehensive WordPress plugin readiness check for security, best practices, and WordPress.org submission

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail	comprehensive
`includeSteps`	No	Specific analysis steps to include
`maxDepth`	No	Maximum directory depth for file discovery (1-5)
`maxFiles`	No	Maximum number of PHP files to analyze
`phpVersion`	No	Target PHP version for compatibility	8.0
`projectPath`	Yes	Path to WordPress plugin root directory
`wpVersion`	No	Target WordPress version for compatibility	6.4

TDQS

B3/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the tool 'saves Claude context for strategic decisions' and hints at analysis capabilities, it fails to describe critical behavioral traits like whether it modifies files, requires specific permissions, has rate limits, or what the output format looks like. For a complex analysis tool with 7 parameters, this is inadequate.

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 uses a bullet-point structure with sections (DESCRIPTION, WORKFLOW, TIP, SAVES) but contains redundant phrasing like 'Comprehensive... check' and 'Perfect for understanding complex code' that could be more concise. The information is somewhat front-loaded but includes marketing language that doesn't earn its place for tool selection.

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 the tool's complexity (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the analysis produces, how results are returned, or what 'saves Claude context' means operationally. The workflow tip is helpful but doesn't compensate for missing behavioral and output context needed for effective tool use.

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 schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly with descriptions, defaults, and constraints. The description adds no parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter semantics.

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 performs a 'comprehensive WordPress plugin readiness check for security, best practices, and WordPress.org submission,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'audit_wordpress_plugin' or 'analyze_wordpress_security,' which appear to offer overlapping functionality.

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 implied usage guidance through 'WORKFLOW' and 'TIP' sections, suggesting it's for analyzing complex code and should be used after reading files with Desktop Commander. However, it lacks explicit when-to-use vs. when-not-to-use instructions or clear alternatives among the many sibling analysis tools.

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

wordpress_theme_from_staticB

Convert static HTML/CSS/JS sites into fully functional WordPress themes with smart template detection

WORKFLOW: Ideal for creating production-ready code, tests, and documentation TIP: Generate unlimited iterations locally, then review with Claude SAVES: Claude context for strategic decisions

ParametersJSON Schema

Name	Required	Description	Default
`analysisDepth`	No	Level of analysis detail for theme conversion	comprehensive
`analysisType`	No	Type of theme conversion to perform	comprehensive
`code`	No	HTML content to convert (for single-file analysis)
`filePath`	No	Path to HTML file to convert
`files`	No	Array of specific static site files to analyze
`includeCustomizer`	No	Include WordPress Customizer options
`includeGutenberg`	No	Include Gutenberg block support
`includeMenus`	No	Include dynamic WordPress menus
`includeSidebars`	No	Include WordPress sidebar/widget areas
`includeWooCommerce`	No	Include WooCommerce template support
`language`	No	Primary language (HTML/PHP for WordPress themes)	html
`maxDepth`	No	Maximum directory depth for static site discovery (1-5)
`projectPath`	No	Path to static site directory (for multi-file analysis)
`themeAuthor`	No	Theme author name	Theme Generator
`themeDescription`	No	Theme description	WordPress theme generated from static site
`themeName`	No	WordPress theme name	Custom Static Theme
`themeVersion`	No	Theme version	1.0.0
`url`	No	Single URL to analyze for theme conversion
`urls`	No	Array of URLs to analyze for theme conversion (e.g., home, blog, about pages)

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 carries the full burden of behavioral disclosure. It mentions 'smart template detection' and workflow tips, but fails to disclose critical behavioral traits such as whether this is a read-only analysis or a destructive write operation, what permissions are needed, potential rate limits, or what the output looks like (e.g., generated files, error handling). For a complex conversion tool with 19 parameters, this is a significant gap.

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 structured with sections (WORKFLOW, TIP, SAVES), but includes extraneous content like 'SAVES: Claude context for strategic decisions,' which doesn't directly help tool selection. The core purpose is clear upfront, but some sentences don't earn their place, reducing efficiency.

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 the tool's complexity (19 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral aspects (e.g., mutation vs. analysis), output format, error conditions, and integration with sibling tools. While the schema covers parameters, the description fails to provide sufficient context for safe and effective use.

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%, meaning all parameters are documented in the schema itself. The description adds no specific parameter semantics beyond what the schema provides (e.g., it doesn't explain how 'analysisDepth' vs 'analysisType' differ or clarify parameter interactions). With high schema coverage, the baseline is 3, and the description doesn't compensate with additional insights.

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's purpose: 'Convert static HTML/CSS/JS sites into fully functional WordPress themes with smart template detection.' This specifies the verb (convert), resources (static sites), and output (WordPress themes). However, it doesn't explicitly differentiate from sibling tools like 'generate_wordpress_plugin' or 'audit_wordpress_theme,' which would require a 5.

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 implied usage context through 'WORKFLOW: Ideal for creating production-ready code, tests, and documentation' and 'TIP: Generate unlimited iterations locally, then review with Claude.' This suggests when to use it (for production themes) and a workflow tip, but lacks explicit guidance on when to choose this over alternatives like 'generate_wordpress_plugin' or clear exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

34 tool updatesv1.0.0Sep 11, 2025
- First observedanalyze_code_quality
- First observedanalyze_database_queries
- First observedanalyze_dependencies
- First observedanalyze_n8n_workflow
- First observedanalyze_project_structure
- First observedanalyze_single_file
- First observedanalyze_wordpress_security
- First observedarcade_game
- First observedaudit_wordpress_plugin
- First observedaudit_wordpress_theme
- First observedclear_analysis_cache
- First observedcompare_integration
- First observedconvert_to_typescript
- First observedcount_files
- First observedcreate_text_adventure
- First observedcss_art_generator
- First observedcustom_prompt
- First observeddiff_method_signatures
- First observedfind_pattern_usage
- First observedfind_unused_css
- First observedfind_unused_files
- First observedgenerate_project_documentation
- First observedgenerate_responsive_component
- First observedgenerate_unit_tests
- First observedgenerate_wordpress_plugin
- First observedget_cache_statistics
- First observedhealth_check
- First observedlist_functions
- First observedresolve_path
- First observedsecurity_audit
- First observedsuggest_refactoring
- First observedtrace_execution_path
- First observedwordpress_plugin_readiness
- First observedwordpress_theme_from_static

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored 2026-04-18 08:46 across 34 tools

Disambiguation2/5

Multiple tools have overlapping purposes that could cause confusion. For example, analyze_code_quality, analyze_single_file, and suggest_refactoring all seem to analyze code quality with unclear boundaries, while audit_wordpress_plugin and wordpress_plugin_readiness both audit WordPress plugins. The descriptions are similar across many analysis tools, making it hard to distinguish when to use each one.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (e.g., analyze_code_quality, generate_unit_tests), with clear and descriptive names. There are minor deviations like arcade_game (noun-only) and custom_prompt (adjective_noun), but the overall pattern is readable and predictable across the set.

Tool Count2/5

With 34 tools, the count is too high for a coherent set, feeling bloated and unfocused. The server mixes code analysis, WordPress-specific tools, game generation, and system diagnostics without a clear unified scope, making it difficult for an agent to navigate effectively.

Completeness3/5

The toolset covers various domains like code analysis, WordPress, and generation, but within each area, there are gaps. For example, in code analysis, there's no tool for updating or deleting code, and in WordPress, missing tools for core operations like installing or managing plugins. The surface is broad but not deep, with notable missing operations for full lifecycle coverage.

Maintenance

ActivityActive

ResponsivenessSlow

Resources

Need Help?

Related Servers

Related MCP Connectors

QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2127
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
265
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2

Related MCP Servers

Claude-LMStudio Bridge
Autonomous Agents Code Execution
infinitimeless
F
license
Not graded
quality
F
maintenance
An MCP server that allows Claude to interact with local LLMs running in LM Studio, providing access to list models, generate text, and use chat completions through local models.
Updated 2 years ago (2025-03-21 13:27 UTC)
13
-
LMStudio-MCP
AI & Machine Learning Developer Tools
samscarrow
A
license
Not graded
quality
D
maintenance
A Model Control Protocol (MCP) server that allows Claude to communicate with locally running LLM models via LM Studio.
Updated a year ago (2025-07-07 14:16 UTC)
MIT
Claude-LMStudio-Bridge
AI & Machine Learning Developer Tools
infinitimeless
A
license
Not graded
quality
F
maintenance
A simple MCP server that enables Claude to communicate with locally running LLM models via LM Studio.
Updated 2 years ago (2025-03-21 17:22 UTC)
9
MIT
Converse MCP Enhanced
justmy2satoshis
A
license
Not graded
quality
D
maintenance
Multi-model AI conversation MCP for Claude Desktop. Seamlessly integrate with GPT-4, Gemini, xAI, Perplexity, and local models via Ollama.
Updated a year ago (2025-09-25 08:25 UTC)
MIT