That is what separates it from a records-only integration: an agent can stand up a tracker, not just fill one in. Begin every session with check_configuration, because the server comes up cleanly even with the realm or token missing, and a missing variable then surfaces as a failing tool rather than a startup error.
A community-built MCP server over the Quickbase REST API, with caching and retry logic in front of it. Not an official Quickbase product, though it uses their public APIs.
- Records: query with filtering, sorting and groupBy; create and update one at a time; bulk_create_records and bulk_update_records for volume
- Tables and applications: create_app and update_app, list_tables, create_table, update_table and get_table_fields
- Fields as first-class objects: create_field, get_field, update_field and delete_field
- Relationships between tables: get_relationships, create_relationship, update_relationship and delete_relationship
- Files: upload_file into a file attachment field, download_file back out of a record
- run_report to execute a saved Quickbase report
- check_configuration and test_connection to prove the realm and token are working, and configure_cache to tune the caching in front of the API
A Quickbase account with API access, and Node.js 18+. Two required environment variables: QUICKBASE_REALM_HOST (your realm, such as company.quickbase.com) and QUICKBASE_USER_TOKEN; QUICKBASE_APP_ID sets a default application. The server starts whether or not they are set, and the tools only work once they are — so call check_configuration first. Optional settings: QUICKBASE_CACHE_ENABLED (default true), QUICKBASE_CACHE_TTL in seconds (default 3600), DEBUG and LOG_LEVEL. Run it over stdio with npx -y mcp-quickbase.
One command plus a key — npx -y mcp-quickbase, then supply credentials