ariadne
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| query_chainsA | Query cross-service chains by business term or endpoint name. Returns candidate clusters of related GraphQL operations, HTTP endpoints, Kafka topics, and frontend queries across all services indexed by the local Ariadne DB. Use this when you need to understand which APIs, topics, or frontend operations are involved in a business feature. |
| expand_nodeA | One-hop neighbours of a known node (endpoint / Kafka topic / GraphQL operation / frontend call), with similarity scores and file paths. Read-only; no writes except a local exploration row if called within 10 min of a matching query_chains. Returns up to 3 matched source nodes × up to 10 neighbours (edges with score ≥ 0.08), plus a Use AFTER query_chains when you already have a concrete node name and want to trace one hop further. Use query_chains (not this) when starting from a business term or when you don't yet know a node name. Partial, case-insensitive match against node id and raw_name; ambiguous inputs return multiple source groups. |
| show_helpA | Return a quick setup and usage guide for Ariadne. Call this first when you are unsure how to use Ariadne, how to index your own microservices, or why query_chains returned no results. Always safe to call — no DB required. |
| rescanA | Refresh the Ariadne index from inside the conversation. Call this when query_chains or expand_node returned a |
| rate_resultA | Record whether Ariadne results were useful. Call this after using query_chains or expand_node to log feedback for future improvement. If node_ids is omitted after a recent query_chains call, Ariadne infers node_ids from hint + cluster_rank. Feedback is stored locally in feedback.db and survives DB rebuilds. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: query_chains for discovery from a business term, expand_node for one-hop traversal from a known node, rescan for index refresh, rate_result for feedback, and show_help for guidance. The descriptions explicitly disambiguate the closest pair (query_chains vs expand_node) by stating when to use each. No two tools overlap in function.
Four of five names follow a clear verb_noun pattern (expand_node, query_chains, rate_result, show_help). The lone 'rescan' is a bare verb without a noun object, a minor deviation that stays readable and consistent in style. Overall predictable and snake_case throughout.
Five tools is well-scoped for a code-relationship exploration server, covering discovery, traversal, maintenance, feedback, and help. Each tool earns its place with no redundant or filler entries. The surface is focused rather than bloated.
The lifecycle is well covered: discovery (query_chains), traversal (expand_node), freshness (rescan), and feedback (rate_result) plus onboarding help. Minor gaps exist — e.g. no way to list indexed repos or enumerating all nodes — but core workflows are supported. A read-only exploration domain reasonably needs no create/update/delete operations.