Karma works with Claude, Cursor, and Codex.

Fetch the full record for a single project: title, description, problem/solution, members, link counts, and milestone counts. Use this when the user asks about a specific project by name or slug, or when you need the project owner / metadata before suggesting an action. For a quick health check ("is this project active?", "how is it going?") prefer get_project_status — it is cheaper and returns completion percentages directly. NEVER call this in a loop to enumerate many projects; for that use list-style tools first to narrow.

Concise health snapshot for a project, distinguishing the two kinds of milestones Karma tracks: (1) ROADMAP milestones the project owner sets on the project itself, and (2) GRANT milestones tied to specific funding (one set per grant). Returns separate counts for each plus an overall total — never collapse them, since a project with 0 roadmap milestones can still have completed grant milestones (or vice-versa). Use this when the user asks "how is X doing?", "what is the status of X?", or wants a single-paragraph summary. Do NOT use this when the user needs the full project description, member roles, or per-milestone titles — call get_project_details / list_project_milestones for those. For per-program scoped progress ("how is X doing in program Y?") call get_project_progress_in_program.

List a project's milestones — BOTH the project's own roadmap milestones AND its grant-tied milestones (grouped by grant). Use this when the user asks "what milestones does X have?", "show me X's milestone updates", "what work is left?", or wants per-milestone titles. Each item carries a `kind` field: "roadmap" (set by the project owner on the project itself) or "grant" (tied to a specific funding grant). Grant items also carry grantUid, grantTitle, and programId for chaining. Pass `grantUid` to scope the list to ONE grant — use this when the user already named a specific grant or program. For a numeric overview ("how many milestones total / completed?") prefer get_project_status — cheaper. For program-scoped progress ("how is X doing in program Y?") prefer get_project_progress_in_program — accepts programId directly. Page through results with the page parameter; defaults to page 1 with up to 20 items.

Single-call total of how much has actually been DISBURSED (paid out on-chain) to a project across ALL grants and programs. Different from "approved amount" — disbursed = funds actually transferred. Use this when the user asks "how much has X received?", "how much has been paid out to project Y?", or wants the running total of payouts. Returns a roll-up plus per-(program, token) breakdown — each row carries programId + grant title so the agent can chain into get_program_details or get_payout_history without an extra hop. For per-payout breakdown of one specific grant call get_payout_history.

Single-call milestone-progress snapshot for a project SCOPED TO ONE PROGRAM. Use this whenever the user asks "how many milestones has project X completed in <program>?", "how is X doing in <program>?", or any per-program progress question. Different from list_project_milestones — that returns ALL milestones across all programs the project participates in. Returns 404-style envelope (reason=not_found) when the project has no grant in the given program — do NOT silently report "0 milestones" in that case.

Single-call list of impact indicators (self-reported metrics) tracked by a project, with their datapoints. Use this when the user asks "what indicators does X track?", "show me X's impact metrics", "how many users/transactions/TVL has X reported?", or wants to read what the public /project/:slug/impact page shows. Each indicator carries id, name, unit-of-measure, last-updated timestamp, and (in detailed mode) the raw datapoints + aggregated views. Different from get_project_status — that returns milestone progress, NOT impact metrics. Returns an empty list (not an error) when the project has no indicators set up yet — many projects don't track impact metrics, so report that plainly without retrying.

Fetch a single funding program: name, description, intake form schema, status, deadlines, and configuration. Use this when the user mentions a specific program by name or ID and you need its setup before answering. For listing many programs in a community use list_community_programs first; for application-level questions use list_program_applications or get_application_details. NEVER fabricate program names, deadlines, or eligibility criteria — return only what this tool provides.

List every funding program registered under a community (e.g. all Filecoin programs). Returns program IDs, names, statuses, and basic stats. Use this when the user asks "what programs does community X run?" or needs to discover programs before drilling into one. For details on a specific program from the list, follow up with get_program_details. NEVER list programs for a community the user has not explicitly named — ask which community they mean instead of guessing.

Generate analytics report for a program including application statistics.

Get the intake form schema for a funding program, showing what fields the applicant needs to fill in. Use this before submitting an application to know the required fields.

