Skip to main content
Glama
bitfiction
by bitfiction

list_source_repositories

Read-only

List all public and private repositories from connected GitHub and GitLab accounts in one call, showing full names, URLs, and source accounts. Select the correct repository for migration or hosting without extra user input.

Instructions

List all public and private repositories accessible through the organization's connected Staticbot source-control integrations — GitHub and GitLab. Call this whenever a workflow needs a repository, with NO arguments: it covers every connected account in one call. An organization can connect several accounts on the same provider, and passing one instance ID narrows the listing to that account, which hides the others' repositories — only do that when the user has already chosen an account. The response is { sources[], repositories[] }. Each repository has fullName, webUrl, private, description, defaultBranch, plus provider, integrationInstanceId and sourceLabel — the account it is hosted in, e.g. "GitHub · octocat". Match the current client/project context against fullName or webUrl. If there is one unambiguous match, use its webUrl directly without asking the user to repeat it. When several are plausible — including the same name in two accounts — present the candidates WITH their sourceLabel and ask the user to choose, because the repositories are different. Listing repositories is not itself a decision to migrate: carry the chosen repository into whichever path get_account_status reported (start_hosting or start_migration), and ask the user which if they have not said. Whichever it is, pass the repository's integrationInstanceId back as sourceControlIntegrationInstanceId when calling create_template, so it is read with the account that can actually see it. A sources[] entry with an unavailableReason means that account's repositories are missing from the list and the user has to act — report it rather than concluding the repository does not exist. If there are no sources at all, direct the user to https://app.staticbot.dev/integrations to connect an account and then retry. Never claim that Staticbot requires a public repository.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
integrationInstanceIdNoOptional: restrict the listing to ONE connected account (from list_integration_instances or a previous sources[] entry). Omit to list every connected account, which is almost always what you want.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYesParsed JSON response from the Staticbot public API

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.8.1

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly and non-destructive annotations, the description discloses important behaviors: passing an instance ID hides other accounts, sources[] may include unavailableReason entries, empty sources require user action, and the tool should never be misrepresented as requiring a public repository. It also outlines the exact response shape and downstream consequences, which is far beyond the annotation baseline.

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

Conciseness5/5

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

The description is long but every sentence earns its place, covering purpose, invocation, parameter behavior, response shape, matching logic, failure modes, and downstream actions. It is front-loaded with the core purpose, then flows logically through usage details, and contains no tautological or filler sentences.

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?

Given the tool's workflow-critical role, the description is remarkably complete: it covers normal usage, ambiguity resolution, unavailable sources, empty sources, and the correct integrationInstanceId to pass downstream. The existing output schema and annotations reduce the need for more return-value detail, so nothing essential is missing for an agent to call this correctly.

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?

The schema already provides a strong description for integrationInstanceId, and coverage is 100%, so the baseline is 3. The main description adds value by explaining why passing the parameter narrows the listing and warns 'only do that when the user has already chosen an account.' This contextualizes the parameter without duplicating the schema.

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 opens with a precise verb and resource: 'List all public and private repositories accessible through the organization's connected Staticbot source-control integrations — GitHub and GitLab.' It also clearly distinguishes itself from provider-specific or single-account tools by emphasizing that it covers every connected account in one call, making its scope and identity unambiguous.

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?

The description provides strong usage guidance: 'Call this whenever a workflow needs a repository' and explains when to pass the optional integrationInstanceId ('only do that when the user has already chosen an account'). It does not explicitly name sibling alternatives such as list_github_repositories, but the 'whenever a workflow needs a repository' directive effectively routes the agent correctly.

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