Skip to main content
Glama
kyle641320

TMF (True Memory Fragments)

by kyle641320
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

tmf_fragment

Traverse indexed code relationships from a claim ID to inspect cross-file effects before changes. Returns verified hops, gaps, and stop reasons.

Instructions

Explore indexed code relationships around a known claim before a cross-file change. Get entry from tmf_context or tmf_retrieve; it is a claim ID, not a path or symbol name. Returns verified_hops, boundaries, gaps, stale_or_unknown, stop_reason and coverage. Start with relations=["calls"], hop_limit=1, boundary_types=["function"], semantic_boundaries=false. Inspect gaps and stop_reason before expanding: missing or stale entries return no verified hops; unsupported relations or invalid bounds raise an error. Re-read source for stale/unknown evidence and use tmf_stale_slice for a stale claim. This does not return a complete dependency graph, modify source, or refresh source-derived claims. For full claim details use tmf_explain(full=true). Source is authoritative; fresh does not mean correct.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entryYesStored claim ID from tmf_context or tmf_retrieve. Paths and qualified symbol names are not accepted as IDs.
hop_limitYesRequired traversal depth, 0–4. Use 1 initially; 0 returns the entry without traversing edges.
max_edgesNoMaximum returned edges, 1–128; default 128. Reaching the cap is reported in stop_reason.
max_nodesNoMaximum visited nodes including entry, 1–64; default 64. Reaching the cap is reported in stop_reason; this is not a character/token budget.
relationsYesNonempty relationship kinds to traverse in either endpoint direction: calls, reads, writes, inherits, overrides, uses_type, reads_env, reads_config_key, injects, publishes_to, subscribes_to, publishes_type, listens_type. Start with only the kinds needed for the task.
boundary_typesYesNonempty list of claim scopes at which to stop expanding when semantic_boundaries=false, e.g. function, declaration, class or topic. Ignored when semantic_boundaries=true.
semantic_boundariesNoDefault true: stop expansion at indexed side-effect boundaries such as writes or publishes_to. Set false to use boundary_types instead. This is not complete runtime or annotation analysis.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.1
    • addedInput schema / properties / boundary_types / description
      Added value: +"Nonempty list of claim scopes at which to stop expanding when semantic_boundaries=false, e.g. function, declaration, class or topic. Ignored when semantic_boundaries=true."
    • addedInput schema / properties / entry / description
      Added value: +"Stored claim ID from tmf_context or tmf_retrieve. Paths and qualified symbol names are not accepted as IDs."
    • addedInput schema / properties / hop_limit / description
      Added value: +"Required traversal depth, 0–4. Use 1 initially; 0 returns the entry without traversing edges."
    • addedInput schema / properties / max_edges / description
      Added value: +"Maximum returned edges, 1–128; default 128. Reaching the cap is reported in stop_reason."
    • addedInput schema / properties / max_nodes / description
      Added value: +"Maximum visited nodes including entry, 1–64; default 64. Reaching the cap is reported in stop_reason; this is not a character/token budget."
    • addedInput schema / properties / relations / description
      Added value: +"Nonempty relationship kinds to traverse in either endpoint direction: calls, reads, writes, inherits, overrides, uses_type, reads_env, reads_config_key, injects, publishes_to, subscribes_to, publishes_type, listens_type. Start with only the kinds needed for the task."
    • addedInput schema / properties / semantic_boundaries / description
      Added value: +"Default true: stop expansion at indexed side-effect boundaries such as writes or publishes_to. Set false to use boundary_types instead. This is not complete runtime or annotation analysis."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it enumerates the return fields, states that missing/stale entries return no verified hops, that unsupported relations or invalid bounds raise an error, that it will not modify source or refresh derived claims, and warns 'fresh does not mean correct.'

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: purpose, entry source, return fields, recommended config, error behavior, and non-goals are ordered sensibly. Slightly verbose for a description, but every sentence carries distinct operational information.

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

Completeness5/5

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

For a 7-parameter traversal tool with no output schema, the description compensates by naming the returned fields (verified_hops, boundaries, gaps, stale_or_unknown, stop_reason, coverage) and by covering error and staleness behavior, so an agent has what it needs to invoke and interpret it.

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 description coverage is 100%, so the schema already documents each parameter; the baseline is 3. The description adds value by prescribing which parameter values to start with and by clarifying entry semantics beyond the schema, earning a bump.

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?

States a specific verb+resource: 'Explore indexed code relationships around a known claim before a cross-file change.' It explicitly contrasts with sibling and non-goal behavior ('This does not return a complete dependency graph'), letting an agent place it against tmf_callers/tmf_readers/tmf_subtypes.

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?

Gives explicit preconditions ('Get entry from tmf_context or tmf_retrieve; it is a claim ID, not a path or symbol name'), recommended initial call shape (relations=["calls"], hop_limit=1, boundary_types=["function"], semantic_boundaries=false), and routes to alternatives (tmf_stale_slice for stale claims, tmf_explain(full=true) for full details).

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