List every milestone completion submitted by an application — text, verification status, who verified it and when. Use this when the user asks "what milestones has X completed?", "is this application up to date?", or wants to see grantee progress against the funding plan. For ONE specific milestone (when you know its field label and title) prefer get_milestone_completion. For program-wide pending work across many applications use list_pending_milestones.

Fetch ONE specific milestone completion by application + field label + title. Returns the completion text, verification status, verifier, and timestamps. Use this when the user wants details on a specific milestone they have already named. NEVER call this without first knowing the exact milestoneFieldLabel and milestoneTitle — use list_milestone_completions to discover what is available, then call this to drill in.

Across all approved applications in a program, find those with at least one unverified milestone completion. Returns one row per application with the count of pending milestones. Use this when the user asks "what needs my review?", "what milestones are waiting on us?", or wants the program-wide review queue. For per-application detail (which specific milestones are pending) follow up with list_milestone_completions on each reference number.

List all completed and pending disbursements for a single grant: amounts, tokens, statuses, timestamps. Use this when the user asks "how much has X received?", "what payouts have gone out for grant Y?", or wants the full ledger of disbursements for one grant. For a single rolled-up total instead of the full list, prefer get_total_disbursed (cheaper, one number). For pending disbursements across an entire community use list_pending_disbursements.

Single rolled-up total: how much has been disbursed across all payouts for one grant. Returns just `{ grantUID, totalDisbursed }`. Use this when the user asks "how much has X been paid?", "what is the running total for grant Y?". Do NOT use this when the user wants the breakdown by payout — call get_payout_history for that.

List disbursements for one community that are awaiting execution: amounts, recipient grants, statuses. Use this when the user asks "what payouts are queued for community X?", "how many pending payouts do we have?", or wants the work-to-do list before a treasury batch. For payouts that have ALREADY been initiated and are waiting for multi-sig signatures, use list_awaiting_signatures instead — different stage of the pipeline.

Fetch the grant agreement record for a single grant: signed-by addresses, status (active/revoked), template version. Returns `agreement: null` when no agreement exists yet — that means the grant has not been formalized. Use this when the user asks "is grant X signed?", "what does the agreement for Y say?". For a list of agreements across many grants in a program, use list_grant_agreements (cheaper than calling this in a loop).

Fetch community metrics from Karma data. Use this for questions about customer or community data, trends, reporting numbers, and metric-backed analysis.

Single-call snapshot of a Karma community: metadata (name, description, image), aggregate stats (project count, grant count, milestone completion %), and the list of active funding programs. Use this when the user asks "tell me about <community>", "what is <community> on Karma?", "what programs does <community> run?", or any open-ended community question. Saves 2–3 tool calls vs. chaining detail + stats + program listing manually. For per-program detail (form, applications, reviewers) call get_program_details with a programId from the response.

Find foundations or nonprofits. Combine arguments freely: • `query` (natural language, e.g. 'climate justice in California'): semantic search over name + description (uses pgvector embeddings). • `name`: hybrid name lookup — substring ILIKE first ('Dobson Foundation' matches 'THE DOBSON FOUNDATION INC'), with semantic embedding fallback when the substring underfills the limit. This catches both spelling variants and reworded names ('Bill Gates Charity' → 'Bill and Melinda Gates Foundation'). May overmatch — agent should disambiguate by inspecting candidates. • `ids`: batch fetch by funding_organization.id. • `kinds`: e.g. ['private_foundation'] for grantmaking foundations, ['nonprofit'] for recipients. • `location`: substring or 'City, ST'. • `minAssets` / `maxAssets`: dollar range against funding_organization.total_assets. • `sortBy`: 'total_assets' (default) or 'name'. • `onlyGrantmakers`: set true for funder/prospect searches; this uses recent outbound grants rather than nonprofit kind alone. • DAF sponsors, major intermediaries, and unresolved recipient sentinels are excluded by default; set includeIntermediaries/includeUnresolvedRecipients true only when explicitly needed. Use this for any organization lookup, ranking, or matching question. The result includes id, name, kind, ein, location, totalAssets, and (when query is set) similarity.

