list_table and describe_table exist so a query can be written against real table and column names rather than guessed ones, which is the difference between an agent using this successfully and an agent inventing a schema. read_query is read-only by name, so nothing here writes back into the base — anything that changes a record belongs elsewhere. The credential pair is the thing to sort out before setup, since the personal base token and the app token are two different values and both are needed.
A Bitable client with three tools — list the tables in the current base, describe one of them by name, and run a read query against it in SQL.
- list_table returns the tables in the current Bitable.
- describe_table returns one table's structure by name.
- read_query runs a SQL read against the base.
A Bitable base and two credentials for it: a personal base token in PERSONAL_BASE_TOKEN and the app token in APP_TOKEN.
One command plus a key — uvx bitable-mcp, then supply credentials