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.

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.openWhat 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.
| Call | Claude Code says it | If Sume is connected |
|---|---|---|
$.mcp.call | Calls a tool on a connected MCP server, under the session's permission rules | The 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.read | Reads environment variables and settings, which can hold API keys | SUME_API_KEY is readable if it is exported. An env reads: line names each variable. |
$.http.fetch | Makes network requests | Anything the mod reads can leave the machine. |
$.fs.read | Reads files anywhere the user can | The CLI's ~/.sume-com/config.json. |
$.process.run | Starts programs as the user | The sume binary, with whatever login it holds. |
$.env.set | Sets an environment variable for Claude Code and everything it starts later | Could 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 listui.render, nottool.check. - Is there an
env reads:line? If it namesSUME_API_KEYor another credential, stop. - Does it pair
$.env.getor$.fs.readwith$.http.fetch? That pair is the one that can move a secret off the machine. - Does it use
$.mcp.callor$.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
- Contract-test Sume API responses against openapi.json (pytest)
Validate recorded Sume responses against the OpenAPI schema with jsonschema, including the OpenAPI 3.0 nullable fix. A tested pytest file and fixtures guide.
- DBOS Python durable workflow for a Sume job: resume after a crash
Submit and poll a Sume image job in a DBOS workflow: step retries, order-derived Idempotency-Key and workflow id, tested with DBOS 3.2.0 on SQLite.
- Dub one Short into 8 languages: Python fan-out and the total cost
Detach and transcribe once, then run one TTS job and one render per language. A Python fan-out and the per-Short bill, from Sume's catalog rates.
- FLUX 3 bounding box to a mask_url: Python region edit on Sume
FLUX 3 Image boxes use [top, left, bottom, right] on a 0-1000 grid. Convert one to an RGBA mask with Pillow and run the region edit on Sume's GPT Image 2.5.
Written by Sume