"GetX" matching MCP tools:

• get-space-documentA

  docuwriterA

  Use this when the user wants to read the full markdown content of a specific Space document/page after search or listing. Read-only: returns the selected document without changing content. Requires the document ID from list-space-documents, search-space-documents, or global-search.

  ConnectorOAuth

• scene-getA

  Foundry MCPA

  Get full scene details: tokens (HP, AC, conditions, grid positions), walls, lights, notes, regions. includeMap (default true) appends an ASCII tactical map — walls, doors, numbered token positions with a legend — for spatial reasoning (who is near whom, what is behind a door, movement planning); set false when you only need the lists. includeScreenshot=true adds a canvas screenshot (~100-500KB) — a visual snapshot of what the DM sees; request it on first scene view or for visual details (terrain, art, ambiance) the map cannot convey, skip it on routine turns. If sceneId is omitted, returns the active scene. Use scene-list to find scene IDs.

  ConnectorAPI key

• instructions-getA

  hjarniA

  Get LLM instructions at the specified level. Call with level 'brain' early in conversations to learn user preferences. Optional: level ('brain'|'personal_root'|'container'|'team'), defaults to 'brain' if omitted or blank; the response echoes resolved_level and defaulted_level (true when the level was defaulted). Optional: id (integer, required for 'container' and 'team' levels). 'container' level takes a personal (or shared) container id and returns the full inheritance chain, outermost first; each entry carries a `level` field ('brain'|'personal_root'|'team'|'container'). Team container ids are not addressable here — read a team note's chain from notes-get, or the team's own instructions with level 'team'.

  ConnectorOAuth

• dashboard-getA

  hjarniA

  Get an overview of the Second Brain: counts of notes, containers, tags, and inbox items, plus recent_notes (the 5 most recently created personal notes) and recent_changes (the 5 most recently edited notes across ALL spaces — personal, teams, and shared containers — newest edit first). Use recent_changes to orient at the start of a conversation on what changed lately everywhere. If everything is empty because the user hasn't saved anything yet, do not just report that: call `me` and follow onboarding.next_action to run their 60-second setup. No parameters required.

  ConnectorOAuth

• get-prospect-worklist-toolA

  CoderbudsA

  Internal Coderbuds staff only. What to do next about the companies and advisers Coderbuds is approaching — the outbound pipeline behind /admin/prospects. Five lists, in the order they should be worked: - **answered** — questions you parked that a person has since answered. Work these first: each one carries `needs_action_reason` (what was asked) and `answer` (what you were told). Do what the answer says, then clear the pair with `update-prospect` and `answer: null`, or the row comes back next run. - **needs_you** — rows parked with a question and still waiting on somebody, oldest first. Do not re-ask a question that is already sitting here. - **replied** — somebody answered and has not been answered back. - **gone_quiet** — written to, no reply, past the quiet threshold. Check `times_contacted` before drafting: one follow-up on a different angle is the rule, so a row already at `max_touches` is a row to close, not to write to again. - **never_contacted** — researched and untouched, priority first. **Start every session working this pipeline by calling this.** It is the only way to know what is already in flight; without it the obvious move is to write to somebody who was written to on Tuesday. **`gate` is the one number that can say stop.** The first run of outbound is a test: at eight prospects written to, two replies means the pitch works and the list can widen, and fewer means the pitch is wrong rather than the volume. When the verdict is `fail`, say so and stop drafting — the next move is a different message, not thirty more of the same one. **`stage_tests` is the definition of done for each stage.** Do not move a row to a stage whose test it does not pass. Read the caveats it returns. Nothing in this list is a qualified lead: each row exists because a dated public signal made it worth a look, and a contact name was read off a profile on that date.

  ConnectorOAuth

• get-reward-policyA

  Crinkl Commerce MCPA

  Get the current Crinkl reward policy. Returns the active policy version, SHA-256 policy hash, reward parameters (referral bonuses, base points), category multipliers (grocery 1.5×, dining 1.5×, etc.), $CRINKL token holding tier multipliers, and the latest reserve checkpoint (BTC price, sats/receipt, coverage ratio). All values are deterministic — the policy hash covers the full parameter set. Updated daily.

  ConnectorNo auth

