Skip to main content
Glama
dreamforgestudiollc

EMET

by dreamforgestudiollc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

emet_status

Idempotent

Diagnostic in one call (replaces emet_setup_status, get_status and emet_verify_connection, 2026-09-27). Reports environment, database, collections, vector index, whether identity and user documents exist, and per-layer counts and health.

Instructions

Diagnostic in one call (replaces emet_setup_status, get_status and emet_verify_connection, 2026-09-27). Reports environment, database, collections, vector index, whether identity and user documents exist, and per-layer counts and health. Pass probe: true to also prove the write path - connect, write a probe document, read the same value back, remove it; a read alone cannot reveal a broken write path. Prefer emet_initialize for a normal session start.

Input Schema

NameRequiredDescriptionDefault
probeNoAlso write and read back a probe document (default false). Use after a deploy or a configuration change.
sourceNoYour own source tag. The status then reports the tag your writes will carry and its approval state.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.5
    • addedInput schema / properties / source
      Added value: +{
+  "description": "Your own source tag. The status then reports the tag your writes will carry and its approval state.",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, but the description goes further by disclosing the exact write-path sequence (connect, write, read back, remove) and why it matters ('a read alone cannot reveal a broken write path'). It still doesn't say what permissions the probe requires or whether it leaves residue on failure.

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-loads the purpose and the tool-replacement note, then the probe semantics, then the routing hint. Slightly dense – the '(replaces ... 2026-09-27)' parenthetical is historical trivia – but every other clause earns its place.

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

Completeness4/5

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

With no output schema, the description compensates by enumerating the reported sections, which is enough for an agent to know what to expect. It stops short of describing the response shape or pagination/format details, but for a diagnostic tool that is a minor gap.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains the probe's rationale (proving the write path) and that 'source' causes the report to echo the tag your writes will carry plus its approval state. That is more than the schema's terse field descriptions.

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

Purpose5/5

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

The description states a specific verb+resource (diagnostic status of the store) and enumerates exactly what is reported: environment, database, collections, vector index, identity/user documents, per-layer counts and health. It also names the three tools it replaces, so an agent can confidently distinguish it from siblings like emet_setup_complete or emet_initialize.

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

Usage Guidelines5/5

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

It explicitly routes the agent: 'Prefer emet_initialize for a normal session start,' and the probe flag is scoped to 'after a deploy or a configuration change.' Both the when and the when-not are stated, with the alternative named.

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