mcpField
S
show-airtable-link

show-airtable-link

github.com/airtableAgent workflows53107 installsUpdated 14w ago
Repository

About show-airtable-link

show-airtable-link is a workflow skill for agents that modify or retrieve user-visible Airtable content. It defines how to return one clickable link to the most specific surface supported by the MCP results and the user's proven access.

Key features

  1. 01Construct URLs from returned IDs
  2. 02Prioritize the most specific surface
  3. 03Respect verified access permissions
  4. 04Use one descriptive Markdown link
  5. 05Avoid fabricated IDs and query parameters

Use cases

  1. 01Hand off a modified Airtable record
  2. 02Link to a table after multi-record updates
  3. 03Return a page link for page-scoped work
  4. 04Share a base after a base-wide operation

MCP support

The skill applies after MCP calls that affect user-visible Airtable content. It uses IDs and access surfaces established by tool responses to determine which Airtable URL to return.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/airtable/skills --skill show-airtable-link

After installing, type/show-airtable-linkin Claude Code to confirm it loaded.

Details

From the project README

Show Airtable link

After any MCP call that affects user-visible Airtable content, return a clickable link to the most-specific surface the call's results give the user access to. The link is how the user reviews the agent's work — without it, the work is invisible until they go hunting for it.

URL templates

All URLs are built from IDs the tool calls actually returned. Don't include any ID slot — viw*, tbl*, rec*, pag*, etc. — that wasn't in a tool response.

SurfaceURL pattern
Workspacehttps://airtable.com/workspaces/<wspId>
Basehttps://airtable.com/<appId>
Base interfaces hubhttps://airtable.com/<appId>/interfaces
Tablehttps://airtable.com/<appId>/<tblId>
Record (table context)https://airtable.com/<appId>/<tblId>/<recId>
Interface pagehttps://airtable.com/<appId>/<pagId>
Record (page context)https://airtable.com/<appId>/<pagId>/<recId>

ID prefixes: wsp (workspace), app (base), tbl (table), pag (interface page), rec (record), fld (field). Construct URLs using IDs verbatim from MCP responses — do not lowercase, transform, or guess them.

Priority order

Hand off the most-specific URL the work allows:

  1. Single record — when the work targeted one record. Use the page-context URL if get_record_for_page returned the record; otherwise the table-context URL.
  2. Interface page — when the work was scoped to a page (page reads / listings).
  3. Table — for multi-record work or schema changes (created / updated tables, fields). Don't list every record back; link the table once.
  4. Base — last resort: just-created base, base-wide schema operation, or when nothing more specific applies.

For multi-record results without one obvious "best" record, link the table or page once. Do not produce a link per record — that's spam.

Permission-aware handoff

The MCP user's auth determines which tools succeed. Hand off URLs only at access surfaces the call sequence has proven:

  • Page-restricted users: only list_pages_for_base, list_records_for_page, get_record_for_page succeeded. Hand off page URLs only — synthesizing a tbl* URL the user can't open produces a dead link from their perspective.
  • Table-level access: list_tables_for_base, get_table_schema, list_records_for_table, update_records_for_table succeeded. Table URLs are safe.
  • Workspace-level access: list_workspaces returned IDs. Workspace URLs are safe.

Standing rule: if a tool call didn't prove the access surface, don't link to it. When in doubt, drop one specificity level and link the surface you do have.

Presentation

  • Markdown link with a descriptive label. Every host (Claude Code, Cowork, Codex, Claude.ai) renders these. Bare URLs render too but read worse.
    • Good: [Sales Pipeline base](https://airtable.com/appEXAMPLEbase001)
    • Acceptable: View in Airtable: [Sales Pipeline](https://airtable.com/appEXAMPLEbase001) — matches Airtable's existing internal handoff label
    • Bad: https://airtable.com/appEXAMPLEbase001 — bare URL with no context
  • One link per response. For multi-step operations, consolidate at the end rather than after each tool call.
  • No rich embeds. Inline chat surfaces don't render OpenGraph cards for Airtable URLs today. Don't structure responses around something the host won't draw.

Anti-patterns

  • Don't synthesize IDs. Every ID in the URL must come verbatim from a tool response. Don't fabricate viw*, tbl*, rec*, pag*, or any other identifier to round out a URL — if your tool calls didn't return that ID, the URL slot it'd fill doesn't have a real target.
  • Don't include ?home=<pagId> or other query params. Page-management modes (/build, /edit, /preview) are for page authors, not handoffs from chat.

Composition

Workflow and methodology skills that create, modify, or return Airtable content should compose this convention at handoff time. Don't re-implement URL construction inline.

In another skill's body:

"After completing the work, return a clickable link via the show-airtable-link skill. Hand off the most-specific URL the agent's tool calls have proven access to."

Examples

Created a new base for product roadmap:

Created your roadmap base with three tables — Roadmap, Feedback, and Releases.

View Roadmap base in Airtable

Updated 12 records' Status field:

Updated Status to "In Review" on 12 records.

View Roadmap table in Airtable

Returned one record from an interface page (page-restricted user):

Found the matching deal: Acme Corp, $50k, Stage = Negotiation.

View record in Sales pipeline

Comments

Markdown supported