Skip to main content
Glama
flukeatzerocool

holonovel

by flukeatzerocool
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Help and Tool Discovery

help
Read-only

Discover and manage MCP tools: list by category, search by keyword, or reassign a tool's category.

Instructions

Show the available tools grouped by category (badge-filtered) or reassign a tool's category. Use when: the caller needs to discover tools, find one by keyword, or override a tool's category for a session. Do NOT use when: reading the current badge's guidance — use the badge_briefing prompt.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoOptional search term matched against tool name, description, and title.
actionNolist (default) or category (reassign a tool's category).
categoryNoNew category label, or null/empty to restore default (category).
tool_nameNoRegistered tool name to reassign (category).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / action
      Added value: +{
+  "description": "list (default) or category (reassign a tool's category).",
+  "enum": [
+    "list",
+    "category"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / category
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "New category label, or null/empty to restore default (category)."
+}
    • addedInput schema / properties / tool_name
      Added value: +{
+  "description": "Registered tool name to reassign (category).",
+  "type": "string"
+}
  2. First observedv1.0.0

TDQS

A4/5.0
Behavior1/5

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

The annotations declare readOnlyHint: true, but the description includes 'reassign a tool's category', which implies a state-changing mutation. This directly contradicts the read-only annotation and could mislead an agent about side effects. The contradiction is serious enough to warrant the lowest score.

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 description is compact and front-loaded, stating the core action first before adding usage guidance. Every sentence serves a purpose, and there is no redundant or filler content.

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

Completeness3/5

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

The description covers the main behavior and usage boundaries, but it does not describe the output format or the result of a category reassignment. Since there is no output schema, some return-structure details would help complete the picture, though the core invocation context is present.

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

Parameters5/5

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

All four parameters are described in the schema with 100% coverage, including the enum constraint on action. The description adds practical context such as null/empty restoring the default category. No parameter meaning is left unclear.

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 clearly states the tool shows available tools grouped by category or reassigns a tool's category. It also specifies when to use and when not to use it, distinguishing it from badge_briefing. This gives an agent a precise sense of the tool's purpose.

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?

Explicit use cases are provided: discovering tools, finding by keyword, or overriding a category for a session. The description also gives a clear negative case with a pointer to the alternative prompt, leaving no ambiguity about when to invoke this tool.

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