cairn
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| resolve_repoA | Find which workspace repo a name, alias, or description means (e.g. 'the admin dashboard'). |
| repo_cardB | Short card for a repo: purpose, run commands, layout, relationships. Read before exploring it. |
| linksA | Which repos a repo is linked to, one line each: "→ one way" (it uses that repo), "← one way" (that repo uses it) or "↔ both ways", and what connects them, then the org's uncloned repos linked by packages (with orgs configured). Leave repo empty for the repo this session is in. When the user asks what a repo links to, show this list to them as is; call related for the evidence. |
| relatedB | Repos related to |
| find_acrossB | Which repos expose or consume something: a route, table, topic, gRPC service, AWS resource (sqs:orders), package, or path. kind: http_route, db_table, topic, grpc_service, cloud_resource, platform_service, package, env_var_name, path_ref. |
| queryC | Where in the code is X? file:line hits in this repo, repos the question names, and related repos unless a literal answered; grep first, a deep index's symbols when built. |
| find_similarA | Before building a feature, find where the org already implemented it (searches the org's repos on GitHub or GitLab; nothing is cloned). task: the feature in a sentence. terms: 2-4 short searches the existing code would literally contain — class or function names, SDK calls, library names, config keys, headers (e.g. ["RateLimiter", "X-RateLimit-Remaining", "express-rate-limit"]), not the request's own words. Each term is one search; they run at once. org: only when several orgs are configured. |
| search_orgA | Where the org's code uses something, in its repos that aren't on disk (searches the org's repos on GitHub or GitLab; nothing is cloned): which templates import an export, what reads a metric, env var, header, queue or secret, which repo builds an image or names a contract-test provider. terms: 1-4 strings the code literally contains (e.g. ["ApiKey1", "gateway_function_invocation_total"]); each is one search, run at once. Then read_org_file(repo, path). org: only when several orgs are configured. |
| org_profileB | The org's stack: the languages, datastores, queues, frameworks, auth, test and deploy tools its recently pushed repos use, their common libraries, and the org's own shared packages: what new code for the org should be built with. Cached for a week; the first call reads the org over its host's API (about 15 s). |
| org_packagesA | The org's own libraries that its repos share (internal SDKs, service clients, logging, HTTP, test helpers): use these before a public package. Empty: the most used, with where each is defined. query: words to filter by (e.g. "retry http"). name: one package's home, every repo using it, and code that calls it. The first call of a day reads the org's manifests over its host's API (about 35 s for 600 repos; after that only repos pushed since). |
| read_org_fileA | Read a file from an org repo's default branch (e.g. one find_similar returned), without cloning. repo: its name in the org (or owner/name); path: inside the repo. A folder (or "" for the root) lists what it holds; a path that isn't there names the likely ones. |
| refreshA | Re-scan the workspace after repos changed. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools have clearly distinct roles: repo resolution, repo cards, remote file reads, refresh, org profiling, package lookup, and several scoped search modes. There is some overlap between links and related, between org_packages and org_profile, and among query, find_similar, search_org, and find_across, but the descriptions provide enough boundaries to guide selection.
The names are all snake_case and readable, but they mix verb-led names (resolve_repo, read_org_file, find_across, search_org) with noun/adjective labels (repo_card, links, related, org_packages, org_profile). The convention is not chaotic, but it is not a predictable verb_noun pattern throughout.
Twelve tools is a reasonable size for an org-scale code intelligence server spanning repo discovery, relationship mapping, package lookup, local/remote search, and refresh operations. Each tool appears to cover a meaningful slice of that workflow rather than padding the surface.
The surface covers the main read-only code intelligence lifecycle: finding repos, understanding them, mapping links and dependencies, locating org packages, searching local and remote code, finding similar implementations, reading remote files, and refreshing state. A minor gap is the lack of an explicit workspace/org repository listing tool, but resolve_repo and related discovery tools largely work around that.