@graview/tools
Derived affordances and the agent tool surface, generated from the same declarations; graview mcp and graview apply host it against a real store.
pnpm add @graview/toolsEntry points: @graview/tools, @graview/tools/cli
What it is
What can legally be done with a selection, and the agent surface that shares it.
Nobody authors an affordance. Providers notice things — a violation and the repairs it names, a mutation whose subject accepts every selected kind, a neighbour all but one of them share — and the results merge into one ranked set. An LLM is one optional provider among these rather than the mechanism.
createToolRuntime generates a tool per mutation from the same declarations, so an external agent over MCP and a seat inside the interface use literally the same actions and produce literally the same diffs. That is why watching an agent work needs no bespoke observability layer.
Read-only calls report the nodes they looked at, which is the half a diff cannot show. A seat holding a principal gets tools for what that principal may run, and is told plainly about the ones it may not.
The host: graview mcp and graview apply
An external agent — an editor's assistant, a worker on a schedule — used to edit the seed file, because the seed was the only thing it could reach. These two commands put the runtime where the data is, so it evolves the live graph the way a person does: through store.apply, under its own seat, judged by the same policy, logged with its name.
graview mcp ./dist/domain/app.js --data ./data --as cursor --roles keeper
graview mcp ./dist/domain/app.js --remote-url https://host.example/app --header "authorization: Bearer …"
graview mcp ./dist/domain/app.js --list --roles keeper # the seat's tools as tools/list JSON
graview apply ./dist/domain/app.js --data ./data --roles keeper \
--call add-task --args '{"listId":"today","label":"Book the van","id":"t-van"}'
graview apply ./dist/domain/app.js --data ./data --roles keeper --plan ./plan.json --preview
graview apply ./dist/domain/app.js --data ./data --roles keeper --undo batch:7mcp speaks MCP over stdio — JSON-RPC, one message per line, no SDK — around createToolRuntime and createMcpAdapter; a reply waits for the write to land, or for the server's verdict against a remote, so "done" is never said before it is true. apply is one act, a plan of many as one batch ([{ mutation, args, as? }], a later call naming an earlier one's node as { "$plan": "<as>" }), or a take-back; --preview writes nothing. Both take the store backends graview serve takes — --data, --sqlite, --remote-url — and the seat flags --as and --roles. Every act that creates a kind accepts an optional id for the node it makes; every kind has a derived remove-<kind>, permitted through the acts that create it.
What it exports (83)
Read off the package's own barrel, so this is what is there today.
acrossallQuestionsapplyAffordanceapplyPlancompletionDecidecompletionForconfiguredRespondercreateInAppAdaptercreateMcpAdaptercreateToolRuntimedecideForDEFAULT_INTELLIGENCEdefaultProvidersdependentsOfderiveAffordancesderiveWithLlmdescribeIntelligencedescribePlandescribeProposaldescribeRundrawFiguredroppedProposalseditableFieldsFIGURE_STYLEfirstJsonObjectgraphDecidegraphResponderinsideinsightProviderintelligenceProviderinvariantProviderisPlanReferenceJEV_ENDPOINTJEV_INPUT_USD_PER_MILLIONJEV_MODELjevCostUsdjevDecideJevErrorjevKeyFromEnvironmentlandRunlensProviderllmIntelligencellmResponderloadIntelligenceConfigloadPinslocalCompletionnearestFigureNO_PINSnodeStateofferOfonlyTheSvgopenAiCompatibleCompletionpairQuestionplanFrompreviewAffordancequestionsForInvariantquestionsForKindquestionsForMutationreadRunreplyFromLoopreplyFromRunresolveProposalrunFromrungForrungHonestyRUNGSrunLoopsaveIntelligenceConfigsavePinsschemaProviderscoreToValuestillNeededstructureProvidertemplateIntelligencetoCalltogglePinusageBoostusageWeightsvalidateProposalsvalueOfwithinwithoutxaiCompletion