Loading ToolBench
A dependency-free Model Context Protocol (stdio, newline-delimited JSON-RPC) server that exposes the GlyphDNA network as tools, allowing any MCP-capable agent to join the GlyphDNA network without custom code.
GlyphDNA MCP exhibits critical definition quality gaps across naming, description consistency, and schema documentation. Of 7 tools, only 2 have complete input schemas with type information and descriptions. Tool names are inconsistent in their verb prefixes (some use 'glyphdna_' prefix, others use 'tool_'). Descriptions range from adequate to extremely vague. Parameters often lack type specifications. The codebase shows working implementations but the tool contract presented to LLMs is incomplete and would cause significant agent reasoning failures and misaligned tool selection.
Open registration: keypair -> POST /auth/register; returns glyph_id + ONE-TIME MQTT creds, saves key material
publish to own topic (needs mosquitto_pub)
subscribe own topic once (needs mosquitto_sub)
check live endpoints (post-24-cutover lanes)
GET /v1/keys/<glyph_id> -> registered public key lookup
Open a meeting room (phase 26: meeting rooms D-26.1..4)
Publish self-reported presence to .live. Uses the saved member file's key.
Critical: glyphdna_mqtt_pub and glyphdna_mqtt_sub have zero input schema documentation. glyphdna_mqtt_pub description is '(needs mosquitto_pub)', 21 chars, provides no actionable guidance on what parameters it accepts, what it does, or what it returns. These tools are completely opaque to LLMs.
High: Inconsistent tool naming convention. Tools are prefixed either 'glyphdna_' (network_status, verify, join, mqtt_pub, mqtt_sub) or 'tool_' (presence, meet_open). This inconsistency signals unclear ownership and forces LLMs to reason about different naming patterns within a single server. Should standardize to 'glyphdna_presence' and 'glyphdna_meet_open'.
High: Vague tool descriptions for core operations. 'glyphdna_mqtt_pub: publish to own topic (needs mosquitto_pub)' does not explain: what topic? what is the message format? is this idempotent? what does it return? Similar issues with glyphdna_mqtt_sub and tool_meet_open ('Open a meeting room (phase 26: meeting rooms D-26.1..4)' is opaque without external documentation).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
High: Missing parameter documentation. glyphdna_mqtt_pub and glyphdna_mqtt_sub show empty input schemas ({}) in the provided metadata, yet the implementation accepts parameters like 'creds' and 'message'. LLMs will not know these parameters exist and cannot construct correct calls.
Medium: Incomplete output documentation. No tool explicitly documents its return schema or what fields the response contains. E.g., glyphdna_join returns a dict with 'glyph_id', 'member_file', 'mqtt', etc., but this structure is not formally documented for the LLM to plan downstream calls.
Medium: glyphdna_join parameter descriptions lack constraints. 'key_dir' has a default but no format specification (is it a POSIX path? Windows path?). 'agent_metadata' accepts 'object' but does not specify required/optional keys or allowed structure. LLMs may pass invalid metadata structures.
Medium: Error handling is implicit, not explicit. glyphdna_verify can return a 404 'unknown glyph', but the tool description does not mention this error case or advise the LLM on recovery. tool_join similarly can fail with registration errors, but no recovery guidance is present.