FirmLedger

npx add-mcp 'https://firmledger.co.ke/mcp'

A Model Context Protocol server for the FirmLedger ledger. It has 36 tools: read-only directory lookups, reads of the key owner’s own account, account changes that always need the user’s explicit confirmation, and checkout links that never charge anything. It follows the website’s permission model exactly. Setting it up in an AI app? Start with the plain-English setup guide.

On this page

Endpoint & transport Authentication Access levels & scopes Confirmation handshake Checkout links Result format Tools (36) Open tools (12) Pro directory tools (4) Account reads (8) Account changes (12) Errors Limits Safety guarantees Raw examples

Endpoint & transport

URL	https://firmledger.co.ke/mcp (or https://firmledger.co.ke/mcp/<api_key>, see below)
Transport	Streamable HTTP, stateless. POST JSON-RPC 2.0, answered as application/json. There are no sessions, so no Mcp-Session-Id is issued. GET returns 405 because the server has no server-initiated stream (clients configured for the older SSE transport fail here). A browser (Accept: text/html) is redirected to the setup guide.
Capabilities	tools only, plus server instructions that tell the model how the confirmation and checkout rules work. Tool annotations are accurate: directory and account-read tools carry readOnlyHint: true. Account changes carry readOnlyHint: false with per-tool destructiveHint / idempotentHint, so clients that ask before side effects (ChatGPT, VS Code and others) do so.
Built on	The official @modelcontextprotocol/sdk, mounted inside the FirmLedger web app. Server name firmledger.
CORS	Access-Control-Allow-Origin: *. Authentication is by key, never by cookie, so browser-based clients work and a browser session can never be ridden.
Caching	Cache-Control: no-store, X-Robots-Tag: noindex. Every response carries X-Request-Id.

Authentication

Keys are ordinary FirmLedger API keys (fl_live_ + 32 characters), created at /dashboard/api. Every key needs the read:listings scope. Send it one of three ways:

preferredAuthorization: Bearer fl_live_your_key # X-API-Key: fl_live_your_key ← accepted alternative # POST https://firmledger.co.ke/mcp/fl\_live\_your\_key ← personal connector URL

Why a key-in-path URL exists. The REST API refuses keys in URLs. The MCP endpoint accepts one because ChatGPT’s custom connectors can only use OAuth or no authentication (no custom headers), and Claude’s header option is a limited beta. The personal URL is therefore the one method that works in every consumer app. The trade-off is that the URL is a bearer credential. Treat it like a password and revoke the key if it leaks. The server never echoes the key in a response, redirect or error. Use the header wherever the client supports one.

No key	Allowed. The caller is free with authenticated: false and gets exactly what a signed-out visitor sees on the website.
Valid key	The caller is pro if the key’s account has Pro (paid or trial), otherwise free. This is decided live on every request, so a lapsed plan drops to free immediately and a renewal restores Pro with the same key.
Unknown / malformed key	HTTP 401 with WWW-Authenticate: Bearer. It is never silently downgraded to Free access, so a mistyped key fails loudly. Failures count toward the per-IP brute-force lock shared with the REST API.
Revoked key	HTTP 401, reason: key_revoked
Suspended account	HTTP 403, reason: account_suspended
Key without read:listings	HTTP 403, reason: insufficient_scope

Access levels & scopes

There is one permission model with two front doors. For directory data, the MCP server uses the site’s own rule (canViewFull): full details are visible to Pro accounts, and to the owner of a listing for their own record. What a profile page shows everyone (the Sources panel, for example) the connector shows everyone too.

open	Anyone, including with no key: search_listings, get_listing, list_categories, list_countries, prepare_listing_submission, compare_listings, list_plans, list_ad_packages, prepare_upgrade, prepare_advertising, prepare_listing_claim, connection_status
pro	Key + Pro: get_relationships, get_news, list_jobs, check_domain
account_read	Key + Pro + scope read:account (“AI assistant — read my account”)
account_write	Key + Pro + scope write:account (“AI assistant — act for me”) + a confirmation on every call
Gate order	Checked in this order: key → Pro → scope. The first failure returns key_required, pro_required (with upgrade_tool: "prepare_upgrade") or scope_required (with required_scope).
Opt-in scopes	read:account and write:account are not in a new key’s defaults. The member ticks them when creating the key, or later under the key’s Scopes. Changes apply on the next call.
Pro-only fields in get_listing	website, email, phone, social_links, key_people, timeline, technology. They are omitted from the basic profile and named in access.locked_fields, exactly as the profile page hides them.
Never available	Other members’ data of any kind; payments and invoices; admin and moderation data; unapproved (pending or rejected) records in the directory tools, and jobs or relationships belonging to them. Account tools only ever see the key owner’s own listings, leads, notifications, watchlist and tickets.

Confirmation handshake

Every account_write tool takes an optional confirmation_token and runs in two steps:

1. Prepare. Call without a token. The server validates everything and writes nothing. It returns either {"status":"no_change","message":…} (already in that state) or: { "status": "confirmation_required", "action": "reply_to_lead", "action_summary": "Send this reply to Wanjiku Buyer in conversation #12 (Boss Co): “Happy to demo on Tuesday.”", "details": { … }, "confirmation_token": "…", "expires_in_seconds": 600, "instructions": "Nothing has been done yet. Show action_summary to the user … Never confirm on their behalf." }
2. Ask. The assistant shows action_summary to the user and waits for a clear yes.
3. Confirm. Call again with the same arguments plus confirmation_token. The server re-validates against the current state, consumes the token, runs the action through the same code path as the dashboard, and returns the result with "status": "done".

Token binding	HMAC-signed and bound to the API key, the user, the tool name and a hash of the exact arguments. It is valid for 10 minutes and single-use: it is consumed even if the action then fails.
Failures	confirmation_invalid with reason: invalid (malformed or forged), expired, mismatch (other tool, key or user), args_changed (arguments differ from the confirmed ones) or used. Nothing is done in any of these cases.
Why tokens	A model cannot skip the prepare step, alter a message after the user approved it, or replay one approval for several actions. Clients’ own approval prompts (driven by the annotations) are a second, independent layer.

Checkout links

prepare_upgrade and prepare_advertising return checkout_url: a signed link to /go/checkout/<token> that says who it was made for and what it buys. They charge nothing, create nothing and never see card data. No tool can confirm or complete a purchase.

GET the link	A review page (plan or package, price, listing, account). It changes nothing, so chat-app link previews are harmless. Not signed in → 302 to /login?next=…. Signed in as a different account, or a tampered token → 409, with nothing charged.
POST (the member’s button)	Requires the session CSRF token, repeats every check against the signed-in account, records the payment intent exactly as the dashboard’s own buttons do (same FLPRO- / FLAD- references the webhooks match), then hands off to the existing Lemon Squeezy hosted checkout.
Lifetime	24 hours. Also behind the payments maintenance switch.
No key	Returns status: "sign_in_needed" with the pricing or advertise page instead of a personal link.
Model guidance	Each result carries a note: if the user says “yes, do it”, give them the link again. Never claim a purchase is done.

Result format

Each successful tool result has a one-line summary plus the JSON payload in content[0].text, and the same payload as structuredContent. Errors the assistant should explain (not found, permission, invalid input, confirmation problems) are tool results with isError: true and structuredContent.error = { code, message, … }, never protocol failures.

pro_required{ "isError": true, "structuredContent": { "error": { "code": "pro_required", "message": "Get news is a FirmLedger Pro feature, and the account behind this API key is not on Pro. …", "tier": "free", "upgrade_url": "…/pricing", "upgrade_tool": "prepare_upgrade", "setup_guide_url": "…/docs/mcp" } } }

Tools

