Welcome to Explyt Academy

Explyt uses three kinds of tools: JetBrains IDE tools, the agent's built-in capabilities, and connected MCP servers. The IDE side gives the agent run configurations, project search on IDE indexes, the source of the library version actually connected to the project, file structure outlines, and safe refactoring through IDE mechanisms. The external side is MCP and Web Search. Connected MCP servers appear in the Tools menu as separate groups; the set depends on the agent mode, the IDE, and the servers you configured.

Key point from the docs

“In the Tools menu you can allow a tool, block it, or require confirmation before it is called. Availability does not mean that every action a tool takes is safe: a test, a command, an application, or an external service can change files and data.” Tools and integrations

Try

• Open the Tools menu next to the input field and write down, for each group, whether it is allowed, blocked, or asks for confirmation.
• Mark which of the allowed tools can change state: files, a database, an external service.
• Check that file access matches what you expect: Edit Scope plus .readignore and .writeignore govern files in addition to the tool settings.

The agent can find and run project configurations, tests, builds, and applications, through the IDE. It works just like pressing Run or Build. Get Configuration lists what is available for a file, a package, or the whole project, including Gradle/Maven tasks and custom configurations. Run Configuration runs the selected one and returns console output, test results, and compilation errors to the agent.

Key point from the docs

“This is more efficient than building or running a project via the terminal, which is what all AI tools rely on: it saves token consumption (the model receives a structured run result); it uses the SDK configured in the project. The agent doesn't need to guess which command to run or which SDK to use.” Running IDE configurations

Try

• Take a failing test. Ask the agent to run it through the run configuration, not the terminal, and to report the test status and the stack trace it received.
• Compare the result with the same test run in a terminal command: which one did you have to scroll, select and paste?
• Ask the agent to build the project and list compilation errors without you opening the terminal.

The terminal tools run commands and manage processes. The catalog is explicit about when you need them: when there is no suitable IDE configuration, or when the task involves an external utility. A command can change files, a database, the environment or a remote system, so the docs give a five-point check to run before one executes. The same page explains what Explyt checks after every edit, and what that check does not do.

Key point from the docs

“Before running one, check: the command itself and the working directory; the environment used; whether it can write or delete data; whether it connects to external systems; how to stop a background process.” Explyt tool catalog

Try

• Pick a read-only command you would want the agent to run itself, for example fetching logs from a pod or querying a row. Answer the five questions for it in writing.
• In the Tools menu, set the terminal to ask for confirmation, then let the agent propose the command and compare it with yours before approving.
• After the agent edits a file, do not stop at the parse check: the docs say it does not build the project and does not run IDE inspections, so an unresolved symbol or a missing import passes it. Ask for a build or a test run.

Explyt has no built-in Kafka, SQL or Kubernetes access. Those come through the terminal or through an MCP server you connect and scope. MCP (Model Context Protocol) is an open JSON-RPC based protocol for connecting LLMs to tools, services and data. You add a server in Settings → Tools → Explyt → MCP Servers, choose STDIO for a local command, HTTP for a remote streamable endpoint, or SSE only when the server's documentation asks for it, then connect it and allow only the tools the task needs.

Key point from the docs

“Before using MCP: check the source of the server; grant minimal rights; look at the list of tools; keep confirmation on for actions that change external data; run the first request in a safe test environment.” Explyt tool catalog, MCP tools

What else the MCP page covers

• Secrets stay out of JSON with ${VARIABLE_NAME} placeholders in a STDIO server's args or an HTTP/SSE server's headers. Substitution does not work in the URL, in command, or in the env object.
• Global configuration lives in ~/.explyt/mcp_servers.json; project configuration in .explyt/mcp_servers.json at the project root and can be versioned as long as it contains no secrets. A project entry with the same name takes precedence over the global one.
• When a large server would push the request toward the hard limit of 128 tools, Explyt represents it as a single tool and hands the task to an MCP subagent automatically.
• The Running <mcp_server> panel shows the tools being called; the Finished block holds the outcome and diagnostic details. Large text resources are moved into files so the agent can read a specific range.

Try

• Connect one read-only source the agent can query itself: a database MCP in restricted mode, or GitHub MCP with a token that has no write permissions, following the docs example with GITHUB_MCP_TOKEN.
• Put the configuration in the project file with the token as an environment variable placeholder, then Refresh Servers and Connect.
• Make the first request a safe read, as the docs recommend, and open the Finished block to see what the server actually returned.

Pasting is supported and sometimes right. Explyt turns large blocks of text into attachments with a short preview of the first line; the agent receives the complete text, and clicking the attachment opens a viewer. You can change the conversion threshold in the agent settings. Very large pastes are saved to a temporary file and the model gets a reference to it. The same page is where the docs draw the line between the terminal and run configurations.

Key point from the docs

“The terminal is needed for commands that have no suitable IDE run configuration. Builds, tests, and running the application are better done through run configurations: they use the project's configured SDK, classpath, and environment variables.” Working with the agent

Try

• For one week, every time you are about to paste output into the chat, ask first: “Which tool can you use to get this yourself?” Paste only when the answer is none.
• Before sending a message with an attachment, look at the card: remove it if you added the wrong file, the context is already out of date, or the data should not reach the model.
• After a code change, ask the agent to check the modified files with IDE static analysis before finishing; for runtime failures, go to Lesson 6.

Debug mode is for a bug you can reproduce by running a test, an application, or an existing IDE run configuration. The flow in the docs: open the Explyt tool window, create a new chat, select Debug in the mode selector, provide the failing test or run configuration or a stack trace, ask the agent to confirm the cause under the debugger first, then ask for a minimal fix, re-run the original scenario and the related tests, and review the changes in Agent Changes.

The request to use, verbatim from the docs

“Reproduce the error in Debug mode. Before changing any code, confirm the cause: set breakpoints, check variable values and the call stack. Once confirmed, apply a minimal fix, then re-run the original scenario and the related tests.” Debugging with Debug mode

What to check, per the docs

• The agent reproduced the original failure in the scenario you specified.
• The cause is confirmed by breakpoints, variable values, and the call stack, not just by a guess based on the code or the log.
• The original scenario passes after the fix.
• The related tests pass on a re-run.