Code Companion - Built-in Tools

Built-in Tools

Tools provide a flexible, powerful way for models to interface with the external world. Code Companion includes several built-in tools which provide the model access to IDE functionality.

1. read_file

Use:
Use this tool if you need to view the contents of an existing file.

Type:
Automatic

Description:
Use this tool if you need to view the contents of an existing file.

Arguments:

• filepath (string): The path of the file to read, relative to the root of the workspace (NOT uri or absolute path)

2. create_new_file

Use:
Create a new file. Only use this when a file doesn’t exist and should be created

Type:
Ask First

Description:
Create a new file. Only use this when a file doesn’t exist and should be created.

Arguments:

• filepath (string): The path where the new file should be created, relative to the root of the workspace
• contents (string): The contents to write to the new file

3. run_terminal_command

Use:
Run a terminal command in the current directory. The shell is not stateful and will not remember any previous commands. When a command is run in the background ALWAYS suggest using shell commands to stop it; NEVER suggest using Ctrl+C. When suggesting subsequent shell commands ALWAYS format them in shell command blocks. Do NOT perform actions requiring special/admin privileges. Choose terminal commands and scripts optimized for darwin and arm64 and shell /bin/zsh.

Type:
Ask First

Arguments:

• command (string): The command to run. This will be passed directly into the IDE shell.
• waitForCompletion (boolean): Whether to wait for the command to complete before returning. Default is true. Set to false to run the command in the background. Set to true to run the command in the foreground and wait to collect the output.

4. file_glob_search

Use:
Search for files recursively in the project using glob patterns. Supports ** for recursive directory search. Will not show many build, cache, secrets dirs/files (can use ls tool instead). Output may be truncated; use targeted patterns.

Type:
Automatic

Description:
Search for files recursively in the project using glob patterns. Supports ** for recursive directory search. Will not show many build, cache, secrets dirs/files (can use ls tool instead). Output may be truncated; use targeted patterns.

Arguments:

• pattern (string): Glob pattern for file path matching

5. view_diff

Use:
View the current diff of working changes

Type:
Automatic

Description:
View the current diff of working changes

Arguments:
(none)

6. read_currently_open_file

Use:
Read the currently open file in the IDE. If the user seems to be referring to a file that you can’t see, or is requesting an action on content that seems missing, try using this tool.

Type:
Ask First

Description:
Read the currently open file in the IDE. If the user seems to be referring to a file that you can’t see, or is requesting an action on content that seems missing, try using this tool.

Arguments: (none)

7. ls

Use:
List files and folders in a given directory

Type:
Automatic

Arguments:

• dirPath (string): The directory path relative to the root of the project. Use forward slash paths like ‘/’. rather than e.g. ‘.’
• recursive (boolean): If true, lists files and folders recursively. To prevent unexpected large results, use this sparingly

8. create_rule_block

Use:
Creates a “rule” that can be referenced in future conversations. This should be used whenever you want to establish code standards/preferences that should be applied consistently, or when you want to avoid making a mistake again. To modify existing rules, use the edit tool instead.

Rule Types:

• Always: Include only “rule” (always included in model context)
• Auto Attached: Include “rule”, “globs”, and/or “regex” (included when files match patterns)
• Agent Requested: Include “rule” and “description” (AI decides when to apply based on description)
• Manual: Include only “rule” (only included when explicitly mentioned using @ruleName)

Type:
Ask First

Description:
Creates a “rule” that can be referenced in future conversations. Should be used for code standards/preferences that should be applied consistently or to avoid making a mistake again. Modify existing rules with the edit tool.

Arguments:

• name (string): Short, descriptive name summarizing the rule’s purpose (e.g. ‘React Standards’, ‘Type Hints’)
• rule (string): Clear, imperative instruction for future code generation (e.g. ‘Use named exports’, ‘Add Python type hints’). Each rule should focus on one specific standard.
• description (string): Description of when this rule should be applied. Required for Agent Requested rules (AI decides when to apply). Optional for other types.
• globs (string): Optional file patterns to which this rule applies (e.g. ['**/*.{ts,tsx}'] or ['src/**/*.ts', 'tests/**/*.ts'])
• regex (string): Optional regex patterns to match against file content. Rule applies only to files whose content matches the pattern (e.g. ‘useEffect’ for React hooks or ‘\bclass\b’ for class definitions)
• alwaysApply (boolean): Whether this rule should always be applied. Set to false for Agent Requested and Manual rules. Omit or set to true for Always and Auto Attached rules.

9. fetch_url_content

Use:
Can be used to view the contents of a website using a URL. Do NOT use this for files.

Type:
Ask First

Description:
Can be used to view the contents of a website using a URL. Do NOT use this for files.

Arguments:

• url (string): The URL to read

10. request_rule

Use:
Use this tool to retrieve additional “rules” that contain more context/instructions based on their descriptions. Available rules: No rules available.

Type:
Excluded

Description:
Use this tool to retrieve additional “rules” that contain more context/instructions based on their descriptions. Available rules: No rules available.

Arguments:

• name (string): Name of the rule

11. edit_existing_file

Use:
Use this tool to edit an existing file. If you don’t know the contents of the file, read it first. When addressing code modification requests, present a concise code snippet that emphasizes only the necessary changes and uses abbreviated placeholders for unmodified sections.

In existing files, you should always restate the function or class that the snippet belongs to.
Since users have access to their complete file, they prefer reading only the relevant modifications.
Only provide the complete file when explicitly requested.
Include a concise explanation of changes unless the user specifically asks for code only.
This tool CANNOT be called in parallel with other tools.

Type:
Ask First

Description:
Use this tool to edit an existing file. Follow best practices for concise code snippets and only include the necessary changes.

Arguments:

• filepath (string): The path of the file to edit, relative to the root of the workspace.
• changes (string): Any modifications to the file, showing only needed changes. Do NOT wrap this in a codeblock or write anything besides the code changes. In larger files, use brief language-appropriate placeholders for large unmodified sections, e.g. ‘// … existing code …’

12. grep_search

Use:
Perform a search over the repository using ripgrep. Will not include results for many build, cache, secrets dirs/files. Output may be truncated, so use targeted queries.

Type:
Automatic

Description:
Perform a search over the repository using ripgrep. Will not include results for many build, cache, secrets dirs/files. Output may be truncated, so use targeted queries.

Arguments:

• query (string): The search query to use. Must be a valid ripgrep regex expression, escaped where needed