MCP Agent Mail

register_agent

Create or update a coding agent's identity and profile in a project, persisting it to Git. Refreshes last-active status to support agent coordination.

Instructions

Create or update an agent identity within a project and persist its profile to Git.

When to use

At the start of a coding session by any automated agent.
To update an existing agent's program/model/task metadata and bump last_active.

Semantics

If name is omitted, a random adjective+noun name is auto-generated.
Reusing the same name updates the profile (program/model/task) and refreshes last_active_ts.
A profile.json file is written under agents/<Name>/ in the project archive.

Agent Identity

Two naming modes are supported:

Explicit identity — pass a stable ID like alpha-one, cc-0, or worker_42. Must match [A-Za-z0-9][A-Za-z0-9._-]{0,127}. Useful for swarm workflows where agents are relaunched onto the same identity.
Auto-generated — omit name to get a random adjective+noun identity like GreenLake or BlueDog (RECOMMENDED for ad-hoc use).

Invalid examples: "BackendHarmonizer", "DatabaseMigrator" (descriptive role names are rejected in strict mode).

Parameters

project_key : str The same human key you passed to ensure_project (or equivalent identifier). program : str The agent program (e.g., "codex-cli", "claude-code"). model : str The underlying model (e.g., "gpt5-codex", "opus-4.1"). name : Optional[str] A valid explicit identity (e.g., "alpha-one", "cc-0") or adjective+noun combination (e.g., "BlueLake"). If omitted, a random valid name is auto-generated (RECOMMENDED). Names are unique per project; passing the same name updates the profile. task_description : str Short description of current focus (shows up in directory listings).

Returns

dict { id, name, program, model, task_description, inception_ts, last_active_ts, project_id }

Examples

{"jsonrpc":"2.0","id":"3","method":"tools/call","params":{"name":"register_agent","arguments":{
  "project_key":"/data/projects/backend","program":"codex-cli","model":"gpt5-codex","task_description":"Auth refactor"
}}}

{"jsonrpc":"2.0","id":"4","method":"tools/call","params":{"name":"register_agent","arguments":{
  "project_key":"/data/projects/backend","program":"claude-code","model":"opus-4.1","name":"BlueLake","task_description":"Navbar redesign"
}}}

Pitfalls

Names MUST match the adjective+noun format or an error will be raised
Names are case-insensitive unique. If you see "already in use", pick another or omit name.
Use the same project_key consistently across cooperating agents.

Input Schema

TableJSON Schema

Name	Required	Default
`name`	No
`model`	Yes
`format`	No
`program`	Yes
`project_key`	Yes
`task_description`	No
`attachments_policy`	No	auto
`registration_token`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.4Sep 30, 2026

TDQS

A4.2/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden and does so well: it discloses the on-disk artifact (agents/<Name>/profile.json), the case-insensitive uniqueness rule, last_active_ts refresh on reuse, the name regex, and strict-mode rejection rules.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-organized with headers, but heavily padded: two near-duplicate JSON-RPC examples, repeated 'RECOMMENDED' notes, and a Pitfalls bullet that contradicts the earlier identity section by claiming names MUST be adjective+noun when explicit IDs were just declared valid.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Rich enough for a mutation tool with no annotations, covering naming, update semantics, and side effects. The unaddressed params and redundant Returns block (an output schema exists) keep it short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there are 8 parameters, but the description documents only 5 (project_key, program, model, name, task_description). format, attachments_policy, and registration_token are left undocumented in both prose and schema, so the agent must guess their meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Create or update an agent identity within a project') plus the persistence side effect ('persist its profile to Git'). An agent can distinguish this from deregister_agent/retire_agent/hard_delete_agent, which are the destructive siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Has an explicit 'When to use' section (session start, metadata update) and a Semantics section for the create-vs-update branch. It does not, however, address overlap with the sibling create_agent_identity, leaving ambiguity about which identity-creation path to pick.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.