Skip to content

MCP surface

The tools and resources the executable serves to an MCP client, the transports, the shared server, and what decides all of it.

An MCP client sees the registry as tools and resources. Every tool is a capability with an mcp.tool exposure; every builtin capability with a resource exposure answers its URI; every object of the layer is one more resource. Nothing is listed here that the registry does not hold.

How a client reaches the server — majordomus mcp over stdio, the one shared server per repository with MCP over HTTP, the lease, the peers, what the server refuses — is the MCP document; the shared server's resilience is doctrine.

Tools

71 tools, as tools/list answers. The input schema of each is the capability's canonical input; the page of the capability shows it.

toolcapabilitykindinput → outputread-only
majordomus_artifacts

The manifest `majordomus generate` commits as docs/generated/artifacts.json, reconciled with the working tree: every document with the encodings it is written in, and every file with its format, schema, source, size, hash and whether the file on disk still matches. Optionally narrowed to one document or one encoding. Reads only; `majordomus generate` writes and `majordomus generate --check` is the byte-for-byte verdict.

artifacts.list query ArtifactsInput → ArtifactReport yes
majordomus_capability

One capability by canonical id: its kind, schemas, provenance, stability, exposures, benchmark and cache policy.

capabilities.describe query DescribeInput → Capability yes
majordomus_capabilities

Every capability of this executable and this repository, summarised: kind, module, stability, provenance, the projections it declares, its benchmark and cache policy; the schemas are answered by capabilities.describe.

capabilities.list query CapabilitiesInput → CapabilityList yes
majordomus_projections

A row per capability with the command line, HTTP route, MCP tool and MCP resource it reaches, whether every exposure it declares is answered by that surface, and the runnable commands no capability claims. Derived from the registry and the clap declaration; nothing is written down.

capabilities.projections query ProjectionsInput → ClosureMatrix yes
majordomus_command

One command by its canonical identity: its arguments with the source of each one's values, what running it changes, what it needs, where it came from, and every surface that carries it — with the reason a machine surface withholds it when one does.

commands.get query CommandRequest → CommandNode yes
majordomus_command_graph

The graph as one document, with its fingerprint and every diagnostic its build found: a duplicate identity, a recipe name two commands would take, an annotation that names a command which no longer exists. Deterministic — two builds over one tree produce the same document — so a client may cache against the fingerprint.

commands.graph query Empty → CommandGraphReport yes
majordomus_commands

The commands this repository offers, filtered by the program that runs them, by what running them changes, or by text. A summary rather than the whole graph: enough to choose a command, and never so much that a client has to read every argument of every command to find one.

commands.list query CommandFilter → CommandIndex yes
majordomus_continuity

The open episode, the active task, the handover and checkpoint that resolve for this worktree and branch, each with its divergence label, the unresolved questions that refuse completion, and the record tallies. Selection is two-tiered and never repository-wide: a record from an unrelated worktree or branch is not offered, because a briefing that is quietly about somebody else is worse than none. Absence is reported as absence.

continuity.state query Empty → Continuity yes
majordomus_deploy_check

Every refusal the declared deployments earn locally: a health route no capability registers, a package or binary the workspace does not produce, a build input that does not resolve, more machines running than exist, a hosted process that would bind loopback. Each names the file, the key, the value observed and the correction. Nothing here contacts the provider.

deploy.check query Empty → DeploymentCheck yes
majordomus_deployment

One deployment by its identity, typed, with the repository-relative file it was read from.

deploy.get query GetDeploymentInput → DeploymentView yes
majordomus_deployments

Every deployment the layer declares, typed: the application, the package and binary shipped, the address the process listens on, the routes a platform polls, the resources, the machine count, the region, the build inputs, the measured budgets and the provider's own facts. An object of the kind this executable cannot read is reported with the reason rather than skipped.

deploy.list query Empty → DeploymentList yes
majordomus_directories

Every directory of the layer the index knows, with the contract it declares, whether it owes one and which contract decided, and — for a named path, or when asked for everywhere — the effective chain composed from the root down, least specific first.

directories.list query DirectoriesInput → DirectoryReport yes
majordomus_artifact

The archive name a target and a tag derive, the directory it unpacks into, and where a release publishes it. The one naming function answers; the release pipeline asks it rather than composing a name in a workflow file.

distribution.artifact query ReleaseArtifactInput → ReleaseArtifactView yes
majordomus_build

What this executable is: the version of the crate it was built from, the Rust target triple, the profile, and the commit — all compiled in at build time, so an installed binary answers without a repository, a toolchain or git.

distribution.build query Empty → BuildReport yes
majordomus_distribution

