Who is the author of a commit made through an MCP server?

Two meanings of "author"

The question has a Git answer and a policy answer, and they are often confused.

Git records two people on every commit. The Pro Git book puts it this way: "The author is the person who originally wrote the work, whereas the committer is the person who last applied the work." Both are just a name, an email address and a date stored in the commit. Git does not check that the named person typed anything.

Projects, on the other hand, care about who is responsible. Fedora's approved policy says "The contributor is always the author and is fully accountable for their contributions." The Linux kernel says AI agents must not add Signed-off-by tags, because certifying the Developer Certificate of Origin is something only a person can do.

What the commit will say, by setup

MCP servers differ in how a change reaches the repository, so the name on the commit depends on which route the agent took.

Route	What creates the commit	Name you will usually see	What decides it
A hosted Git service's API, through a server such as the GitHub MCP server	The hosting service, acting on your token or OAuth login	The account that owns the token	API defaults, unless the call passes an explicit author
The agent runs git commit in a terminal or shell tool on your machine	Your local Git	Whatever user.name and user.email that Git is set to	Your Git config, unless the command the agent ran overrides it
A file-only server such as the Filesystem MCP server	Nobody yet: the server writes files, you commit later	You, when you commit	Your Git config

Through the GitHub MCP server. The server's README says it authenticates with OAuth or a personal access token, and it lists write tools such as create_or_update_file and push_files. GitHub's REST endpoint for repository contents, which creates a commit for a file change, documents the defaults: the committer is "the authenticated user", and the author is "the committer or the authenticated user if you omit committer". The README does not say which REST endpoint each tool calls or whether it passes an author, so treat the table row as the likely result and check the commit itself.

Through a local shell. If the agent commits with your local Git, the commit carries the identity your Git is configured with. An agent can override that identity in the command it runs, so read the command, not only the result.

Through the Filesystem server. The Filesystem MCP server reads and writes files inside the directories you allow and has no Git tools of its own. Any commit is one you make afterwards.

How to check a specific commit

1. Fetch, then run git log -1 --format='author: %an <%ae> %ad%ncommitter: %cn <%ce> %cd' <commit>. The %an, %ae and %ad specifiers are the author's name, email and date; %cn, %ce and %cd are the committer's, as listed in the Pro Git table of format specifiers.
2. Compare both to the account the agent used. If the author is you and you did not review the change, that is the problem to fix, not the name.
3. On the hosting service, open the commit page and compare it with what your local Git printed.
4. Read the end of the message for trailers such as Assisted-by: or Co-authored-by:.

What to put in the commit

Keep yourself as author when you directed the change and reviewed it, and record the tool separately:

fix: escape user input in the search results list

Replaces innerHTML with textContent in renderResults().

Assisted-by: coding agent via GitHub MCP server (reviewed by hand)

Do not use Co-authored-by: for the tool. GitHub reads that trailer to list co-authors on a commit, and Mesa says it is reserved for human co-authors. Do not let the agent add Signed-off-by: on your behalf on any project that uses the Developer Certificate of Origin.

Because an API commit never runs your local hooks, the trailer has to come from the agent's instructions or from a CI check on the pull request. The thread on enforcing an Assisted-by trailer has a script for that check.

Keep the agent from committing as you without review

The MCP tools specification says there should always be a human in the loop with the ability to deny tool invocations. In practice:

1. Give the token only the scopes the task needs, and use a separate token for agent work so its commits are easy to find. The GitHub MCP server's README recommends minimum scopes and separate tokens.
2. Run the server read-only when the agent only needs to read. The server's configuration documentation describes a read-only mode that disables write tools even when they are requested.
3. Have the agent work on a branch and open a pull request instead of pushing to the default branch, then review the diff yourself.
4. Approve each write tool call in your client rather than allowing them all.

The scopes question has its own thread: which token scopes the GitHub MCP server needs. For the details of each GitHub tool and its settings, see the CodeLifter page on the GitHub MCP server.

Ownership is a separate question

Who the commit names does not settle who owns the code. The US Copyright Office has said copyright does not extend to purely AI-generated material, and that the human contribution is analysed case by case. That question is covered on who owns AI-generated code.