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/anilist-mcp-server/releasenpx skills add Grinv/anilist-mcp-server --skill releasegit clone --depth 1 https://github.com/Grinv/anilist-mcp-serverWrote 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/anilist-mcp-server/release)<a href="https://agentmods.dev/skills/grinv/anilist-mcp-server/release"><img src="https://agentmods.dev/badge/skills/grinv/anilist-mcp-server/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.1 | $0.00048 | $0.01918 |
| Opus 5 | $0.00024 | $0.00959 |
| Sonnet 5 | $0.00010 | $0.00384 |
| Haiku 4.5 | $0.00005 | $0.00192 |
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 5d 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 — 122 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 also renames CHANGELOG.md's ## [Unreleased] heading to
## [X.Y.Z] - <today> (adding a fresh empty ## [Unreleased] above it) —
version.test.ts guards that version.ts/manifest.json/server.json never drift.
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 orphaned this repo's own v0.1.2 (twonpm versionruns six minutes apart, the first tag/commit never pushed — see CHANGELOG.md's note on that version). 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. It blocksnpm versionifCHANGELOG.md's[Unreleased]section is empty at that point: 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.)
Do NOT rename ## [Unreleased] to a dated heading yourself before running
npm version. That used to be this skill's documented step 1 and it's a
confirmed, self-inflicted failure mode: the preversion gate checks whether
[Unreleased] is populated, and by definition it's empty right after you've
already moved its entries into a dated section — so a manual pre-rename
guarantees the gate blocks, forcing an awkward CONFIRM_EMPTY_CHANGELOG=1
override for a release that isn't actually empty. sync-version.mjs now does
this rename itself, from inside the version lifecycle script, which runs
strictly after the preversion gate has already passed — so the entries
are still under [Unreleased] (and thus visible to the gate) at exactly the
moment it matters, and get filed under the right dated heading automatically
right after.
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 and leave them under[Unreleased]— don't rename the heading (see above). - 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's andserver.json'stoolsarrays,server.json'senvironmentVariables, README's tool table, AGENTS.md'ssrc/tree). - Commit all of the above.
npm version <patch|minor|major>— preversion gate, then bumps + syncs every file (including the CHANGELOG rename) + commits + tagsvX.Y.Z.git push --follow-tags— pushing the tag triggers.github/workflows/release.yml.
The tag push (v*) runs the Release workflow: check:api gate → 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, GitHub OIDC;
pinned to an exact version + verified SHA-256 rather than latest, since this
step runs with live OIDC publishing credentials).
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.
- 5d ago First seen · 122 lines · 48 tokens per session scan A aa2d923ba70b
release is a skill published in the GitHub repository Grinv/anilist-mcp-server (1 stars, last pushed 12d ago), licensed MIT. It adds 48 tokens to every session and 1,918 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 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).
live-audit
Audit mal-mcp — build/test/lint gate, live MCP tool edge-case sweep (input validation, not-found paths, mutations with capture/revert), source-level code review, and docs/metadata consistency. Use when asked to test/audit the published or just-fixed mal-mcp package, hunt for bugs/edge cases, or repeat "the same kind…
prompt-check
Live-test every MCP Prompt in src/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.
tool-description-check
Self-check a new or edited MCP tool description/field .describe() text before committing — verify every behavioral claim against live testing, check for contradictions with sibling tools, and score against Glama's Tool Definition Quality Score (TDQS) rubric. Use whenever a tool description or schema field description…
docs-consistency-check
Check README/manifest.json/server.json/CHANGELOG.md/AGENTS.md and docs/.md for drift against the actual registered tools and source. Use after adding, renaming, or removing a tool, or as part of a live-audit pass.