This list is generated from the server’s live tool definitions, so it can’t drift from what the server offers. A listing argument accepts a slug (best), an exact name, a FirmLedger ID such as FL-00012, or a profile URL. Several exact-name matches return ambiguous with candidates. No match returns not_found, with any similarly named records labelled as different records.

Open tools open

No key needed. With a key they respect the caller’s tier, e.g. get_listing adds the Pro fields for Pro.

get_listing Open · no key

Get a FirmLedger company profile. The public FirmLedger profile of one company: description, category, location, verification state (tick, how ownership was proved, when it was last checked), confidence and health scores, sources, recent moderated news headlines and the open jobs count. With FirmLedger Pro it also includes website, email, phone, social links, key people, timeline and technology — the same line the website draws.

listing *	string (≤ 300 chars) The company: its FirmLedger slug (best — returned by search_listings), its exact name, its FirmLedger ID such as "FL-00012", or its FirmLedger profile URL.

list_countries Open · no key

List countries on FirmLedger. The countries present in the FirmLedger directory, each with its number of approved listings.

No arguments.

prepare_listing_submission Open · no key

Prepare a FirmLedger listing submission link. Does NOT create anything. Returns a link to the real FirmLedger submission form with the company name, website and (optional) category, country and city pre-filled. The user opens it, signs in, completes the remaining fields, reviews everything and submits it themselves. Also reports if the company is already listed, so nothing is submitted twice.

name *	string (≤ 120 chars) Company name.
website	string (≤ 200 chars) Company website, e.g. "example.co.ke".
category	string (≤ 60 chars) Optional category.
country	string (≤ 60 chars) Optional country.
city	string (≤ 80 chars) Optional city.

compare_listings Open · no key

Compare FirmLedger listings side by side. Compare 2 to 4 approved FirmLedger companies side by side: entity type, category, location, founded, team size, website, tagline, date registered, ownership, tick, confidence and sponsored status — the same rows as the FirmLedger comparison page. Use after search_listings when the user wants to weigh companies against each other.

listings *	string[] (2–4 items) 2 to 4 companies (slugs are best).

list_plans Open · no key

List FirmLedger Pro plans. The current FirmLedger Pro offers with price, billing and duration. With an API key it also says whether this account is already on Pro and whether a free trial is available. Use before prepare_upgrade.

No arguments.

prepare_upgrade Open · no key

Prepare a FirmLedger Pro checkout link. Does NOT charge anything. Returns a personal link to FirmLedger's own checkout for the chosen Pro plan (optionally with a promo code). The user opens it, signs in, reviews the order on FirmLedger and pays on the secure Lemon Squeezy checkout themselves. You can never complete or confirm a payment and must never ask for card details; if the user says "yes, do it", give them the link again. Without an API key it returns the pricing page instead.

plan	string (≤ 120 chars) The plan id from list_plans (or its exact name).
promo_code	string (≤ 40 chars) Optional promo code the user gave you.

prepare_listing_claim Open · no key

Prepare a listing ownership claim. Free. Prepare a link to claim an approved listing using DNS TXT, HTML meta tag or site badge. Creates nothing and never grants ownership. The user signs in, generates a token, installs the proof on the business domain and verifies it on FirmLedger.

listing *	string (≤ 300 chars) The company: its FirmLedger slug (best — returned by search_listings), its exact name, its FirmLedger ID such as "FL-00012", or its FirmLedger profile URL.
method	"dns" | "meta" | "badge"

connection_status Open · no key

Check FirmLedger connection access. Report what this FirmLedger connection can do: Free or Pro access, authentication and active free-trial status, and which tools and fields are available. Use when the user asks why something is locked.

No arguments.

Pro directory tools pro

Need a key whose account has Pro (paid or trial).

get_relationships PRO

Get a company's relationship graph (Pro). FirmLedger Pro. The recorded relationship graph of one company: founders, investors, parent companies, subsidiaries, products, services and partners — plus the reverse edges (companies it founded or invested in). Only relationships recorded by the verified owner or moderators; nothing is inferred.

listing *	string (≤ 300 chars) The company: its FirmLedger slug (best — returned by search_listings), its exact name, its FirmLedger ID such as "FL-00012", or its FirmLedger profile URL.

get_news PRO

Get moderated company news (Pro). FirmLedger Pro. Recent moderated news headlines about one company with dates, publishers and links — the same accuracy-gated stories shown on the profile's news panel.

listing *	string (≤ 300 chars) The company: its FirmLedger slug (best — returned by search_listings), its exact name, its FirmLedger ID such as "FL-00012", or its FirmLedger profile URL.
limit	integer (min 1 · max 12 · default 10) Stories to return (1-12).

list_jobs PRO

List open jobs (Pro). FirmLedger Pro. Open roles at approved FirmLedger companies, filtered by company and/or location and keyword: title, company, location, posted date and where to apply. Jobs on unapproved listings never appear.

company	string (≤ 300 chars) Optional company (slug, exact name, FirmLedger ID or profile URL).
location	string (≤ 80 chars) Optional location, e.g. "Nairobi" or "Kenya" or "Remote".
query	string (≤ 80 chars) Optional keyword in the job title or description.
limit	integer (min 1 · max 25 · default 10)
offset	integer (min 0 · max 10000 · default 0)

check_domain PRO

Check whether a website is listed (Pro). FirmLedger Pro. Given a website domain or URL, report whether an approved FirmLedger record uses it and return that record — useful for "is this site legit?" questions.

domain *	string (≤ 200 chars) A domain such as "example.co.ke" or a full URL.

Account reads account_read

Need a key + Pro + the opt-in read:account scope. Only ever return the key owner’s own data.

get_my_listings PRO read:account

List my FirmLedger listings. The listings this account owns or submitted, with moderation status, tick, scores, Pro perks, sponsorship, jobs and new-lead counts. Use first when the user refers to "my listing".

No arguments.

get_analytics PRO read:account

Read my audience analytics. Audience analytics for the user's own listings — views today/7/30 days/total, unique visitors, profile and website clicks, leads, the 30-day funnel, top visitor locations and per-listing views. The same numbers as Dashboard → Audience analytics.

listing	string (≤ 300 chars) Optional: one of the user's listings. Omit for all of them combined.

list_leads PRO read:account

List my leads. The user's FirmLedger Leads inbox: inquiries received on their listings (box "received", the default), archived ones ("archived"), or inquiries they sent to other businesses ("sent"). Filter by status or listing; paginated.

box	"received" | "archived" | "sent"
status	"new" | "contacted" | "qualified" | "won" | "lost"
listing	string (≤ 300 chars) Optional: only leads for this listing of the user's.
limit	integer (min 1 · max 50 · default 20)
page	integer (min 1 · default 1)

get_lead PRO read:account

Read one lead conversation. One conversation from the Leads inbox with the inquirer's details and every message, oldest first. Use before reply_to_lead so the reply fits the thread.

lead_id *	integer (min 1) lead_id from list_leads.

get_watchlist PRO read:account

Read my watchlist. The companies the user watches on FirmLedger, newest first.

No arguments.

export_watchlist_csv PRO read:account

Export my watchlist as CSV. The user's watchlist as CSV text (name, category, type, location, contact details, tech stack, verified owner, confidence, watched since) — the same file as the dashboard's Export button.

No arguments.

get_notifications PRO read:account

Read my notifications. The user's in-app FirmLedger notifications, newest first, with the unread count. Set unread_only for just the unread ones.

unread_only	boolean (default false)
limit	integer (min 1 · max 60 · default 20)

list_my_tickets PRO read:account

Read my support tickets. The user's FirmLedger support tickets. Pass a ticket reference to read that ticket's full conversation.

ticket	string (≤ 40 chars) Optional ticket reference, e.g. "TK-1A2B3C".

Account changes account_write

Need a key + Pro + the opt-in write:account scope, and the confirmation handshake on every call.

reply_to_lead PRO write:account · confirms

Reply to a lead. Send a reply in one of the user's lead conversations, exactly as the Reply box on the website does (the other party is notified). Requires the user's confirmation: the first call returns the exact message for them to approve.

lead_id *	integer (min 1)
message *	string (≤ 4000 chars) The reply text, written or approved by the user.
confirmation_token	string (≤ 2048 chars) Leave empty on the first call: you get an action_summary and a token instead of the action. After the user explicitly confirms that summary, call again with the SAME arguments plus this token.

set_lead_status PRO write:account · confirms

Change a lead's status. Move a lead in the user's business inbox to new, contacted, qualified, won or lost. Requires the user's confirmation.

lead_id *	integer (min 1)
status *	"new" | "contacted" | "qualified" | "won" | "lost"
confirmation_token	string (≤ 2048 chars) Leave empty on the first call: you get an action_summary and a token instead of the action. After the user explicitly confirms that summary, call again with the SAME arguments plus this token.

watchlist_add PRO write:account · confirms

Add a company to my watchlist. Add an approved company to the user's watchlist so they are notified when its record changes. Requires the user's confirmation.

listing *	string (≤ 300 chars) The company: its FirmLedger slug (best — returned by search_listings), its exact name, its FirmLedger ID such as "FL-00012", or its FirmLedger profile URL.
confirmation_token	string (≤ 2048 chars) Leave empty on the first call: you get an action_summary and a token instead of the action. After the user explicitly confirms that summary, call again with the SAME arguments plus this token.

watchlist_remove PRO write:account · confirms

Remove a company from my watchlist. Remove a company from the user's watchlist. Requires the user's confirmation.

listing *	string (≤ 300 chars) The company: its FirmLedger slug (best — returned by search_listings), its exact name, its FirmLedger ID such as "FL-00012", or its FirmLedger profile URL.
confirmation_token	string (≤ 2048 chars) Leave empty on the first call: you get an action_summary and a token instead of the action. After the user explicitly confirms that summary, call again with the SAME arguments plus this token.

create_support_ticket PRO write:account · confirms

Open a support ticket. Open a FirmLedger support ticket for the user. Categories: billing, technical, listing, account, verification, other. Requires the user's confirmation of the exact subject and message.

subject *	string (≤ 200 chars)
category *	"billing" | "technical" | "listing" | "account" | "verification" | "other"
body *	string (≤ 5000 chars) The issue in a few sentences.
confirmation_token	string (≤ 2048 chars) Leave empty on the first call: you get an action_summary and a token instead of the action. After the user explicitly confirms that summary, call again with the SAME arguments plus this token.

post_job PRO write:account · confirms

Post a job on my listing. Submit a job opening on one of the user's listings (the listing needs active Pro perks; up to 5 open or pending roles). Like the dashboard form, it goes to moderation first and is published after approval. Requires the user's confirmation.

listing *	string (≤ 300 chars) One of the user's own listings.
title *	string (≤ 80 chars)
role_type	"Full-time" | "Part-time" | "Contract" | "Internship" | "Remote"
location *	string (≤ 80 chars) City, or "Remote".
apply_url *	string (≤ 400 chars) Full https:// link to the job post or careers page.
description *	string (≤ 600 chars)
confirmation_token	string (≤ 2048 chars) Leave empty on the first call: you get an action_summary and a token instead of the action. After the user explicitly confirms that summary, call again with the SAME arguments plus this token.

mark_notifications_read PRO write:account · confirms

Mark notifications as read. Mark one notification (notification_id) or all of them (all: true) as read. Requires the user's confirmation.

notification_id	integer (min 1)
all	boolean
confirmation_token	string (≤ 2048 chars) Leave empty on the first call: you get an action_summary and a token instead of the action. After the user explicitly confirms that summary, call again with the SAME arguments plus this token.

refresh_listing_scores PRO write:account · confirms

Refresh my listing's scores. Recompute the confidence, health and completeness scores of one of the user's listings from its current record — the dashboard's "Re-align scores". Requires the user's confirmation.

listing *	string (≤ 300 chars) One of the user's own listings.
confirmation_token	string (≤ 2048 chars) Leave empty on the first call: you get an action_summary and a token instead of the action. After the user explicitly confirms that summary, call again with the SAME arguments plus this token.

refresh_listing_tech PRO write:account · confirms

Refresh my listing's technology snapshot. Scan the website of one of the user's listings and refresh its technology snapshot — the dashboard's "Refresh tech". Requires the user's confirmation.

listing *	string (≤ 300 chars) One of the user's own listings.
confirmation_token	string (≤ 2048 chars) Leave empty on the first call: you get an action_summary and a token instead of the action. After the user explicitly confirms that summary, call again with the SAME arguments plus this token.

refresh_listing_news PRO write:account · confirms

Refresh my listing's news. Look for new coverage of one of the user's approved listings with the same accuracy rules and moderation as the dashboard's "Refresh news" (once a minute per listing). Requires the user's confirmation.

listing *	string (≤ 300 chars) One of the user's own approved listings.
confirmation_token	string (≤ 2048 chars) Leave empty on the first call: you get an action_summary and a token instead of the action. After the user explicitly confirms that summary, call again with the SAME arguments plus this token.

request_listing_removal PRO write:account · confirms

Request removal of my listing. Send a removal request for a listing the user owns or originally submitted. A moderator reviews it; nothing is removed until they accept. Requires the user's confirmation.

listing *	string (≤ 300 chars) A listing the user owns or submitted.
reason *	string (≤ 2000 chars) Why it should be removed (20+ characters).
confirmation_token	string (≤ 2048 chars) Leave empty on the first call: you get an action_summary and a token instead of the action. After the user explicitly confirms that summary, call again with the SAME arguments plus this token.

create_webhook PRO write:account · confirms

Create a webhook destination. Register a webhook on the user’s account after explicit confirmation. Listing events will be sent to this URL. Requires Pro (including a free trial) and write:account. The signing secret is returned only once; keep it private.

url *	string (≤ 500 chars) Public HTTPS destination for signed events.
label	string (≤ 80 chars)
events *	string[] (1–6 items)
categories	string[]
confirmation_token	string (≤ 2048 chars) Leave empty on the first call: you get an action_summary and a token instead of the action. After the user explicitly confirms that summary, call again with the SAME arguments plus this token.

Errors

Tool errors (isError: true, HTTP 200)

not_found	No approved record (or none of yours) matches. Includes did_you_mean (different records, clearly labelled) and, for companies, a hint to use prepare_listing_submission. Never answered with invented data.
ambiguous	Several records share that exact name. Includes candidates, so call again with a slug.
key_required	An account tool was called with no API key. Includes create_key_url.
pro_required	The tool or action needs Pro. Includes tier, upgrade_url, upgrade_tool: "prepare_upgrade" and, when eligible, free_trial_url.
scope_required	The key lacks read:account / write:account. Includes required_scope and manage_keys_url.
confirmation_invalid	See the confirmation handshake. reason is one of invalid, expired, mismatch, args_changed or used.
not_approved	The action needs an approved listing (e.g. advertising, posting a job) and this one is pending or rejected.
limit_reached	A site rule was hit, e.g. at most 5 open positions per listing.
payments_unavailable · payments_paused · checkout_unavailable	Online checkout isn’t configured, is in maintenance, or the plan or package isn’t connected to checkout. No link was prepared.
promo_invalid	The promo code passed to prepare_upgrade can’t be applied. No link was prepared.
upstream_unavailable	A confirmed refresh (news or tech) couldn’t reach its source. Safe to try later.
invalid_input	A required argument is missing or malformed. The message, and errors where present, say which.
unknown_tool	No tool by that name. Includes available_tools.
internal_error	An unexpected failure (logged server-side). Nothing further was changed. Safe to retry.

HTTP errors (JSON-RPC error body)

401	Unknown, malformed or revoked key (reason: invalid_key / key_revoked). JSON-RPC -32001.
403	account_suspended (-32004) or insufficient_scope for read:listings (-32005)
405	GET / DELETE: the server is stateless
429	Rate limit or confirmed-write limit (-32006), or the per-address lock after repeated bad keys (-32003). Includes Retry-After.
503	The API area is in maintenance (-32002). Includes Retry-After.
400 / 404	Body isn’t JSON-RPC (-32700), or a path other than /mcp or /mcp/<key> (-32601)

Limits

With a key	60 tool calls per minute per key: the same live per-key read budget as the REST API, in a separate bucket. initialize and tools/list are free.
Confirmed changes	An account-change call with a confirmation_token is also charged to the key’s write budget: 20 per minute, the same as REST writes. Prepare calls (no token) are ordinary calls.
Without a key	120 tool calls per minute per client address
Page sizes	search_listings ≤ 25 (default 10) · list_jobs ≤ 25 (default 10) · get_news ≤ 12 · offsets ≤ 10000. Out-of-range values are clamped, and the response reports the limit actually used.
Paging	List responses carry total (exact), count, offset, has_more and next_offset.
Usage counters	MCP calls are not added to your REST usage statistics.

Connection and action semantics

connection_status returns tier (free/pro), authenticated, access_source (free/free_trial/paid_pro), trial_active, trial_expires_at and access_expires_at. A keyless connection cannot identify a member’s trial. Account scopes remain required during trials.

prepare_listing_claim writes nothing, accepts dns/meta/badge and links to the ownership verification form. create_webhook uses the shared webhook service’s public-URL validation, signing, delivery queue and limits. Creating a destination requires explicit confirmation and returns a signing secret once; it does not send a test event. Removal requests remain subject to ownership and moderation checks.

FirmLedger has no Vercel OAuth flow. A Vercel login challenge indicates connector configuration or an upstream deployment restriction to investigate; do not add OAuth discovery metadata or disable invalid-key checks to hide it. Production MCP must be reachable without a hosting-provider login.

Safety guarantees

• Directory tools are read-only at the database level. They query through a separate SQLite connection opened readonly. A write through it fails with SQLITE_READONLY.
• Account reads write nothing, not even “mark as read”. Marking notifications read is its own confirmed action.
• Account changes reuse the dashboard’s code (the same validation, limits, notifications and moderation), so the connector can’t do anything the member couldn’t do on the website. It can’t edit, delete or claim listings, and removal is a request that a moderator reviews.
• Checkout links create nothing until the member presses the button on FirmLedger itself, signed in, with a CSRF token.
• prepare_listing_submission only builds a link to /dashboard/listings/new with the fields pre-filled.
• The test suite (npm run test:mcp) fingerprints every relevant table before and after exercising every read tool and every prepare step, and fails on any difference. It then checks that each confirmed action changes exactly what it described.

Raw examples

searchcurl -s https://firmledger.co.ke/mcp \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -H "Authorization: Bearer fl_live_your_key" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search_listings","arguments":{"category":"Fintech","city":"Nairobi","verified_only":true,"limit":5}}}'

prepare, then confirm# 1. prepare: returns action_summary + confirmation_token, changes nothing {"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"watchlist_add","arguments":{"listing":"kilimo-soft"}}} # 2. after the user says yes: same arguments + the token {"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"watchlist_add","arguments":{"listing":"kilimo-soft","confirmation_token":"…"}}}

SDK clients do the initialize handshake for you. The stateless server also answers a bare tools/call, as above.