Skip to main content
Glama
SVerITG

Metis

by SVerITG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Metis — Verify Install

verify_install

Checks that Metis and its connected AI apps, database, dashboard, and scheduled tasks are set up correctly, then repairs what it can. Use it when something stops working or after an update.

Instructions

Check everything Metis needs on this computer, and repair what can be repaired.

The install doctor — the same check the installers run and schedule daily —
over the list in system/install/essentials.json: computer, Metis's
programs, every AI app it connects to and whether Metis starts from that
app's own settings, the dashboard and its scans, the scheduled tasks, and
the data. With fix=True (default) it reinstalls broken or outdated tools,
reconnects apps (merging, never replacing their other connectors), adds
missing database tables, downloads the search model, starts the dashboard
and re-creates missing scheduled tasks — then checks again.

Use when the person says something is not working, after an update, or when
they ask whether everything is set up. Tell them the result in plain words;
if an app was reconnected, they must quit it completely (Claude Desktop:
also from the tray) and open it again.

Input Schema

NameRequiredDescriptionDefault
fixNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.6

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the checklist source (system/install/essentials.json) and exactly what fix=True mutates — reinstalls, app reconnects with merge-not-replace semantics, DB table creation, model download, dashboard start, task re-creation — then a re-check. The merge guarantee and the required app restart are non-obvious behavioral facts an agent could not get anywhere else.

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?

Front-loaded with the one-line purpose, then scope, then fix behavior, then usage. Dense but every clause carries information; the enumeration is long yet each item is a distinct thing being verified.

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?

An output schema exists, so return values needn't be explained, and the mutation surface is well covered for an un-annotated tool. The remaining gap is relational: nothing distinguishes it from metis_doctor, which a sibling-aware agent would want.

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

Parameters4/5

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

Schema coverage is 0% and the single parameter has no description in the schema, so the description must compensate. It explains fix=True (default) in detail and implies fix=False is check-only via 'repair what can be repaired', but never states that mode explicitly, leaving a small gap.

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

Purpose4/5

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

States a concrete verb pair (check/repair) and a concrete resource (everything Metis needs on this computer), and enumerates what is covered: programs, connected AI apps, dashboard, scheduled tasks, data. It never names the obvious sibling (metis_doctor) or explains how this differs from it, so differentiation is left to inference.

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?

Gives real trigger conditions: the person says something isn't working, after an update, or when asked whether everything is set up. It also tells the agent what to do afterward (plain words, quit the app fully after a reconnect). It stops short of exclusions or naming alternatives such as metis_doctor.

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

Deploy Server

Other Tools