Problem
The six servers expose tools and nothing else. There is no server.resource(...) or server.prompt(...) call anywhere in packages/.
Why it matters
Everything a client wants as ambient context has to be fetched by an explicit tool call that spends a turn and lands as a blob in the transcript. Resources exist for exactly that: the client attaches them, the user sees what is attached, and the content does not have to be re-fetched per question.
Natural fits already backed by existing handlers:
ferrlabs://org/{slug}/overview — get_org_overview, packages/mcp/src/tools/org-admin.ts:107
ferrlabs://org/{slug}/usage — get_org_usage, org-admin.ts:120
ferrtrack://project/{slug}/issues — packages/mcp-track/src/tools/issues.ts
ferrvault://vault/{id} (metadata only, never values) — packages/mcp-vault/src/tools/vault-details.ts
Prompts are the other half — the repeated workflows a user drives by hand today: triage a FerrTrack backlog, review an org's vault audit log, summarise a FerrFleet run.
Proposed approach
- Add read-only resources for the org/project/site overviews, reusing the existing fetch functions rather than duplicating them.
- Add a small set of prompts, starting with FerrTrack triage and FerrFleet run review.
- Declare the
resources and prompts capabilities in the server construction so clients discover them.
- Vault resources expose metadata only — secret values stay behind
get_secret and its reveal gate.
Acceptance criteria
resources/list and prompts/list return a non-empty set on the relevant servers.
- Resource handlers share the tool fetch path (no second copy of the URL building).
- The README documents which resources and prompts each server exposes.
Problem
The six servers expose tools and nothing else. There is no
server.resource(...)orserver.prompt(...)call anywhere inpackages/.Why it matters
Everything a client wants as ambient context has to be fetched by an explicit tool call that spends a turn and lands as a blob in the transcript. Resources exist for exactly that: the client attaches them, the user sees what is attached, and the content does not have to be re-fetched per question.
Natural fits already backed by existing handlers:
ferrlabs://org/{slug}/overview—get_org_overview,packages/mcp/src/tools/org-admin.ts:107ferrlabs://org/{slug}/usage—get_org_usage,org-admin.ts:120ferrtrack://project/{slug}/issues—packages/mcp-track/src/tools/issues.tsferrvault://vault/{id}(metadata only, never values) —packages/mcp-vault/src/tools/vault-details.tsPrompts are the other half — the repeated workflows a user drives by hand today: triage a FerrTrack backlog, review an org's vault audit log, summarise a FerrFleet run.
Proposed approach
resourcesandpromptscapabilities in the server construction so clients discover them.get_secretand its reveal gate.Acceptance criteria
resources/listandprompts/listreturn a non-empty set on the relevant servers.