Skip to main content
Glama
Sign In
epsilongraph

epsilongraph

by silverenternal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

vault_skeleton

Load every vault rule and typed relation without note bodies, giving agents a session-sized graph overview instead of repeated searches.

Instructions

Every rule and every typed relation in the vault, with no bodies (~29k tokens here, 18% of the corpus). Small enough to hold for a whole session, which is usually better than repeated searching.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "vault_skeleton"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

No annotations, so the description carries the full burden. It discloses token cost (~29k, 18% of corpus) and behavioral scope (no bodies) — genuinely useful context for planning whether to hold it in context. It doesn't disclose auth or freshness/caching behavior.

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?

Two sentences, front-loaded with the scope and followed by the usage rationale. Every clause earns its place — token count and corpus percentage are concretely useful.

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?

Given zero params, no annotations, and no output schema, the description does a good job of framing scope and cost tradeoffs. Could be stronger by stating what the agent is expected to do with the skeleton next (e.g., pair with vault_get for bodies).

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?

Zero parameters, so the baseline is 4. The description correctly implies the parameterless nature by framing it as a whole-vault view.

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?

States a specific resource ('every rule and every typed relation in the vault') with scope exclusions ('with no bodies'). Without named siblings, it doesn't explicitly distinguish itself from vault_load_bearing or vault_gaps, but the scope wording implies a complete-but-shallow view.

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?

Explicitly gives guidance: 'Small enough to hold for a whole session, which is usually better than repeated searching.' This steers the agent to prefer skeleton over vault_search for session-wide holds. It doesn't name which sibling to use when bodies ARE needed, which is a minor gap.

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