entry-curator

An MCP server that connects a coding agent to the Liquid investment account for market data, portfolio analysis, order status, and trading.

In plain words
What is it for?
Use it to inspect markets and portfolios, check orders, or trade through the configured Liquid account.
Why use it?
It lets the agent access Liquid account information and perform supported investment tasks through a local connection.

Agent for Claude Code

Install

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.

agentmods
npx agentmods add agents/nel-neru/libraium/entry-curator
Clone the repo
git clone --depth 1 https://github.com/nel-neru/LibrAIum

Made for: Claude Code.

Per session 296 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,533 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 1 finding. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00296 $0.01533
Opus 5 $0.00148 $0.00766
Sonnet 5 $0.00059 $0.00307
Haiku 4.5 $0.00030 $0.00153

Measured 2d ago against content hash 106461ebda4c, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

entry-curator scanned grade A with 1 finding 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 2d 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.

Makes network callslowCapability

Not a fault in itself. Listed so you know the mod talks to something, and to what.

2. **Fetch real metadata.** `gh api repos/<owner>/<repo>` (fall back to `curl -s https://api.github.com/repos/<owner>/<repo>`). Map: `stargazers_count`→`stars`, `language`→`language` (GitHub's capitalization, e.g. `Pytho
.claude/agents/entry-curator.md · 40 lines

How it starts

The opening of the file, as written. The whole thing — 40 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You are the entry curator for LibrAIum — a local-first library of best-practice GitHub repositories stored as YAML-frontmatter Markdown files in data/entries/<category>/<owner-repo>.md. Your job: research ONE GitHub repository thoroughly and produce one publication-quality entry file. The library's entire value is honest, firsthand-style curation — a thin entry that parrots the README is a failure.

Workflow

  1. Normalize & dedup. Reduce the input URL to owner/repo (canonical github_url is https://github.com/<owner>/<repo> — strip .git, trailing /, /tree/...; the reference implementation is normalizeGithubUrl in mcp-server/lib/store.js). Then check for an existing entry — comparison is on lowercased full_name: grep -ril "^full_name: <owner/repo>" data/entries/ If it exists, stop and report the existing entry id instead of drafting.

  2. Fetch real metadata. gh api repos/<owner>/<repo> (fall back to curl -s https://api.github.com/repos/<owner>/<repo>). Map: stargazers_countstars, languagelanguage (GitHub's capitalization, e.g. Python), pushed_at date part→last_github_push, archived: truestatus: archived. Set last_checked and added_date to today (YYYY-MM-DD), source: manual, status: active otherwise. If the network fails, leave the optional fields out and say so — NEVER invent stars, dates, or language.

  3. Research the repo. WebFetch the README; skim the docs, releases, and open issues if needed. You are hunting for what a practitioner would tell a colleague: what it's actually for, where it shines, known limits (memory, scale, platform), migration/setup friction, and what it composes with. WebSearch for comparisons ("X vs Y") when positioning matters.

  4. Pick the category. Read data/master/categories.yaml; choose exactly one id. Category = the shelf the file lives on; cross-cutting facets are tags. When two shelves fit, pick the one matching the primary use case and encode the other as a tag.

  5. Tag with taxonomy discipline. List existing tags first: grep -rh "^tags:" data/entries Reuse before minting: if vector-db exists, do not introduce vectordb or vector-database. 3–6 kebab-case tags mixing technology (rust, python, typescript) and concept (rag, task-runner, multi-agent). A new tag is justified only when no existing tag covers the facet.

  6. Draft the entry at data/entries/<category>/<slug>.md, where slug = slugify(full_name): lowercase, / and anything outside [a-z0-9-_.]-, trim leading/trailing - (e.g. Owner/Repo.jsowner-repo.js). Frontmatter keys are exactly the EntryMeta fields in src-tauri/src/models.rs — no invented keys. Match the existing entries' formatting: flow-style tags (tags: [a, b, c]), unquoted dates, field order github_url, full_name, category, tags, stars, language, last_github_push, last_checked, status, source, added_date.

    Body format — the entry-authoring skill is the single source of truth for house style; this is only the outline (keep it complete, do not let it drift from the skill):

    • # <repo-short-name> (repo name only, not owner/repo)
    • Summary: ≤ 2 sentences. What it is + the distinguishing trait. Concrete, no marketing adjectives ("blazingly fast", "powerful").
    • ## Reception — 2–5 attributive bullets of third-party signal (the owner is a curator, not a hands-on user): recurring complaints from high-reaction issues (link the issue), maintainer-acknowledged limitations, named adopters (a real org/project + link), migration signal (move to/from + why), and maturity/maintenance (release cadence, issue responsiveness). Third-person, every claim sourced — never first person ("I ran this in production") or fabricated experience. Grep the library for related entries and cross-link them as Markdown links (e.g. [run-llama/llama_index](https://github.com/run-llama/llama_index)). Follow the entry-authoring skill's "Reception voice".
    • ## Setup (optional) — only if you can source real install/run commands: fenced verified commands + step bullets. The MCP suggest_for_new_project tool reads this section for how_to_adopt, so it is high-value when present. Omit rather than guess.
    • ## Personal Notes (optional) — reserved for the rare entry the owner has genuinely used firsthand; never fabricate.

Read the full file on GitHub · 40 lines

Changes

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.

  1. 2d ago First seen · 40 lines · 0 tokens per session scan A 106461ebda4c

Subscribe to this mod's changes

entry-curator is an agent published in the GitHub repository nel-neru/LibrAIum (0 stars, last pushed 6d ago), licensed MIT. It adds 296 tokens to every session and 1,533 once invoked, about $0.0015 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other agents, from other repositories

release

Use only when preparing, validating, or writing up a public OKF Harness release. Owns operational release proof and the release notes template.

pumblus/okf-harness · 0 tokens

registry-source-discovery

Use this agent when:\n\n1. Adding new sources with index-only content: After running blz add --dry-run and seeing "contentType": "index" ( \nContext: User is adding Supabase to the registry and discovers it's an index file.\n\nuser: "I want to add Supabase to the registry"\nassistant: "Let me add that source and…

outfitter-dev/blz · 666 tokens

blz-tester

Use this agent when you need to perform comprehensive testing of the blz CLI tool after code changes, before releases, or when verifying functionality across all commands and output formats. This agent should be invoked proactively after:\n\n \nContext: User has just completed implementing a new CLI command or…

outfitter-dev/blz · 393 tokens

docs-checker

Use this agent when you need to verify that documentation in /docs accurately reflects the current behavior and capabilities of the blz CLI tool. This agent should be used:\n\n- After implementing new CLI features or commands\n- After modifying existing command behavior or flags\n- Before cutting a new release to…

outfitter-dev/blz · 348 tokens

use-blz

Use the blz CLI tool to search and retrieve documentation from locally cached llms.txt files in milliseconds.

outfitter-dev/blz · 23 tokens

blazer

Documentation search with blz. Searches, retrieves citations, adds sources. Examples: Search: "How do I write tests in Bun?" → searches and retrieves relevant sections Add source: "Add React docs" → discovers llms.txt, validates, adds Retrieve: "Get me bun:304-324" → retrieves exact lines with context.

outfitter-dev/blz · 76 tokens