FileForge

Overview Schema Source Related Servers Discussions Admin

fileforge_a11y_action

Run focused accessibility checks on one page: audit WCAG compliance, read the accessibility tree, test keyboard navigation, and check color contrast without changing the page.

Instructions

Check one page's accessibility: run an audit, read the accessibility tree, and check keyboard navigation and color contrast. Use this for focused accessibility work, and fileforge_audit_action for a wider audit. Doesn't change the page; results can be stored locally. Needs the extension.

Input Schema

Name	Required	Description	Default
`store`	No	Save the result in ~/.fileforge and return a ref.
`tabId`	No	Tab ID, or "active" for the active tab.	active
`action`	Yes	What to do. Required parameters are in brackets. audit: Run an accessibility audit against the active or specified tab. get_tree: Get the accessibility tree for the current page. check_keyboard: Check keyboard navigability. check_contrast: Check color contrast across the page.
`standard`	No	Accessibility standard to check against.	wcag2aa

Output Schema

Name	Required	Description
`ok`	Yes	False if the action failed or a check did not pass.
`ref`	No	Stored result ID, for fileforge_result_action.
`data`	No	The result. Its shape depends on the action.
`meta`	No	Tool, action and context.
`error`	No	Failure code and message.
`warnings`	No	Notes about a call that still ran.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.3.0Nov 5, 2026

changedInput schema / properties / action / description

Previous value: -"The accessibility action to perform."New value: +"What to do. Required parameters are in brackets. audit: Run an accessibility audit against the active or specified tab. get_tree: Get the accessibility tree for the current page. check_keyboard: Check keyboard navigability. check_contrast: Check color contrast across the page."

addedInput schema / properties / standard / description

Added value: +"Accessibility standard to check against."

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."

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"
+}

First observedv0.2.1Nov 5, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare openWorldHint=true, destructiveHint=false and idempotentHint=false; the description adds real value beyond them by stating it "Doesn't change the page" and that results "can be stored locally," which is what explains readOnlyHint=false for an inspection tool. It stops short of describing return shape, per-action latency, or what happens when the extension is missing.

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?

Four short sentences, front-loaded with the core action and followed by the alternative, side effects, and prerequisite. The first sentence partly restates the action enum and the final fragment "Needs the extension." is clipped, but nothing is wasted.

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 an output schema present and full schema coverage, the description needn't explain return values, and it covers purpose, sibling differentiation, side effects, and the extension dependency. What is missing is narrow: behavior on failure (no extension, page without a tabId) and whether the four action modes differ in cost or wait time.

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 every parameter (store, tabId, action, standard) is documented in the schema itself, including the action enum meanings. The description merely aggregates the action names in prose ("run an audit, read the accessibility tree, and check keyboard navigation and color contrast") without adding format, default, or interaction semantics, so baseline 3 applies.

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 concrete verb and resource ("Check one page's accessibility") and enumerates the four concrete sub-operations: audit, accessibility tree, keyboard navigation, color contrast. It also names the sibling it is not (fileforge_audit_action for a wider audit), so an agent can distinguish scope without opening either schema.

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?

Explicitly routes the agent: "Use this for focused accessibility work, and fileforge_audit_action for a wider audit" supplies both the when-to-use condition and the named alternative. It also states the prerequisite ("Needs the extension"), so an agent knows invocation can fail if that dependency is absent.

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