Skip to main content
Glama
software-mansion

Argent

Official
by software-mansion
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

flow-read-prerequisite

Read a flow's execution prerequisite without running it to confirm the device is on the expected app, account, or screen. Reads a file only—nothing is launched or changed.

Instructions

Read the execution prerequisite of a flow without running it — a saved flow from the .argent/flows/ directory, or an explicit boundary-managed flow_path. Returns { flow, executionPrerequisite }: the logical name, plus the precondition its author recorded verbatim. Empty when none was declared, which is always so for a self-contained scenario: one opening on a launch may declare no prerequisite, because it builds its own start state. Use when deciding whether the device already sits where a fragment expects it (correct app foregrounded, correct account, correct screen) before committing to a run, or when relaying that requirement to a human. Touches no device: nothing is launched, tapped, dispatched or torn down, and no simulator or emulator needs booting, so calling this costs nothing but a file read. Fails if the flow file does not exist. Address the flow exactly as you will address it in flow-execute: name or flow_path, one and only one; supplying both or neither is rejected. The name goes in name, which resolves /.argent/flows/.yaml.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName of a saved flow to inspect from `.argent/flows` (e.g. "settings-explore"). Omit when flow_path is set.
flow_fileNoPath to the flow .yaml as readable by the tool-server. Internal — the argent client derives it from project_root and name automatically; leave unset.
flow_pathNoOmit when name is set. Absolute path to a co-located flow .yaml on the client and tool server's shared filesystem. This must be supplied through the file-input boundary. Pass the same flow source here as to flow-execute, so the prerequisite you read belongs to the flow that will run; for remote reads, pass name + project_root instead.
project_rootYesAbsolute path to the calling agent's project root — the cwd it is working in. With name, the saved flow is read from `.argent/flows/<name>.yaml` under this root; with flow_path, the prerequisite is read from that YAML instead, so pass the agent's cwd.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changedv0.22.0
    • removedInput schema / oneOf
      Removed value: -[
-  {
-    "required": [
-      "name"
-    ]
-  },
-  {
-    "required": [
-      "flow_path"
-    ]
-  }
-]
    • changedInput schema / properties / flow_path / description
      Previous value: -"Absolute path to a co-located flow .yaml on the client and tool server's shared filesystem. This must be supplied through the file-input boundary. Pass the same flow source here as to flow-execute, so the prerequisite you read belongs to the flow that will run; for remote reads, pass name + project_root instead."New value: +"Omit when name is set. Absolute path to a co-located flow .yaml on the client and tool server's shared filesystem. This must be supplied through the file-input boundary. Pass the same flow source here as to flow-execute, so the prerequisite you read belongs to the flow that will run; for remote reads, pass name + project_root instead."
  2. Changed5 schema fields changedv0.19.0
    • addedInput schema / oneOf
      Added value: +[
+  {
+    "required": [
+      "name"
+    ]
+  },
+  {
+    "required": [
+      "flow_path"
+    ]
+  }
+]
    • addedInput schema / properties / flow_path
      Added value: +{
+  "description": "Absolute path to a co-located flow .yaml on the client and tool server's shared filesystem. This must be supplied through the file-input boundary. Pass the same flow source here as to flow-execute, so the prerequisite you read belongs to the flow that will run; for remote reads, pass name + project_root instead.",
+  "type": "string"
+}
    • changedInput schema / properties / name / description
      Previous value: -"Name of the flow to inspect (e.g. \"settings-explore\")"New value: +"Name of a saved flow to inspect from `.argent/flows` (e.g. \"settings-explore\"). Omit when flow_path is set."
    • changedInput schema / properties / project_root / description
      Previous value: -"Absolute path to the project root directory that contains `.argent/flows/<name>.yaml`."New value: +"Absolute path to the calling agent's project root — the cwd it is working in. With name, the saved flow is read from `.argent/flows/<name>.yaml` under this root; with flow_path, the prerequisite is read from that YAML instead, so pass the agent's cwd."
    • changedInput schema / required
      Previous value: -[
-  "name",
-  "project_root"
-]New value: +[
+  "project_root"
+]
  3. First observedv0.15.0

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it does so thoroughly. It discloses the return shape, the empty-result behavior when no prerequisite is declared, the fact that no device is touched, that no simulator/emulator needs booting, that it is just a file read, and that it fails if the file does not exist.

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?

The description is front-loaded and logically ordered, with no filler, but it is somewhat dense and repeats the name/flow_path distinction and the flow location. These repetitions reinforce important constraints, so the slight redundancy costs only one point.

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?

With no output schema and no annotations, the description covers all essential context: what is returned, what empty means, what a prerequisite represents, failure behavior, cost/risk profile, and parameter constraints. An agent can decide whether to call it and construct a correct call without needing extra information.

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

Parameters5/5

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

Schema coverage is already 100%, but the description adds critical cross-parameter semantics: name and flow_path are mutually exclusive, supplying both or neither is rejected, name resolves under project_root/.argent/flows/, and flow_path must be supplied through the file-input boundary. This materially improves correct invocation beyond the schema alone.

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 description opens with a specific verb and object: 'Read the execution prerequisite of a flow without running it', and clearly scopes the resource to a saved flow from .argent/flows/ or a boundary-managed flow_path. It also distinguishes itself from siblings by repeatedly stressing that executing the flow is not what this tool does.

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?

The description explicitly says when to use it: before committing to a run, to check whether the device is already in the expected state, or to relay a precondition to a human. It ties addressing to flow-execute ('Address the flow exactly as you will address it in flow-execute'), giving the agent a clear alternative and preventing misuse.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/software-mansion/argent'

If you have feedback or need assistance with the MCP directory API, please join our Discord server