Coderbuds

Report AI usage

report-ai-usage-tool

Idempotent

Report that you — the coding agent — wrote or helped write this change, and how much of it. Coderbuds otherwise has to infer AI authorship from the shape of the diff, and a heuristic that decides who counts as an AI adopter is a heuristic that decides where a CTO spends budget. You already know the answer. Say it, and the team's AI numbers stop being a guess.

Call this once per change, after the work is done — ideally with pull_request_number once the PR exists, or branch before it does. Re-reporting the same change refreshes the record rather than double-counting it, so it is safe to call again as the work evolves.

Set authorship honestly: agent_authored (you wrote essentially all of it), agent_assisted (you wrote a meaningful part, a person wrote the rest), or human_authored (a person wrote it and you only looked things up or reviewed).

Then say what you saw a person do before the pull request opened, in review_evidence. Do not judge whether the change was "reviewed" — list only what happened in front of you:

approved_each_edit — each edit was shown to a person as a diff and approved before it applied (you ran in a mode that asks before editing, not one that bypasses permissions)
diff_comments — a person left comments on the diff before it opened (in Conductor, the GetDiffComments tool returns them)
edited_by_person — a person changed the code themselves
replied_after_changes — a person replied after the change was finished and before the pull request opened, so they saw at least your summary of it

Pass an empty list when none of these happened. You cannot see a person reading a diff in their editor, so an empty list means "no evidence", and Coderbuds words it that way.

Reports are team-visible and attributed to you. The response tells you whether Coderbuds' own detector agreed with your report; where it did not, yours is the one that counts.

Input Schema

Name	Required	Description
`tool`	Yes	The coding agent that did the work, as a stable slug — e.g. claude-code, cursor, copilot, codex, amp. Name the product the person worked through, not the model under it: an agent running inside Amp reports amp even when the model is Claude, and puts the model in `model`. Free text is normalised, so "Claude Code" and "claude-code" are the same tool.
`model`	No	Optional model that did the work, e.g. claude-opus-5. Separate from `tool`: Amp, Cursor and others run several models.
`notes`	No	Optional short context, e.g. "agent wrote the migration, human rewrote the query". Max 500 characters.
`branch`	No	The source branch, for when you report before the pull request exists. Matched to the pull request when it appears.
`authorship`	Yes	How much of the change you wrote: agent_authored (essentially all), agent_assisted (a meaningful part), or human_authored (a person wrote it, you only assisted).
`repository`	Yes	The repository the change is in, as owner/name or a bare repo name. Also binds the session to the owning team.
`human_reviewed`	No	Deprecated — send review_evidence instead, which this is derived from. Used only when review_evidence is absent.
`review_evidence`	No	What you saw a person do before the pull request opened: approved_each_edit, diff_comments, edited_by_person, replied_after_changes. An empty list when none of these happened.
`pull_request_number`	No	The pull request this change became, if it exists yet. The strongest anchor — it lets Coderbuds compare your report against what its detector inferred from the same diff.

Output Schema

Name	Required	Description
`team`	Yes	Team name.
`tool`	Yes	Normalised tool slug recorded.
`model`	No	Model recorded, if given.
`branch`	No	Branch the report is anchored to, if given.
`created`	Yes	False when this refreshed an existing report for the same change.
`message`	Yes	Human-readable confirmation.
`authorship`	Yes	Authorship level recorded.
`repository`	Yes	Repository the report was recorded against.
`review_level`	Yes	What the evidence adds up to: inspected, saw_change, unseen, or unknown.
`human_reviewed`	Yes	Whether the evidence shows a person looked at the code before it opened.
`inferred_score`	No	What Coderbuds' own detector scored this pull request, or null when there is nothing to compare yet.
`detector_agreed`	No	Whether the inferred score agreed with your report. Null when there is nothing to compare.
`review_evidence`	No	The evidence recorded, or null when none was sent.
`pull_request_number`	No	Pull request number the report is anchored to, if given.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 14, 2026

