Skip to main content
Glama

OBSOLETE — renamed to help.explainConfigKey

demo.explainConfigKey

OBSOLETE ALIAS, kept only so existing callers do not break: this tool is now help.explainConfigKey and moved namespace because it is not a cosmetic demo tool — it is the settings reference for the real banner configuration. It still works and returns exactly the same answer. Call help.explainConfigKey instead; this name will be retired.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNoOne key to explain. Accepts a bare name (`blocking`, `bodyText`, `bannerBackground`) or a dotted path exactly as the preview tools take it (`config.blocking`, `config.regulations.gdpr`, `design.primaryColor`, `text.bodyText`, `consentConfig.*`). Every match is returned when a bare name exists in more than one vocabulary.
listNoEnumerate a whole vocabulary instead of explaining one key: `config` (the 69 BannerConfigJSON settings, each with its tier and consequence), `regulations`, `consentConfig`, `design`, `text`, `snippet` (the huOptions keys that go in the page, including `blocking`), or `all`. Use this to find out WHICH setting does what you want before naming one — start with `config` for anything about consent categories, geolocation, consent mode or GPC.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / key / description
      Previous value: -"A huOptions.design.* or huOptions.text.en.* key to explain."New value: +"One key to explain. Accepts a bare name (`blocking`, `bodyText`, `bannerBackground`) or a dotted path exactly as the preview tools take it (`config.blocking`, `config.regulations.gdpr`, `design.primaryColor`, `text.bodyText`, `consentConfig.*`). Every match is returned when a bare name exists in more than one vocabulary."
    • addedInput schema / properties / list
      Added value: +{
      +  "description": "Enumerate a whole vocabulary instead of explaining one key: `config` (the 69 BannerConfigJSON settings, each with its tier and consequence), `regulations`, `consentConfig`, `design`, `text`, `snippet` (the huOptions keys that go in the page, including `blocking`), or `all`. Use this to find out WHICH setting does what you want before naming one — start with `config` for anything about consent categories, geolocation, consent mode or GPC.",
      +  "enum": [
      +    "config",
      +    "regulations",
      +    "consentConfig",
      +    "design",
      +    "text",
      +    "snippet",
      +    "all"
      +  ],
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "key"
      -]
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the transparency burden and does add useful behavioral context: it still works, returns exactly the same answer, and is not a cosmetic tool but the settings reference. It does not explicitly state the operation is read-only or side-effect-free, but the help/reference nature plus deprecation notice makes the behavior clear enough.

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

Conciseness5/5

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

The message is front-loaded with OBSOLETE ALIAS and uses three short sentences to convey deprecation, continued behavior, and the required replacement. Every sentence earns its place and no extraneous details are present.

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?

For an obsolete alias, the description is complete: it explains why the tool exists, what behavior to expect, which sibling to call instead, and that the name will be retired. The schema fully covers the parameters, so no additional return or format details are needed for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100% and the schema already documents key (bare names, dotted paths, multi-match behavior) and list (vocabularies, hint to start with config) in rich detail. The tool description itself adds no parameter-level meaning, so the baseline 3 applies.

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 immediately identifies the tool as an OBSOLETE ALIAS and states it is now help.explainConfigKey, the settings reference for the real banner configuration. It distinguishes it from the demo sibling tools by explicitly saying it is not a cosmetic demo tool. For an alias, this states its purpose completely.

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 gives an explicit when-not-to-use directive: call help.explainConfigKey instead and notes this name will be retired. It also explains the only reason to keep it (existing callers who need backward compatibility), so an agent knows never to select this name for new calls.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources