Skip to main content
Glama
dreamforgestudiollc

EMET

by dreamforgestudiollc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

emet_floor

Read-onlyIdempotent

Read the floor: the standing description of how this assistant engages with the person using it. It ships in the server code, so setup cannot overwrite it and no install can lose it - the character document holds the user's modifiers on…

Instructions

Read the floor: the standing description of how this assistant engages with the person using it. It ships in the server code, so setup cannot overwrite it and no install can lose it - the character document holds the user's modifiers on top of it. emet_initialize already returns the whole floor at session start; call this to read it again without re-running initialize. Use compact: true for the short form partway through a long session, when the start of the conversation is far behind. Pass gem to read one installed GEM's floor; reading does not turn that GEM on. Read-only, and re-reading is not the same as being bound by it.

Input Schema

NameRequiredDescriptionDefault
gemNoRead one installed GEM's floor by id, for example 'neurendipity'. Reading does not turn the GEM on. Omit it to read the core floor.
compactNoReturn the short re-assertion form instead of the whole floor.
sectionNoReturn one section only, e.g. 'voice'. Call with no arguments to see the section names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.5
    • addedInput schema / properties / gem
      Added value: +{
+  "description": "Read one installed GEM's floor by id, for example 'neurendipity'. Reading does not turn the GEM on. Omit it to read the core floor.",
+  "type": "string"
+}
    • changedInput schema / properties / section / description
      Previous value: -"Return one section only, e.g. 'neurodivergent_support'. Call with no arguments to see the section names."New value: +"Return one section only, e.g. 'voice'. Call with no arguments to see the section names."
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds non-obvious context: the floor ships in server code so setup cannot overwrite it, and 're-reading is not the same as being bound by it' clarifies a semantic effect no annotation covers.

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 core purpose before any caveats, and no sentence is filler. It is somewhat dense and long for a read-only getter, but each clause (immutability, initialize overlap, compact, gem, read-only framing) carries distinct information.

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

Completeness5/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 must convey what is returned, and it does: the whole floor, the compact short re-assertion, a single section, or one GEM's floor. It also explains how to discover valid section names (call with no arguments), leaving nothing important unstated for a 3-param, all-optional tool.

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 and the schema carries the syntax. The description nonetheless adds usage meaning for two parameters: compact is framed as the short form for late in a long session, and gem is framed as reading one GEM without enabling it. The section parameter is left to the schema, which documents it adequately.

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?

States a specific verb and resource ('Read the floor') and immediately defines the domain-specific noun as 'the standing description of how this assistant engages with the person using it.' It also distinguishes itself from the closest sibling by noting emet_initialize already returns the floor at session start and this re-reads it without re-running 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?

Gives explicit alternatives and conditions: use this instead of re-running emet_initialize, use compact:true when 'the start of the conversation is far behind,' pass gem to read a specific GEM's floor. It also states a boundary ('reading does not turn that GEM on'), so the agent knows what this tool does not do.

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