Skip to main content
Glama
569,274 tools. Updated 2026-09-14 22:20

"bitbucket" matching MCP tools:

  • Scan a public GitHub MCP-server repository for security issues. Clones the repo (shallow, <60s, <200 MB), runs compuute-scan v0.6.2 in static analysis mode (no code execution from the target), and returns a structured report with severity counts, a 0-100 score, and the 10 most severe findings. WHEN TO USE: - Before connecting to an unknown MCP server discovered via Anthropic Registry, Smithery, mcp.so, or a Discord recommendation. - Before installing a third-party MCP-server package into a production pipeline. - As part of an agent's pre-commit / pre-deploy due-diligence step when adding new dependencies. - As one input to a multi-source trust evaluation (combine with publisher reputation, package install count, last-update recency). WHEN NOT TO USE: - For private repos. Use the on-prem CLI instead: `npx compuute-scan ./path-to-private-repo` - For deep exploitability assessment of a specific code path. This is pattern matching, not dataflow analysis. Book a manual L2-L4 audit at https://compuute.se/audit for that depth. - For non-GitHub hosts (GitLab, Bitbucket, self-hosted). v1 supports github.com only. - For repos > 200 MB or clone time > 60s. The endpoint returns a 413 or 504 in those cases — fall back to local CLI. EXPECTED RESPONSE TIME: - Median: ~1-2 seconds for small repos (<100 files). - p99: ~10 seconds for medium repos. - Hard timeout at clone=60s, scan=120s combined. EXPECTED COST: - Free tier in MVP. Future Pro tier may charge per-scan or per-month. DATA FRESHNESS: - Scanner version is reported in response.scanner.version. - L1 rule set freshness reflects compuute-scan releases — see github.com/Compuute/compuute-scan/CHANGELOG.md for the latest CVE and threat-intel response timeline. EXAMPLES: Example 1 — scan an MCP server you're evaluating: github_url = "https://github.com/modelcontextprotocol/servers" → score: 0, summary: {critical: 1, high: 94, medium: 22} → top_findings include SSRF, eval, etc. → recommendation: "AVOID — 1 critical and 94 high finding(s)..." Example 2 — scan a clean reference implementation: github_url = "https://github.com/microsoft/azure-devops-mcp" → score: 90+, summary: {critical: 0, high: 1} → recommendation: "REVIEW — 1 high finding(s)..." Example 3 — scan your own dev MCP-server before publishing: github_url = "https://github.com/yourorg/your-mcp" → audit your own surface before others install it OUTPUT FIELDS (stable schema): - repo_url (str): canonical URL of the scanned repo. - score (int): 0-100, higher safer. Coarse summary, not a precision claim. - summary (object): {critical, high, medium, low, info, files_scanned}. - recommendation (str): action guidance derived from severity counts. - findings_count (int): total raw findings (may include false positives). - top_findings (list): up to 10 most severe, each with {id, title, severity, file, line, owasp, cwe}. - l0_discovery (object): MCP transport, tool count, dependency pinning. - performance (object): clone_seconds, scan_seconds, repo_size_bytes. - scanner (object): {name, version, layers_covered}. - _disclaimer (str): MANDATORY triage disclaimer. Read it. Args: github_url: Public GitHub HTTPS URL (e.g. https://github.com/org/repo). Must be public and < 200 MB. v1 is github.com only. Returns: Structured scan result. On error, returns {"error": code, "message": ...} with HTTP-style code (invalid_url, clone_failed, scan_timeout, etc.).
    ConnectorNo auth
  • Use this when the user wants to choose a repository from a connected GitHub, GitLab, Bitbucket, or Azure DevOps provider before creating an Autopilot link. Read-only external-provider lookup: fetches repository choices or returns reauthorization/browser guidance. Requires provider and space_id.
    ConnectorOAuth
  • Use this when the user asks whether GitHub, GitLab, Bitbucket, or Azure DevOps is connected, or asks which imported repository records already exist. Read-only: returns provider status and browser-only connect/reconnect guidance without exposing credentials. Use repository-link tools for Space Autopilot links.
    ConnectorOAuth
  • Is this repo ready for agents? Coderbuds Standards opinion #3 judges the repository a coding agent is dropped into — not the change it makes. For each connected repository it returns pass / fail / insufficient_data on: deploy automation configured, deployed recently, PR size discipline (share of merged PRs inside the Coderbuds line standard), review coverage, agent guidance present (CLAUDE.md / AGENTS.md), CI config present, a tests directory present, and whether the fit check is actually wired in. Each failing check comes with a plain-language gap and recommendation, plus a team rollup of how many repos are ready and the most common gaps. Insufficient-data checks are always EXCLUDED, never counted against a repo — a repo is only "not ready" when a check genuinely fails. When the team has opted out of Coderbuds Standards the opinionated checks report insufficient_data. BitBucket repos report the content checks as insufficient_data (the API path is GitHub-only). Archived repositories are skipped, and dormant ones (nothing merged in the window, flagged `dormant`) never fail the wiring/deploy-recency checks and are excluded from the rollup's top_gaps — the headline reflects the repos actually shipping. Call this to find what is holding a repo back before pointing an agent at it.
    ConnectorOAuth
  • Checks whether a public GitHub, GitLab or Bitbucket repository will deploy: the services it found, what's missing (each with its fix), the environment variables it needs, and what it would cost a month on DigitalOcean, AWS, Google Cloud and Azure. Reads the code and changes nothing. No API key needed. A check can take up to a minute; if it's still running, call again with the check_id it returned.
    ConnectorNo auth
  • Has this repo's agent guidance file drifted from the repo it describes? A CLAUDE.md or AGENTS.md that lists the directories under `app/Domain` (or any other path) is making a claim that decays silently — the list was right when written, the code kept moving, and nothing fails when the two diverge. Agents read the stale list as truth, so a rotted guidance file is worse than none: it teaches the wrong shape of the codebase with full confidence. For each connected repository this returns the guidance file found, when it last changed, and every directory whose listing has gone stale — how many entries the file documents, how many are actually there now, and examples of what is missing. Call it before trusting a guidance file, when onboarding an agent onto an unfamiliar repo, or when deciding whether a hand-maintained inventory should be replaced by a get-team-context call. Only ENUMERATIONS are flagged. A file that mentions a path in passing is referencing it, not claiming an inventory, and is never reported. A directory is flagged only when the file already names several of its children (so it is holding a list) and is missing several more. Repos with no guidance file, BitBucket repos, and unreadable repos report insufficient_data — never a false drift. Archived repositories are skipped. Use get-repo-readiness for whether a guidance file exists at all; this tool judges whether the one that exists is still true.
    ConnectorOAuth

Matching MCP Servers

Matching MCP Connectors

  • Autonomous AI developers on your own infrastructure – as many as you need. Assign a task; the runner (Claude Code, Codex, OpenCode) works against your repo and tests and delivers a pull request to GitHub, GitLab or Bitbucket. Any model, your data stays with you.

  • Post-quantum cryptography (PQC) vulnerability scanner. Detects ECDSA, RSA, AES-128 and other quantum-vulnerable algorithms in GitHub/GitLab/Bitbucket repos and Ethereum smart contracts. Returns risk score 0-100, CBOM (CycloneDX 1.6), and migration paths to NIST FIPS 203/204/205. Free tier: 10 scans/day, no key required.

  • Internal Coderbuds staff only. The whole signup and conversion funnel across every account, matching the /admin/activity/conversion dashboard. Two funnels joined at "an account exists": - **Front door** — visitors sent to GitHub or BitBucket to authorize, how many came back, how many became an account, and how many were lost on the provider's own authorize screen. Broken down by provider and by campaign source. This is the only stage the account funnel structurally cannot see. - **Activation** — for accounts created in the window: what share reached each milestone (repository, GitHub App, first PR, first review, deploy tracking, deploy observed, Slack, MCP, paid) and the median days to get there; where open trials are stuck, counted by next step; the trial-state split; trials lapsing within a week; and per-account journeys with owner, milestone dates, next step and trial state. Use it to ask why signups stall, which step loses the most people, whether a change to onboarding moved anything, or who is worth an email this week. Read the caveats it returns: rates over a tiny sample are flagged unreliable, three milestones are reported without a median because nothing records when they happened, and the per-account list is capped while every rate beside it is over the whole cohort.
    ConnectorOAuth
  • Internal Coderbuds staff only. Add a company or adviser to the outbound pipeline. The buyer to look for: a CTO, head of engineering or hands-on engineering manager at a product company with 10–30 engineers on GitHub or Bitbucket. **Coderbuds does not support GitLab** — a GitLab-only team is not a prospect, however good the fit otherwise looks. Give the `signal` that made them worth writing down and the `source_url` it came from, and put what you could not verify in `qualification_needed` rather than guessing. A row whose signal is "looked like a fit" is a row nobody can act on later. Everything starts at Sourced regardless of what you pass. Duplicates are worth checking for first with `get-prospect-worklist`.
    ConnectorOAuth
  • Fetch deps.dev project metadata for a GitHub, GitLab, or Bitbucket repository (e.g. project_key="facebook/react"), returning scorecard scores, version count, and linked package references.
    ConnectorNo auth
  • Use this when the user explicitly asks to disconnect GitHub, GitLab, Bitbucket, or Azure DevOps. After authorization, this destructive action revokes the selected provider connection; it requires a provider key from the connection list.
    Connector
    Destructive
    OAuth