The one-line install command, where an installation goes, and every declared target with the artifact name it derives. This is what the installation page, the landing page's install block and the cockpit's install card render; none of them holds a platform list of its own.

distribution.model query Empty → DistributionReport yes
majordomus_releases

Every release this repository recorded, newest first, and the one an unpinned installation resolves to: the highest version among the stable, unwithdrawn records. The pointer is derived here and never authored anywhere.

distribution.releases query Empty → ReleasesReport yes
majordomus_install_status

Whether a machine that has never seen this project can install it right now with the advertised one-line command, and when it cannot, which link in the chain is missing and what changes it. Derived from the distribution model and the release records alone: it reaches no network, so it is as fast as any other local query and answers offline. The served bytes are proved by the release pipeline's smoke phase, not guessed at here.

distribution.status query Empty → InstallabilityReport yes
majordomus_environment_explain

The provenance of the snapshot: for each field, what decided it — a compile-time constant, a file, a command, or the cache — which resolver read it, and how far it can be trusted. Narrow it to one field, or to a prefix, by name.

environment.explain query ExplainInput → EnvironmentProvenance yes
majordomus_environment

One snapshot of this checkout: project identity, repository identity, version control, declared toolchains, what the layer holds counted per kind, the workflows the runner describes, the provider projections against the policy that renders them, and the local services with the address a running server published. Every value carries where it came from.

environment.status query EnvironmentInput → RepositoryEnvironment yes
majordomus_execution_cancel

Set the execution's cancellation flag and say so on its stream. Cancellation is cooperative: a task looks at its flag and stops, and a capability whose policy says it is not cancellable runs to completion — which the answer says rather than pretending otherwise.

executions.cancel command CancelInput → CancelReport no — changes this process's memory
majordomus_demonstrate_execution

Walk a given number of steps, reporting each one, logging a line and advancing progress, then finish — or fail at a step you name. It exists so that an operator, a probe and an end-to-end test can prove the whole path works without waiting for real work: it reads nothing, writes nothing, and its only effect is the events it produces. It looks at its cancellation flag between steps and while it waits, so cancelling it stops it.

executions.demonstrate query DemonstrateInput → DemonstrateReport yes
majordomus_execution_events

The retained events of one execution, oldest first, after a sequence number. This is what a browser reads after a reload and what a client reads after a reconnect: the page carries the cursor to open the live channel with, so nothing is missed between the history and the stream.

executions.events query EventsInput → EventHistory yes
majordomus_execution

The whole of what is known about one execution: its state, its input as it was stored, its steps, its progress, its diagnostics, and its output or its error. Taken under one lock, so a snapshot that says it succeeded carries what it produced.

executions.get query GetInput → ExecutionView yes
majordomus_executions

Every execution this process remembers, newest first, narrowed by state or by capability. The counts beside them — remembered, active, queued, live channels — are what a control plane shows without asking a second question.

executions.list query ListInput → ExecutionList yes
majordomus_execution_protocol

Where the WebSocket is, how a subscription and a reconnect are expressed, what the server writes, and the JSON Schema of every message — derived from the Rust types that implement it, so a client validating against this is validating against the implementation. OpenAPI cannot describe a socket; this is where that contract lives.

executions.protocol query Empty → ProtocolReport yes
majordomus_execution_start

Run any executable capability of this registry as an execution: the input is checked against that capability's own input schema, the work is queued, and this answers at once with the execution's id and the links to follow it. Nothing waits for the handler. The capability runs through the same executor every other interface calls, so there is no second implementation of anything.

executions.start command StartInput → ExecutionView no — changes this process's memory
majordomus_graph

One graph by id: its nodes and edges with the vocabularies that say what each kind means, the file every node was derived from, and whether the result is acyclic. Deterministic for a given tree and executable.

graph.get query GraphInput → Graph yes
majordomus_graphs

Every graph this executable derives: its id, what it shows, and what it is derived from.

graph.list query Empty → GraphList yes
majordomus_health

Every dimension of what this process serves — the layer as it was read, the registry, the scope, version control, benchmark coverage, the committed registry manifest and the attached peers — each decided by the engine that owns it, with the command that reproduces the verdict.

health.report query Empty → Health yes
majordomus_get

