Try this first

Here is a tool definition with something missing:

# Anthropic's version. Other providers have their own; some have none.
{"type": "text_editor_20250728", "name": "str_replace_based_edit_tool"}

No description. No input_schema. Two keys.

Compare it with the ones you have been writing, which have four or five keys and a paragraph
of English. This one still works.

What is going on

Some tools are defined by the provider, not by you. The model already knows their names,
their arguments and how to use them, because they were part of its training. You are not
describing a tool. You are switching on one it already knows.

Anthropic’s file editor and shell are the clearest examples:

{"type": "text_editor_20250728", "name": "str_replace_based_edit_tool"}
{"type": "bash_20250124", "name": "bash"}

Note the type carries a date. These are versioned, and the name and type are a matched
pair — mixing a name from one version with a type from another is an error, not a warning.

Whether your provider offers anything like this varies, and it is not something to build on if
you want your agent to be portable. What matters is the idea, and one consequence of it that
people get wrong.

They are still executed by you

This goes straight back to Lesson 1.4.

“Provider-defined” describes who wrote the schema. It does not mean the tool runs on the
provider’s servers. The model asks for the tool, and your code performs the file operation
or runs the command, exactly as with your own tools.

You get the definition for free. You still write the implementation, and you still own every
consequence of it — including everything in the next three lessons.

The text editor, for instance, sends you a command field and expects you to implement four
operations:

def text_editor(arguments):
    command = arguments["command"]

    if command == "view":
        ...      # return file contents, or a directory listing
    if command == "create":
        ...      # write arguments["file_text"] to arguments["path"]
    if command == "str_replace":
        ...      # replace old_str with new_str, exactly once
    if command == "insert":
        ...      # insert insert_text after line insert_line
    return f"Unknown command: {command}"

Look at str_replace. That is edit_file from the last lesson, with the same one-match rule.
You did not build a worse version of a standard tool — you built the standard tool, and now
you know why it is shaped that way.

That is the real lesson here. These pre-defined tools are not magic and they are not a
different mechanism. They are the same three fields, with the description already written and
the schema already agreed.

Which to use

One trap worth naming: do not define a custom tool named bash with your own schema on a
provider that already defines one. You get a different tool that happens to share a name,
without the built-in behaviour, and the resulting confusion is hard to see.

Rover keeps its own tools for the rest of the course. Not because provider-defined ones are
worse, but because a tool you defined works on every model in Lesson 1.1, and everything from
here on — permissions, path safety, recovery — attaches to the implementation, which is yours
either way.

Provider-defined means the provider wrote the schema. Your code still does the work, and
still carries every risk in the next three lessons.

Try this before the next lesson

Whether or not your provider has these, do this thought experiment properly: write down what
your read_file, write_file and edit_file would look like as one tool with a command
field, the way the text editor does it.

Then ask yourself which is easier for a model to choose correctly — three tools with three
clear descriptions, or one tool with four modes. That question has no single right answer, and
Module 2 gave you everything you need to argue it either way.