Use the tools behind your app

Conversation and Preview can carry your first iteration. When a form fails to save or an email never arrives, inspect the actual data and request behind it. These guides connect the app-building flow to the integrated developer tools in Vortex.

Follow data through the app

Connect to MySQL/MariaDB, PostgreSQL or SQLite, inspect a known row and compare it with the API response. Save requests with environments and the intended authorization, then test a successful, empty and invalid-input case. Use schema and import/export tools with a clear destination.

See what the app sends and reports

Capture development mail locally or through a configured cloud SMTP credential. Inspect its rendered HTML, text and raw content. Signals can receive a fictional test event before you instrument real failures. Local mail heuristics are useful checks, not guaranteed deliverability scores.

Reach saved resources with control

Use saved SSH hosts, tunnels and FTP/FTPS/SFTP connections for the environments you intend. External MCP tools for chats and sharing Vortex tools with a local agent are different directions. Discover resource IDs, keep credentials private and review the scope of writes or remote commands.

Follow the detailed guides

  1. Open your app's database

    Open the data behind the app you are building. If Small Stories saves articles, Database lets you see those stored titles rather than relying only on the page.

  2. Read and change saved data

    Use a table view for a quick inspection, or SQL when you need a more specific question. Both operate on the database connection you selected.

  3. Understand your data structure

    The database structure explains how the app stores information. Inspect it before asking an agent to add a field or change a relationship.

  4. Move database data

    Move the data you actually need, in a format the receiving tool can use. Start by naming the source, destination and scope so you do not confuse a development copy with a live database.

  5. Try an app request

    Try the request behind your app’s screen. For Small Stories, reading the article endpoint lets you check the data before the page renders it.

  6. Connect a request to the right service

    Keep one request useful across environments without sending it to the wrong service. Name the environment clearly and check it before every consequential request.

  7. Check an API response

    Use the response to answer a concrete question: did the service return the right data, and does it behave correctly when the input changes?

  8. Import, export and sharing

    Bring in existing requests, share clusters through Nexus and review proposed changes.

  9. Connect to a server

    Open a terminal on a server you control when your project needs remote work. A local project shell and an SSH session run on different machines; keep that distinction visible.

  10. Reach a server-side service

    A tunnel lets a local tool reach a service through an SSH server. Use it when the database should not be directly exposed to your computer’s network.

  11. Move files to and from a server

    Use the file-transfer workspace to browse a server and move selected files. Choose the protocol the server actually supports: FTP, FTPS or SFTP.

  12. Edit a remote file

    For a small server-file change, open the file, edit it locally through the supported workflow and let the tracked upload return the saved change.

  13. Capture an email from your app

    Catch an email from your development app before you send real messages. Vortex Mail is a test-email receiver, not a replacement for a personal IMAP inbox.

  14. Capture test mail through cloud SMTP

    Cloud SMTP capture is useful when the test app cannot reach your computer’s local receiver. Create a credential for that app, then find its captured messages in Vortex.

  15. See what a test email looks like

    Check the actual email your app produced: its wording, layout, text alternative and attachments. Select the message and confirm whether it came from local or cloud capture.

  16. Bring an app event into Vortex

    Bring an application event into Vortex so you and your agent can inspect what happened. Start with a deliberate test event before depending on the feed for real errors.

  17. Find the event that needs attention

    Use the feed to find the event that explains a broken app flow. Unread attention and total stored history are different counts.

  18. Add tools to a conversation

    Add a supported external MCP server when your coding agent needs another tool. MCP is a way to connect tools; discovering a server does not make every action it offers safe.

  19. Let an agent use Vortex tools

    Let a supported local external agent use saved developer resources through Vortex. Credentials are resolved by Vortex rather than pasted into the agent’s resource list.

Explore the Vortex demo or browse all guides.