Prode

Get a list of all the repositories which are available to the user. This is useful when you have to fetch details of related services for coding tasks involving interactions with other services.

Get high level context about functionality implemented across various repositories. This tool returns a concise summary of relevant documentations and code symbols. You can fetch context from all repositories if you are not sure about the exact list of repositories to ask the question to. repository_ids are needed only if check_all_repositories is false, is ignored if check_all_repositories is true. If you need to explore multiple aspects of the product, you should make multiple parallel high level context calls. Only ask multiple questions if they target separate unrelated aspects of the system. Take cues from the user's query to understand what they are looking for. Pick up terminologies, names, concepts etc. from the user's query and use them in your questions. Do not ask very elaborate questions. Your questions should be specific to searching where information is location, example - where is abc feature implements, where are xyz things located. High level context is to locate information, not to understand the implementation details. You should make this call before drilling into specific implementation details. Once you have the high level context, you SHOULD use the get_documentations tool to fetch the full content of the documentation that are relevant to your task. Just relying on truncated content might mislead you to make wrong assumptions. In case you do not find relevant high level context, or high level context is missing for some repositories, you can look at the documentation hierarchy to figure out things or fall back to get_folder_structure, search_file_contents, read_file, find_symbol_usages, or shell_command (rg, fd, tree over the repositories on disk) to explore those repositories directly. Good queries - Where is feature xyz implemnted, are there any docs which describe xyz? Bad queries - how does abc work, which repository is called xyz, which files or modules are there for xyz, is abc supported? where is abc implmented in the xyz repo?

Fetch contents for specific documentations. This is useful when you have the specific documentations you want to fetch the contents of. You can fetch multiple documentations in one go for a single repository by specifying the documentation ids. For fetching documentations across multiple repositories, you can make the tool call multiple times , once for each repo with corresponding documentation ids. You should call the get_high_level_context tool first to get related documentations first. The tool requires documentation ids as input, which you will find by calling the get_high_level_context tool.

Search for specific code snippets or patterns inside a the contents of repository's source files. Use this tool when the user's request requires locating exact code implementations, function usages, or logic that can be matched using a regex expression. This tool is stateless and does not rely on previous context. This performs a regex search on the contents of the files and returns matching lines with surrounding context to help understand the code. This tool supports searching across multiple repositories in a single call for better performance. Do not make more than four parallel search_file_contents calls. Parameters: repository_ids (List[str], optional): List of repository IDs to search. Provide one ID for single-repo search, multiple IDs for multi-repo search, or omit when check_all_repositories=true. check_all_repositories (bool, required): If true, searches all team repositories (ignores repository_ids). If false, searches repositories specified in repository_ids. path (str): Path inside the repository to search (can be root or a subdirectory). regex (str): Regex expression to search for inside the contents of the files. file_pattern (str, optional, default='**'): Glob pattern to filter files by path, with terminal/gitignore semantics. '*' and '?' match within a single path segment and do NOT cross '/'; '**' matches across directories. So '*.py' matches Python files directly inside `path` only, while '**/*.py' matches them at any depth. Brace alternation is supported, e.g. '**/{package.json,pyproject.toml}'. Matching is exact, so '*.ts' does not match '.tsx'. `path` is the directory the pattern is relative to. The default '**' matches all files. context_lines (int, required): Number of surrounding lines to include for context around each match. max_results (int, optional, default=20): Maximum number of files from which results should be returned. If more files match, only the top files are returned. Usage examples: Single repository: check_all_repositories=false, repository_ids=['repo-id']. Multiple specific repositories: check_all_repositories=false, repository_ids=['repo-id-1', 'repo-id-2']. All repositories: check_all_repositories=true (repository_ids can be omitted or will be ignored).

List repository files whose paths match a glob pattern. Use this when you want to find files by name or path (e.g. 'all TypeScript files', 'every package.json') rather than by their contents. Unlike search_file_contents this does NOT read file contents, so it is a fast, cheap way to enumerate files. This tool is stateless and supports searching across multiple repositories in a single call. Parameters: repository_ids (List[str], optional): List of repository IDs to search. Provide one or more IDs, or omit when check_all_repositories=true. check_all_repositories (bool, required): If true, searches all team repositories (ignores repository_ids). If false, searches repositories specified in repository_ids. pattern (str, required): Glob pattern to match file paths against, with terminal/gitignore semantics. '*' and '?' match within a single path segment and do NOT cross '/'; '**' matches across directories. So '*.py' matches Python files directly inside `path` only, while '**/*.py' matches them at any depth. Brace alternation is supported, e.g. '**/{package.json,pyproject.toml}'. Matching is exact, so '*.ts' does not match '.tsx'. path (str, optional, default=''): Directory the pattern is relative to (e.g. 'src/api'). Omit or '' for the repository root. max_results (int, optional, default=100): Maximum number of file paths to return. If more files match, the result is truncated. Usage examples: All TS files in a repo: check_all_repositories=false, repository_ids=['repo-id'], pattern='**/*.ts'. Manifests across all repos: check_all_repositories=true, pattern='**/{package.json,pyproject.toml}'.

