Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/grinv/tmdb-mcp/releasenpx skills add Grinv/tmdb-mcp --skill releasegit clone --depth 1 https://github.com/Grinv/tmdb-mcpWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/grinv/tmdb-mcp/release)<a href="https://agentmods.dev/skills/grinv/tmdb-mcp/release"><img src="https://agentmods.dev/badge/skills/grinv/tmdb-mcp/release.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00047 | $0.01855 |
| Opus 5 | $0.00023 | $0.00928 |
| Sonnet 5 | $0.00009 | $0.00371 |
| Haiku 4.5 | $0.00005 | $0.00186 |
Grade A, and why
release scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 117 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Releasing
package.json is the single source of truth for the version. The npm
version lifecycle hook runs scripts/sync-version.mjs, which propagates it to
src/version.ts, manifest.json and server.json (incl. the .mcpb release-asset
URL), and moves CHANGELOG.md's [Unreleased] notes under a new
## [x.y.z] - <date> heading (leaving [Unreleased] empty); version.test.ts
guards that the version files never drift and that a heading for the current
version exists. This used to be a manual "docs: move Unreleased notes under
X.Y.Z" step that had to happen before npm version — easy to forget, or
easy to do in the wrong order (a v0.9.0 release once shipped tagged with
CHANGELOG.md still saying "Unreleased", caught by nothing). It's now
atomic with the version bump itself, so there's no ordering to get wrong.
sync-version.mjs and preversion-check.mjs locate the repo root via
fileURLToPath(import.meta.url) + dirname() — no Node-version floor above
the package's own engines.node (≥ 20.11) applies to running npm version
yourself.
A preversion hook (scripts/preversion-check.mjs) runs first, with two checks:
- Unpushed-tag race: if the current
package.jsonversion already has a local git tag, it blocks unless that tag is also onorigin— this is the exact race that once orphaned a version in a sibling repo (npm versionrun twice within minutes, the first tag/commit never pushed, silently buried under the second). Push the dangling tag (git push origin vX.Y.Z) or delete it if it was a mistake (git tag -d vX.Y.Z), then retry. - Empty
[Unreleased]: presence-only safety net, not a substitute for actually running the skill below as a real judgment step. Run thechangelog-styleskill against the commits since the last tag first — it's what actually makes the entries short, self-describing, free of implementation detail, and linked to their commits; the hook only confirms something is there, not that it follows that style. (Or re-run withCONFIRM_EMPTY_CHANGELOG=1if this release genuinely has no user-facing changes, e.g. a pure dependency bump.)
When invoked as this skill, run these as explicit steps, not optional —
don't rely on the preversion hook alone to catch a skipped one:
- Invoke the
changelog-styleskill against the commits since the last tag; write/fix the[Unreleased]entries per its style rules. Leave them under[Unreleased]— do not hand-rename that heading to the target version;npm version(step 4) does that automatically now. - Run the
docs-consistency-checkskill — none of this is version-bump mechanics, sosync-version.mjs/version.test.tsdon't catch drift here, and it accumulates silently across several PRs (manifest.json'stools/promptsarrays,server.json'senvironmentVariables/ description length, README's tool table, AGENTS.md'ssrc/tree). Notetop_by_entity'stextbranches onmedia_type/genre, so re-check it whenever that branching logic changes, not just when its wording does. - Commit all of the above.
npm version <patch|minor|major>— preversion gate, then bumps + syncs every file + commits"release: vX.Y.Z"+ tagsvX.Y.Z.git push --follow-tags— pushing the tag triggers.github/workflows/release.yml.
The tag push (v*) runs the Release workflow: build → test
→ pack .mcpb → extract CHANGELOG.md's section for this version (fails loudly,
not silently, if that section is empty — the workflow's own safety net for
whatever slipped past sync-version.mjs/preversion-check.mjs) → GitHub Release
→ npm publish (OIDC trusted publishing, with provenance, pinned to an exact
verified-good npm version — no token; skipped without failing the job if this
version is already on npm, so a re-run after a partial failure doesn't abort) →
inject the just-packed .mcpb's SHA-256 into server.json (fails loudly if the
injection didn't actually match a package, instead of silently leaving a stale
hash) → publish to the official MCP Registry (mcp-publisher, pinned to an
exact version + verified SHA-256 rather than latest — it runs with live OIDC
publishing credentials, so it gets the same pin discipline as everything else
in this job — GitHub OIDC).
Never hand-edit the version in the derived files; bump package.json via
npm version and let the hook sync the rest.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 117 lines · 47 tokens per session scan A 62d00762378c
release is a skill published in the GitHub repository Grinv/tmdb-mcp (4 stars, last pushed 10d ago), licensed MIT. It adds 47 tokens to every session and 1,855 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
release
Cut a release of steam-games-mcp — draft CHANGELOG entries, check docs/metadata consistency, then bump/tag/push. Use when asked to release, cut a version, or publish a new version of this package.
release
Cut a release of mal-mcp — draft CHANGELOG entries, check docs/metadata consistency, then bump/tag/push. Use when asked to release, cut a version, or publish a new version of this package.
changelog-style
Turn a commit range into CHANGELOG.md entries following common-changelog style. Use when finishing a PR (adding to the [Unreleased] section) or cutting a release (moving [Unreleased] under a new version heading).
changelog-style
Turn a commit range into CHANGELOG.md entries following common-changelog style. Use when finishing a PR (adding to the [Unreleased] section) or cutting a release (moving [Unreleased] under a new version heading).
live-audit
Audit steam-games-mcp — build/test/lint gate, live MCP tool edge-case sweep (input validation, SteamID64/vanity/appid edge cases, key-gating), and source-level code review. Use when asked to test/audit the published or just-fixed steam-games-mcp package, hunt for bugs/edge cases, or repeat "the same kind of testing as…
prompt-check
Live-test every MCP Prompt in src/tools/prompts.ts through the real MCP protocol (not a static read) across every argument combination. Use when a prompt is added or its argument-handling logic changes, or as part of a live-audit pass.