Skip to main content
Glama

Teable MCP (Official)

get-doc

Read-onlyIdempotent

Get comprehensive documentation for Teable features and configurations. Use this tool to understand configuration formats before creating or updating resources. Workflow:

  1. Identify the category needed (field, view, or record)

  2. Query the specific subtopic (e.g., "field.formula" or "field.colors")

  3. Use examples from documentation to construct correct configurations

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "topic": "<topic>",
      "baseId": "<baseId>"
    },
    "name": "get-doc"
  }
}

Input Schema

NameRequiredDescriptionDefault
topicYesDocumentation topic in format "category.subtopic": Field Configuration: - field.basic: Basic fields (text, number, date, checkbox, user, attachment, rating) - field.select: Select fields (single/multiple select with choices) - field.link: Link fields (relationships between tables) - field.formula: Formula fields (computed values with expressions) - field.lookup: Lookup fields (display values from linked records, includes conditional lookup) - field.rollup: Rollup fields (aggregate values from linked records, includes conditional rollup) - field.ai: AI-enhanced fields (extraction, classification, etc.) - field.formatting: Number and datetime formatting options - field.show-as: Visual representation options (progress bars, rings, charts, clickable links) - field.colors: Available color options for fields View Configuration: - view.filter: Filter records by conditions - view.sort: Sort records by field values - view.group: Group records into collapsible sections - view.column: Configure visible columns and widths Record Data: - record.value-format: Exact format for field values when creating/updating records without typecasting Automation: - automation.trigger: Trigger types and configuration (recordCreated, recordUpdated, recordMatchesConditions, formSubmitted, scheduledTime, buttonClick, webhook) - automation.send-email: SendEmail action configuration with system or custom SMTP - automation.api: Teable REST API reference for scripts (records, fields, filters) - automation.ai: Call AI from a script (prompt, attachments, structured output) External Integrations (for automation scripts): - integration.slack: Slack API - send messages, notifications, interact with channels and users Scrape: - scrape.guide: Find, price and run third-party data endpoints (social platforms, e-commerce, company and people data, search) App Builder: - app.ai: How the app calls AI models through the Teable proxy (env vars, server-side usage, available model keys) Reference: - reference.url: Teable resource URL patterns and ID prefixes — parse a pasted link into its resource type and IDs, or generate a link to a table/record/automation/app/dashboard
baseIdYesThe project (base) ID, e.g. "bseXXXXXXXX". Use list-bases to find it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint/idempotent/non-destructive/closed-world, so safety is covered and the description is free to add real value. It does: docs contain worked examples that should be copied into configuration payloads, which tells the agent what kind of content comes back despite there being no output schema. Nothing contradicts the annotations, but nothing is said about how large or structured the returned documentation is.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in sentence one, followed by a use condition and a compact numbered workflow. Every sentence earns its place; the only minor cost is that step 1's 'field, view, or record' categories omit the automation/integration/app topic families that the enum actually contains.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, fully described, read-only lookup tool the definition is close to sufficient. What is missing is the unexplained mandatory baseId — an agent may wonder whether docs differ per base — and any hint about the response shape or size, which matters since there is no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the topic enum is exhaustively documented in-schema with 24 values, so the description carries no burden there. It adds only a light nudge — 'query the specific subtopic (e.g., "field.formula" or "field.colors")' — which echoes values the schema already defines. Notably it never explains why a documentation lookup needs a required baseId, which is the one genuinely non-obvious parameter of the two.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: retrieve comprehensive documentation for Teable features and configurations, with an explicit domain (field/view/record configuration). An agent can tell this is a reference-lookup tool rather than the data-mutation or query siblings in the list. It does not explicitly position itself against the closest ambiguous sibling, search-api, which is the only gap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use this tool to understand configuration formats before creating or updating resources" gives a clear when-to-use condition tied to a downstream action. The three-step workflow (identify category, query subtopic, apply examples) operationalizes usage further. No explicit when-NOT-to-use or named alternative is given, which keeps it short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources