Guide
Use MCP and CLI to Bring Workflow Data into Claude and Codex
Use FieldSignal MCP and CLI access with Claude and Codex skills to turn workflow evidence into draft AI tests for your development process.
FieldSignal makes workflow data accessible through MCP and CLI, and provides Claude and Codex skills to help turn that evidence into evals. Open one case, draft the tests, check the expected actions and run the approved tests in your chosen tools.
Connect the data first. Give the assistant a skill with instructions for the task. Review the AI tests it drafts. Run them in your chosen test tool and check the results.
This article describes a recommended working method. Installation, authentication, available tools and CLI commands depend on current FieldSignal product documentation and access arrangements. No command or endpoint is invented here.
What MCP, CLI and skills each contribute
MCP provides a standard interface through which an AI application can use connected capabilities and context. The protocol defines the connection; it does not establish that a source is complete or that a business decision is approved. MCP architecture
FieldSignal’s CLI provides command-line access to its data. This can fit the routines of a developer working with evidence alongside implementation. The exact operations and supported formats should come from the current CLI documentation.
FieldSignal’s Claude and Codex skills provide instructions for using workflow evidence to help create evals. Review what a particular skill actually supports. A useful instruction set can guide work, but the generated result still needs assessment against the case and the rule.
| Part | Job in this workflow | What to inspect |
|---|---|---|
| FieldSignal evidence | The available records and decision context | Source references, gaps and approval state. |
| MCP or CLI | Access to the data | The actual returned records and scope of access. |
| Claude/Codex skill | Instructions for drafting AI tests | The instructions used and the test file produced. |
| Team review | Acceptance of context and expected behavior | Missing facts, policy authority and intended checks. |
| Eval runner | Execution and assessment | Action/state results and failure evidence. |
Choose a case with a useful decision boundary
Suppose the implementation must handle replacement requests. Choose a case where the original part is unavailable and an alternative has not yet been verified as compatible.
Retrieve the relevant evidence through the supported FieldSignal interface. Check what was actually returned before asking the assistant to reason from it. A missing approval record is not proof of approval; a related message is not necessarily part of the same case.
Set the task boundary explicitly: prepare evals for the decision about whether a substitute can be offered. Asking the assistant to “understand the whole business” makes both the evidence requirements and completion criteria unclear.
Give Claude or Codex a concrete output to prepare
Use the available FieldSignal skill and a task brief that states what the team needs. For example:
Using the replacement-workflow evidence available through FieldSignal, prepare draft AI tests for the substitute-product decision. Separate the information available to the agent from evaluator-only references. Use reviewed business rules for expected behavior. Show missing evidence and unresolved policy questions. Include a case where the agent must request review and a separate case where the rule permits it to proceed. Do not report a test as passed unless it has actually been run.
This is an example task request, not a skill name or an executable product command. The downloadable task brief adds fields for workflow scope, links to records, the person who reviews the test and the test tool to use.
Inspect the output. If the assistant invents compatibility, adds information from after the decision or assumes an approver, revise the case before it becomes part of the suite.
Review the expectation before wiring the test
For the unknown-compatibility case, the reviewed expectation may be to request specialist review and leave the order unplaced. The case where the agent may proceed needs affirmative evidence for every required condition.
Ask the owner to resolve policy uncertainty. Ask the developer to map the expected actions to the actual tool names and system results. Those are separate review questions.
Keep sensitive case data in the approved working environment. A public repository needs a suitable fictional or approved redacted fixture, not an unexamined export from a customer’s records.
Inspect the public replacement example to see how a case and test are structured. It uses fictional data. It does not claim to match every current FieldSignal output format.
Use the accepted case when changing the agent
Connect the reviewed fixture to the team’s evaluation setup. Establish the current implementation’s behavior, make the intended change and compare results using the same approved expectation and relevant environment.
Check that the blocked case stays blocked and the permitted case can progress. Inspect the action trace and resulting state, not only the final message. If the test fails, distinguish a wrong implementation from missing test infrastructure or an ambiguous rule.
That is how workflow evidence becomes useful during development: it informs what to build, what to check and how to investigate a failure. It can also reveal a business question that needs answering before any implementation change is appropriate.
FieldSignal supplies the evidence-access path and Claude/Codex assistance for preparing evals. Your team owns the reviewed behavior and the development process in which it is tested.
Discuss FieldSignal platform access around one workflow and the evaluation setup your team already uses.
Related reading: build evals from workflow data, inspect the replacement example, and de-risk an agent deployment.