claude plugin validate: read the hooks and calls lines of a mod

Before installing a Claude Code mod, run claude plugin validate and read its hooks and calls lines. Which combinations matter when Sume's MCP is connected.

5 min readSume
All posts

Run claude plugin validate ./some-mod on a copy of the mod's files and read two lines: hooks: lists the events the mod handles, and calls: lists the mods API methods its code uses, such as $.fs.read or $.http.fetch. It does this without running the mod. If your session has Sume's hosted MCP connected, the combinations to look for are a mod that sees every tool call, a mod that can call MCP tools itself, and a mod that reads environment variables and also reaches the network.

The command and its output format come from Claude Code's organization guide and mods overview, read 2026-10-03. The Sume reading of each line is this post's.

What does the output look like?

Claude Code's documented sample is below. Fetch the plugin's files first, for example by cloning its repository; the command takes a directory.

claude plugin validate ./some-mod

#   ./register.js hooks: session.start, tool.call, ui.render{component=Pane}
#   ./register.js calls: $.fs.read, $.http.fetch, $.store.set, $.ui.open

What do the calls lines mean for Sume?

Claude Code's admin guide has a table of calls to look for. The table below keeps its meaning and adds the consequence for a session where Sume's hosted MCP is connected, or where the Sume CLI is installed on the same machine.

Calls from Claude Code's admin guide, with the Sume consequence, read 2026-10-03.
CallClaude Code says itIf Sume is connected
$.mcp.callCalls a tool on a connected MCP server, under the session's permission rulesThe mod can call Sume tools. A paid call still needs Write on the OAuth session or an API key, and an idempotency_key.
$.env.get, $.settings.readReads environment variables and settings, which can hold API keysSUME_API_KEY is readable if it is exported. An env reads: line names each variable.
$.http.fetchMakes network requestsAnything the mod reads can leave the machine.
$.fs.readReads files anywhere the user canThe CLI's ~/.sume-com/config.json.
$.process.runStarts programs as the userThe sume binary, with whatever login it holds.
$.env.setSets an environment variable for Claude Code and everything it starts laterCould change what an MCP server or command runs with; an env writes: line names each variable.

What do the hooks lines mean?

Claude Code's guide reads them this way. tool.call and prompt.submit mean the mod sees every tool call and every prompt and can change them, which includes the arguments of a Sume generate_video call and the prompt you wrote for it. tool.check means it can approve or deny a call before a permission prompt appears. session.append means it can rewrite each row of the conversation before it is stored. ui.render{component=AskUserQuestion} means it can redraw the dialog Claude uses to ask you something.

A mod with tool.call is not suspect by itself; a spend guard needs it, as the counter mod shows. The question is whether the calls line matches what the mod says it does. A token-chart mod has no reason to use $.http.fetch.

What is the checklist?

Use this after you run the command and before you install. It takes a couple of minutes and needs no code beyond reading the output.

  • Does hooks: match the README's claim? A pane mod should list ui.render, not tool.check.
  • Is there an env reads: line? If it names SUME_API_KEY or another credential, stop.
  • Does it pair $.env.get or $.fs.read with $.http.fetch? That pair is the one that can move a secret off the machine.
  • Does it use $.mcp.call or $.process.run? Then it can act on Sume without the model asking.
  • Does validate refuse to read it? Claude Code refuses to load a mod that uses the API in a way the command cannot read.

What does validate not tell you?

It lists methods, not arguments, so $.http.fetch does not say which host. It does not run the mod or test its logic. And it describes what the code asks Claude Code to do, not what a process the mod starts will do afterward. For that, read the source, or have an administrator keep unreviewed mods out with allowManagedModsOnly. To try a mod once with nothing else, load its directory with --plugin-dir, and check /plugin for the line that names the mods the session loaded.

A reasonable routine is to validate, read the source for anything that touched the network, load the mod once with --plugin-dir in a throwaway project with no Sume credentials set, and only then install it. If the mod turns out to need Sume access, give it OAuth with Write off first, and widen only when a task needs it.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume