Coderbuds

Report Ai Usage Tool

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). Set human_reviewed to whether a person actually read the diff before it went up — that is the governance number a board asks for, and guessing it helps nobody.

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

TableJSON Schema

Name	Required	Description
`tool`	Yes	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.
`model`	No	Optional model that did the work, e.g. claude-opus-5.
`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	Whether a person actually read the diff before it went up. Defaults to false — report it honestly rather than flatteringly.
`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

TableJSON 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.
`human_reviewed`	Yes	Whether a person read the diff.
`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.
`pull_request_number`	No	Pull request number the report is anchored to, if given.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 11, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Beyond the idempotentHint annotation, it discloses that reports are team-visible and attributed to the caller, that re-reporting refreshes rather than double-counts, and that the response compares the caller's report against the service's own detector with the caller's value winning. It stops short of stating permission requirements or error behavior.

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?

Front-loaded with the core action and organized into purpose, timing, field guidance, and behavior. Some of the motivational framing ('a heuristic that decides where a CTO spends budget') and the restatement of the authorship enum definitions duplicate schema text rather than earning their space.

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?

An output schema exists, so return-value documentation is not required, and the description still explains the salient part of the response. Combined with timing, anchor choice, and enum semantics, it covers what an agent needs; only auth/error detail is absent.

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 already 100%, so the baseline is 3, but the description adds decision guidance the schema does not: which of pull_request_number vs branch to supply and when, and why human_reviewed should be answered honestly. That is real interpretive value on top of the field definitions.

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 AI authorship of a change, with explicit scope ('wrote or helped write this change, and how much of it'). It is immediately distinguishable from read-side siblings like get-ai-adoption-tool, which surface the aggregate numbers this tool feeds.

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?

Gives explicit timing ('once per change, after the work is done'), an anchor-selection rule (pull_request_number once the PR exists, branch before it does), and a re-call policy ('safe to call again as the work evolves'). It also distinguishes the three authorship values with concrete conditions for choosing each.

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

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?