bigapi
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BIGAPI_KEY | No | Use this key instead of the stored one | |
| BIGAPI_URL | No | API base (for self-hosting / testing) | https://api.bigapi.dev |
| BIGAPI_CONFIG_DIR | No | Where get_access stores the key (config.json, mode 600) | ~/.bigapi |
| BIGAPI_OUTPUT_DIR | No | Default output folder (default: OS temp dir) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_toolA | Find the right bigapi operation for a task. Describe what you need in plain words, English or German – "convert a png to webp", "remove customer names from a contract", "extract the ZUGFeRD invoice XML" – and get the matching operations with their parameters, a ready-to-run example, the price and a guide link. It recommends only: it never touches your files and never spends credit; run what it names with run_operation. Free and no API key needed, so it is also the cheapest way to see what bigapi covers. Start here whenever you are unsure which operation fits, and skip it when you already know the operation name. If nothing fits, the answer says so plainly instead of guessing. |
| run_operationA | Run any bigapi operation on real files: merge or redact a PDF, OCR a scan, convert an image, chunk text for embeddings, read a ZUGFeRD invoice, sign an image as AI-generated. Take the operation name from find_tool (e.g. "pdf/merge", "ocr", "text/chunk"). Uploads are local file paths. A file result is written to output_path, or to a temporary file when you omit it, and the path comes back with size and content type; a data result comes back as JSON. $0.01 per operation flat, no subscription, and failed calls cost nothing. This one executor covers every operation, including ones added after your client started – enable_tools only adds convenience wrappers around it. Files are processed in Germany, deleted right after delivery, and every operation ships with a published proof that it does what it promises. |
| enable_toolsA | Add the dedicated tools for specific operations to this session, e.g. ["pdf_redact","ocr"], or ["all"] for every operation. bigapi starts lean – only find_tool, run_operation, get_access and get_balance are listed – so your context stays free. You rarely need this: every operation already runs through run_operation. Reach for it when you will call the same operation many times and want its parameters spelled out in your tool list. Names come from find_tool; unknown names are reported back and skipped while the rest are still enabled. The effect lasts for this session, adds to what is already enabled, and cannot be undone from here – restart the server for the lean list again. |
| get_accessA | Get a bigapi API key for this machine. Call this once when no key is configured; other bigapi tools fail with "no API key" until you do. Creates a NEW free key (no signup, no credit card) and stores it in the local config file, where every bigapi tool picks it up. Calling it again creates an additional key rather than returning the existing one – use get_balance to check the key you already have. The new key includes 100 free operations, then $0.01 per operation from a prepaid balance; neither expires. Needs network access to api.bigapi.dev. |
| get_balanceA | Check the bigapi key that is currently configured: remaining credit, free operations left, monthly cap and spend so far this month. Read-only, free, and a snapshot of this moment – the numbers move as operations run. Use it to confirm a key works, before a large batch, or when an operation reports a low balance. It does not create keys (that is get_access) and does not list past operations. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool has a distinct lifecycle role: discovery (find_tool), execution (run_operation), session convenience (enable_tools), key creation (get_access), and balance checking (get_balance). The descriptions explicitly cross-reference each other and state what they do not do, so there is little risk of an agent picking the wrong one.
All five names follow a consistent snake_case verb_noun pattern (find_tool, run_operation, enable_tools, get_access, get_balance). The verbs are specific and match the action, and no style mixing or vague generic names appear.
Five tools is well-scoped for a server that intentionally stays lean and dynamically exposes operations through find_tool/run_operation. Each tool covers a necessary concern: discovery, execution, optional tool enabling, access, and balance.
The core workflow is fully covered: obtain a key, find an operation, run it, and check credit/usage. The dynamic design means new operations don't require new server tools, so there are no obvious dead ends or missing lifecycle steps.