Skip to main content
Glama

fileforge_memory_action

Save and track web pages to find earlier visits, diff changes, and search saved pages for evidence. Use it to see what changed on a page.

Instructions

Remember pages over time: save a page, find earlier visits, diff it against a previous visit, and search saved pages or pull evidence for a question. Use this to see what changed on a page. Use fileforge_result_action to read tool results and fileforge_search_action to search history. Data stays in ~/.fileforge. save_page and diff_page need the extension.

Input Schema

NameRequiredDescriptionDefault
refNoRef of a stored result.
urlNoURL to look up in saved pages.
limitNoMaximum items to return.
queryNoSearch text.
storeNoSave the result in ~/.fileforge and return a ref.
tabIdNoTab ID, or "active" for the active tab.active
actionYesWhat to do. Required parameters are in brackets. save_page: Save the text of a tab's page to local memory. query (query): Search saved pages by keyword. semantic_search (query): Run the same keyword search as query. Embeddings are not configured. answer (question): Return saved pages relevant to a question as evidence. It doesn't write an answer. find_previous_visit (url): Find the saved copy of a URL. diff_page: Compare a tab's text with a stored result (ref) or the page's saved copy. Stores the diff by default. compact_result (ref): Summarize a stored result. get_result_slice (ref): Read part of a stored result using offset and limit.
offsetNoItems to skip, for paging.
projectNoProject name that groups stored results.default
questionNoQuestion to answer from saved pages.

Output Schema

NameRequiredDescriptionDefault
okYesFalse if the action failed or a check did not pass.
refNoStored result ID, for fileforge_result_action.
dataNoThe result. Its shape depends on the action.
metaNoTool, action and context.
errorNoFailure code and message.
warningsNoNotes about a call that still ran.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.3.0
    • changedInput schema / properties / action / description
      Previous value: -"The memory action to perform."New value: +"What to do. Required parameters are in brackets. save_page: Save the text of a tab's page to local memory. query (query): Search saved pages by keyword. semantic_search (query): Run the same keyword search as query. Embeddings are not configured. answer (question): Return saved pages relevant to a question as evidence. It doesn't write an answer. find_previous_visit (url): Find the saved copy of a URL. diff_page: Compare a tab's text with a stored result (ref) or the page's saved copy. Stores the diff by default. compact_result (ref): Summarize a stored result. get_result_slice (ref): Read part of a stored result using offset and limit."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum items to return."
    • addedInput schema / properties / offset / description
      Added value: +"Items to skip, for paging."
    • addedInput schema / properties / project / description
      Added value: +"Project name that groups stored results."
    • addedInput schema / properties / query / description
      Added value: +"Search text."
    • addedInput schema / properties / question / description
      Added value: +"Question to answer from saved pages."
    • addedInput schema / properties / ref / description
      Added value: +"Ref of a stored result."
    • addedInput schema / properties / store / description
      Added value: +"Save the result in ~/.fileforge and return a ref."
    • addedInput schema / properties / tabId / description
      Added value: +"Tab ID, or \"active\" for the active tab."
    • addedInput schema / properties / url / description
      Added value: +"URL to look up in saved pages."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "description": "query_* actions return their modules as extra top-level fields.",
      +  "properties": {
      +    "data": {
      +      "description": "The result. Its shape depends on the action."
      +    },
      +    "error": {
      +      "description": "Failure code and message."
      +    },
      +    "meta": {
      +      "description": "Tool, action and context."
      +    },
      +    "ok": {
      +      "description": "False if the action failed or a check did not pass.",
      +      "type": "boolean"
      +    },
      +    "ref": {
      +      "description": "Stored result ID, for fileforge_result_action."
      +    },
      +    "warnings": {
      +      "description": "Notes about a call that still ran."
      +    }
      +  },
      +  "required": [
      +    "ok"
      +  ],
      +  "type": "object"
      +}
  2. First observedv0.2.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-destructive, open-world behavior, so the bar is lower, yet the description still adds real context: data persists in ~/.fileforge and save_page/diff_page require the extension installed. It does not spell out the disk-write side effect of save_page or what store=false disables, but the location and prerequisite disclosures are meaningful beyond the annotations.

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?

Purpose is front-loaded in the first clause and each subsequent sentence adds a distinct fact (change detection, sibling routing, storage location, extension prerequisite). It is dense and slightly run-on, but there is no filler.

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?

With 10 parameters, an output schema, and full annotation coverage, the description covers purpose, alternatives, persistence location, and the extension prerequisite. The gaps are minor: behavior when store=false and the fact that save_page mutates local memory are left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the action enum description already spells out per-action required parameters, so the description need not duplicate that. The extra sentence about the extension being needed for save_page and diff_page adds a small amount of action-level meaning, but nothing about ref/offset/limit/store semantics is contributed here.

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?

The opening sentence names a specific verb set and resource ('Remember pages over time: save a page, find earlier visits, diff it...') and enumerates the capabilities an agent would care about. It also names two siblings it is not (fileforge_result_action, fileforge_search_action), so the tool is distinguishable without opening the schema.

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?

'Use this to see what changed on a page' gives the core selection rationale, and 'Use fileforge_result_action to read tool results and fileforge_search_action to search history' routes the agent to the right alternatives with conditions. It stops short of saying when NOT to use this tool (e.g. for live page reads), so it is not a full 5.

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