changedInput schema / properties / model / description

Previous value: -"Optional model that did the work, e.g. claude-opus-5."New value: +"Optional model that did the work, e.g. claude-opus-5. Separate from `tool`: Amp, Cursor and others run several models."

changedInput schema / properties / tool / description

Previous value: -"The coding agent that did the work, as a stable slug — e.g. claude-code, cursor, copilot, codex. Free text is normalised, so \"Claude Code\" and \"claude-code\" are the same tool."New value: +"The coding agent that did the work, as a stable slug — e.g. claude-code, cursor, copilot, codex, amp. Name the product the person worked through, not the model under it: an agent running inside Amp reports amp even when the model is Claude, and puts the model in `model`. Free text is normalised, so \"Claude Code\" and \"claude-code\" are the same tool."

Changed6 schema fields changedSep 29, 2026

changedInput schema / properties / human_reviewed / description

Previous value: -"Whether a person actually read the diff before it went up. Defaults to false — report it honestly rather than flatteringly."New value: +"Deprecated — send review_evidence instead, which this is derived from. Used only when review_evidence is absent."

addedInput schema / properties / review_evidence

Added value: +{
+  "description": "What you saw a person do before the pull request opened: approved_each_edit, diff_comments, edited_by_person, replied_after_changes. An empty list when none of these happened.",
+  "items": {
+    "enum": [
+      "approved_each_edit",
+      "diff_comments",
+      "edited_by_person",
+      "replied_after_changes"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / properties / human_reviewed / description

Previous value: -"Whether a person read the diff."New value: +"Whether the evidence shows a person looked at the code before it opened."

addedOutput schema / properties / review_evidence

Added value: +{
+  "description": "The evidence recorded, or null when none was sent.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / review_level

Added value: +{
+  "description": "What the evidence adds up to: inspected, saw_change, unseen, or unknown.",
+  "enum": [
+    "inspected",
+    "saw_change",
+    "unseen",
+    "unknown"
+  ],
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "team",
-  "repository",
-  "tool",
-  "authorship",
-  "human_reviewed",
-  "created",
-  "message"
-]New value: +[
+  "team",
+  "repository",
+  "tool",
+  "authorship",
+  "human_reviewed",
+  "review_level",
+  "created",
+  "message"
+]

First observedSep 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover idempotentHint and destructiveHint; the description adds substantive behavior beyond them: reports are team-visible and attributed, re-reports refresh the existing record, and the response indicates whether Coderbuds' detector agreed with the report. It also clarifies that an empty review_evidence list is interpreted as 'no evidence' rather than a negative judgment.

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?

The core instruction (call once per change, use PR number or branch) is front-loaded and the enum guidance is well structured as a list. The opening paragraph spends several sentences on motivation and budget rhetoric, which is persuasive but not strictly needed for correct invocation.

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

Completeness5/5

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

For a 9-parameter mutation tool with an output schema, the description covers when to call, how to pick authorship, how to enumerate review evidence, and how the response is used. Nothing an agent needs in order to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it: it explains each authorship value operationally, defines what each review_evidence enum physically observed ('approved_each_edit' requires a permission-asking mode), and reinforces the empty-list convention. It stops short of explaining 'repository' binding or the deprecated 'human_reviewed' fallback beyond what the schema says.

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?

The description states a specific verb and resource: report that the agent wrote or helped write a change, and how much. It is unmistakably a write/report tool, contrasting cleanly with read-only siblings like get-ai-adoption-tool or get-agent-activity-tool, and the first sentence alone lets an agent place it.

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

Usage Guidelines5/5

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

It gives explicit timing ('once per change, after the work is done'), explicit anchor alternatives ('pull_request_number' once the PR exists, 'branch' before it does), and states that re-reporting refreshes rather than double-counts, so re-invocation is sanctioned. It also tells the agent to set authorship honestly and enumerates the criteria for each choice.

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

All Coderbuds tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?