Skip to main content
Glama
dreamforgestudiollc

EMET

by dreamforgestudiollc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

emet_setup_complete

Destructive

First-time setup, the owner's only: record the user's interview answers as bootstrap/IDENTITY.md, bootstrap/CHARACTER.md and bootstrap/USER.md and as an identity-layer entry, and create the owner person. Every write is read-back verified.

Instructions

First-time setup, the owner's only: record the user's interview answers as bootstrap/IDENTITY.md, bootstrap/CHARACTER.md and bootstrap/USER.md and as an identity-layer entry, and create the owner person. Every write is read-back verified. Refused under a bot tag. On a store that is already set up it is refused unless reissue is true (the owner's explicit word): a re-run writes new versions of the user's identity documents; prior versions are archived, never destroyed. answers.more_than_one_bot is optional. Absent or no leaves sub-keys off. yes writes EMET_SUBKEYS=1, a generated pepper and EMET_SUBKEY_PEPPER_VERSION=1 into .env only when that file is the config source, after the store writes succeed, and does not turn the flag on in this process. A hosted server refuses yes and returns the three variables to set, then redeploy. See docs/SUBKEYS.md. answers.bot_team_backup is optional. Yes or no, in the user's words, the same way as more_than_one_bot. Yes and Yes. record the flag. yes is the recommended choice. Absent or no leaves bot-team backup off. Anything else, including a non-string, is refused before a write. Setup does not copy prompts or settings.

Input Schema

NameRequiredDescriptionDefault
sourceNoYour source tag. Setup is refused under a bot tag.
answersYesAnswers keyed exactly as the interview questions returned by emet_initialize.
reissueNoOnly on the owner's explicit word: re-run setup on a store that is already set up. Without it, a re-run is refused and nothing is written.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.1
    • addedInput schema / properties / answers / properties / bot_team_backup
      Added value: +{
+  "description": "Optional. Yes or no, in the user's words. Yes and Yes. count as yes. yes is the recommended choice and records bot-team backup as on. Absent or no leaves it off. A non-string is refused. Do not invent this answer.",
+  "type": "string"
+}
    • addedInput schema / properties / answers / properties / more_than_one_bot
      Added value: +{
+  "description": "Optional. yes or no, in the user's words. Absent or no leaves sub-keys off. yes turns them on only when this server reads .env. Do not invent this answer.",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: writes are read-back verified, prior identity documents are archived rather than destroyed, .env subkey writes happen only after store writes succeed, and hosted servers refuse subkey activation with remediation steps. This is meaningful operational context for a destructive, non-idempotent setup tool.

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

Conciseness3/5

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

The description is front-loaded and covers necessary complexity, but it is dense and includes awkward fragments such as 'Yes and Yes. record the flag.' and repeated explanations of optional flags. It is informative but not tightly structured.

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

Completeness4/5

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

For a complex mutation tool with no output schema, it covers the critical side effects, refusal conditions, reissue behavior, and environment-file handling. The main remaining gap is that it does not describe what a successful invocation returns.

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 already 100%, and the description adds important meaning for the optional flags, especially more_than_one_bot and bot_team_backup behavior, reissue semantics, and source-tag refusal. Some phrasing is confusing, but it still adds more than the schema alone.

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 action and resource: first-time setup that records interview answers into three bootstrap documents, creates an identity-layer entry, and creates the owner person. It also distinguishes the owner-only scope, making the tool clearly identifiable among siblings.

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

Usage Guidelines5/5

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

It provides explicit when-to-use and when-not-to-use guidance: first-time setup only, owner only, refused under a bot tag, and refused on an already-set-up store unless reissue=true is explicitly authorized. Hosted-server behavior for subkeys is also called out.

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