mcp-airtable-query

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: status, bases, schema, records (list/get/create/update/delete), and filter formula building. There is no overlap or ambiguity between tools.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (e.g., list_bases, create_records), with 'get' for single items and 'list' for collections. The one deviation is 'airtable_status', which reads more like a noun than a verb, but it is still easily understood.
Tool Count5/5
With 9 tools, the server is well-scoped for Airtable data operations. Each tool serves a necessary function without unnecessary bloat.
Completeness5/5
The CRUD lifecycle for records is fully covered (list, get, create, update, delete), along with base and schema discovery and a filter helper. There are no significant missing operations for a query-focused Airtable server.
Average 3.7/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint and idempotentHint, and the description ('Retrieve') is consistent with these. The description adds no additional behavioral context such as error handling, return format, or authorization requirements, but the annotations cover the safe read operation, so the description meets the baseline without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets directly to the point without unnecessary words. It is well-structured and front-loaded with the primary action, making it efficient and easy to parse.
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 simple read tool, the description provides the minimal necessary information, and the annotations and output schema fill some gaps. However, it lacks usage guidance, parameter explanations, and any mention of not-found behavior, making it only marginally complete for an agent needing broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for any of the three required parameters (baseId, table, recordId), and the description does not explain their meaning or relationship. With 0% schema description coverage, the tool description fails to compensate, leaving the agent to rely solely on parameter names.
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?
The description clearly states the tool retrieves a single Airtable record, using a specific verb ('Retrieve') and resource ('Airtable record'), and the word 'one' distinguishes it from list_records. However, it does not explicitly contrast with sibling tools or explain the recordId parameter, so it is clear but not fully differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use get_record versus list_records or other alternatives. The description gives no context or exclusions, leaving the agent to infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description doesn't need to restate safety. It adds the 'available to the token' qualifier, indicating token-scoped access, which is beyond annotations. However, it does not describe pagination or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and resource.
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 simple listing tool with annotations and an output schema, the description covers the core purpose and scope. However, it lacks usage guidance and parameter semantics for 'offset', leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional 'offset' parameter with no description, and the description provides no explanation of its purpose or pagination behavior. With 0% schema description coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'bases available to the token', distinguishing it from sibling tools like list_records or get_base_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives, nor any exclusions. The description implies the tool lists bases for the token, but lacks direction about using other tools for schema or records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that the tool supports various query features (view, formula, fields, sorting, pagination), which is behavioral context beyond the annotations, but it does not disclose details like default page size, max records, or response shape. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence uses 11 words and communicates the core purpose plus key capabilities. There is no fluff or repetition; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and good annotations, the tool is complex with 9 parameters and pagination. The one-line description does not cover usage scenarios, parameter relationships, or edge cases (e.g., how maxRecords interacts with pageSize, or how view affects formula evaluation). The description is too sparse to fully guide an agent on this non-trivial query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names high-level parameter categories (view, formula, fields, sorting, pagination) but does not explain their syntax, interplay, or constraints (e.g., filterByFormula uses Airtable formula language, offset for pagination). This is insufficient for a 9-parameter tool with no param descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Query' with the resource 'records', and enumerates distinct capabilities (view, formula, fields, sorting, pagination). This clearly differentiates it from sibling get_record, which presumably fetches a single record, and from create/update/delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for listing multiple records with filtering and pagination, but it does not explicitly state when to use this tool versus get_record or other siblings. No exclusions or alternatives are mentioned, leaving the agent to infer usage from the name and feature list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds that the input is 'validated' and structured as a tree, but it doesn't disclose error handling, escaping behavior, or output format details. Beyond annotations, it adds limited context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of 13 words, front-loaded with the action and output. Every word earns its place, and there is no redundancy or filler.
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?
The description is sufficient for a simple pure function with an output schema and safety annotations, but it doesn't connect to sibling tools or explain when this should be used (e.g., for list_records). This missing integration context makes the description less complete than it could be.
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?
The single parameter 'filter' has no schema description (0% coverage). The description adds that the parameter is a 'validated AND/OR comparison tree', which supplements the schema's structural definition. However, it doesn't explain operator semantics, value constraints, or how the tree maps to Airtable's formula syntax, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Build an Airtable filterByFormula string' with a specific input ('validated AND/OR comparison tree'). It uses a specific verb and resource, distinguishing it from sibling tools that operate on Airtable bases/records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies the tool is used to produce a filter formula for Airtable queries, but there is no explicit 'when to use' or exclusions. It doesn't mention alternatives like manual formula construction or relationship to sibling tools such as list_records, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds that it reports non-secret configuration, which provides useful safety context, though it does not detail other behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. Every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema, the description is adequately complete. It communicates the tool's purpose and the non-secret safety aspect, while the output schema can explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to add beyond what the schema shows. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports non-secret Airtable configuration, using a specific verb and resource. This distinguishes it from sibling tools which handle bases, records, and schema operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It simply states what it does without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive and non-read-only behavior. The description adds 'permanently' and the ten-record limit, which is useful, but it does not disclose additional behavioral context such as how missing IDs are handled or whether deletion is reversible in any way. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds value: 'Permanently' warns about irreversibility, 'delete' states the action, 'up to ten' conveys the batch limit, and 'records' specifies the target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations, an output schema, and only three straightforward required parameters, the description covers the essential action, permanence, and batch limit. It doesn't explain return values (which are in the output schema) or failure modes, but it is largely complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for explaining parameters, but it only says 'records' without detailing baseId, table, or recordIds. The 'up to ten' qualifier matches the schema's maxItems, adding little beyond the field names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'delete' with the resource 'records', and adds important qualifiers 'permanently' and 'up to ten'. This makes the tool's purpose unmistakable and distinguishes it from siblings like create_records, update_records, and list_records.
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?
The phrase 'Permanently delete' clearly signals that this tool is for irreversible batch removal of records, which is distinct from create/update/list operations. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, establishing that this is a non-destructive write. The description adds value by specifying the batch limit of up to ten records and the requirement to update by ID, which are useful constraints beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to conveying the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters including two boolean flags that have nuanced behavior, the description is overly sparse. It fails to describe the semantics of replace and typecast, batch update behavior, or potential failure modes, making the tool under-specified for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only provides a high-level mention of updating by ID and a max of ten records. It does not explain the required baseId, table, records structure, or the optional replace and typecast flags, leaving significant ambiguity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' and identifies the resource as 'records', explicitly scoping to 'up to ten records by ID'. This clearly distinguishes it from sibling tools like create_records, delete_records, and list_records.
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?
The context is clear: the tool is for updating existing records by ID, which implies a prerequisite that records already exist. While it does not explicitly name alternatives or exclusions, the purpose statement makes the appropriate use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent mutation. The description adds valuable context about batching (up to ten records per request), which is not provided by annotations or schema. It is consistent with annotations and does not omit critical safety information beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the action verb. Every word earns its place; it is highly concise and free of redundancy.
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?
While the tool has a clear purpose and an output schema exists, the description omits important behavioral details such as the effect of 'typecast' or any error handling. The batching limit is noted, but for a create operation with four parameters, the description is somewhat underspecified. It is minimally viable but has room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining parameters. It only implies the 'records' parameter via 'up to ten records' but does not explain 'baseId', 'table', or especially 'typecast', which is a non-obvious Airtable concept. The schema provides names and types, but the description adds no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('records in Airtable'), and adds a clear scope constraint ('up to ten') and batching behavior ('in one request'). It clearly distinguishes from siblings like update_records, delete_records, and list_records.
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?
The description implies when to use this tool: for creating multiple records in a single request. It effectively differentiates from updating or deleting by naming 'Create'. It lacks explicit exclusions or alternative tool names, but the context is clear enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and idempotentHint annotations already covering the safe, non-mutating behavior, the description adds valuable context by specifying that the tool returns tables, fields, and views—clarifying the exact scope of what the operation exposes. It does not describe error behavior or pagination, but these are less critical given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'List tables, fields, and views for a base.' Every word earns its place, with no filler, repetition, or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema (so return values do not need description), and annotations cover safety. The description covers the core operation adequately, and nothing else appears necessary for an AI agent to select and invoke this tool correctly.
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?
The input schema defines a single baseId parameter with only a type and minLength constraint; schema description coverage is 0%, so the description must compensate. The phrase 'for a base' hints at the parameter's purpose but does not explain how to obtain or format baseId, nor does it mention that baseId is required. Minimal compensation at best.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and names the resources 'tables, fields, and views' for a 'base', making its function immediately clear. It distinguishes itself from sibling tools like list_bases and list_records by focusing on schema structure rather than data or base listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (if you need the schema of a base, this is the tool), but it does not explicitly state when to use it versus alternatives like list_bases or mention any exclusions/prerequisites. No 'when' or 'when not' guidance is provided, relying on the name and description to convey intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-airtable-query MCP server](https://glama.ai/mcp/servers/TTaoGaming/mcp-airtable-query/badges/card.svg)](https://glama.ai/mcp/servers/TTaoGaming/mcp-airtable-query)

Score Badge

Copy to your README.md:

[![mcp-airtable-query MCP server](https://glama.ai/mcp/servers/TTaoGaming/mcp-airtable-query/badges/score.svg)](https://glama.ai/mcp/servers/TTaoGaming/mcp-airtable-query)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TTaoGaming/mcp-airtable-query'

If you have feedback or need assistance with the MCP directory API, please join our Discord server