Co to znamená
Klient, který se o URI dozví z resources/list, z majordomus_list, z nálezu hledání nebo z dokumentace, ji může přečíst libovolným rozhraním, které má, a dostane totéž. Soubor vrstvy (majordomus://rule/..., majordomus://prompt/...) je soubor tak, jak byl přečten, se svými metadaty a původem. majordomus://repository není soubor: je to dotaz repository.info s expozicí jako zdroj a jeho čtení dotaz spustí. Přes resources/read se zpráva vrací jako text JSON; přes majordomus_get nebo GET /api/v1/object se vrací jako data pod answer, s id, druhem, titulkem a původem schopnosti, a týmž textem pod content. Odpověď nese source: declarative nebo source: builtin, aby klient poznal, co dostal, bez hádání z polí. URI, kterou nic neprojektuje, není nalezena na žádném rozhraní.
Princip
apps/majordomus-cli/src/capability/builtin/objects.rs má jedinou funkci, resolve: registr mapuje URI na schopnost, která jej promítá, a na expozici, jíž odpovídalo (CapabilityRegistry::by_mcp_uri); deklarativní schopnost se odpovídá z indexu, spustitelná se provede přes Context::execute s prázdným vstupem, takže se uplatní počítadla executoru a politika cache jako u jakéhokoli volání. objects.get vykreslí výsledek jako ResourceView (ObjectView, nebo AnswerView kolem odpovědi dotazu); read povrchu MCP vykreslí tentýž výsledek jako obsah zdroje, takže se nemohou rozejít. Dotaz, který odmítne, předá své odmítnutí dál; dotaz, který selže, je vnitřní chyba jmenující schopnost; registr jmenující objekt, který index nedrží, je vnitřní chyba, nikdy „nenalezeno“. Registr se odmítne sestavit, když dotaz vystavený jako zdroj má vstup s povinnou vlastností, protože čtení žádnou nedodává (tests/registry.rs).
Jak to vidět
just build
B=apps/majordomus-cli/target/debug/majordomus
$B capabilities describe objects.get --format json | jq '.output.name' # ResourceView
# in an MCP client: call majordomus_get with {"uri": "majordomus://repository"}
# -> source: builtin, id: repository.info, answer: the report, content: its text
# with a server running (an MCP client open, or `just serve` in another terminal):
curl -s 'http://127.0.0.1:8741/api/v1/object?uri=majordomus://repository' | jq '{source, id, identity, media_type}'
curl -s 'http://127.0.0.1:8741/api/v1/object?uri=majordomus://rule/none@1' # 404 not_foundCo nepokrývá
Nic zde nevytváří nové URI: množina čitelných URI je množina registru, jedno na objekt indexu plus každý dotaz s vystavením jako zdroj, a dnes je to samotné majordomus://repository. objects.get provádí jen to, co registr promítá na URI, nikdy schopnost, kterou klient pojmenuje podle id; k tomu slouží capabilities.describe.
Proč existuje
Čtení zdroje poskytlo majordomus://repository, zatímco majordomus_get a routa objektu na něj odpověděly „unknown resource“, protože nástroj hledal jen v indexu. Dvě odpovědi pro jedno URI jsou přesně ten drift, kterému má model schopností předcházet, takže oprava je jedno řešení, které volají obě projekce, dokázané test/cases/72_rust_mcp.sh přes skutečné roury a tests/objects.rs, tests/mcp_stdio.rs a tests/http_serve.rs crate.