• get-scan-resultA

  DSGVO.pro — German Digital-Law ComplianceA

  Get the full compliance report for a completed scan. Returns score (0–100), financial risk in EUR, per-module results, and all violations with law references, fine estimates, and fix instructions. ⚠️ Only call after the scan is complete — check status first with get-scan-status. If called while scan is still running, returns current progress instead of an error.

  ConnectorNo auth

• get-venueA

  Bronjoy MarketplaceA

  Full public profile for one venue: address, opening hours, what it offers, amenities, payment methods, website and whether it can be booked online. WHEN TO USE: after search-venues, when the user asks anything about a specific place — "are they open on Sunday", "do they do colouring", "where exactly is it", "how much". This is the right tool for the ~99% of the catalogue that is not bookable: it carries everything needed to answer a question or send the user there in person. The phone number is masked here — call reveal-phone only when the user actually wants to ring them.

  ConnectorNo auth

• get-checkout-linkA

  SimFuse eSIM StorefrontA

  Get the page where a person buys one specific eSIM plan, for an assistant to hand them a link. The page sells exactly this plan with Apple Pay, Google Pay and card, takes the email at payment, and sends the eSIM there. Nothing is charged or reserved by this call and the buyer needs no account. Use this whenever a PERSON is going to pay. Use create-checkout-session instead when the agent is settling the purchase itself, or for more than one plan or unit.

  ConnectorNo auth

• get-created-pull-requests-toolA

  CoderbudsA

  Count pull requests OPENED over a recent window (default 1 day), broken down per repository and per author, with a human-vs-bot/dependabot split. Use this whenever the question is how many pull requests were created, opened or raised — today, this week, on a repo, or across the team — and especially when someone asks to see it "per repo" or "by repository". Prefer this over a per-person activity breakdown for any total. It counts from the team's repositories rather than its member list, so it includes authors who have no Coderbuds account (reported as `authors_without_member` and `created_by_non_members`) and excludes a member's work in repositories this team does not ship. A member-first count gets both of those wrong. The result carries its own denominator: `repositories` is exactly the list the numbers came from, so you can answer "which repos is this based on" from the same call. Slugs that match no team repository come back in `unmatched_repositories` instead of quietly counting zero. Opened is counted by the time the provider recorded the pull request being opened. That is a different set from merged in the window — use `get-merged-pull-requests` for merges, and never present the two as reconciling.

  ConnectorOAuth

• compendium-document-getA

  Foundry MCPA

  Get a compendium document as a readable summary: actors come back as a statblock (HP, AC, abilities, attacks), other types as core fields plus system data. For the complete raw JSON use compendium-document-get-raw, or uuid-resolve when you already hold the document UUID (what the filter tools return). Use compendium-browse to find document IDs.

  ConnectorAPI key

• journal-getA

  Foundry MCPA

  Get a journal entry by ID with all its pages as plain text (default) or as raw JSON with HTML and page metadata (formatAsText=false). Use journal-list or journal-search to find journal IDs; for one page of a long journal use journal-page-get.

  ConnectorAPI key

• world-time-getA

  Foundry MCPA

  Get the current in-world time (game.time.worldTime) as whole seconds since the world epoch, plus the same value broken down into days / hours / minutes / seconds so no conversion is needed. Use to read the clock before world-time-advance or world-time-set.

  ConnectorAPI key

• get-open-pull-requests-toolA

  CoderbudsA

  List the team's open pull requests grouped by author, with the signal that shows what is blocking each one: whether it is awaiting a reviewer, has changes requested, is approved and ready to merge, is still a draft, is failing CI checks, or is simply too large for anyone to review. Optionally scope to specific "owner/name" repositories (e.g. patchstack/hub). Use this to nudge people to merge — lead with the `headline`. Human authors include their oldest open PRs with age; bot authors (dependabot etc.) are collapsed into count-only summaries so a dependency backlog cannot drown out the PRs a person should act on. `total_oversized` and the per-PR `oversized` flag mark pull requests past the hard review limits — over 100 files, over 5,000 added or deleted lines, or over 8,000 changed in total. These are the ones a reviewer cannot pick up at all, so they are named in the headline and sorted to the front of their author's list. Report them as blocked on being split, not as blocked on a reviewer. The threshold is deliberately the hard limit rather than the team's line target: an open PR gives no file list, so the test/docs discount `assess-change-fit` applies to a numstat cannot be applied here, and judging against the target would flag changes that check would have passed. `size.category` is `unknown` when the counts were never recorded — that is missing data, not a small pull request; do not describe it as small. Set `include_bot_details` when you are working the dependency queue itself — merging dependabot PRs, chasing failing bumps — and each bot author gains the PR numbers, repositories, titles and URLs you need to act, ordered by what can be closed out first: ready to merge, then failing checks, then oldest. Check `status_freshness` before quoting counts: it flags open PRs whose local status may be stale, and repositories that have not synced pull requests recently — whose PRs may be missing from these counts altogether. Archived (decommissioned) repositories are excluded — this is a review queue, and their PRs are nobody's to review.

  ConnectorOAuth

