Skip to main content
Glama

TestGraph

by uk.co.21dle.testgraph
OverviewDiscussionsAdmin

Resolve a semantic subject hierarchy

resolve_subject_hierarchy
Idempotent

Use only after bounded root/child traversal provides enough evidence that the specific subject type does not yet exist. Submit the verified existing path plus genuinely missing terms broad-to-specific, for example ['food','recipe']. The server reuses existing dictionary entries, creates only missing provisional nodes in context, adds belongs_to relationships and rejects cycles. Do not include 'review': review is the record type, not a subject category. Semantic placement must be based on meaning, never on which review arrived first. Before creating a new semantic node, distinguish a genuinely different concept from a mere naming variant. Naming variants should reuse identity; genuine meaning differences may remain separate. Classification vocabulary should represent what a subject fundamentally is. Before creating, selecting, relating or proposing a subject type, identify the semantic head and descriptive modifiers. Material, arrangement/grouping, state/condition, quantity, colour, size, location and purpose/use normally belong in attributes or relationships rather than subject-type names. This is not a simplistic head-noun rule: a compound may remain a distinct type when the combined concept has materially different identity, behaviour, relationships, classification meaning or realistic retrieval needs. The server independently validates structural writes, so client guidance cannot bypass this rule.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / version_check
      Removed value: -{
-  "description": "Required live deployment token. Call get_server_info immediately before this write and pass write_version_token unchanged. Stale or missing tokens are rejected before any write occurs.",
-  "maxLength": 64,
-  "minLength": 64,
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "terms",
-  "version_check"
-]New value: +[
+  "terms"
+]
  2. Changed2 schema fields changed
    • addedInput schema / properties / version_check
      Added value: +{
+  "description": "Required live deployment token. Call get_server_info immediately before this write and pass write_version_token unchanged. Stale or missing tokens are rejected before any write occurs.",
+  "maxLength": 64,
+  "minLength": 64,
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "terms"
-]New value: +[
+  "terms",
+  "version_check"
+]
  3. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations (readOnly=false, idempotent=true, destructive=false), the description discloses exactly what is written: existing entries are reused, only missing provisional nodes are created, belongs_to relationships are added, cycles are rejected, and the server independently validates structural writes. That is unusually rich side-effect disclosure for a mutation 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?

It is front-loaded correctly (gating condition, then invocation, then behavior), but roughly half the text is extended semantic policy about head nouns, modifiers, and naming variants that reads as server documentation rather than invocation guidance. Useful, but repetitive and longer than the one-parameter call requires.

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 semantic-write tool with no output schema and an undocumented parameter, the description covers the call contract, ordering, exclusions, and write semantics thoroughly. What is missing is the response shape and the terms-length limit, which an agent would otherwise have to discover by trial.

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 0% and the single `terms` array has no field description, so the description carries the burden. It explains the content and ordering (verified existing path plus genuinely missing terms, broad-to-specific, with the ['food','recipe'] example), though it never states the schema's 8-item cap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action on a specific resource: submitting an ordered path of terms so the server reuses existing dictionary entries and creates only missing provisional subject nodes with belongs_to relationships. It is clearly not the same as resolve_subject/resolve_subject_type, though it never names those siblings to sharpen the distinction.

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

Usage Guidelines4/5

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

It gives a hard precondition ('Use only after bounded root/child traversal provides enough evidence that the specific subject type does not yet exist') and an explicit exclusion ('Do not include review'). It does not name the alternative sibling tools an agent should consider first, so routing is implied by phrase rather than by tool name.

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

All TestGraph toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources