Alim Polat
6821568523
* feat(registry): add Bank Statement Sheet MCP server An MCP server that converts PDF bank statements into transaction data which arrives with a pass/fail reconciliation verdict. Each file is checked against its own printed figures — balance continuity where the bank prints a running balance, footing against the statement's control totals where it does not. Below the threshold the rows are withheld and an agent has to ask for them explicitly. Covers the path the bank import does not: CAMT.053 and CSV are supported, the PDF itself has no way in. Verified against the sandbox 2026-08-07: 14 of 14 transactions imported under Bankfil, Inkomster 35 500 kr and Utgifter −23 540,86 kr to the öre, zero warnings and zero skipped rows on the semicolon + comma-decimal CSV. Writes nothing to accounted and requests no scopes. First-time contributor, so the author profile is added in the same PR. npm run validate:registry: 21 entries, 3 authors, 0 failures. Signed-off-by: alimpolat <alimpolat@users.noreply.github.com> * fix(registry): correct two claims and drop prose em dashes Addresses the CodeRabbit review on #1472. The verdict did not survive where the entry said it did. It claimed the per-row marker "overlever" decomposition into vouchers, which reads as the verdict persisting into accounted. It does not: the flag exists only in the MCP response, and nothing imported carries it. Now says so, and says the reader must have seen the verdict before importing rather than expect to find it in the books afterwards. "Den kor inte lokalt" was wrong about the wrong thing. The MCP server does run locally over stdio; it is the conversion that is remote. The sentence now separates the local stdio process from the EU API, keeping the server-side engine, thin MIT client and EU data location intact. Em and en dashes removed from both files per the repo's coding guidelines. Five occurrences, not the three flagged. Not taken: pinning the install command to @0.1.0. Pinning would leave every installed copy on the first release with no path to fixes; the version field records what was verified, and the body already dates it. npm run validate:registry: 21 entries, 3 authors, 0 failures. Signed-off-by: alimpolat <alimpolat@users.noreply.github.com> --------- Signed-off-by: alimpolat <alimpolat@users.noreply.github.com> Co-authored-by: alimpolat <alimpolat@users.noreply.github.com>
Community Registry
This directory is the source of truth for the registry shown at gnubok.se/community/registry: skills, MCP servers, workflows and apps built on Accounted. The website syncs its registry pages from here, so adding an entry is a normal pull request against this repo.
Structure
registry/
entries/ one .mdx file per registry entry
authors/ one .mdx file per author profile
Files starting with _ are templates and are ignored by validation and sync.
Adding an entry
- Copy
entries/_template.mdxtoentries/<your-slug>.mdx. The filename is the slug and the public URL:gnubok.se/community/registry/<your-slug>. - If this is your first contribution, copy
authors/_template.mdxtoauthors/<your-handle>.mdx. Theauthorfield in your entry must match an author file, so first-time contributors add both files in the same PR. - Validate locally:
npm run validate:registry(ornpx tsx scripts/validate-registry.tswithout installing everything). - Open a PR. Commits need a DCO sign-off (
git commit -s), same as the rest of the repo; see CONTRIBUTING.md.
A maintainer reviews the entry (does it work, does it describe itself honestly, is the content safe) and merges. After merge the website pulls the entry in with its registry sync; expect it live on the site within a few days of merging.
Entry frontmatter
Required:
| Field | Type | Notes |
|---|---|---|
title |
string | Shown as the card and page title |
description |
string | Card subtitle, max 500 chars; put detail in the body |
slug |
string | Must equal the filename |
kind |
skill | mcp | workflow | app |
Which shelf it goes on |
author |
string | Handle of a file in authors/ |
status |
live | beta | archived |
Be honest; beta is fine |
lang |
sv | en |
Language of the entry body |
personas |
list | Any of founder, finance, byra, developer |
publishedAt |
date | YYYY-MM-DD |
updatedAt |
date | YYYY-MM-DD, bump when you edit |
At least one of installCommand, downloadUrl, repoUrl, externalUrl is
required so readers can actually get the thing. Optional extras:
featured (maintainer-set), oauthScopes, gnubokTools (which MCP tools it
touches), requiresWriteScope, sieCompatible, version, faq (list of
{q, a}), related (list of slugs), ogImageEyebrow.
Body rules
The body after the frontmatter is plain Markdown (headings, lists, tables,
links, fenced code blocks). The website renders bodies through MDX, which
evaluates raw tags (lowercase HTML included), {...} expressions and
import/export statements at build time, so the validator rejects all of
them. Fenced code blocks and backtick inline code are fine; they are
displayed, never executed. Need a literal <tag> or {value} in prose? Put
it in backticks.
Write the body like documentation, not a landing page: what it does, what it needs (scopes, API keys), what it will not do, and one honest limitation beats three superlatives.
What gets accepted
- It must exist and work against Accounted today (the live app or the MCP server).
- It must describe its write behavior truthfully. Anything that writes to the ledger goes through staged operations that a human approves; entries that work around that will not be listed.
- No fees are charged for listing, and your IP stays yours. Entries are documentation and are contributed under this repo's license; the thing the entry points to keeps whatever license you gave it.