objects.list
List the declarative objects of the repository's AI layer, optionally by kind or tag.
List the declarative objects of the repository's AI layer, optionally by kind or tag.
- query
- behaviorally_verified
- module objects
- #objects
Exposure
Where this one definition is reachable. Absence is explicit: a surface not listed does not carry it.
| surface | as |
|---|---|
| MCP | tool majordomus_list |
| HTTP | GET /api/v1/objects operationId objects.list |
| command line | — |
Schemas
The canonical input and output, from the Rust types; the MCP tool schema and the OpenAPI parameters and responses are derived from these.
input · ListInput
Filters; both optional.
| property | type | required | description |
|---|---|---|---|
| kind | string | null | no | Only objects of this kind; the kinds present are listed by `repository.info`. A kind the repository does not have is an invalid input, not an empty answer. default null |
| tag | string | null | no | Only objects whose metadata tags include this tag. default null |
JSON Schema
{
"additionalProperties": false,
"description": "Filters; both optional.",
"properties": {
"kind": {
"default": null,
"description": "Only objects of this kind; the kinds present are listed by `repository.info`. A kind\nthe repository does not have is an invalid input, not an empty answer.",
"type": [
"string",
"null"
]
},
"tag": {
"default": null,
"description": "Only objects whose metadata tags include this tag.",
"type": [
"string",
"null"
]
}
},
"title": "ListInput",
"type": "object"
}output · ObjectList
The answer of `objects.list`: the matching objects, summarised, in URI order.
| property | type | required | description |
|---|---|---|---|
| count | integer | yes | How many objects matched. |
| objects | array | yes | The objects, one summary each. |
JSON Schema
{
"$defs": {
"ObjectSummary": {
"description": "One object, summarised for a listing.",
"properties": {
"description": {
"description": "The one-line description, when the kind holds one.",
"type": [
"string",
"null"
]
},
"id": {
"description": "The capability id, `<kind>.<identity>`.",
"type": "string"
},
"identity": {
"description": "The identity within the kind.",
"type": "string"
},
"kind": {
"description": "The kind the object was read as.",
"type": "string"
},
"path": {
"description": "Repository-relative source path.",
"type": "string"
},
"title": {
"description": "The title, when the kind's title rule found one.",
"type": [
"string",
"null"
]
},
"uri": {
"description": "`majordomus://<kind>/<identity>`.",
"type": "string"
}
},
"required": [
"uri",
"id",
"kind",
"identity",
"path"
],
"type": "object"
}
},
"description": "The answer of `objects.list`: the matching objects, summarised, in URI order.",
"properties": {
"count": {
"description": "How many objects matched.",
"format": "uint",
"minimum": 0,
"type": "integer"
},
"objects": {
"description": "The objects, one summary each.",
"items": {
"$ref": "#/$defs/ObjectSummary"
},
"type": "array"
}
},
"required": [
"count",
"objects"
],
"title": "ObjectList",
"type": "object"
}Policies
- benchmark
- required — a target on every transport the exposure declares; the cases are the input type's
- cache
- disabled — every call runs the handler
Benchmark targets
Derived from the registry for this repository: one requirement per transport, and the cases the input type provides. The whole matrix is on the benchmarks page.
| transport | state | cases | targets |
|---|---|---|---|
| direct | covered | 2 | all first-kind |
| mcp | covered | 2 | all first-kind |
| http | covered | 2 | all first-kind |
Claims implemented beside it
Attached by the file that implements each claim; every one links to its page with the implementation and the test that proves it.
The moments this answers
- watched the strongest model, at maximum effort, rename a variable Capability, reasoning depth, context size and verbosity collapse into one habit — everything on — because nothing ever named them separately.
- found the rule for that directory in a README no session ever loaded A local rule is either in the always-loaded file, where every session pays for it, or beside the code, where nothing relates it to the path being edited.
- spent an hour discovering something the repository already knew, twice A worker learns something expensive about the codebase, uses it once, and it dies with the session because nothing turned it into a durable record.
- found finished work on a branch that nobody ever merged Workers produce far more than integration absorbs, and nothing distinguishes work that is done from work that is done and landed.
- read a promise in the README that no test stood behind A sentence describing what the software does is written once and never connected to anything that would fail if it stopped being true.
- let a fast, cheap session make a decision the whole codebase now lives with Capability is dialled down for cost and nothing distinguishes the tasks where that is prudent from the ones where it is expensive.
- found the same thing explained three times, slightly differently Every hand-maintained copy of a fact drifts on its own schedule, and a reader cannot tell which copy is the current one.
- published a page that promised more than any test could support Public material is written by a different act from the code, so it drifts ahead of the behaviour and nothing brings it back.
- spent the first hour in an unfamiliar repository working out what was normal here What is conventional in a codebase is knowledge held by its regulars, so every arrival — human or machine — pays for it again.
- reviewed a well-written contribution that broke a convention it had no way to discover Assistants let anybody produce plausible contributions at volume; the conventions that make one correct are still only in the maintainers.