Search grant transactions. Combine arguments freely: • `query`: natural language topic (semantic search over grant description embeddings). • `foundationName` / `recipientName`: case-insensitive substring match (ILIKE %name%). 'Dobson Foundation' matches 'The Dobson Foundation, Inc.'. Pass the most distinctive part of the name; resolve to an ID via search_organizations first if you need a specific entity. • `foundationId` / `foundationIds`, `recipientId` / `recipientIds`: filter by IDs. • `year` + `dateBasis`: e.g. year=2023, dateBasis='tax_period_end_year' (default). • `minAmount` / `maxAmount`: dollar bounds. • `sortBy`: 'amount' | 'actionDate' | 'taxPeriodEndYear' | 'filingYear'. `sortOrder`: 'asc' | 'desc' (default desc). • Grantor intermediaries and unresolved recipient sentinels are excluded by default. Returns up to `limit` matching grants (default 50, max 500). Use aggregate_grants when you need totals across the FULL match set.

Search for and retrieve a program's official process guide by program name. You MUST use this tool when a user asks process-related questions like how to submit milestones, manage their grant, or follow program procedures. If the tool returns found=false, tell the user that no process guide is available for that program. NEVER fabricate or improvise process steps from your own knowledge — only use content returned by this tool. Ask the user which program they are referring to if not clear from the conversation.

Search customer-specific guides, how-tos, and process documentation. Use this before answering customer process questions. Do not invent process steps when no matching documentation is returned.

Search this community's curated knowledge base. CALL THIS FIRST for ANY question that mentions a topic, term, acronym, project name, program name, person, ecosystem, or process — including things that sound like a program lookup. The KB is where curators publish the canonical answer; only fall back to other tools (programs, applications, projects) if this returns no hits. Returns excerpts with source URLs you must cite. If results are empty, tell the user the topic is not covered — never fabricate an answer from general knowledge. Do not ask clarifying questions before searching; search first, clarify only if results are ambiguous.

Bundle the two reads a project owner usually chains for a status check: project details (title, owner, members, communities) + per-milestone status (titles, due dates, completion). Use this when the user asks "what is happening with my project", "give me the full project picture", or before suggesting an action that needs both project metadata and milestone state. Saves 1 tool call vs. chaining get_project_details + list_project_milestones manually. For just a one-line health snapshot prefer get_project_status (cheaper). NEVER call this for projects the user has not named explicitly — for discovery, ask the user which project they mean.

Cross-resource search across Karma projects, communities, AND funding programs by partial name, slug, or description. Each result is labelled with `type: "project" | "community" | "program"` so you can pick the right follow-up tool. Use this FIRST when the user names something loosely without saying which type ("what is drand?", "who got funded in ProPGF Batch 2?", "find filecoin") — it is the cheapest way to resolve a free-form name before chaining into `get_project_details`, `get_community_overview`, or `get_program_details`/`get_program_funding_summary`. If the user explicitly said "project", "community", or "program", call the type-specific tool directly to save a hop.

Search the public web for foundation contact pages, grant guidelines, application portals, RFPs, or any URL we do not already have on file. Use specific queries: • "<foundation name> contact email" • "<foundation name> grant application 2026" • "<foundation name> request for proposals"Returns the top results with title, url, snippet, and domain. When you know the foundation's domain, pass `site` to restrict the search to that domain — much higher signal than an open-web query.

Fetch a URL and return clean markdown plus outbound links. Use after web_search to read a contact page, grants page, or application form. Set `renderJs: true` for JS-heavy pages (Submittable, SmartSimple, most application portals); leave it false for static foundation sites — JS rendering costs more and is slower. The markdown is truncated to ~12000 characters; if you need a different page, follow a link from the response.

Fetch a URL and extract structured data matching the requested schema. Prefer this over fetch_page when you already know what fields you need: • foundation_contact — emails, phones, address, contact persons • application_details — applicationUrl, deadlines, eligibility, fields, attachments • grant_program_summary — list of programs run by a foundationResult includes a confidence indicator (low/medium/high). Low confidence usually means the page does not actually contain that information — try a different URL via web_search rather than retrying with the same input.