Reads the content of a file from a repository. This tool is useful for retrieving the full content of a specific file. It can be useful for understanding the context or details of a particular implementation. Make sure the correct repository_id and file_paths are provided in the tool call. Parameters: repository_id (str, required): Unique identifier of the repository. file_path (str, required): Path for the file that you want to read in the repo. start_line (int, optional): Starting line number if you want to read a specific range. end_line (int, optional): Ending line number if you want to read a specific range. Files larger than 1000 lines will be automatically truncated to first 1000 lines unless a specific range is requested. When the returned lines make HTTP calls to other services in the organisation, an outgoing_http_calls section lists them with the service and route each one reaches. That section comes from the last service-mesh ingest rather than from this revision of the file, so treat it as a lead to verify in the code, not as ground truth.

Retrieves the folder structure of a repository. This tool is useful for understanding the organization of the repository, which can help in navigating and finding specific files or directories. Make sure the correct repository_id is provided in the tool call. Parameters: repository_id (str, required): Unique identifier of the repository. folder (str, optional): Path to the folder inside the repository by default it is root folder. depth (int, optional): Depth of the folder structure to retrieve. Default is 2.

Find all usages of a symbol across a repository. This is the 'Find References' or 'Find Usages' functionality. Use this tool when you need to find where a function, class, or variable is used in the codebase. The tool performs two parallel operations: 1. Structured import lookup - finds all symbols that explicitly import the target symbol 2. Text search - finds all files containing the symbol name as a backup (catches untracked usages) The symbol name can be partial/fuzzy - the tool will find the best matching symbol. Provide a line_number for better disambiguation when multiple symbols have similar names. IMPORTANT: If multiple symbols match, the tool returns possible_symbols instead of target_symbol. In this case, call again with the exact symbol_name from possible_symbols or provide a line_number. Parameters: repository_id (str, required): Repository ID to search in. file_path (str, required): Path to the file containing the symbol definition. symbol_name (str, required): Name of the symbol to find usages for. Can be partial. line_number (int, optional): Line number where the symbol is defined. Helps with disambiguation. Returns: - target_symbol: The resolved symbol (null if ambiguous) - possible_symbols: List of candidates if ambiguous (call again with exact name or line_number) - import_references: List of symbols that import the target (file, symbol name, type, lines) - search_matches: List of files containing the symbol name with match counts

Get the documentation hierarchy for a repository. Returns a tree of nodes where each node has a doc_id, a title, and a list of child nodes. Use this tool to understand how documentation is organized for a repository, then call the get_documentations tool with the relevant doc_ids to fetch the actual content. Parameters: repository_id (str, required): Unique identifier of the repository.

Enrich an MCP session with what you are doing and how it went. Use the session_id you were given in a tool response's prode_message (sessions open automatically — there is no separate start call). `add_intent` appends another thing you are trying to accomplish under this session; `feedback` appends free-form notes — what worked, what was missing, or a correction. `recommend_score` is an optional objective 0-10 rating (eNPS-style) that rides along with your feedback: how likely you, the coding agent, are to keep using the ProdE MCP for work like this — 0 = would avoid it, 10 = would definitely keep using it; it can only be given together with feedback. Calling this also activates the session. At least one of add_intent or feedback is required.

Runs a bash command in your team's sandbox and returns its output. Use it to search, navigate and read the team's repositories the way you would locally — `rg`, `fd`, `ls`, `git log`, pipelines of them — and to write notes, scratch files and intermediate results you want to keep across calls. REQUIRED Arguments: - command (str): The command to run. It runs under `bash -lc`, so pipes, globs and redirects work as written. OPTIONAL Arguments: - workdir (str): Where to run the command. Always set it rather than starting the command with a `cd`. Every call starts in `$HOME` again, so set it on each call that needs one — neither `workdir` nor a `cd` carries over to the next call. - session_id (str): The MCP session id you pass to every other ProdE tool. It names your shell as well: the same id means the same folder, with everything your earlier commands wrote still in it. Omit it and a session is opened for you and returned in the response — reuse that id from then on, or the next call starts in a new empty folder. Filesystem: the team's repositories are at `/repos`, **read-only**, one directory per repository named with the repository's full id — a repository with id `x.y` is checked out at `/repos/x.y`. `ls /repos` lists them, and get_all_repositories gives you the ids. `$HOME` is a folder of your own and the only place you can write; it persists across the commands of one session and its absolute path is in every response. Sandbox: no network access, so anything needing the internet, a package install or an API call will fail. `rg` (ripgrep), `fd`, `jq`, `tree`, `git`, `less` and `file` are installed — prefer `rg` and `fd` over `grep -r` and `find`, which are much slower here. Long-running commands are killed at the sandbox time limit (about a minute), and very large output is truncated in the middle. Returns the exit code, stdout and stderr. A non-zero exit code is a result, not a failure of the tool — read stderr and decide what to do.