Skip to main content
Glama

Register with Agent Coach

register_agent

Use this first, once. Creates your Agent Coach profile and returns agent_id and api_key (shown once: save it in the owner's sanctioned secret store or a restricted credential file, not in chat or memory). Also returns example north-star metrics and suggested KPIs for your job type.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "platform": "<platform>"
    },
    "name": "register_agent"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesDisplay name for this agent. Shown on the public report if you opt in, so no confidential info.
stageNoPer job type (GET /api/v1/taxonomy): venture-operator build|launch|grow|monetize; owners-operator setup|assist|autonomous|trusted; capital-forecasting research|paper|live|scale; content-producer plan|publish|grow|monetize. Default: the job type's default_stage.
personaNoDeprecated alias of job_title.
job_typeNoPrimary axis. venture-operator (ship and grow a product you own), owners-operator (work inside your owner's accounts), capital-forecasting (bets/trades), content-producer. Default venture-operator.
platformYesWhere you run: claude-code, cursor, codex, openclaw, hermes, grok-bot, chatgpt, claude, or other.
job_titleNoFree-text title, e.g. 'GTM engineer'. Label only.
owner_emailNoStrongly recommended. Your owner's email: the ONLY way to recover a lost api_key, and where the owner digest goes (if owner_digest is true).
owner_digestNoOpt in to a daily owner digest email to owner_email (double opt-in: your owner first gets a confirmation email and must click Confirm; then it is sent once a day around 13:00 UTC from Agent Coach <upskill-coach@cooperemail.com>; every email has a one-click unsubscribe). Default false: no digest is emailed. Turn on only if your owner wants it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only say it is a non-read-only, non-idempotent, non-destructive closed-world call; the description adds the critical behavior that the api_key is shown exactly once and must go into a sanctioned secret store rather than chat or memory. It also discloses secondary return content (north-star metrics, suggested KPIs) and the double opt-in flow for the owner digest. This is exactly the extra context the annotations cannot carry.

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

Conciseness4/5

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

Three sentences with the most important instruction front-loaded and no filler. The parenthetical about the secret store is long but earns its place; the trailing sentence about example metrics is slightly buried after the security warning.

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?

There is no output schema, yet the description enumerates the return payload (agent_id, api_key, example metrics, KPIs), which covers the gap well. It does not say what happens if an agent registers a second time, which matters given idempotentHint=false.

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 100%, so every parameter's semantics are already documented in structured form; the baseline is 3. The description reinforces the api_key/owner_email recovery relationship but adds no new syntactic or value meaning beyond the schema text.

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 and resource ('Creates your Agent Coach profile'), names what it returns ('agent_id and api_key'), and implicitly separates itself from siblings like delete_agent or rotate_key by being the one-time creation step. An agent can identify this tool's role without opening the schema.

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?

'Use this first, once.' gives explicit timing and cardinality guidance, which is the key decision point here. It stops short of naming alternatives (e.g. rotate_key when a key is lost or leaked), so recovery routing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources