Coderbuds

Get Team Context Tool

get-team-context-tool

Read-onlyIdempotent

The team's org map: every repository the team ships to, how alive each one is (merged/open PR activity, top contributors, last merge), how each deploys to production, whether each is ready for a coding agent (a compact readiness flag with failing check keys — call get-repo-readiness for the full checks and recommendations), how repos relate (taught links plus shared-contributor signals), and the team's confirmed working conventions. Everything is derived from live shipping data, so it never goes stale like a hand-maintained repo list in an agent rules file.

Pass repository (the repo you are working in) to get a FOCUSED map: that repository's details, the repositories most relevant to it with the reasons they matter, and the rest as names only — the right call at session start in a multi-repo org, instead of pulling the whole atlas. When the map is wrong or incomplete, teach it with link-repositories. For size/review norms, use assess-change-fit.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`repository`	No	The repository you are working in, as owner/name (from `git remote get-url origin`) or a bare repo name. Binds the session to the owning team AND focuses the map: you get this repo, the repos most relevant to it (with reasons), and the rest as names only.
`window_days`	No	Activity window in days for PR/contributor signals. Defaults to 90, clamped to 7–180.

Output Schema

TableJSON Schema

Name	Required	Description
`team`	Yes	Team name.
`focus`	No	Present in focused mode: the repository the map is scoped to.
`links`	Yes	Taught repository relationships (from, to, relation, note) — recorded via link-repositories.
`conventions`	Yes	Confirmed team/repo working conventions the team has taught its Coderbuds agents. Focused mode returns only team-wide and focus-repo conventions.
`window_days`	Yes	Activity window in days.
`repositories`	Yes	Active repositories with activity level, top contributors, production deploy setup, and a compact agent-readiness verdict (ready flag + failing check keys; use get-repo-readiness for detail). Full map: most active first. Focused map: the focus repository first, then the most relevant repositories, each with `relevance.reasons`.
`relationships`	Yes	Repository pairs the same people ship to, with shared-contributor counts and co_changes (how often one author merged into both within 48h — "ships together in practice", which ranks a pair higher). Pairs taught as unrelated are suppressed.
`other_repositories`	No	Present in focused mode: the remaining active repositories, names only.
`archived_repositories`	Yes	Decommissioned repositories, by name — they exist but no work should land there.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 11, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds genuinely useful behavioral context: all data is derived from live shipping data and never goes stale, and the focused-map mode degrades non-relevant repos to names only. It does not describe volume/latency or pagination, but the value-add beyond annotations is real.

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 resource and its contents, then the parameter-driven mode, then alternatives. Dense and mostly earned, though the first paragraph's compound enumeration is long enough to border on overload for a read-only lookup tool.

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?

An output schema exists so return values need not be explained, and annotations cover the safety profile. Given the tool's complexity, the description still covers scope, focused vs. full modes, data freshness, and escalation paths to three sibling tools — nothing an agent needs 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 description coverage is 100%, so the baseline is 3. The description goes further by explaining the semantic effect of `repository` — binding the session to the owning team and focusing the map — which is more than a restatement of the schema's type/format note.

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 names a specific artifact (the team's org map) and enumerates its contents: repositories shipped to, liveness signals, deploy paths, readiness flags, repo relationships, and confirmed conventions. It is clearly distinguishable from siblings like get-team-overview or get-repo-readiness, which it explicitly delegates detailed checks to.

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 states the exact selection rule: pass `repository` to get a focused map, described as 'the right call at session start in a multi-repo org, instead of pulling the whole atlas.' It also routes to alternatives by condition — get-repo-readiness for full checks, link-repositories when the map is wrong, and assess-change-fit for size/review norms.

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?