MCP & Agent-Driven Builds

What agentic development is here

Aquargin exposes the Model Context Protocol — the protocol used by Claude Code, IDE plugins and other agent tools to talk to your org programmatically.

An agent connected over MCP works in the same four primitives you have been using all trail long: objects, functions, pages and roles. There is no separate "agent API" with its own rules — which is exactly why an agent can author changes safely. It cannot reach anything your own admin screens cannot.

MCP credentials

Agent access runs on per-user API tokens. Each credential belongs to a specific user, carries a creation date, and can be revoked at any time.

Generating one

• Open Setup ▸ Integration ▸ MCP Credentials.
• Click + Generate New Credential.
• Copy the token — it is shown once — and paste it into the agent tool's credential config.
• Use the per-row Revoke action to invalidate a compromised token.

Wiring up Claude Code

With a credential in hand, point your agent tool at the org. In Claude Code that is one MCP server entry; IDE plugins and CLI tools follow the same shape.

// Your org's MCP Credentials screen gives you the server URL and the token.
// Store the token as a secret — never commit it.
{
  "mcpServers": {
    "aquargin": {
      "url":   "<server URL from the MCP Credentials screen>",
      "token": "<your per-user credential>"
    }
  }
}

Once connected, the agent can — in the words of the platform reference — list objects, query records, deploy functions and run workflows from the editor you already work in. A change made from a terminal is as traceable as one made from the admin screens.

What you can drive

Three modes of working, from safest to most powerful: ask, build, operate.

① Ask a question

Natural-language queries run against live data and return an answer with the records behind it: "Which SKUs breached their reorder point this week?"

② Build a process

Describe a rule and the platform authors the pieces that enforce it — the same objects, functions and screens you would build by hand:

you:  Hold dispatch on any order above ₹50,000 until the regional
      manager approves it.

agent authors:
  function      approve_over_50k     // trigger, bulkified — Trail 01 rules apply
  role rule     regional_manager
  screen state  dispatch_blocked

③ Run an operation

Operations execute through the same conversation, against the same validation and audit rules as the interface: "Raise a credit note against invoice 4471 and notify the customer."

Autonomy, undo & attribution

An agent that can change a production org is only useful if you can bound what it does. Three controls do that work.

Autonomy is a setting

• Cautious — the agent asks before it executes anything.
• Balanced — it executes, with a confirmation prompt on each operation.
• Autonomous — it runs on its own, under oversight.

Start cautious. Move up only after you have reviewed enough of the agent's work to trust the next level — the same judgement you would apply to a new team member.

Every AI operation is undoable

The platform keeps an operation history and exposes the set of operations that can still be reversed. A rule that lands wrong at four in the afternoon is taken back, and the history shows both the change and the reversal.

Every change has a name against it

Because credentials are per-user, an agent-made change attributes to the person whose credential authored it. The audit trail you learned to rely on in the other trails keeps working exactly as before — agents do not get an anonymous lane.

Earn the Agent Wrangler stamp

Answer all five to lock in Module A1.