One object by URI (majordomus://<kind>/<identity>): metadata, provenance and content; a URI a query projects (majordomus://repository) answers that query as a JSON document. The same resolution serves the MCP resource read.

objects.get query GetInput → ResourceView yes
majordomus_list

List the declarative objects of the repository's AI layer, optionally by kind or tag.

objects.list query ListInput → ObjectList yes
majordomus_search

Case-insensitive substring search over identities, titles, descriptions and content.

objects.search query SearchInput → SearchResult yes
majordomus_verify_objects

Read every file the layer was built from and compare it with what this process is serving. The index is built once at start-up and kept, which is what makes every other request cost nothing and what makes a file edited afterwards be served as it was; this is how a running server says whether that has happened, without being restarted to find out. A file that is one object is compared byte for byte; a collection file, whose objects the index keeps as members rather than as text, is compared by size, and every finding says which comparison was made. It reads every file of the layer, so it reports its progress file by file and stops when it is asked to.

objects.verify query VerifyInput → VerifyReport yes
majordomus_obligation_closure

Every obligation the active task declared, joined with what the vocabulary says about it and with the evidence that does or does not discharge it: what is owed, what is discharged, and what has gone stale — with the recorded input hash and the tree's current one, or the recorded commit and its label, so a reader can see against what. The judgement is the one `finish` applies, reproduced rather than re-decided, and the staleness words are the repository's only four. A checkout with no task reports that, rather than reporting nothing owed.

obligations.closure query Empty → Closure yes
majordomus_obligations

The tokens a task may declare in `requires`: what each one asks of a worker, the command that discharges it, the pathspecs its evidence is hashed over, and whether its fact is remote and therefore bound to a commit rather than to a tree. Shipped data, identical in every clone, so this answers in a checkout that has never run the lifecycle.

obligations.vocabulary query Empty → Vocabulary yes
majordomus_announce

Tell the other peers of this shared server what the calling session is doing and which paths it expects to touch. Changes this process's memory only; the repository is never written. Needs an MCP session: over plain HTTP there is no caller.

peers.announce command AnnounceInput → Announced no — changes this process's memory
majordomus_peers

Every client attached to this shared server: id, the client's own name and version from its initialize, transport, when it attached, when it was last seen, and what it announced. In-memory, gone with the process.

peers.list query Empty → PeerList yes
majordomus_perf

The counters of this process: repository scans, index and registry builds, schema generations, projection builds, executions, handler invocations, cache hits, misses and evictions, and the phase timings, as they stand now.

perf.counters query Empty → CounterSnapshot yes
majordomus_plan_issues

One record per issue with its derived status, its wave, the dependencies it declares, the ones that are not DONE (plus `milestone:<id>` when the gate holds the whole outcome back), the issues that depend on it, the paths it touches and its evidence tally. Filtering by `status: READY` is the ready set and by `status: BLOCKED` the blocked set; nothing here is a separate derivation.

plan.issues query PlanIssueFilter → PlanIssueList yes
majordomus_plan

Every milestone and issue with its derived status, wave, rank, both directions of its graph and its counts; the execution waves; both dependency graphs as edges; every validation finding; and the plan's header with the active milestone derived. The one value every other capability of this module answers out of. Derived on every call: a transition writes a lifecycle marker into a record between two calls, and a plan answered from a snapshot would send two workers to one issue.

plan.model query Empty → Plan yes
majordomus_plan_next

The lowest-wave READY issue of the active milestone, highest priority first, then id. The active milestone can have nothing ready while another one does — one waiting on its own acceptance evidence, for instance — so the search widens to the whole plan rather than answering `none` and sending a worker away from work that is genuinely executable. This is what an agent asks before it starts.

plan.next query PlanMilestoneFilter → PlanNextIssue yes
majordomus_plan_record

A milestone with its issues in full, or an issue with the issues it waits on in full. The record's own prose stays where it has always been — `majordomus://issue/<id>` returns the file — and this answers what the file cannot say about itself: what its status is, where it sits in the graph, and what is between it and being executable.

plan.record query PlanRecordInput → PlanRecord yes
majordomus_plan_roadmap

The milestone graph laid out by rank, with `order` breaking ties inside a rank only, and the first unblocked unfinished milestone as `now` and the one after it as `next`. Nothing in the sequence is authored: a milestone whose prerequisites are not real cannot be nominated, which is what makes `each step is gated by the previous one being real` an invariant rather than a sentence.

plan.roadmap query Empty → PlanRoadmap yes
majordomus_plan_status

Every milestone with its derived status and its issues counted by status, the milestone a worker is executing now, the next ready issue in full, and the plan's own totals. The counts are keyed by the declared vocabulary, which travels with the answer, so a status added to the engine appears here without anything being edited.

plan.status query PlanMilestoneFilter → PlanStatusReport yes
majordomus_plan_validate

Every finding the derivation produced, in the order it produced them: a dependency on something that is not an issue, a cycle, an issue executing ahead of its dependencies or of its milestone's gate, an issue with no acceptance criteria, evidence missing under a completion date, a milestone whose graph contradicts itself, two issues of one wave sharing a path. A failure means the model is invalid; a warning means it is legal and worth reading.

plan.validate query Empty → PlanValidation yes
majordomus_plan_waves

The topological layering of the issue graph: an issue enters a wave only once every dependency has left it, so its wave is one past the longest path to it. Sharing a wave is a necessary condition for running two issues at once, not a sufficient one — overlapping scope serialises them, and every such overlap is reported beside the waves rather than left for two workers to discover in a merge conflict.

plan.waves query PlanMilestoneFilter → PlanWaveReport yes
majordomus_feature

One product feature in full: the record as its file declares it, and everything derived from what it names — the capabilities of its modules with their tools, routes and command-line paths, the commands with their summaries, the objects of its kinds counted, the rules with their class and whether the tool enforces them, the documents, the decisions, the claims with their status, the use cases, the Cockpit areas and web surfaces with their routes, the moments it answers, and the interfaces all of that adds up to.

product.feature query FeatureInput → ResolvedRefs yes
majordomus_features

Every product feature this repository declares, narrowed by any of the facets the model derives — featured, area, module, command, surface, text — with the interfaces each is exposed through, the counts behind it and what is guaranteed about it, none of which its file states. The default is the stable set; pass status=any for the drafts too.

product.features query ProductQuery → FeatureList yes
majordomus_product_matrix

Every feature against the command line, the HTTP API, MCP, the Cockpit and the documentation, each mark derived from what the feature names; then every builtin module of the executable, every public command of the shell tool and every kind of the layer with the stable features that name it. A row with no feature is reported as a gap rather than hidden.

product.matrix query Empty → Matrix yes
majordomus_providers

Every provider the tool has an adapter for — one per template the distribution ships — with the bootstraps this repository's policy renders through it, the client configuration it carries for the shared MCP server, and the hooks the policy wires. The set is the templates; nothing here is a list of vendors.

product.providers query Empty → ProviderList yes
majordomus_product_validate

Every finding over the product model: a reference that resolves to nothing, with the nearest candidate; a duplicate identity; a file name that disagrees with its id; a draft that is featured; a stable feature under its floors; and every module, command or kind that no stable feature names. Errors make the model invalid; warnings do not.

product.validate query Empty → ProductValidationReport yes
majordomus_quality

The crate's exported surface measured against the repository's rules: how many items are documented and exampled, how many modules are documented, exampled and behaviourally tested, how the canonical operations stand against the command line, HTTP, OpenAPI and MCP, and one finding per violation carrying a stable code, the rule that requires it, its file and line, why it matters and what to do about it.

quality.report query QualityInput → QualityAnswer yes
majordomus_changelog

Every release the layer records, newest first, with the work that has not been released leading. A section's decisions are the ADRs dated inside that release's window, its changes the conventional commits in its range, its artifacts the record's own evidence. Nothing in it is authored, and a section that could not be read says so rather than appearing empty.

release.changelog query ReleaseChangelogInput → ReleaseChangelog yes
majordomus_release_version

The version the crate manifest declares, the version the shell tool prints, and whether they agree — the same question `scripts/release-version --check` gates on. Then the bump the conventional commits since the last release imply, the version it would produce, and the commits themselves as the evidence for it.

release.version query Empty → ReleaseVersionReport yes
majordomus_repository

The repository root, layer sections, git state, discovery mode, kinds present, every diagnostic, and the capability registry counted.

repository.info query Empty → RepositoryReport yes
majordomus_scope

The scope declaration as read, where it came from (the repository's own or the distribution's default), and every tracked file tallied against it: how many are in, how many are out for each reason, and which.

repository.scope query Empty → ScopeReport yes
majordomus_scope_classify

Whether a repository-relative path is in or out of the scope, the reason when it is out, and the pattern or limit that decided; an existing file is judged by name, then size, then content.

repository.scope_classify query ClassifyInput → Classification yes
majordomus_trace_commit

One commit with the issue and milestone it served, or the fact that none can be found. Attributed when exactly one issue's branches hold it, ambiguous when branches naming two issues do, and unattributed when no branch naming an issue holds it at all — which is either work committed without an execution contract or a branch deleted after its merge, and the answer says so rather than guessing between them.

trace.commit query TraceCommitInput → CommitAttribution yes
majordomus_trace_issue

One issue with the branches that name it — local, and remote-tracking where only the remote still has the branch — and, for each, the commits it holds that the trunk did not: measured against the trunk while the branch is open, and against the first parent of the merge commit that brought it in once it is merged. A branch that reached the trunk without a merge commit of its own says so and claims nothing, because its commits cannot be told from the trunk's. The milestone comes from the canonical issue record, which is the one edge here that git does not hold, and `declared` says whether the project model has this id at all — a repository with no plan still gets the branches, and a typo still cannot read as work nobody did.

trace.issue query TraceIssueInput → IssueTrace yes
majordomus_traceability

Every issue at least one branch names with its branches and commits, every declared issue no branch names, and the newest stretch of the trunk with each commit attributed to the issue whose branches hold it or reported as unattributed. The tallies count both sides, so the proportion of the trunk that no execution contract accounts for is a number rather than an impression. Read from git on every call: the history changes outside this process.

trace.report query TraceReportInput → TraceReport yes
majordomus_web_surfaces

The web topology in route-precedence order, with each surface's mount, category, visibility, kind, producer, artifact, runtime feature and the provenance of every value a reader could be surprised by; and which ids are served, published and offered to a person. Answered from the resolution this process serves from, so it cannot disagree with what the router routes or what the home page lists.

web.surfaces query Empty → SurfaceReport yes
majordomus_why_areas

Every operational area the catalogue declares, each with the public moments that fall under it. Membership is derived from the moments and is never listed in an area's own file.

why.areas query Empty → AreaList yes
majordomus_why_audiences

Every audience the catalogue declares, each with the public moments that name it. Membership is derived from the moments and is never listed in an audience's own file.

why.audiences query Empty → AudienceList yes
majordomus_why_diagnose

What a reader's own symptoms imply: the moments the selection resolves to, the operational areas and audiences they weigh towards, and the capabilities, commands, claims, rules and use cases that answer them — each carrying the moments that produced it. Counting, not inference: there is no weighting and no percentage.

why.diagnose query DiagnoseInput → Diagnosis yes
majordomus_why

Every operational moment this repository holds, narrowed by any of the facets the catalogue itself reports, with the audiences, the areas, the derived filters and the counts. The default is the public catalogue; pass status=any for the drafts too.

why.list query Query → CatalogueView yes
majordomus_why_moment

One operational moment in full: what it looks like, why it happens, what it costs, what this tool does about it, and every relation derived from its metadata — the responsibilities its claims belong to, the moments that name it, and the moments nearest it by shared area, audience and tag.

why.moment query MomentInput → MomentDetail yes
majordomus_why_validate

Every finding over the catalogue: a reference that resolves to nothing, with the nearest candidate; a duplicate identity; a file name that disagrees with its id; and a public record that does not meet the floor its status promises. Errors make the catalogue invalid; warnings do not.

why.validate query Empty → ValidationReport yes
majordomus_worktree_inspect

The canonical path of a branch, derived from its name alone, whether the branch exists, whether something occupies that path, the worktree holding the branch when one does, and what stands in the way of creating or migrating it. The answer for a branch that does not exist yet is the path `worktree create` would use.

worktree.inspect query InspectInput → InspectReport yes
majordomus_worktree_migration_plan

One step per misplaced worktree with a branch: where it is, where it belongs, how it would move, the uncommitted work that moves with it, and what blocks it; plus the exceptions the migration cannot address by design — detached worktrees, stale registrations, the primary checkout off the trunk — each with what a person does about it. Planning changes nothing; `majordomus worktree migrate` applies it with a fingerprint taken before and after every move.

worktree.migration_plan query Empty → MigrationPlan yes
majordomus_worktree_status

One worktree — the repository's own, or the one holding the directory the caller names — with its standing, its branch, its canonical path, its uncommitted work counted, whether it is where it belongs, and how many errors the whole topology carries. What an agent reads before it starts, and what the guard decides on.

worktree.status query StatusInput → StatusReport yes
majordomus_worktrees

The repository, the container, the trunk and how it was decided, every registered worktree with its standing (primary, canonical, misplaced, detached, missing), its uncommitted work, its upstream distance and the issue its branch provably names, every local branch with or without a worktree and whether it is eligible for cleanup, every diagnostic with its code and remedy, and the tallies. Read from git on every call: the topology changes outside this process.

worktree.topology query Empty → RepositoryTopology yes

Resources

The builtin capabilities that answer a URI, and the shape of every declarative object's URI. resources/list returns these first, then one entry per object of the layer (1116 in this repository, listed on the registry page).

Protocol

server name
majordomus 0.4.0
protocol versions
2025-06-18, 2025-03-26, 2024-11-05
transports
stdio (majordomus mcp), and MCP over HTTP at /mcp on the shared server
side effects
none on the repository; the lease under the local state directory while a server runs

Claims about the MCP surface and the shared server

Attached by the file that implements each claim; every one links to its page with the implementation and the test that proves it.