Composing an AI Agent
An AI Agent node is assembled from sub-nodes wired to its ports. The agent reasons with its chat model, decides which tool to call, FluidGrids runs that tool, and the result goes back to the model until it can answer.
| Port | Takes | Required |
|---|---|---|
| Chat Model | OpenAI, Anthropic, Gemini, Groq, Mistral, Bedrock or Ollama chat model | Yes, exactly one |
| Tool | Calculator, Code, HTTP Request Tool, Workflow Tool, any connector operation, the MCP Client Tool | No, any number |
| Retriever | Retriever, pgvector, Pinecone, Qdrant or Milvus | No, any number |
| Memory | Buffer, Redis or Postgres memory | No, at most one |
| Output Parser | Structured Parser | No, at most one |
Every tool and retriever call runs as a separate, sandboxed step with that sub-node's own connection; the agent itself never holds the credentials. Tool approval and agent identities apply to every tool on the Tool and Retriever ports, including the tools of a remote MCP server.
Tools
Wire a node to the Tool port and pick the operation it should offer. The model sees the operation's inputs as the tool's parameters and fills them in for each call.
Tools from a remote MCP server
The MCP Client Tool node connects the agent to any remote Model Context Protocol server that speaks the Streamable HTTP transport.
- Add an MCP Client Tool node and wire it to the agent's Tool port.
- Enter the server's Server URL, for example
https://mcp.example.com/mcp. - If the server needs authentication, choose a connection. A Header Auth connection (for example
Authorization=Bearer <token>) covers most servers; use Custom Auth when it needs several headers. Leave it empty for a public server. - Optionally list the Tools to offer (comma-separated names) and a Tool name prefix to keep two servers' tools apart.
When the agent starts, FluidGrids asks the server for its tools and offers the agent one tool per server tool, with the server's own descriptions and input schemas, so the agent always sees the server's current tools. The server URL and the tool name of every call come from the node; the model only supplies the tool's arguments.
The same node also works on its own in a workflow: List MCP server tools returns the tools and their schemas, and Call an MCP tool calls one tool with a JSON object of arguments.
For safety, the node only connects to public http(s) addresses, never follows redirects, and caps the size of what a server can send back. To let outside agents call your workflows over MCP, see the MCP gateway.
Retrievers and vector stores
Wire a Retriever node or a vector store (pgvector, Pinecone, Qdrant, Milvus) to the Retriever port to ground the agent's answers in your documents. Configure the store on the node: the provider, the collection, how many chunks to return (top K) and the minimum score. Those settings are fixed for every search; the model only writes the search text. Fill the collection beforehand with a workflow that loads, splits and ingests your documents (Document Loader, a text splitter and the vector store's ingest operation).
Memory
Memory nodes attach to the Memory port. Today the agent starts every run from the run's own prompt: history is not yet loaded from, or saved to, the memory node by the agent loop. Until that ships, pass earlier turns in the prompt, or read and write history with the memory node's own operations in the workflow.
Output parser
A Structured Parser on the Output Parser port turns the agent's final answer into the JSON shape you describe, ready for the next node.