Skip to main content
Glama

fileforge_app_action

Read-only

Inspect an open web app tab to detect its framework and read routes, Next.js data, client storage, feature flags, and React tree hints for understanding how the app is built.

Instructions

Inspect a web app in an open tab: detect its framework, and read routes, Next.js data, client storage, feature flags and React tree hints. Use this to understand how an app is built. Use fileforge_coding_action for a full bundle. Read-only, but get_client_storage returns raw localStorage and sessionStorage values, which can include tokens. Needs the extension.

Input Schema

NameRequiredDescriptionDefault
tabIdNoTab ID, or "active" for the active tab.active
actionYesWhat to do. Required parameters are in brackets. detect_framework: Detect the frontend framework used by the page (React, Vue, Next.js, etc.). get_next_data: Extract Next.js __NEXT_DATA__ and server-side props. get_route_info: Get current route information from the SPA router. get_client_storage: Get localStorage, sessionStorage, and accessible cookies. get_feature_flags: Detect feature flags exposed in the page (LaunchDarkly, GrowthBook, etc.). get_react_tree_hint: Get a React component tree hint from the page.
includeStateHintsNoInclude hints about client state.

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. Changed4 schema fields changedv0.3.0
    • changedInput schema / properties / action / description
      Previous value: -"The action to perform. Available actions: detect_framework: Detect the frontend framework used by the page (React, Vue, Next.js, etc.). get_next_data: Extract Next.js __NEXT_DATA__ and server-side props. get_route_info: Get current route information from the SPA router. get_client_storage: Get localStorage, sessionStorage, and accessible cookies. get_feature_flags: Detect feature flags exposed in the page (LaunchDarkly, GrowthBook, etc.). get_react_tree_hint: Get a React component tree hint from the page."New value: +"What to do. Required parameters are in brackets. detect_framework: Detect the frontend framework used by the page (React, Vue, Next.js, etc.). get_next_data: Extract Next.js __NEXT_DATA__ and server-side props. get_route_info: Get current route information from the SPA router. get_client_storage: Get localStorage, sessionStorage, and accessible cookies. get_feature_flags: Detect feature flags exposed in the page (LaunchDarkly, GrowthBook, etc.). get_react_tree_hint: Get a React component tree hint from the page."
    • addedInput schema / properties / includeStateHints / description
      Added value: +"Include hints about client state."
    • addedInput schema / properties / tabId / description
      Added value: +"Tab ID, or \"active\" for the active tab."
    • 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.3/5.0
Behavior5/5

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

Beyond the annotations' readOnly/destructive flags, the description warns that get_client_storage returns raw localStorage and sessionStorage values that can include tokens, which is exactly the kind of sub-action-specific safety caveat an agent needs before dispatching. It also discloses the prerequisite "Needs the extension," a dependency the annotations do not carry.

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?

Three tight sentences: scope first, disambiguation second, safety and prerequisite last. No filler, and the risk warning is placed where it will still be read before invocation.

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 six-mode dispatcher with a full input schema and an output schema, the description covers the remaining gaps an agent needs: what the tool is for, the sibling to use instead, the extension dependency, and the sensitive-data caveat. Return-value details are correctly left to the output schema.

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 already documents each of the six modes in detail, so the description correctly relies on the schema. It adds only a hazard note tied to one enum value (get_client_storage) and says nothing extra about tabId or includeStateHints.

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?

"Inspect a web app in an open tab" is a specific verb+resource, and the sentence enumerates the six readable artifacts (framework, routes, Next.js data, client storage, feature flags, React tree hints). It explicitly rules out fileforge_coding_action for the full-bundle case, but it does not distinguish itself from other plausibly overlapping siblings such as fileforge_devtools_action or fileforge_runtime_action.

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 understand how an app is built" gives a clear triggering context, and "Use fileforge_coding_action for a full bundle" names an alternative with the condition that selects it. It stops short of explicit when-not guidance (e.g., when to prefer devtools/runtime instead).

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