Loading page
About this tool
Lint AI tool-call JSON or JSONL locally against explicit name, path, domain, recipient, numeric-limit and confirmation policies without executing anything.
Tool-Call Argument Policy Linter checks a log of AI agent tool calls against a JSON policy with seven rule types — allowedTools, deniedTools, allowedPathPrefixes, allowedDomains, allowedRecipients, numericLimits and confirmation — and reports each call as a pass, a warning or a violation without executing anything. It is for engineers reviewing what an agent actually tried to do, from an OpenAI-style function-call trace or a JSONL transcript. Findings are labelled by rule, from tool-denied and path-not-allowed through to confirmation-required, and can be exported as a counts-only report that carries no tool names, paths, domains or recipients.
Open Tool-Call Argument Policy Linter on AltFTool — it loads instantly in your browser.
Paste your rules into Policy JSON and the agent trace into Tool-call JSON or JSONL — an array, a wrapped calls array, or one JSON object per line.
Press Lint calls to check up to 500 calls; Load sample fills both boxes with a worked example, and Clear empties them.
Read Per-call findings and Counts by rule, then press Download counts-only report, which omits tool names, paths, domains and recipients.
It reads a JSON array, an object with a calls/toolCalls/tool_calls/actions/entries array, a single object, or JSONL, and unpacks OpenAI-style function.arguments even when they arrive as a JSON-encoded string.
Backslashes, drive letters, . and .. segments are resolved before the prefix comparison, so docs/../etc/passwd does not slip past an allowedPathPrefixes rule.
Unparseable arguments, unreadable domains and numeric fields it could not evaluate are raised as explicit warnings, and hitting the traversal depth or entry limit produces a coverage-limit finding rather than a silent pass.
Twelve rule outcomes across seven policy keys: tool allow and deny lists with * wildcards, filesystem path prefixes, domain allowlists supporting *.example.com suffixes, recipient allowlists, per-field numeric maximums compared on absolute value, and required confirmation flags. Argument keys are matched by normalised name, so filePath, file_path and "file path" are all treated as a path field.
Up to 500 calls per run, traversing arguments to a depth of 10 and 5,000 entries per call. Anything beyond those bounds is reported — extra calls trigger a truncation warning and deep structures produce a coverage-limit finding — so partial coverage is never mistaken for a clean result.
A key listed in confirmation.acceptedFlags — defaulting to "confirmed" — set to an affirmative value: boolean true, the number 1, or the strings approved, confirmed, true or yes. Anything else, including false or a missing flag, raises a confirmation-required violation on tools listed in requiredForTools.
No. This is deterministic static analysis of a text log: it does not execute tools, prove runtime enforcement, resolve symlinks or environment variables, follow redirects or inspect DNS, or convert currencies and units on numeric limits. It also only sees the tool names and argument keys it recognises, so treat it as one check alongside real runtime enforcement.