• get-person-activity-toolA

  CoderbudsA

  What one person on the team has actually been doing, over a recent window (default 8 weeks). Answers "is Dave still shipping?" or "what has Sam been working on?" with three counts read together rather than one in isolation: pull requests opened and merged, reviews given to other people, and production deploys triggered — plus a week-by-week rollup, the busiest days, and the longest quiet run. Lead with the `headline`. A pull request count on its own supports the wrong conclusion: someone who opened 5 pull requests and gave 70 reviews is carrying the team's review load, not coasting. The headline says which of those it is. Identify the person by name or provider login ("dave", "Dave Smith", "@dsmith"). When the reference is ambiguous or unknown the tool returns the team's member names in `candidates` instead of guessing — ask which one rather than reporting activity for the wrong person. `not_captured` lists what this data cannot see (commits, review comment volume, ticket assignment, anything outside git). Repeat those limits when the answer is "this person looks quiet" — never present an absence of pull requests as an absence of work.

  ConnectorOAuth

• get-team-context-toolA

  CoderbudsA

  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`.

  ConnectorOAuth

• get-repo-readiness-toolA

  CoderbudsA

  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

• get-mcp-adoption-toolA

  CoderbudsA

  Who on the team is actually using the Coderbuds MCP. Every MCP tool call is recorded per member, so this reports adoption over a recent window (default 30 days): total invocations, per-member usage with last-used time and favourite tool, per-tool call counts, and — the nudge list — login members who have never connected the MCP at all. The denominator is who could plausibly connect one today — a login member (only they can mint API tokens) who is still shipping code. Tracked contributors cannot connect, deactivated or long-inactive members have left, and someone with several linked identities counts once. Use when asked "who is using the MCP", "is the team on the MCP yet", or to find who still needs the setup instructions. A call is attributed to the team it was about — the `repository` slug on it, or the `?team=` binding on the connection — not to whichever team the web switcher last landed on, so a member working across several teams shows up under the one they were working in.

  ConnectorOAuth

• get-icp-toolA

  CoderbudsA

  Internal Coderbuds staff only. Who Coderbuds sells to and what an opener is allowed to say — the rules behind the **Who it is for** tab of /admin/prospects, as they stand today. **Call this before writing anything to a prospect**, alongside `get-prospect-worklist`. The worklist says who to write to; this says what the message has to be. Rules change as outbound teaches us something, so read them rather than working from a version you saw in a document — that gap is exactly how outbound came to be sent on a wedge that had already been measured and dropped. Seven groups come back: who it is for, what the opener does, what makes a row worth sourcing, what closes a row, what we can say, how it may be sent, and what to do when somebody writes back. Three things to read carefully: - **`retired`** carries wedges that were tried and abandoned, each with the reason. Do not re-propose one of these in different words. The reason is the finding. - **`evidence: null`** marks a rule nobody has grounded in anything. Follow it, but weigh it as somebody's opinion rather than a measurement. - **`proposed`** are suggestions waiting on a person. **They are not binding** — do not draft against them, and do not propose the same thing twice. Use `propose-icp-rule` when outbound teaches you something this list does not say.

  ConnectorOAuth

• get-sideways-strategy-category-disruptA

  SidewaysA

  Get a random Disrupt strategy. Use when stuck in safe patterns, avoiding risk, or when work feels too polished or predictable. Best for injecting energy and unpredictability. Use this when: break patterns, embrace chaos, make destructive moves, honor mistakes. Returns a labeled strategy card to help shift your perspective and break through blocks.

  ConnectorNo auth

• folder-getA

  Foundry MCPA

  Get a single folder. includeSubfolders=true returns the full subfolder tree; includeContents=true lists the ids of documents directly inside this folder (not inside subfolders: fetch each subfolder for its own contents). Both default false.

  ConnectorAPI key