Summary: This MCP server gives AI assistants full control and monitoring of a Homebridge smart home instance, from managing accessories and plugins to editing config and reading logs.
Accessory control — list_accessories, get_accessory, set_accessory (on/off, brightness, color, temperature, etc.) and get_accessory_layout.
System status — get_homebridge_status, get_server_status, get_system_info, get_pairing_info and restart_homebridge.
Cached accessories — list, remove one (remove_cached_accessory), or reset all (reset_cached_accessories).
Config management — get_config and update_config (full overwrite of config.json).
Plugin management — list, search npm, look up details/versions/config schema/changelog.
Logs — get_recent_logs (tail up to 5000 lines) and search_logs (substring or regex, case-sensitive option, up to 2000 matches).
Provides tools to control Homebridge accessories, manage plugins, edit configuration, and monitor server status.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@mp-consulting/homebridge-mcp-server Turn off the living room lights"
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.
AI toolkit for Homebridge, in one package:
An MCP server that lets AI assistants (Claude Desktop, Claude Code, Cursor) control accessories, manage plugins, edit configuration and read logs, over stdio or Streamable HTTP.
The Assistant: provider adapters (Claude, OpenAI, Gemini, any OpenAI-compatible server), an agent loop wired to the MCP tools, and ready-made features (log doctor, config copilot, device-error explainer, update-risk briefing, organiser, daily digest). Homebridge Glass UI and the MP Consulting plugins use these.
A Homebridge plugin (HomebridgeAiKit platform) with a settings page to pick the provider and model, test the connection, serve MCP over HTTP and generate client configs.
The AI building blocks that don't need MCP also ship on their own as @mp-consulting/homebridge-ai-core — see Packages.
Renamed from
@mp-consulting/homebridge-mcp-server. The oldhomebridge-mcp-servercommand still works, so existing MCP client configs don't need to change. See Migrating from homebridge-mcp-server.
Related MCP server: hass-mcp-server
This repository is an npm workspace that publishes two packages, both at version 2.0.0:
Package | Use it for | Runtime dependencies |
Homebridge plugins. The plugin-UI Assistant routes ( |
| |
| Homebridge Glass UI and MCP. Everything in ai-core (re-exported) plus the MCP server, | ai-core, |
Plugins should depend on ai-core, so installing them doesn't pull in the MCP SDK, socket.io or zod. ai-kit stays backward compatible: its . and ./plugin exports re-export everything ai-core has under the same names, so code that imports from ai-kit keeps working.
MCP tools (43): accessories (list, get, control with value checks, bulk control with dryRun, locks / garage doors / alarms behind confirmation, room layout, sensor history), scenes (list, run, save), server (status, restart, pairing, cached accessories), child bridges (list, health, restart, stop, start), config (read with secrets redacted, full write, partial patch_config, dryRun diffs, backups and restore), instance backups, test notifications, plugins (list, search, versions, schema, changelog, install, update, uninstall), system info and logs (recent lines, filtered regex search).
MCP resources you can subscribe to: homebridge://accessories, homebridge://logs/recent, homebridge://status. Changes arrive over the Homebridge UI's socket.io namespaces, or by polling when the socket can't be used.
MCP resource templates (listed in resources/list, with completion): homebridge://accessory/{uniqueId} (one accessory with every characteristic), homebridge://plugin/{name} (one installed plugin and its child bridges; URL-encode scoped names), homebridge://child-bridge/{id} (one child bridge by username, with its health on Glass UI).
MCP prompts: diagnose-logs, plan-upgrade, audit-config, troubleshoot-device (device, symptom?), nightly-health-check (hours?), scene-builder (description, room?).
Assistant features (library): diagnoseLogs, generatePluginConfig, explainDeviceError, assessPluginUpdate, suggestOrganization, dailyDigest, ask, and runAgent for anything that needs the tools. Every input is redacted before it reaches a provider and trimmed to fit its context window; JSON outputs are checked against a schema with one automatic repair attempt; token usage and Claude costs are tracked.
All providers use plain fetch (no SDKs). Each declares what it can do, and features without tool calling fall back to prompt-only answers.
| Default model | API key | Tools | Streaming | Context |
|
| required | yes | yes | 1M (200K for Haiku) |
|
| required | yes | yes | 128K (set |
|
| required | yes | yes | 1M |
|
| optional | yes | yes | 8K (set |
Claude models: claude-sonnet-5-5 (default), claude-haiku-4-5-20251001 (cheapest), claude-opus-5-5 (most capable).
OpenAI models: gpt-6.1-sol (default), gpt-6-luna (cheapest), gpt-6-astra (most capable). Requests use the Responses API with store: false (nothing is kept on OpenAI's side); newer models only call tools through it. Set "openaiApi": "chat" to use Chat Completions instead, e.g. for a proxy that only speaks it.
openai-compatible works with Ollama (http://127.0.0.1:11434/v1, the default), LM Studio (http://127.0.0.1:1234/v1), vLLM and similar. Set contextTokens to your model's context window so inputs are trimmed correctly.
An on-device Apple Foundation Models provider is planned.
Install it like any plugin (Homebridge 1.8+ or 2.x):
npm install -g @mp-consulting/homebridge-ai-kitThen open its settings in the Homebridge UI. The settings page edits the HomebridgeAiKit platform block, tests the connection with the values in the form, and shows ready-to-paste configs for Claude Desktop, Claude Code and Cursor.
{
"platform": "HomebridgeAiKit",
"name": "AI Kit",
"enabled": true,
"provider": "anthropic", // anthropic | openai | gemini | openai-compatible
"model": "claude-sonnet-5-5", // optional, defaults per provider
"apiKey": "sk-ant-…", // secret, redacted wherever config is shown to a model
"baseUrl": "http://127.0.0.1:11434/v1", // openai-compatible only (or a proxy)
"contextTokens": 32768, // optional override, mainly for local models
"maxOutputTokens": 2048,
"effort": "medium", // Claude and OpenAI: low | medium | high | xhigh | max (unset = model default)
"openaiApi": "responses", // openai / openai-compatible: responses | chat (default responses for OpenAI, chat for local servers)
"maxRetries": 2, // retries on 408/429/5xx/529 and network errors (backoff, honours retry-after); 0 = off
"mcp": {
"http": {
"enabled": false,
"host": "127.0.0.1",
"port": 8582,
"token": "…", // bearer token MCP clients must send
"homebridgeUrl": "http://127.0.0.1:8581",
"homebridgeToken": "hbg_…", // Glass UI API token the tools act with
"homebridgeTokenId": "…", // written by Glass UI so it can revoke that token; leave as is
"homebridgeCertFingerprint": "AB:CD:…", // https UI with a self-signed certificate: its SHA-256 fingerprint
"homebridgeCertPath": "/path/to/certificate.pem", // or a PEM with the UI's certificate or its CA
"readOnly": false, // true caps every client token at read-only
"clients": [ // more client tokens, each with a scope: read | control | admin
{ "name": "Dashboard", "token": "…", "scope": "read" }
],
"allowedOrigins": ["https://my-dashboard.local"], // browser pages allowed besides localhost / this server's IP
"auditLog": true, // log every write tool call (JSONL)
"auditLogPath": "/var/lib/homebridge/homebridge-ai-kit-audit.jsonl" // default: Homebridge storage path
}
}
}With mcp.http.enabled, the plugin serves MCP at http://<host>:<port>/mcp while Homebridge runs. It needs a client token (mcp.http.token, HOMEBRIDGE_AI_MCP_TOKEN, or at least one scoped token in mcp.http.clients) and Homebridge credentials: a Glass UI API token in homebridgeToken, or the HOMEBRIDGE_* environment variables. A read-only API token gives clients read-only access.
The MCP server uses two different tokens:
Token | What it is for | Stored in |
Client token | What Claude, Cursor or another MCP client must send ( |
|
Scoped client tokens | Optional extra client tokens with less access, e.g. a read-only token for a dashboard |
|
Homebridge API token | What the MCP server sends to the Homebridge UI to run its tools. Its scope decides what clients can do: |
|
Where to set or generate them:
Homebridge Glass UI 2.0.0-beta.6 or later: Settings → Assistant → MCP server generates the client token, creates the Homebridge API token in one click (read-only or admin, revoked again when you replace or remove it), and shows the client configs. Each secret is shown once; after that the page only says whether one is set.
This plugin's settings page: Generate creates a client token. Paste a Homebridge API token created in Glass UI under Users → API Tokens.
The CLI: set HOMEBRIDGE_AI_MCP_TOKEN and HOMEBRIDGE_TOKEN (see MCP server), e.g. HOMEBRIDGE_AI_MCP_TOKEN=$(openssl rand -base64 24).
Client token scopes (each includes the ones before it):
Scope | Tools |
| Every read-only tool |
| Plus device control: |
| Plus everything else: config writes and restores, backups, |
The main client token is admin (as before), or read when readOnly is on; readOnly caps the scoped tokens too. A session belongs to the token that opened it. The client token decides which tools a client sees; the Homebridge API token still limits what the server itself can do, so a read API token keeps everything read-only.
Every write tool call is appended to an audit log (<Homebridge storage>/homebridge-ai-kit-audit.jsonl by default; mcp.http.auditLog / auditLogPath, or HOMEBRIDGE_AI_AUDIT_LOG for the CLI): one JSON object per line with ts, tool, args (secrets redacted), ok, error, session, client, principal (the token's name: default for the main token, agent for runAgent) and scope; notConfirmed: true marks a destructive call the user declined (MCP elicitation, or runAgent's confirm), which did not run. Dry runs are logged too, with dryRun: true in args. runAgent takes the same audit option. It rotates at 5 MB and keeps three old files.
Glass UI also stores homebridgeTokenId, the id of the API token it created, so it can revoke the token when you replace or remove it. The settings page keeps it (and any other field it doesn't show) when it saves.
Node refuses a self-signed certificate, so the MCP server can't reach a Homebridge UI served that way until you tell it which certificate to trust. Verification is never turned off: the setting only applies to the server's requests to the Homebridge UI.
Setting | CLI | What it trusts |
|
| Exactly the certificate with this SHA-256 fingerprint (pinned). Any other certificate, even a valid one, is refused with an error that shows both fingerprints. |
|
| The certificates in this PEM file, on top of the public CAs: the UI's own self-signed certificate (accepted under any host name, e.g. |
Get the fingerprint on the Homebridge machine with openssl x509 -noout -fingerprint -sha256 -in <certificate.pem> (Glass UI's self-signed certificate is <storage>/ssl-certs/certificate.pem); colons and case don't matter. Setting both requires the chain to validate against the PEM and the certificate to match the fingerprint. Update the fingerprint when the certificate is renewed. Both only apply to an https URL. Resource subscriptions then follow changes by polling, since the socket.io connection keeps Node's default verification.
Changes to mcp.http apply after a Homebridge restart, since the plugin starts the HTTP server when Homebridge loads it. Treat both tokens like passwords: anyone with the client token can use every tool the Homebridge API token allows.
A plugin's custom UI server can offer the Assistant with one call. Import the routes from @mp-consulting/homebridge-ai-core/plugin (ai-kit's ./plugin re-exports them, but plugins should depend on the slimmer ai-core). The browser side is MpKit.ai from @mp-consulting/homebridge-ui-kit:
// homebridge-ui/server.js
import { HomebridgePluginUiServer } from '@homebridge/plugin-ui-utils';
import { registerAiRoutes } from '@mp-consulting/homebridge-ai-core/plugin';
class UiServer extends HomebridgePluginUiServer {
constructor() {
super();
registerAiRoutes(this, { pluginName: '@mp-consulting/homebridge-ewelink' });
this.ready();
}
}
new UiServer();Route | Body | Result |
| none |
|
|
|
|
|
|
|
|
|
|
With a requestId, the server streams ai:chunk { requestId, delta } events, then ai:done { requestId } or ai:error { requestId, message }. The routes read the HomebridgeAiKit block from config.json on every request, so settings changes apply at once.
Variable | Description |
| URL of your Homebridge UI, e.g. |
| A Homebridge UI API token (Glass UI |
| UI login, when no token is set |
|
|
|
|
|
|
| Request timeout (default |
| SHA-256 fingerprint of an |
| PEM file with the |
| Bearer token required by |
|
|
| Path of a JSONL audit log of write tool calls (off by default for the CLI) |
|
|
|
|
|
|
{
"mcpServers": {
"homebridge": {
"command": "npx",
"args": ["-y", "@mp-consulting/homebridge-ai-kit", "mcp"],
"env": {
"HOMEBRIDGE_URL": "http://192.168.1.100:8581",
"HOMEBRIDGE_TOKEN": "hbg_…"
}
}
}
}claude mcp add homebridge -e HOMEBRIDGE_URL=http://192.168.1.100:8581 -e HOMEBRIDGE_TOKEN=hbg_… -- npx -y @mp-consulting/homebridge-ai-kit mcpHOMEBRIDGE_AI_MCP_TOKEN=$(openssl rand -base64 24) \
HOMEBRIDGE_URL=http://127.0.0.1:8581 HOMEBRIDGE_TOKEN=hbg_… \
homebridge-ai-kit mcp --http --port 8582 --host 127.0.0.1The endpoint is http://127.0.0.1:8582/mcp. Every request needs Authorization: Bearer <HOMEBRIDGE_AI_MCP_TOKEN>. It binds to 127.0.0.1 by default; only use --host 0.0.0.0 on a trusted network, ideally behind HTTPS.
Origin check. As the MCP spec requires, a request with an Origin header (i.e. from a web page) is refused with 403 unless the origin is a loopback one (http://localhost:…, 127.0.0.1, [::1]), the server's own IP address, or listed in HOMEBRIDGE_AI_MCP_ALLOWED_ORIGINS (plugin: mcp.http.allowedOrigins). This stops a malicious page from reaching the server through DNS rebinding. Desktop clients send no Origin and are unaffected.
Sessions close after 30 idle minutes, and at most 32 stay open. Sessions with an open stream are never idle. All sessions share one Homebridge change feed for resources/subscribe.
Bad tokens. After 5 wrong tokens from one address, it must wait before trying again (429 with Retry-After, doubling up to 5 minutes); a correct token resets the count.
claude mcp add --transport http homebridge http://127.0.0.1:8582/mcp --header "Authorization: Bearer <token>"Group | Tools |
Accessories |
|
Server |
|
Child bridges |
|
Scenes* |
|
Notifications* |
|
Config |
|
Backups |
|
Plugins |
|
System |
|
Logs |
|
* Needs Homebridge Glass UI; with another Homebridge UI these tools answer with an error saying so.
The list/get tools (list_accessories, get_accessory, list_plugins, list_child_bridges, get_child_bridge_health, get_homebridge_status, get_server_status, search_logs, list_scenes) also return structuredContent matching their outputSchema.
set_accessory checks the value against the characteristic first (format, min/max, step, valid values, write permission), coerces "50" to 50 or 1 to true, and explains what is wrong instead of sending a bad value.
Locks, garage doors and security systems (LockTargetState, TargetDoorState, SecuritySystemTargetState, or any characteristic of a LockMechanism, GarageDoorOpener or SecuritySystem service) are refused by set_accessory; they go through set_security_accessory, which is annotated destructiveHint: true so MCP clients and runAgent ask the user before unlocking, opening or disarming anything. Lights and switches still change without a prompt.
get_accessory_history returns an accessory's recorded sensor values (temperature, humidity, light level, battery, air quality, power, energy) over the last hours (default 24, up to 8760), optionally for one characteristic type. Per series it gives count, min / max (value and when), the time-weighted avg, last, and the points averaged down to maxPoints (default 48, 2–500), with times in UTC to the minute. It needs Homebridge Glass UI (GET /api/accessories/:uniqueId/history), which records these values while Homebridge runs in insecure mode.
patch_config changes one platform or accessory block (found by platform/accessory plus name); objects merge, null removes a key, and __REDACTED__ keeps the current secret.
install_plugin, update_plugin and uninstall_plugin start a job on the Homebridge UI and wait up to two minutes for it; get_plugin_job follows a longer one. They need Homebridge Glass UI (POST /api/plugins/install|update|uninstall, GET /api/plugins/jobs/:id).
The log tools need a Homebridge install managed by hb-service.
import {
createProvider, readAiConfig, runAgent, diagnoseLogs, generatePluginConfig, UsageTracker,
} from '@mp-consulting/homebridge-ai-kit';
import { HomebridgeClient } from '@mp-consulting/homebridge-ai-kit/mcp';
const config = await readAiConfig(); // HomebridgeAiKit block of ~/.homebridge/config.json
const provider = createProvider(config);
// One-shot feature, streamed
const { text } = await diagnoseLogs({ provider, logs, onChunk: (d) => process.stdout.write(d) });
// Agent with the MCP tools, acting as the current user
const client = new HomebridgeClient({ url: 'http://127.0.0.1:8581', getToken: () => mintShortLivedToken(user) });
const result = await runAgent({
provider,
client,
messages: [{ role: 'user', content: 'Turn off every light downstairs' }],
confirm: async (call) => askUser(`Allow ${call.name}?`), // destructive tools are refused without it
onEvent: (e) => console.log(e),
});Export | Purpose |
|
|
| Loops model ↔ MCP tools (in-memory transport), |
| Ready-made features; all accept |
| Schema-checked JSON (ajv) with one repair retry |
| Keep inputs inside the context window (logs keep their tail) |
| Token and cost accounting (Claude prices; unknown models cost |
| Prompt templates, shared with the MCP prompts |
| Read and default the |
| Keep credentials and pairing codes out of model context |
| Server helpers: per-user rate limit, expiring cache, confirmations with a timeout, log tails |
Everything in this table except runAgent comes from @mp-consulting/homebridge-ai-core and is re-exported here unchanged.
./mcp exports createServer, HomebridgeClient, runStdioServer, runHttpServer, createLiveSource, shareLiveSource, createAuditLog, the token SCOPES, and the TLS pinning helpers createTrustedFetch, normalizeFingerprint, pemFingerprints; ./plugin exports registerAiRoutes and testAiConnection (from ai-core's ./plugin), mcpClientSnippets and AiKitPlatform.
Secrets stay out of the model's context. get_config, patch_config and the Assistant features replace passwords, tokens, API keys (including the AI Kit apiKey and MCP tokens) and the bridge pin with __REDACTED__. Writes swap the placeholders back for the real values. get_config's includeSecrets only exists when the server opts in with HOMEBRIDGE_ALLOW_SECRETS=true (allowSecrets for createServer / runHttpServer), and never in read-only mode. Free text sent to a provider (logs, errors) has credential-shaped values masked too.
Destructive actions need consent. Every tool declares MCP readOnlyHint / destructiveHint; runAgent refuses destructive tools unless a confirm callback allows them. When the MCP client supports elicitation, the server itself asks the user to confirm each destructive tool call (arguments shown with secrets redacted; dry runs skip it; a declined or failed confirmation does not run the tool); HOMEBRIDGE_ELICITATION=false turns that off. Unlocking a door, opening a garage door or disarming an alarm only works through the destructive set_security_accessory, so it is confirmed too; set_accessories and scenes refuse those targets. Config writes can be previewed with dryRun and rolled back with restore_config. HOMEBRIDGE_READ_ONLY=true removes write tools entirely.
Tool output is treated as data. Logs (tools and the homebridge://logs/recent resource), changelogs and other Homebridge-sourced free text come back wrapped in <untrusted-data source="…"> tags (runAgent wraps every tool result it sends to the model), with any tag inside the data defused (JSON results and structuredContent stay plain data so they parse), and the base system prompt tells the model never to follow instructions found in tool output and to change things only when the user asked. Combined with confirmation for destructive tools, a log line saying "unlock the front door" can't open it.
HTTP is locked down. The HTTP transport requires a bearer token, compares it in constant time and binds to 127.0.0.1 by default. It checks Origin, expires idle sessions and slows down repeated bad tokens.
Least privilege and an audit trail. Extra client tokens can be limited to read or control, and every write tool call is logged with redacted arguments (see MCP tokens).
update_config rejects incomplete configs, and regex log searches run in a worker thread that is killed after 5 seconds.
The server warns if HOMEBRIDGE_URL sends credentials over plain http to a non-local host.
TLS verification stays on. A self-signed Homebridge UI certificate is trusted only through HOMEBRIDGE_CERT_FINGERPRINT / HOMEBRIDGE_CERT_PATH (or the matching mcp.http settings), and only for the requests to the Homebridge UI; a certificate that doesn't match is refused.
npm uninstall -g @mp-consulting/homebridge-mcp-server
npm install -g @mp-consulting/homebridge-ai-kitThe package installs both homebridge-ai-kit and a homebridge-mcp-server alias, and the environment variables are unchanged, so existing configs keep working. New configs should use homebridge-ai-kit mcp. The MCP server now reports its name as homebridge-ai-kit, and library users import createServer and HomebridgeClient from @mp-consulting/homebridge-ai-kit/mcp.
git clone https://github.com/mp-consulting/homebridge-ai-kit.git
cd homebridge-ai-kit
npm install
npm run build # builds packages/ai-core, copies the ui-kit assets into homebridge-ui/public/lib, then tscThe repository is an npm workspace: the root is ai-kit and packages/ai-core is ai-core. The root scripts run both packages (ai-core first); npm run <script> -w packages/ai-core runs one script for ai-core alone. ai-kit's tests resolve @mp-consulting/homebridge-ai-core to its sources, while typecheck and build use ai-core's dist, so they build it first.
npm run dev # MCP server on stdio with tsx
npm test # Run tests
npm run test:coverage # Tests with coverage thresholds (as CI does)
npm run lint # ESLint
npm run typecheck # Type-check src and test (both packages)Publishing. The release workflow publishes @mp-consulting/homebridge-ai-core first (skipped if that version is already on npm), then @mp-consulting/homebridge-ai-kit, which depends on it. Both use npm trusted publishing (OIDC): before the first release, configure a trusted publisher on npmjs.com for the new @mp-consulting/homebridge-ai-core package name too (repository mp-consulting/homebridge-ai-kit, workflow publish.yml); if npm only lets you add one to an existing package, publish ai-core 2.0.0 once by hand from packages/ai-core. The first ai-core release has to go out before ai-kit 2.0.0 can be installed from npm.
MIT
Get detailed information about a specific accessory by its uniqueId. Use list_accessories first to find the uniqueId.
| Name | Required | Description | Default |
|---|---|---|---|
| uniqueId | Yes | The unique identifier of the accessory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read operation via 'Get detailed information' but does not state read-only, permissions, or expected response structure. Adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should hint at response content. It vaguely says 'detailed information' without specifics. For a simple single-param tool, it's adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description. The description adds value by explaining how to obtain the uniqueId parameter via list_accessories, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Get detailed information about a specific accessory by its uniqueId.' Distinguishes from sibling tools like list_accessories and set_accessory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Use list_accessories first to find the uniqueId,' guiding the agent on prerequisite steps and which sibling to use for discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the accessories room layout as configured in the Homebridge UI.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states it gets layout data, implying a read-only operation without side effects. However, it does not disclose authentication needs, error behavior, or return format. For a simple getter, this is adequate but lacks the richness expected for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that contains no extraneous information. Every word contributes to clarifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description explains what it does but does not describe the return value or structure. Given that no output schema exists, the description would ideally mention what the layout object contains or its format. This gap makes it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is trivially 100%. With no parameters, the description does not need to add meaning beyond the schema. The baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'accessories room layout', specifying the source as 'configured in the Homebridge UI'. This distinguishes it from sibling tools like get_accessory (single accessory) and list_accessories (list without layout).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like list_accessories or get_config. However, with zero parameters and a clear purpose, the usage is implied: call it to retrieve the room layout. The lack of comparative context lowers the score to 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all cached accessories stored by Homebridge. These persist across restarts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 reveals that cached accessories persist across restarts, which is a key behavioral trait. However, it does not state whether the operation is read-only or require authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no fluff. Every word adds value: lists the action, the resource, and a notable property (persistence).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the core purpose and an important behavioral detail. It could mention the return format, but this is not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. The description does not need to add parameter details; a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('cached accessories stored by Homebridge'), clearly distinguishing it from sibling tools like 'list_accessories' (general list) or 'get_accessory' (single item).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing cached data but lacks explicit guidance on when to use this versus alternatives. However, given the tool's simplicity (no parameters), the implied context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current Homebridge config.json file content. Returns the full configuration including bridge settings, accessories, and platforms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description clearly states it is a read operation and specifies the return contents (full configuration including bridge settings, accessories, and platforms), which adds behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary detail; every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately explains the return value for a simple read tool; it could be slightly more detailed about the structure but is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description adds value by explaining what the returned configuration contains, compensating for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Read' and the resource 'current Homebridge config.json file content', clearly distinguishing it from sibling tools that focus on accessories, plugins, or status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or not use this tool compared to alternatives like get_system_info or get_homebridge_status; usage is implied from the purpose but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if Homebridge is running and get its current status (up/down, version, plugins status).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full burden. It accurately describes a read-only, non-destructive operation that checks status. While it doesn't elaborate on side effects or auth needs, none are expected for a simple status check. It is transparent enough for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence of 15 words with no waste. Every phrase adds value: 'Check if Homebridge is running' immediately communicates purpose, followed by specifics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers the key aspects of the status returned. For a tool with zero parameters, it is sufficiently complete to inform an agent about what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds value by explaining the output aspects (up/down, version, plugins status) beyond the empty schema. Baseline 4 is appropriate for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and specifies the resource 'Homebridge running status' with details (up/down, version, plugins status). It distinguishes from sibling tools like get_server_status and get_system_info by focusing on Homebridge-specific operational status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when Homebridge status is needed) but does not provide explicit guidance on when not to use or alternatives among the many sibling tools. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the HomeKit pairing information (setup code, QR code URL) for this Homebridge instance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the action and output but does not disclose any behavioral traits such as being read-only, permissions needed, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a simple readonly operation, the description is mostly complete. It mentions the return fields. However, it lacks details about potential errors or usage context, but this is acceptable for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100% (trivially). The description adds no parameter information, but none is needed. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('HomeKit pairing information'), and specifies the output (setup code, QR code URL). It distinguishes itself from sibling get_* tools by focusing on pairing info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the CHANGELOG.md content for an installed Homebridge plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| pluginName | Yes | The npm package name of the plugin (e.g. 'homebridge-hue') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavior, but it only states the basic function without mentioning what happens if the plugin lacks a changelog, performance implications, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description is adequate but leaves uncertainty about edge cases (e.g., missing changelog) and does not specify the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a complete description of 'pluginName' (100% coverage), so the description adds only minor context by specifying 'installed' and an example, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get') and resource ('CHANGELOG.md content for an installed Homebridge plugin'), distinguishing it from sibling tools that retrieve other types of information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_plugin_versions' or 'lookup_plugin', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the config.schema.json for a plugin, which describes how to configure it in Homebridge.
| Name | Required | Description | Default |
|---|---|---|---|
| pluginName | Yes | The npm package name of the plugin (e.g. 'homebridge-hue') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'Get' which implies read-only, and describes the retrieval of a schema file. It does not elaborate on authentication or side effects, but for a read operation it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the action and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one fully-described parameter and no output schema, the description provides all necessary context to understand the tool's purpose and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no additional meaning beyond the schema description for the parameter. Baseline 3 is appropriate as the schema already documents the parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Get' and resource 'config.schema.json for a plugin' and explains its purpose ('describes how to configure it in Homebridge'). It clearly distinguishes from siblings like get_config or get_plugin_changelog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to get configuration schema for a plugin) but provides no explicit guidance on when not to use or alternatives. Given the tool's simple nature, it is adequate but lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available versions and dist-tags for a specific Homebridge plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| pluginName | Yes | The npm package name of the plugin (e.g. 'homebridge-hue') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It implies a read operation and mentions the resource, but does not disclose any potential side effects, response format, or additional behavioral traits. For a simple tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key information, and contains no unnecessary words. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally complete. However, it lacks context on the return value and usage guidance relative to siblings, which would help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a clear description for pluginName. The tool description adds no extra meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'available versions and dist-tags for a specific Homebridge plugin'. It distinguishes itself from sibling tools like get_plugin_changelog or get_plugin_config_schema by specifying versions and dist-tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Among 20 sibling tools, there are several other 'get_*' tools, but the description does not mention when this one is appropriate or when another should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the most recent lines from the Homebridge log (ANSI-stripped). Requires an hb-service based Homebridge install.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of lines to return from the tail (default 200, max 5000). |
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 that output is ANSI-stripped and that an hb-service install is required, which are useful behavioral details. Minor gaps like output format (array vs. string) or behavior on empty logs are not critical for this simple tool, so a high score is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the core function front-loaded in the first sentence and the prerequisite in the second. No wasted words, perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers essential functionality and the key constraint. It does not explicitly mention the output type (e.g., array of lines), but that is likely inferable. The lack of differentiation from search_logs is a minor gap, so not a 5 but solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the single 'lines' parameter with default, min, max, and a clear description, achieving 100% coverage. The description adds no extra meaning about the parameter, so it stays at the baseline for schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'the most recent lines from the Homebridge log', with the specific detail of ANSI-stripping. It is distinct from siblings like search_logs (which implies search), and from status/config tools, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite ('Requires an hb-service based Homebridge install') but does not explicitly state when to choose this tool over alternatives like search_logs. It implies usage for fetching recent log output, but lacks any when-not-to-use guidance or explicit alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Homebridge server information including version, Node.js version, uptime, OS details, and Homebridge instance ID.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only implies read-only behavior via 'get', but does not disclose permissions, side effects, or performance characteristics. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, front-loads the purpose and lists key data points efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema, return value structure not described. Adequate for a simple read tool but could hint at response format or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies automatically. The description adds no parameter information but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Homebridge server information and lists specific data fields (version, Node.js version, uptime, OS details, instance ID), distinguishing it from sibling tools like get_system_info or get_homebridge_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get system information for the machine running Homebridge (CPU, memory, OS, network interfaces, uptime).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It clearly indicates a read-only operation and lists the categories of information returned, providing adequate transparency for a simple info tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 15 words with no redundancy. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description sufficiently covers what the tool does by listing the categories of information. It could mention return format but is complete enough for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds value by specifying the types of system information returned, exceeding the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves system information (CPU, memory, OS, network interfaces, uptime) for the Homebridge machine, distinguishing it from sibling tools that focus on accessories, plugins, or configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when system-level info is needed but does not provide explicit guidance on when to use vs. alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Homebridge accessories with their current state (on/off, brightness, temperature, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by service name (case-insensitive, contains match) | |
| room | No | Filter by room name (case-insensitive) | |
| type | No | Filter by accessory type (e.g. 'Lightbulb', 'Switch', 'Thermostat') | |
| manufacturer | No | Filter by manufacturer (case-insensitive, contains match) | |
| excludeManufacturer | No | Exclude accessories from this manufacturer (case-insensitive, contains match) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the tool's basic function without disclosing important behaviors like performance implications for large numbers of accessories, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core purpose without unnecessary words. Every part is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the output includes state details, which is helpful given the absence of an output schema. However, it lacks information about pagination, limits, default behavior with no filters, or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 5 parameters with clear descriptions (e.g., 'case-insensitive, contains match'), so the description adds no further semantic value. Schema coverage is 100%, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all Homebridge accessories with current state, which is a specific verb-resource pair. However, it does not explicitly distinguish from sibling tools like get_accessory or get_cached_accessories, leaving some ambiguity for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The agent has no context to decide between list_accessories and other list or get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all currently installed Homebridge plugins with their versions and update status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool lists installed plugins with versions and update status, implying read-only behavior. However, it does not mention permissions, rate limits, or return format, which are missing for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains return values (versions and update status). For a simple, parameterless list operation, it is mostly complete, though it could clarify the structure (e.g., array of objects).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters (schema coverage 100% by default). The rubric sets a baseline of 4 for 0 parameters, and the description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all currently installed Homebridge plugins') and clearly states what is returned ('their versions and update status'). It distinguishes from sibling tools like list_accessories or get_plugin_versions by focusing on installed plugins with version and update info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., when to use list_plugins vs get_plugin_versions or search_plugins). The agent must infer based on the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Homebridge plugin from the npm registry.
| Name | Required | Description | Default |
|---|---|---|---|
| pluginName | Yes | The npm package name of the plugin (e.g. 'homebridge-hue') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It only states it gets info from npm registry, which is read-only, but omits details like rate limits, authentication, or what 'detailed information' includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that immediately communicates the tool's purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description is vague about what 'detailed information' contains. Without an output schema, it should hint at fields like version or author.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, and the description adds an example and clarifies the parameter is the npm package name, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'detailed information about a specific Homebridge plugin', and the source 'from the npm registry'. This distinguishes it from sibling tools like search_plugins and list_plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when detailed info on a specific plugin is needed, but does not explicitly contrast with sibling tools or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a specific cached accessory by its UUID. Useful for cleaning up stale accessories.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | The UUID of the cached accessory to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the action but discloses no behavioral traits such as whether removal is permanent, the effect on other data, error handling for invalid UUIDs, or safety considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. The action is front-loaded, and the purpose is immediately clear. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool without output schema, the description is adequate but incomplete. It does not mention return values or success/failure indicators, which are helpful for an agent to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the 'uuid' parameter. The description adds 'by its UUID', which restates the schema purpose without adding new semantics like format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove', the object 'cached accessory', and the method 'by its UUID'. It also provides a use case ('cleaning up stale accessories'), making it distinct from siblings like 'reset_cached_accessories'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for removing stale accessories but does not explicitly state when to use this tool versus alternatives (e.g., 'reset_cached_accessories' for bulk removal). No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset ALL cached accessories. WARNING: This removes all cached accessories and requires a Homebridge restart.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly warns that the action removes all cached accessories and requires a Homebridge restart, disclosing destructive behavior and a necessary post-condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the function, the second provides a critical warning. Every word is necessary, and the warning is front-loaded for visibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple destructive action, the description sufficiently explains what happens (removes, requires restart). It could mention if a response is returned, but the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100%. The description adds no parameter information, which is acceptable. Baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reset') and the resource ('ALL cached accessories'), with the word 'ALL' distinguishing it from the sibling tool 'remove_cached_accessory' which likely removes a single accessory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Reset ALL' but does not explicitly guide when to use this tool versus the sibling 'remove_cached_accessory' (which probably removes one). It also lacks context about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart the Homebridge service. This will temporarily make all accessories unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: temporary unavailability of accessories. However, it does not cover other aspects like authentication needs or potential duration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the purpose, the second adds important context. No extraneous information, efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is largely complete. It covers the action and the primary side effect. Could optionally mention if the restart is instantaneous or asynchronous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%. The description adds no parameter-specific meaning, which is acceptable per the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Restart the Homebridge service') with a specific verb and resource. Among siblings, which are mostly read-only or configuration tools, this is the only restart operation, making it distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the impact (accessories unavailable) but provides no explicit guidance on when to use or when not to use this tool. It lacks alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Homebridge log for matching lines. Returns up to limit most recent matches (ANSI-stripped). Useful for finding errors, warnings, or events involving a specific device.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matches to return, taken from the most recent (default 100, max 2000). | |
| regex | No | Treat pattern as a JavaScript regex (default: false, treats pattern as a literal substring). | |
| pattern | Yes | Substring or regex pattern to match against each log line. | |
| caseSensitive | No | Case-sensitive match (default: false). |
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 usefully discloses that results are ANSI-stripped and that matches are returned in most-recent order. However, it omits other behavioral details like whether it blocks, whether it searches the entire file each time, or any rate/performance caveats. For a read tool the core behavior is reasonably conveyed, but not exhaustively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the primary action and result format before adding use-case context. No filler words, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward search operation with 4 documented params at 100% schema coverage and no output schema. The description explains the return limit and pre-processing (ANSI stripping), which covers the main expectations. It does not fully spell out return format or match content, but that is not necessary given the schema and the nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description references 'limit' explicitly and adds the ANSI-stripped detail, but it does not add further meaning beyond what the schema already documents for parameters like regex or caseSensitive. It provides an adequate but not enriched view.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search'), a clear resource ('Homebridge log'), and defines the result scope (matching lines, limited, ANSI-stripped). It is clearly distinct from sibling get_recent_logs because searching implies pattern matching rather than simple retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for finding errors, warnings, or events involving a specific device' gives practical scenarios, but it does not explicitly contrast with siblings like get_recent_logs or define when not to use this tool. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the npm registry for Homebridge plugins matching a query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g. 'hue', 'camera', 'thermostat') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states behavior as searching; lacks disclosure on rate limits, authentication, error handling, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no wasted words. Front-loaded with verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain return values, pagination, or error conditions. It does not, leaving the agent without essential information for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the query parameter. The description adds no extra meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Search', resource 'npm registry for Homebridge plugins', and condition 'matching a query'. It effectively differentiates from sibling tools like list_plugins and lookup_plugin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings (e.g., list_plugins, lookup_plugin). Does not mention prerequisites, expected input types, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control a Homebridge accessory — turn it on/off, set brightness, color temperature, etc. Use list_accessories first to find the uniqueId and available characteristicTypes.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The value to set (e.g. true/false for On, 0-100 for Brightness) | |
| uniqueId | Yes | The unique identifier of the accessory | |
| characteristicType | Yes | The characteristic to set (e.g. 'On', 'Brightness', 'ColorTemperature', 'Hue', 'Saturation', 'TargetTemperature', 'TargetDoorState') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that this is a mutating control action and gives representative effects, but it does not mention error behavior, persistence, reversibility, or side effects beyond the value change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first states the main function and examples, the second gives the critical prerequisite. Every sentence earns its place, with no filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, it adequately explains how to obtain inputs and what to set. It does not describe the return value or failure cases, leaving some operational context unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a meaningful description. The tool description adds no new parameter semantics beyond reinforcing the characteristicType examples, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Control') with a specific resource ('Homebridge accessory') and lists concrete example operations (on/off, brightness, color temperature). It is easily distinguished from sibling get_accessory and listing tools, so an agent can identify when to use it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit prerequisite and tells the agent exactly what to look up first: uniqueId and characteristicTypes via list_accessories. It does not explicitly state exclusions or when to prefer get_accessory for reads, so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the Homebridge config.json file. You must provide the FULL config object — it replaces the entire file. Use get_config first to read the current config, then modify and pass back the complete object.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | The complete config.json object to write |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description discloses that the tool replaces the entire config file, implying destructive behavior. It does not mention authentication or rate limits, but given the context, the key behavioral trait is communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The purpose is front-loaded, and the important usage instruction follows immediately. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that replaces an entire config file, the description adequately covers the input requirement and the need to read first. No output schema is present, but a return value is not critical. Could be slightly more complete by mentioning that the operation is irreversible, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described as 'The complete config.json object to write'. The description adds critical context: 'You must provide the FULL config object — it replaces the entire file', emphasizing the requirement for completeness beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'Homebridge config.json file'. It distinguishes from sibling tools like get_config, which is a read operation, and other siblings that deal with accessories or plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions: 'You must provide the FULL config object — it replaces the entire file. Use get_config first to read the current config, then modify and pass back the complete object.' This tells when to use it and mentions the prerequisite sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.0get_recent_logssearch_logsset_accessory2 fields changedInput schema / properties / value / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "number"
- },
- {
- "type": "boolean"
- }
-]Input schema / properties / value / typeAdded value: +[
+ "string",
+ "number",
+ "boolean"
+]v1.0.5get_accessoryget_accessory_layoutget_cached_accessoriesget_configget_homebridge_statusget_pairing_infoget_plugin_changelogget_plugin_config_schemaget_plugin_versionsget_server_statusget_system_infolist_accessorieslist_pluginslookup_pluginremove_cached_accessoryreset_cached_accessoriesrestart_homebridgesearch_pluginsset_accessoryupdate_configScored across 22 tools
Each tool targets a distinct aspect of Homebridge management: accessories (list/get/set/layout/cached), server status, logs, config, plugins, and system info. Even similar-sounding tools like get_homebridge_status and get_server_status have clear differences in their descriptions—one focuses on health and plugin status, the other on version and instance details—so there is no ambiguity.
All tool names follow a consistent verb_noun pattern using snake_case: get_, set_, list_, search_, remove_, reset_, update_, restart_, lookup_. The same verbs are reused predictably across domains (e.g., get_accessory, get_cached_accessory, get_plugin_versions), which makes it easy to infer tool behavior from the name alone.
With 22 tools, the server is on the heavier side, but it covers a wide range of domains—accessory control, configuration, plugins, logs, status, and system info—all relevant to Homebridge. Each tool has a distinct role, and the count feels justified given the breadth of functionality, though it could be trimmed slightly without losing critical functionality.
The tool set is remarkably complete for the Homebridge domain: it covers accessory discovery and control, cached accessory management, config reading and writing, plugin discovery/search/details/versions/schema/changelog, log retrieval and search, server and system status, restart, and pairing info. There are no obvious dead ends—agents can perform full lifecycle operations on accessories, plugins, and configuration.
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
An MCP server that integrates with Discord to provide AI-powered features.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server for AI dialogue using various LLM models via AceDataCloud
