A
licenseB
qualityC
maintenanceAn MCP server that supercharges AI assistants with powerful tools for software development, enabling research, planning, code generation, and project scaffolding through natural language interaction.
11
67
101
MIT
Xano Developer MCP
Officialby xano-inc
The Xano Developer MCP server provides AI assistants with tools for developing on the Xano backend platform, covering code validation, documentation, and workflow guidance.
Validate XanoScript Code: Check XanoScript for syntax errors using multiple input methods — raw code strings, single
.xsfiles, batch file arrays, or entire directories (with optional glob filtering). Returns detailed errors with line/column positions and suggestions.Access XanoScript Documentation: Retrieve context-aware, token-budget-aware docs covering 35+ topics including syntax, data types, database operations, APIs, agents, integrations (S3, Redis, Elasticsearch), security, realtime, and more. Supports full, quick-reference, or index modes, plus pre-packaged tiers (
survival~800 tokens,working~3500 tokens).Access Meta API Documentation: Get documentation for programmatically managing Xano resources — workspaces, API groups, endpoints, database tables, functions, tasks, agents, MCP servers, middleware, branches, and more. Configurable detail levels (overview, detailed, examples) with optional JSON schema inclusion.
Access CLI Documentation: Retrieve Xano CLI docs covering local development workflows, authentication, workspace sync, sandbox environments, branch management, releases, unit/workflow tests, and more. Includes an integration guide for CLI vs. Meta API usage.
Check Server Version: Get the current semantic version of the Xano Developer MCP server.
Pre-built Agent Skills: Leverage specialized skills like
xano-initfor guided project setup andxanoscript-docs-expertfor in-depth documentation reference.Direct Documentation Resource Access: Access XanoScript documentation topics directly via MCP resource URIs (e.g.,
xanoscript://docs/syntax).
Provides documentation and code validation for XanoScript, including integration guidance for Algolia search operations.
Provides documentation and code validation for XanoScript, including integration guidance for Elasticsearch search operations.
Provides documentation and code validation for XanoScript, including integration guidance for OpenSearch search operations.
Provides documentation and code validation for XanoScript, including integration guidance for Redis caching, rate limiting, and queue operations.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Xano Developer MCPGuide me through initial Xano workspace configuration."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🚀 Xano Developer MCP
Supercharge your AI with the power of Xano
🤖 AI-Powered · 📚 Comprehensive Docs · ⚡ Instant Setup · 🔧 Built-in Tools
An MCP server and standalone library that gives AI assistants superpowers for developing on Xano — complete with documentation, code validation, and workflow guides. Use it as an MCP server or import the tools directly in your own applications.
💡 What's Xano? The fastest way to build a scalable backend for your app — no code required. Build APIs, manage databases, and deploy instantly.
🔗 Quick Links
Overview
This MCP server acts as a bridge between AI models and Xano's developer ecosystem, offering:
Meta API Documentation - Programmatically manage Xano workspaces, databases, APIs, functions, and more
CLI Documentation - Command-line interface for local development, code sync, and execution
XanoScript Documentation - Language reference with context-aware docs based on file type
Code Validation - Syntax checking with the official XanoScript language server
Workflow Guides - Step-by-step guides for common development tasks
Related MCP server: Caipher MCP
Quick Start
Claude Code (Recommended)
claude mcp add xano -- npx -y @xano/developer-mcpThat's it! The MCP server will be automatically installed and configured.
Install via npm
You can also install the package globally from npm:
npm install -g @xano/developer-mcpThen add to Claude Code:
claude mcp add xano-developer -- xano-developer-mcpClaude Desktop
Add to your Claude Desktop configuration file:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"xano-developer": {
"command": "npx",
"args": ["-y", "@xano/developer-mcp"]
}
}
}Xano Skills
This repo ships two agent skills under skills/:
xano-init— guided setup that profiles a Xano workspace and builds a sandbox-first development playbookxanoscript-docs-expert— deep reference for working with XanoScript documentation and this MCP project's architecture
Using Claude Code inside this repo? You already have both skills. They're committed to .claude/skills/ and load automatically when Claude Code starts a session in this directory — no install step needed. Just invoke xano-init or xanoscript-docs-expert by name, or describe the task in natural language.
Using a different agent, or want the skills available in other projects? Skills are distributed via the open Agent Skills standard and install with a single npx command — no cloning or manual file copying.
Install xano-init globally into Claude Code:
npx skills add xano-inc/xano-developer-mcp -s xano-init -a claude-code -gInstall into multiple agents at once (Claude Code, Codex, Cursor, OpenCode, etc.):
npx skills add xano-inc/xano-developer-mcp -s xano-init \
-a claude-code -a codex -a cursor -a opencode -gDrop -s to install every skill in the repo, or drop -g to scope the install to the current project instead of your user profile. Other supported agents include gemini-cli, windsurf, continue, cline, github-copilot, and more — see the skills CLI for the full list.
Start a new agent session after installing so the skill manifest is picked up.
Checking Your Version
npx @xano/developer-mcp --versionIf installed from source:
node dist/index.js --versionInstallation from Source
Prerequisites
Node.js (ES2022+ compatible)
npm
Setup
# Clone the repository
git clone https://github.com/xano-inc/xano-developer-mcp.git
cd xano-developer-mcp
# Install dependencies
npm install
# Build the project
npm run buildUsage
Running the Server
# Production
npm start
# Development (build + run)
npm run devThe server communicates via stdio (standard input/output) using the JSON-RPC protocol, which is the standard transport for MCP servers.
Source Install Configuration
If you installed from source, configure your MCP client to use the local build:
Claude Code:
claude mcp add xano-developer node /path/to/xano-developer-mcp/dist/index.jsClaude Desktop:
{
"mcpServers": {
"xano-developer": {
"command": "node",
"args": ["/path/to/xano-developer-mcp/dist/index.js"]
}
}
}Library Usage
In addition to using this package as an MCP server, you can import and use the tools directly in your own applications.
Installation
npm install @xano/developer-mcpImporting Tools
import {
validateXanoscript,
xanoscriptDocs,
metaApiDocs,
cliDocs,
mcpVersion
} from '@xano/developer-mcp';Validate XanoScript Code
import { validateXanoscript } from '@xano/developer-mcp';
// Validate code directly
const result = validateXanoscript({ code: 'var:result = 1 + 2' });
if (result.valid) {
console.log('Code is valid!');
} else {
console.log('Validation errors:');
result.errors.forEach(error => {
console.log(` Line ${error.range.start.line + 1}: ${error.message}`);
});
}
// Validate a file
const fileResult = validateXanoscript({ file_path: './function/utils.xs' });
// Batch validate a directory
const dirResult = validateXanoscript({ directory: './api', pattern: '**/*.xs' });
console.log(`${dirResult.valid_files}/${dirResult.total_files} files valid`);Get XanoScript Documentation
import { xanoscriptDocs } from '@xano/developer-mcp';
// Get the compact topic index (the no-arg default; ~4KB / ~1K tokens)
const index = xanoscriptDocs();
console.log(index.documentation);
// Get the full prose overview (the previous no-arg default)
const overview = xanoscriptDocs({ topic: 'readme' });
// Get specific topic
const syntaxDocs = xanoscriptDocs({ topic: 'syntax' });
// Get context-aware docs for a file path
const apiDocs = xanoscriptDocs({ file_path: 'api/users/create_post.xs' });
// Get compact quick reference
const quickRef = xanoscriptDocs({ topic: 'database', mode: 'quick_reference' });Get Meta API Documentation
import { metaApiDocs } from '@xano/developer-mcp';
// Get overview
const overview = metaApiDocs({ topic: 'start' });
// Get detailed documentation with examples
const workspaceDocs = metaApiDocs({
topic: 'workspace',
detail_level: 'examples',
include_schemas: true
});
console.log(workspaceDocs.documentation);Get CLI Documentation
import { cliDocs } from '@xano/developer-mcp';
const cliSetup = cliDocs({ topic: 'start' });
console.log(cliSetup.documentation);Get Package Version
import { mcpVersion } from '@xano/developer-mcp';
const { version } = mcpVersion();
console.log(`Using version ${version}`);Available Exports
Export | Description |
| Validate XanoScript code and get detailed error information |
| Get XanoScript language documentation |
| Get Meta API documentation |
| Get CLI documentation |
| Get the package version |
| MCP tool definitions (JSON Schema, for building custom MCP servers) |
| Tool specs with Zod input/output shapes (preferred for new code — works directly with |
| Async tool dispatcher ( |
TypeScript Support
Full TypeScript support with exported types:
import type {
ValidateXanoscriptArgs,
ValidationResult,
ParserDiagnostic,
XanoscriptDocsArgs,
MetaApiDocsArgs,
CliDocsArgs,
ToolResult
} from '@xano/developer-mcp';Package Entry Points
The package provides multiple entry points:
// Main library entry (recommended)
import { validateXanoscript } from '@xano/developer-mcp';
// Tools module directly
import { validateXanoscript } from '@xano/developer-mcp/tools';
// Server module (for extending the MCP server)
import '@xano/developer-mcp/server';Available Tools
1. xano_validate_xanoscript
Validates XanoScript code for syntax errors. Supports multiple input methods. The language server auto-detects the object type from the code syntax.
Parameters:
Parameter | Type | Required | Description |
| string | No | The XanoScript code to validate as a string |
| string | No | Path to a single |
| string[] | No | Array of file paths for batch validation |
| string | No | Directory path to validate all |
| string | No | Glob pattern to filter files when using |
One of
code,file_path,file_paths, ordirectoryis required.
Examples:
// Validate code directly
xano_validate_xanoscript({ code: "var:result = 1 + 2" })
// Validate a single file
xano_validate_xanoscript({ file_path: "function/utils/format.xs" })
// Validate multiple files
xano_validate_xanoscript({ file_paths: ["api/users/get.xs", "api/users/create.xs"] })
// Validate all .xs files in a directory
xano_validate_xanoscript({ directory: "api/users" })
// Validate with a specific pattern
xano_validate_xanoscript({ directory: "src", pattern: "api/**/*.xs" })Returns: List of errors with line/column positions and helpful suggestions, or confirmation of validity.
2. xano_xanoscript_docs
Retrieves XanoScript programming language documentation with context-aware support. Called with no parameters, it returns a compact topic index (~4KB / ~1K tokens) for orientation; use topic='readme' for the full prose overview, or topic=/file_path= to drill in.
Parameters:
Parameter | Type | Required | Description |
| string | No | Specific documentation topic to retrieve |
| string | No | File path being edited for context-aware docs (e.g., |
| string | No |
|
| string | No | Pre-packaged documentation tier for context-limited models: |
| number | No | Maximum estimated token budget. Loads topics in priority order until budget is reached. Helps prevent context overflow for small-window models |
| string[] | No | Topic names to exclude from |
Available Topics:
Topic | Description |
| Minimal syntax survival kit (~5KB, ~1.2K tokens) for models with <16K context — reach via |
| Complete working reference (~17KB, ~4.4K tokens) for models with 16-64K context — reach via |
| XanoScript overview, workspace structure, and quick reference |
| Common patterns, quick reference, and common mistakes to avoid |
| Expressions, operators, and filters for all XanoScript code |
| String filters, regex, encoding, security filters, text functions |
| Array filters, functional operations, and array functions |
| Math filters/functions, object functions, bitwise operations |
| Data types, input blocks, and validation |
| Database schema definitions with indexes and relationships |
| Reusable function stacks with inputs and responses |
| HTTP endpoint definitions with authentication and CRUD patterns |
| Scheduled and cron jobs |
| Event-driven handlers (table, realtime, workspace, agent, MCP) |
| All db.* operations: query, get, add, edit, patch, delete |
| AI agent configuration with LLM providers and tools |
| AI tools for agents and MCP servers |
| MCP server definitions exposing tools |
| Unit tests, mocks, and assertions within functions, APIs, and middleware |
| End-to-end workflow tests with data sources and tags |
| External service integrations index |
| AWS S3, Azure Blob, and GCP Storage |
| Elasticsearch, OpenSearch, and Algolia |
| Redis caching, rate limiting, and queues |
| HTTP requests with api.request |
| Local storage, email, zip, and Lambda |
| Static frontend development and deployment |
| Reusable subqueries for fetching related data |
| Logging, inspecting, and debugging XanoScript execution |
| Performance optimization best practices |
| Real-time channels and events for push updates |
| Security best practices for authentication and authorization |
| Streaming data from files, requests, and responses |
| Request/response interceptors for functions, queries, tasks, and tools |
| Branch-level settings: middleware, history retention, visual styling |
| Workspace-level settings: environment variables, preferences, realtime |
Examples:
// Get the compact topic index (no-arg default)
xano_xanoscript_docs()
// Get the full prose overview (previous no-arg default)
xano_xanoscript_docs({ topic: "readme" })
// Get survival kit for small context models (~1.2K tokens)
xano_xanoscript_docs({ tier: "survival" })
// Get working reference for medium context models (~4.4K tokens)
xano_xanoscript_docs({ tier: "working" })
// Get essentials (recommended first stop)
xano_xanoscript_docs({ topic: "essentials" })
// Get specific topic
xano_xanoscript_docs({ topic: "functions" })
// Discover available topics with sizes
xano_xanoscript_docs({ mode: "index" })
// Budget-aware: load docs up to token limit
xano_xanoscript_docs({ file_path: "api/users/create_post.xs", max_tokens: 2000 })
// Context-aware: get all docs relevant to file being edited
xano_xanoscript_docs({ file_path: "api/users/create_post.xs" })
// Context-aware with exclusions (skip already-loaded topics)
xano_xanoscript_docs({ file_path: "api/users/create_post.xs", exclude_topics: ["syntax", "essentials"] })
// Compact quick reference (uses less context)
xano_xanoscript_docs({ topic: "database", mode: "quick_reference" })3. xano_version
Get the current version of the Xano Developer MCP server.
Parameters: None
Returns: The version string from package.json.
Example:
xano_version()4. xano_meta_api_docs
Get documentation for Xano's Meta API. Use this to understand how to programmatically manage Xano workspaces, databases, APIs, functions, agents, and more.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | Documentation topic to retrieve |
| string | No |
|
| boolean | No | Include JSON schemas for requests/responses (default: true) |
Available Topics:
Topic | Description |
| Getting started with the Meta API |
| API authentication and authorization |
| Workspace management endpoints |
| API group operations |
| API endpoint management |
| Database table operations |
| Function management |
| Scheduled task operations |
| AI agent configuration |
| AI tool management |
| MCP server endpoints |
| Middleware configuration |
| Branch management |
| Real-time channel operations |
| File management |
| Version history |
| Step-by-step workflow guides |
Examples:
// Get overview of Meta API
xano_meta_api_docs({ topic: "start" })
// Get detailed table documentation
xano_meta_api_docs({ topic: "table", detail_level: "detailed" })
// Get examples without schemas (smaller context)
xano_meta_api_docs({ topic: "api", detail_level: "examples", include_schemas: false })
// Step-by-step workflow guides
xano_meta_api_docs({ topic: "workflows" })5. xano_cli_docs
Get documentation for the Xano CLI. The CLI is optional but recommended for local development workflows. Not all users will have it installed.
Use this tool to understand CLI commands for local development, code synchronization, and XanoScript execution.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | Documentation topic to retrieve |
| string | No |
|
Available Topics:
Topic | Description |
| Getting started with the CLI - installation and setup |
| Browser-based OAuth authentication |
| Profile management - credentials and multi-environment setup |
| Workspace operations - pull/push code sync, git integration |
| Personal auto-provisioned dev environment (paid plans only) |
| Branch management - list, switch, create, and delete branches |
| Function management - list, get, create, edit |
| Release management - create, export, import, pull, push |
| Tenant management - CRUD, deployments, env vars, backups, clusters |
| Unit test management - list and run unit tests |
| Workflow test management - list, run, and manage workflow tests |
| Platform management - list and view platform versions |
| Static hosting - deploy frontend builds |
| Update the CLI to the latest version |
| CLI + Meta API integration guide - when to use each |
Examples:
// Get CLI setup guide
xano_cli_docs({ topic: "start" })
// Learn when to use CLI vs Meta API
xano_cli_docs({ topic: "integration" })
// Get workspace sync commands
xano_cli_docs({ topic: "workspace", detail_level: "detailed" })
// Profile management with examples
xano_cli_docs({ topic: "profile", detail_level: "examples" })MCP Resources
The server also exposes XanoScript documentation as MCP resources for direct access:
Resource URI | Description |
| Minimal syntax survival kit (~1.2K tokens) |
| Complete working reference (~4.4K tokens) |
| Overview and quick reference |
| Common patterns, quick reference, and common mistakes to avoid |
| Expressions, operators, and filters |
| String filters, regex, encoding, security filters |
| Array filters, functional operations |
| Math filters/functions, object functions, bitwise |
| Data types and validation |
| Database schema definitions |
| Reusable function stacks |
| HTTP endpoint definitions |
| Scheduled and cron jobs |
| Event-driven handlers |
| Database operations |
| AI agent configuration |
| AI tools for agents |
| MCP server definitions |
| Unit tests and mocks |
| End-to-end workflow tests |
| External service integrations index |
| AWS S3, Azure Blob, GCP Storage |
| Elasticsearch, OpenSearch, Algolia |
| Redis caching and queues |
| HTTP requests with api.request |
| Email, zip, Lambda utilities |
| Static frontend development |
| Reusable subqueries for related data |
| Logging and debugging tools |
| Performance optimization |
| Real-time channels and events |
| Security best practices |
| Data streaming operations |
| Request/response interceptors |
| Branch-level settings |
| Workspace-level settings |
npm Scripts
Script | Command | Description |
|
| Compile TypeScript and copy docs |
|
| Run the MCP server |
|
| Build and run in development |
|
| Run unit tests |
|
| Run tests in watch mode |
|
| Run tests with coverage report |
Project Structure
xano-developer-mcp/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── lib.ts # Library entry point (for npm imports)
│ ├── xanoscript.ts # XanoScript documentation logic
│ ├── xanoscript.test.ts # Tests for xanoscript module
│ ├── xanoscript-language-server.d.ts # TypeScript declarations
│ ├── tools/ # Standalone tool modules
│ │ ├── index.ts # Unified tool exports & handler
│ │ ├── index.test.ts # Tests for tool handler
│ │ ├── types.ts # Common types (ToolResult)
│ │ ├── validate_xanoscript.ts # XanoScript validation tool
│ │ ├── xanoscript_docs.ts # XanoScript docs tool
│ │ ├── xanoscript_docs.test.ts # Tests for xanoscript docs tool
│ │ ├── mcp_version.ts # Version tool
│ │ ├── meta_api_docs.ts # Meta API docs tool wrapper
│ │ └── cli_docs.ts # CLI docs tool wrapper
│ ├── meta_api_docs/ # Meta API documentation
│ │ ├── index.ts # API docs handler
│ │ ├── index.test.ts # Tests for index
│ │ ├── types.ts # Type definitions
│ │ ├── types.test.ts # Tests for types
│ │ ├── format.ts # Documentation formatter
│ │ ├── format.test.ts # Tests for formatter
│ │ └── topics/ # Individual topic modules
│ ├── cli_docs/ # Xano CLI documentation
│ │ ├── index.ts # CLI docs handler
│ │ ├── types.ts # Type definitions
│ │ ├── format.ts # Documentation formatter
│ │ └── topics/ # Individual topic modules
│ └── xanoscript_docs/ # XanoScript language documentation
│ ├── docs_index.json # Machine-readable topic registry
│ ├── version.json
│ ├── README.md
│ ├── essentials.md
│ ├── syntax.md
│ ├── syntax/ # Syntax sub-topics
│ │ ├── string-filters.md
│ │ ├── array-filters.md
│ │ └── functions.md
│ └── ...
├── dist/ # Compiled JavaScript output
├── vitest.config.ts # Test configuration
├── package.json
└── tsconfig.jsonDependencies
Package | Version | Purpose |
| ^1.26.0 | Official MCP SDK |
| ^11.6.5 | XanoScript parser and validation |
| ^10.1.2 | Glob pattern matching for context-aware docs |
Dev Dependencies
Package | Version | Purpose |
| ^5.9.0 | TypeScript compiler |
| ^3.0.0 | Fast unit test framework |
| ^22.0.0 | Node.js type definitions |
| ^5.1.2 | Minimatch type definitions |
How It Works
AI Client
│
▼
MCP Protocol (JSON-RPC over stdio)
│
▼
Xano Developer MCP Server
│
├─► xano_validate_xanoscript → Parses code with XanoScript language server
│
├─► xano_xanoscript_docs → Context-aware docs from /xanoscript_docs/*.md
│
├─► xano_meta_api_docs → Meta API documentation with detail levels
│
├─► xano_cli_docs → CLI documentation for local development workflows
│
├─► xano_version → Returns server version from package.json
│
└─► MCP Resources → Direct access to XanoScript documentationAuthentication
The MCP server and library functions do not require authentication. However, when using the documented APIs (Meta API) to interact with actual Xano services, you will need appropriate Xano API credentials. See the xano_meta_api_docs tool for authentication details.
Development
Building
npm run buildCompiles TypeScript to JavaScript in the dist/ directory.
Documentation Structure
XanoScript Documentation (src/xanoscript_docs/):
Markdown files for XanoScript language reference
Configured in
src/xanoscript_docs/docs_index.jsonwith:file: The markdown file containing the documentation
applyTo: Glob patterns for context-aware matching (e.g.,
api/**/*.xs)description: Human-readable description of the topic
aliases: Alternative names for topic lookup
priority: Ordering weight for file_path matching
Meta API Documentation (src/meta_api_docs/):
TypeScript modules with structured documentation
Supports parameterized output (detail levels, schema inclusion)
Better for AI consumption due to context efficiency
Testing
The project uses Vitest as its test framework with comprehensive unit tests.
Running Tests
# Run all tests
npm test
# Run tests in watch mode (re-runs on file changes)
npm run test:watch
# Run tests with coverage report
npm run test:coverageTest Coverage
Module | Test File | Description |
|
| Core XanoScript documentation logic including file path matching and quick reference extraction |
|
| Tool handler dispatch and argument validation |
|
| XanoScript documentation tool and path resolution |
|
| Meta API documentation handler and topic management |
|
| Documentation formatting for endpoints, examples, and patterns |
|
| Type structure validation |
Test Structure
Tests are co-located with source files using the .test.ts suffix:
src/
├── xanoscript.ts
├── xanoscript.test.ts # Tests for xanoscript.ts
├── tools/
│ ├── index.ts
│ ├── index.test.ts # Tests for tool handler
│ ├── xanoscript_docs.ts
│ ├── xanoscript_docs.test.ts # Tests for xanoscript docs tool
│ └── ...
├── meta_api_docs/
│ ├── index.ts
│ ├── index.test.ts # Tests for index.ts
│ ├── format.ts
│ ├── format.test.ts # Tests for format.ts
│ └── ...Writing Tests
Tests use Vitest's API which is compatible with Jest:
import { describe, it, expect } from "vitest";
import { myFunction } from "./myModule.js";
describe("myFunction", () => {
it("should return expected result", () => {
expect(myFunction("input")).toBe("expected");
});
});Upgrading from 1.x to 2.0
Version 2 modernizes the MCP server internals and normalizes all tool names
under a single xano_ namespace. The high-level standalone library functions
(validateXanoscript, xanoscriptDocs, metaApiDocs, cliDocs, mcpVersion)
are unchanged.
Tool renames (MCP clients)
If your agent or MCP client config references tools by name, update them:
1.x | 2.0 |
|
|
|
|
|
|
|
|
|
|
The single xano_ prefix improves discoverability when multiple MCP servers
are installed and lets clients filter Xano tools by name pattern.
Library API
handleTool(name, args) is now async and returns Promise<ToolResult>
instead of ToolResult. Update call sites to use await and the new tool
names:
// 1.x
const result = handleTool("xanoscript_docs", { topic: "syntax" });
// 2.0
const result = await handleTool("xano_xanoscript_docs", { topic: "syntax" });The individual *ToolDefinition exports (validateXanoscriptToolDefinition,
xanoscriptDocsToolDefinition, mcpVersionToolDefinition,
metaApiDocsToolDefinition, cliDocsToolDefinition) were removed in favor
of a single source of truth. Use toolSpecs[name].definition instead:
// 1.x
import { validateXanoscriptToolDefinition } from "@xano/developer-mcp";
// 2.0
import { toolSpecs } from "@xano/developer-mcp";
const validateXanoscriptToolDefinition =
toolSpecs.xano_validate_xanoscript.definition;A new ToolName type export enumerates every registered tool name.
Notable fixes and additions
xano_xanoscript_docsnow correctly accepts the documentedtierandmax_tokensparameters — previously they were silently dropped before reaching the handler.The server is built on the modern
McpServerAPI with Zod-derived schemas, so the JSON Schema published over the wire can no longer drift from the runtime parser.New
toolSpecsexport exposes each tool's Zod input/output shape — use it when registering tools in a customMcpServer.xano_validate_xanoscriptresults now include awarningscount instructuredContenton success.
License
See LICENSE for details.
Available Tools
7 toolsxano_cli_docsARead-onlyIdempotent
Get documentation for the Xano CLI. Use this to understand how to use the CLI for local development, code sync, and XanoScript execution.
Topics
auth: Xano CLI - Authentication
start: Xano CLI - Getting Started
profile: Xano CLI - Profile Management
workspace: Xano CLI - Workspace Operations
branch: Xano CLI - Branch Management
function: Xano CLI - Function Management
knowledge: Xano CLI - Knowledge & Skills
release: Xano CLI - Release Management
tenant: Xano CLI - Tenant Management
unit_test: Xano CLI - Unit Test Management
workflow_test: Xano CLI - Workflow Test Management
sandbox: Xano CLI - Sandbox Environment
platform: Xano CLI - Platform Management
static_host: Xano CLI - Static Hosting
update: Xano CLI - Update
integration: Xano CLI + Meta API Integration Guide
Usage
Start with "start" topic for installation and setup
Use "auth" or "profile" to understand authentication options
Use "integration" to understand when to use CLI vs Meta API
Use specific topics for command reference (workspace, sandbox, branch, release, tenant, function, etc.)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Documentation topic to retrieve. Start with 'start' for installation and setup. Example: topic='function' for function management commands, topic='sandbox' for the personal dev environment. | |
| detail_level | No | Level of detail to return. 'overview' = brief summary of commands and their purpose. 'detailed' = full command reference with flags and arguments. 'examples' = includes usage examples for each command. Default: 'detailed'. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| documentation | Yes | The CLI documentation content for the requested topic. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds value by listing topics and usage guidelines, which helps the agent understand the scope of documentation.
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?
Concise with clear sections (Topics, Usage). Every sentence is informative, no filler. Front-loaded with purpose.
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?
Given simple input schema (2 params, both enums) and presence of output schema, description combined with schema fully covers what the agent needs to use the tool effectively. Usage guidelines are comprehensive.
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?
Schema coverage is 100% with enums and descriptions. Description complements by explaining topic categories and recommended starting points, adding practical usage context beyond 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?
Description clearly states 'Get documentation for the Xano CLI.' It lists 16 topics and includes usage guidance. Differentiates from sibling tools like xano_meta_api_docs by mentioning when to use CLI vs Meta API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Usage' section advises to start with 'start' topic, use 'auth' or 'profile' for authentication, and use 'integration' to compare CLI vs Meta API. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xano_knowledge_getARead-onlyIdempotent
Get the CLI command to fetch the full content of one named knowledge item (a skill, doc, or agents.md), or one of a skill's attached reference files. This tool does not run the command itself — it returns the exact xano knowledge get command to run in a shell, so you can invoke it and read its output.
Use this after xano_knowledge_list has identified an on-demand item whose full content is now needed, or when a skill's step tells you to consult a specific reference file (via @filename syntax in the skill content).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | Path of a reference file attached to the item (as listed in that item's `references` array from xano_knowledge_list), fetched instead of the item's own content. | |
| name | Yes | The knowledge item's name (case-insensitive exact match). Required. | |
| branch | No | Branch ID. Optional; defaults to the workspace's live branch. | |
| output | No | text returns the raw markdown content. json wraps it with metadata (item: full object; file: {content, name, path}). Default: text. | |
| profile | No | CLI credential profile to use. | |
| workspace | No | Workspace ID. Optional if the active profile has a default workspace configured. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| command | Yes | The `xano knowledge get` command to run to fetch the knowledge item's content. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses key behavioral trait beyond annotations: 'This tool does not run the command itself — it returns the exact xano knowledge get command to run in a shell'. This adds value over readOnlyHint and idempotentHint.
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?
Two concise paragraphs, front-loaded with purpose and behavior, followed by usage context. No unnecessary words.
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?
Output schema exists, description needn't detail return values. It covers what is returned (CLI command), when to use, and relation to xano_knowledge_list. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 is appropriate. Description adds little beyond schema descriptions, only noting the purpose of 'name' and reference files already covered in 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 clearly states it returns the CLI command to fetch content of a knowledge item (skill, doc, agents.md) or reference file. It distinguishes from siblings by noting it does not run the command itself and positions itself after xano_knowledge_list.
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?
Explicitly states when to use: after xano_knowledge_list identifies an item or when a skill step references a file. Implicitly excludes direct execution. Could add explicit 'when not to use' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xano_knowledge_listARead-onlyIdempotent
Get the CLI command to list a Xano workspace's knowledge base: skills, docs, and the agents.md file. This tool does not run the command itself — it returns the exact xano knowledge list command to run in a shell, so you can invoke it and read its output.
Use this to get an overview of what knowledge/skills exist before answering questions about workspace conventions, or before deciding whether a new skill/doc needs to be created (to avoid duplicating existing ones).
Always-on items (mode=always) are returned by the command with full content; on-demand items are returned with just name+description — use xano_knowledge_get to get the command for fetching an on-demand item's full content when it becomes relevant.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter to a single knowledge type. Omit to list all types. | |
| branch | No | Branch ID to read knowledge from. Optional; defaults to the workspace's live branch. | |
| output | No | markdown is human-readable (always-on items inline, on-demand items as a name+description index). json returns the full raw item array — prefer json when you need structured fields (id, guid, mode, references, etc.) for further processing. Default: markdown. | |
| profile | No | CLI credential profile to use. Optional; falls back to XANO_PROFILE env var or the credentials file default. | |
| workspace | No | Workspace ID. Optional if the active profile has a default workspace configured. | |
| enabled_only | No | When true (default), only enabled items are returned. Set to false to include disabled items too. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| command | Yes | The `xano knowledge list` command to run to get the workspace's knowledge base. |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses that the tool does not run the command but returns it for shell execution. It also explains the command's output behavior (always-on items with full content, on-demand with name+description). Annotations (readOnlyHint, idempotentHint) are consistent and reinforced.
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 three paragraphs with clear front-loading: first sentence states the core action, second clarifies a key nuance, third provides usage guidance. Every sentence is informative and non-redundant.
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?
Given the simple scope (returning a command string) and presence of an output schema, the description fully covers what the tool does, how its output relates to sibling tools, and the nuances of the underlying command. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by explaining the purpose of output format options (markdown vs json) and the enabled_only parameter. It provides context on when to use each format, enhancing the schema's descriptions.
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 it returns the CLI command to list a Xano workspace's knowledge base, specifying the verb (get), resource (CLI command), and distinguishing it from actual execution. It also mentions the knowledge types (skills, docs, agents.md) and differentiates from sibling xano_knowledge_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: use to get an overview before answering questions or creating new knowledge. It also gives when-not-to-use by directing to xano_knowledge_get for on-demand items needing full content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xano_meta_api_docsARead-onlyIdempotent
Get documentation for Xano's Meta API. Use this to understand how to programmatically manage Xano workspaces, databases, APIs, functions, agents, and more.
Topics
start: Xano Meta API - Getting Started
authentication: Authentication & Authorization
workspace: Workspace Management
apigroup: API Group Management
api: API Endpoint Management
table: Database Table Management
function: Reusable Function Management
task: Scheduled Task Management
agent: AI Agent Management
tool: Agent Tool Management
mcp_server: MCP Server Management
middleware: Middleware Management
branch: Branch Management
realtime: Realtime Channel Management
file: File Storage Management
history: Request & Execution History
workflows: Common Workflows
Usage
Start with "start" topic for overview and getting started
Use "workflows" for step-by-step guides
Use specific topics (workspace, table, api, etc.) for detailed endpoint docs
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Documentation topic to retrieve. Start with 'start' for an overview of the Meta API. Example: topic='workspace' for workspace management endpoints, topic='table' for database table operations. | |
| detail_level | No | Level of detail to return. 'overview' = brief summary of endpoints and their purpose. 'detailed' = full API reference with parameters, headers, and response formats. 'examples' = includes curl and fetch code examples for each endpoint. Default: 'detailed'. | |
| include_schemas | No | Include JSON schemas for request bodies and response payloads. Useful for understanding the expected data format. Set to false to reduce response size. Default: true. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| documentation | Yes | The Meta API documentation content for the requested topic. |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description confirms read-only behavior by stating it 'gets documentation'. It adds context about available topics and response detail levels, but does not disclose additional behavioral traits beyond what annotations provide.
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?
The description is well-structured with sections, bullet points, and usage tips. Every sentence serves a purpose, though it could be slightly more concise. Front-loaded with the main purpose.
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?
With 3 parameters fully documented in the schema, output schema present, and annotations covering safety, the description provides all necessary context: what the tool does, how to use it, and what topics are available. No gaps.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by recommending which topic to start with and explaining how to use each parameter (e.g., 'Start with "start" topic for overview'), enriching the schema's enum descriptions.
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 it retrieves documentation for Xano's Meta API, listing 17 specific topics and usage instructions. This clearly distinguishes it from sibling tools like xano_cli_docs which cover different APIs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: start with 'start' topic, use 'workflows' for step-by-step guides, and pick specific topics (workspace, table, api, etc.) for detailed endpoint docs. Also implies when not to use (when other docs needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xano_validate_xanoscriptARead-onlyIdempotent
Validate XanoScript code for syntax errors. Supports multiple input methods:
code: Raw XanoScript code as a string
file_path: Path to a single .xs file (easier than escaping code!)
file_paths: Array of file paths for batch validation
directory: Validate all .xs files in a directory
Returns errors with line/column positions and helpful suggestions for common mistakes. The language server auto-detects the object type from the code syntax.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | The XanoScript code to validate as a string. Use file_path instead if the code contains special characters that are hard to escape. Example: "var $name:text = 'hello'\nreturn $name" | |
| pattern | No | Glob pattern to filter files when using 'directory' (default: "**/*.xs"). Examples: "api/**/*.xs" to match only API files, "**/create.xs" to match all create files. | |
| directory | No | Directory path to validate. Validates all .xs files recursively. Use with 'pattern' to filter specific subdirectories or files. Example: "api/users" | |
| file_path | No | Path to a single XanoScript file to validate. Easier than passing code directly - avoids escaping issues. Example: "function/format.xs" | |
| file_paths | No | Array of file paths for batch validation. Returns a summary with per-file results. Example: ["api/users/get.xs", "api/users/create.xs", "function/format.xs"] |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | Whether the code passed validation without errors. |
| message | Yes | Human-readable validation summary with error details if any. |
| warnings | No | Number of non-fatal warnings encountered, if any. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description adds that it returns errors with line/column positions and helpful suggestions, and that the language server auto-detects object types. No contradictions 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?
Concise yet comprehensive. Uses bullet points for clarity, front-loads the purpose, and each sentence adds information. No fluff.
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?
Given the complexity (5 parameters), high schema coverage, annotations, and output schema, the description fully covers how to use the tool, what inputs are available, and what to expect as output. No gaps.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of each parameter and offering usage tips (e.g., easier than escaping). This justifies a higher score.
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 it validates XanoScript code for syntax errors, with a specific verb (validate) and resource (XanoScript code). It differentiates itself from sibling tools (documentation, version) by focusing on validation.
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?
Provides clear guidance on when to use each input method (e.g., file_path over code for escaping issues). However, does not explicitly state when not to use this tool or mention alternatives beyond its own parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xano_versionARead-onlyIdempotent
Get the current version of the Xano Developer MCP server. Returns the version string from package.json.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| version | Yes | The semantic version string of the MCP server. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint=true), non-destructive (destructiveHint=false), and idempotent (idempotentHint=true). The description adds value by specifying the return value source ('package.json'), providing additional context beyond 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 concise (two sentences) and front-loads the verb ('Get'). Every sentence contributes essential information without waste.
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?
For a simple version-retrieval tool with no parameters and an existing output schema, the description adequately covers purpose and return value. It mentions the return is a version string from package.json, which is sufficient for an agent to understand the tool's function.
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 input schema has no parameters, and schema description coverage is 100% (default). Per instructions, baseline for 0 parameters is 4. The description does not need to elaborate on parameters.
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 explicitly states the tool's purpose: 'Get the current version of the Xano Developer MCP server.' It uses a specific verb ('Get') and resource ('current version'), and clearly distinguishes from sibling tools which focus on documentation and validation.
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?
While the description does not explicitly state when or when not to use the tool, the use case is straightforward (checking server version) and sibling tools are unrelated, so the context is clear. However, adding a suggestion like 'Use this to verify server version' would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xano_xanoscript_docsARead-onlyIdempotent
Get XanoScript programming language documentation for AI code generation. Call without parameters for a compact index of all topics (~4KB, ~1K tokens); then drill in with topic= or file_path=. Use topic='readme' for the full prose overview (previously the no-arg default). For context-limited models: use tier='survival' (~1.2K tokens) or tier='working' (~4.5K tokens). Use 'topic' for specific documentation, or 'file_path' for context-aware docs based on the file you're editing. Use mode='quick_reference' for compact syntax reference (recommended for context efficiency). Use max_tokens to limit documentation size to fit your context budget. file_path mode defaults to 'quick_reference' to reduce context size; use mode='full' to get complete docs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'full' = complete documentation with explanations and examples. 'quick_reference' = compact reference with just syntax patterns and signatures. 'index' = compact topic listing with descriptions and byte sizes (~4KB, ~1K tokens). When set, 'index' takes precedence over topic and file_path. Use 'index' to discover available topics before loading them. Use 'quick_reference' to save context window space when you just need a reminder. Default: 'full' for topic mode, 'quick_reference' for file_path mode. | |
| tier | No | Pre-packaged documentation tier for context-limited models. 'survival' (~5KB, ~1.2K tokens): minimum syntax to write valid XanoScript. 'working' (~18KB, ~4.5K tokens): complete reference for common tasks. Overrides topic/file_path/mode when set. Use 'survival' for models with <16K context, 'working' for 16-64K context. | |
| topic | No | Documentation topic to retrieve. Call without any parameters to get the compact topic index; use topic='readme' for the full prose overview. Example: topic='syntax' for language syntax, topic='database' for database operations, topic='types' for type system. Common synonyms are accepted and resolved automatically (e.g. 'upload'/'storage' -> 'file-uploads'); an unrecognized topic returns the list of valid topics. Available topics: survival (Minimal syntax survival kit for writing valid XanoScript), working (Complete working reference for common XanoScript tasks), readme (XanoScript overview, workspace structure, and quick reference), essentials (Common patterns, quick reference, and common mistakes to avoid), syntax (Expressions, operators, and filters for all XanoScript code), syntax/string-filters (String filters, regex, encoding, security filters, text functions), syntax/array-filters (Array filters, expression-based higher-order filters (map/filter/reduce), JS lambda filters (lambda_map/lambda_reduce), and array functions), syntax/functions (Math filters/functions, object functions, bitwise operations), types (Data types, input blocks, and validation), tables (Database schema definitions with indexes and relationships), functions (Reusable function stacks with inputs and responses), apis (HTTP endpoint definitions with authentication and CRUD patterns), tasks (Scheduled and cron jobs), triggers (Event-driven handlers (table, realtime, workspace, agent, MCP)), database (All db), agents (AI agent configuration with LLM providers and tools), tools (AI tools for agents and MCP servers), mcp-servers (MCP server definitions exposing tools), unit-testing (Unit tests, mocks, and assertions within functions, APIs, and middleware), workflow-tests (End-to-end workflow tests with data source selection and tags), integrations (External service integrations index - see sub-topics for details), integrations/cloud-storage (AWS S3, Azure Blob, and GCP Storage operations (external buckets, not native Xano storage)), integrations/search (Elasticsearch, OpenSearch, and Algolia search operations), integrations/redis (Redis caching, rate limiting, and queue operations), integrations/external-apis (HTTP requests with api), integrations/utilities (Local storage, email, zip, and Lambda utilities), file-uploads (Uploading files to native Xano storage: file? input, create_attachment, sign_private_url), frontend (Static frontend development and deployment (static hosting)), addons (Reusable subqueries for fetching related data), debugging (Logging, inspecting, and debugging XanoScript execution), performance (Performance optimization best practices), realtime (Real-time channels and events for push updates), security (Security best practices for authentication and authorization), streaming (Streaming data from files, requests, and responses), middleware (Request/response interceptors for functions, queries, tasks, and tools), branch (Branch-level settings: middleware, history retention, visual styling), workspace (Workspace-level settings: environment variables, preferences, realtime) | |
| file_path | No | File path being edited. Returns all relevant docs automatically based on the file type and location. Uses applyTo pattern matching to select applicable topics. Example: 'api/users/create.xs' returns API, database, and syntax docs. 'function/format.xs' returns function and syntax docs. | |
| max_tokens | No | Maximum estimated token budget for documentation. When used with file_path, loads topics in priority order until budget is reached. Helps prevent context overflow for small-window models. Estimate: 1KB of docs ≈ 250 tokens. | |
| exclude_topics | No | List of topic names to exclude from file_path results. Use this to skip topics you've already loaded (e.g., exclude_topics: ['syntax', 'essentials']). Only applies when using file_path parameter. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| mode | No | The documentation mode used. |
| tier | No | The pre-packaged tier used, if any. |
| topics | No | List of matched topic names (file_path mode only). |
| version | No | The XanoScript documentation version. |
| file_path | No | The file path that was matched (file_path mode only). |
| documentation | No | The documentation content (index, topic, tier, or file_path mode). |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating safe read operations. The description adds significant behavioral context: token sizes, parameter overrides (tier overrides topic/file_path/mode), default modes for file_path, and pattern matching for file_path. No contradictions.
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?
The description is efficient and front-loaded with the main purpose, then systematically covers parameters. It is relatively long but every sentence earns its place. Slight improvement could be bullet points for parameter details, but it is still well-structured.
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?
Given 6 interdependent parameters and no required ones, the description comprehensively covers all usage scenarios: context limits, token budgets, default behaviors, and parameter priorities. Output schema exists, so return values are documented elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description enriches beyond schema by explaining interactions (e.g., tier overrides), giving examples (topic='readme' default change), and detailing context budget strategies. It adds substantial value.
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's purpose: 'Get XanoScript programming language documentation for AI code generation.' It uses a specific verb and resource, and distinguishes it from sibling tools like xano_cli_docs and xano_meta_api_docs by focusing on XanoScript documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each parameter: call without parameters for index, use topic, file_path, tier, mode, max_tokens, exclude_topics. It explains context considerations and default behaviors, and implicitly indicates alternatives (sibling tools for other docs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
4 tool updates
v2.2.2- Changed
xano_cli_docs1 field changed- changed
Input schema / properties / topic / enumPrevious value: -[ - "auth", - "start", - "profile", - "workspace", - "branch", - "function", - "release", - "tenant", - "unit_test", - "workflow_test", - "sandbox", - "platform", - "static_host", - "update", - "integration" -]New value: +[ + "auth", + "start", + "profile", + "workspace", + "branch", + "function", + "knowledge", + "release", + "tenant", + "unit_test", + "workflow_test", + "sandbox", + "platform", + "static_host", + "update", + "integration" +]
- Added
xano_knowledge_get - Added
xano_knowledge_list - Changed
xano_xanoscript_docs2 fields changed- changed
Input schema / properties / tier / descriptionPrevious value: -"Pre-packaged documentation tier for context-limited models. 'survival' (~5KB, ~1.2K tokens): minimum syntax to write valid XanoScript. 'working' (~17KB, ~4.4K tokens): complete reference for common tasks. Overrides topic/file_path/mode when set. Use 'survival' for models with <16K context, 'working' for 16-64K context."New value: +"Pre-packaged documentation tier for context-limited models. 'survival' (~5KB, ~1.2K tokens): minimum syntax to write valid XanoScript. 'working' (~18KB, ~4.5K tokens): complete reference for common tasks. Overrides topic/file_path/mode when set. Use 'survival' for models with <16K context, 'working' for 16-64K context." - changed
Input schema / properties / topic / descriptionPrevious value: -"Documentation topic to retrieve. Call without any parameters to get the compact topic index; use topic='readme' for the full prose overview. Example: topic='syntax' for language syntax, topic='database' for database operations, topic='types' for type system. Common synonyms are accepted and resolved automatically (e.g. 'upload'/'storage' -> 'file-uploads'); an unrecognized topic returns the list of valid topics.\n\nAvailable topics:\nsurvival (Minimal syntax survival kit for writing valid XanoScript), working (Complete working reference for common XanoScript tasks), readme (XanoScript overview, workspace structure, and quick reference), essentials (Common patterns, quick reference, and common mistakes to avoid), syntax (Expressions, operators, and filters for all XanoScript code), syntax/string-filters (String filters, regex, encoding, security filters, text functions), syntax/array-filters (Array filters, functional operations, and array functions), syntax/functions (Math filters/functions, object functions, bitwise operations), types (Data types, input blocks, and validation), tables (Database schema definitions with indexes and relationships), functions (Reusable function stacks with inputs and responses), apis (HTTP endpoint definitions with authentication and CRUD patterns), tasks (Scheduled and cron jobs), triggers (Event-driven handlers (table, realtime, workspace, agent, MCP)), database (All db), agents (AI agent configuration with LLM providers and tools), tools (AI tools for agents and MCP servers), mcp-servers (MCP server definitions exposing tools), unit-testing (Unit tests, mocks, and assertions within functions, APIs, and middleware), workflow-tests (End-to-end workflow tests with data source selection and tags), integrations (External service integrations index - see sub-topics for details), integrations/cloud-storage (AWS S3, Azure Blob, and GCP Storage operations (external buckets, not native Xano storage)), integrations/search (Elasticsearch, OpenSearch, and Algolia search operations), integrations/redis (Redis caching, rate limiting, and queue operations), integrations/external-apis (HTTP requests with api), integrations/utilities (Local storage, email, zip, and Lambda utilities), file-uploads (Uploading files to native Xano storage: file? input, create_attachment, sign_private_url), frontend (Static frontend development and deployment), addons (Reusable subqueries for fetching related data), debugging (Logging, inspecting, and debugging XanoScript execution), performance (Performance optimization best practices), realtime (Real-time channels and events for push updates), security (Security best practices for authentication and authorization), streaming (Streaming data from files, requests, and responses), middleware (Request/response interceptors for functions, queries, tasks, and tools), branch (Branch-level settings: middleware, history retention, visual styling), workspace (Workspace-level settings: environment variables, preferences, realtime)"New value: +"Documentation topic to retrieve. Call without any parameters to get the compact topic index; use topic='readme' for the full prose overview. Example: topic='syntax' for language syntax, topic='database' for database operations, topic='types' for type system. Common synonyms are accepted and resolved automatically (e.g. 'upload'/'storage' -> 'file-uploads'); an unrecognized topic returns the list of valid topics.\n\nAvailable topics:\nsurvival (Minimal syntax survival kit for writing valid XanoScript), working (Complete working reference for common XanoScript tasks), readme (XanoScript overview, workspace structure, and quick reference), essentials (Common patterns, quick reference, and common mistakes to avoid), syntax (Expressions, operators, and filters for all XanoScript code), syntax/string-filters (String filters, regex, encoding, security filters, text functions), syntax/array-filters (Array filters, expression-based higher-order filters (map/filter/reduce), JS lambda filters (lambda_map/lambda_reduce), and array functions), syntax/functions (Math filters/functions, object functions, bitwise operations), types (Data types, input blocks, and validation), tables (Database schema definitions with indexes and relationships), functions (Reusable function stacks with inputs and responses), apis (HTTP endpoint definitions with authentication and CRUD patterns), tasks (Scheduled and cron jobs), triggers (Event-driven handlers (table, realtime, workspace, agent, MCP)), database (All db), agents (AI agent configuration with LLM providers and tools), tools (AI tools for agents and MCP servers), mcp-servers (MCP server definitions exposing tools), unit-testing (Unit tests, mocks, and assertions within functions, APIs, and middleware), workflow-tests (End-to-end workflow tests with data source selection and tags), integrations (External service integrations index - see sub-topics for details), integrations/cloud-storage (AWS S3, Azure Blob, and GCP Storage operations (external buckets, not native Xano storage)), integrations/search (Elasticsearch, OpenSearch, and Algolia search operations), integrations/redis (Redis caching, rate limiting, and queue operations), integrations/external-apis (HTTP requests with api), integrations/utilities (Local storage, email, zip, and Lambda utilities), file-uploads (Uploading files to native Xano storage: file? input, create_attachment, sign_private_url), frontend (Static frontend development and deployment (static hosting)), addons (Reusable subqueries for fetching related data), debugging (Logging, inspecting, and debugging XanoScript execution), performance (Performance optimization best practices), realtime (Real-time channels and events for push updates), security (Security best practices for authentication and authorization), streaming (Streaming data from files, requests, and responses), middleware (Request/response interceptors for functions, queries, tasks, and tools), branch (Branch-level settings: middleware, history retention, visual styling), workspace (Workspace-level settings: environment variables, preferences, realtime)"
1 tool update
v2.2.0- Changed
xano_xanoscript_docs5 fields changed- changed
Input schema / properties / mode / descriptionPrevious value: -"'full' = complete documentation with explanations and examples. 'quick_reference' = compact reference with just syntax patterns and signatures. 'index' = compact topic listing with descriptions and byte sizes (~1KB). Use 'index' to discover available topics before loading them. Use 'quick_reference' to save context window space when you just need a reminder. Default: 'full' for topic mode, 'quick_reference' for file_path mode."New value: +"'full' = complete documentation with explanations and examples. 'quick_reference' = compact reference with just syntax patterns and signatures. 'index' = compact topic listing with descriptions and byte sizes (~4KB, ~1K tokens). When set, 'index' takes precedence over topic and file_path. Use 'index' to discover available topics before loading them. Use 'quick_reference' to save context window space when you just need a reminder. Default: 'full' for topic mode, 'quick_reference' for file_path mode." - changed
Input schema / properties / tier / descriptionPrevious value: -"Pre-packaged documentation tier for context-limited models. 'survival' (~3KB, ~800 tokens): minimum syntax to write valid XanoScript. 'working' (~12KB, ~3500 tokens): complete reference for common tasks. Overrides topic/file_path/mode when set. Use 'survival' for models with <16K context, 'working' for 16-64K context."New value: +"Pre-packaged documentation tier for context-limited models. 'survival' (~5KB, ~1.2K tokens): minimum syntax to write valid XanoScript. 'working' (~17KB, ~4.4K tokens): complete reference for common tasks. Overrides topic/file_path/mode when set. Use 'survival' for models with <16K context, 'working' for 16-64K context." - changed
Input schema / properties / topic / descriptionPrevious value: -"Documentation topic to retrieve. Call without any parameters to get the README overview. Example: topic='syntax' for language syntax, topic='database' for database operations, topic='types' for type system.\n\nAvailable topics:\nsurvival (Minimal syntax survival kit for writing valid XanoScript (~3KB)), working (Complete working reference for common XanoScript tasks (~12KB)), readme (XanoScript overview, workspace structure, and quick reference), essentials (Common patterns, quick reference, and common mistakes to avoid), syntax (Expressions, operators, and filters for all XanoScript code), syntax/string-filters (String filters, regex, encoding, security filters, text functions), syntax/array-filters (Array filters, functional operations, and array functions), syntax/functions (Math filters/functions, object functions, bitwise operations), types (Data types, input blocks, and validation), tables (Database schema definitions with indexes and relationships), functions (Reusable function stacks with inputs and responses), apis (HTTP endpoint definitions with authentication and CRUD patterns), tasks (Scheduled and cron jobs), triggers (Event-driven handlers (table, realtime, workspace, agent, MCP)), database (All db), agents (AI agent configuration with LLM providers and tools), tools (AI tools for agents and MCP servers), mcp-servers (MCP server definitions exposing tools), unit-testing (Unit tests, mocks, and assertions within functions, APIs, and middleware), workflow-tests (End-to-end workflow tests with data source selection and tags), integrations (External service integrations index - see sub-topics for details), integrations/cloud-storage (AWS S3, Azure Blob, and GCP Storage operations), integrations/search (Elasticsearch, OpenSearch, and Algolia search operations), integrations/redis (Redis caching, rate limiting, and queue operations), integrations/external-apis (HTTP requests with api), integrations/utilities (Local storage, email, zip, and Lambda utilities), frontend (Static frontend development and deployment), addons (Reusable subqueries for fetching related data), debugging (Logging, inspecting, and debugging XanoScript execution), performance (Performance optimization best practices), realtime (Real-time channels and events for push updates), security (Security best practices for authentication and authorization), streaming (Streaming data from files, requests, and responses), middleware (Request/response interceptors for functions, queries, tasks, and tools), branch (Branch-level settings: middleware, history retention, visual styling), workspace (Workspace-level settings: environment variables, preferences, realtime)"New value: +"Documentation topic to retrieve. Call without any parameters to get the compact topic index; use topic='readme' for the full prose overview. Example: topic='syntax' for language syntax, topic='database' for database operations, topic='types' for type system. Common synonyms are accepted and resolved automatically (e.g. 'upload'/'storage' -> 'file-uploads'); an unrecognized topic returns the list of valid topics.\n\nAvailable topics:\nsurvival (Minimal syntax survival kit for writing valid XanoScript), working (Complete working reference for common XanoScript tasks), readme (XanoScript overview, workspace structure, and quick reference), essentials (Common patterns, quick reference, and common mistakes to avoid), syntax (Expressions, operators, and filters for all XanoScript code), syntax/string-filters (String filters, regex, encoding, security filters, text functions), syntax/array-filters (Array filters, functional operations, and array functions), syntax/functions (Math filters/functions, object functions, bitwise operations), types (Data types, input blocks, and validation), tables (Database schema definitions with indexes and relationships), functions (Reusable function stacks with inputs and responses), apis (HTTP endpoint definitions with authentication and CRUD patterns), tasks (Scheduled and cron jobs), triggers (Event-driven handlers (table, realtime, workspace, agent, MCP)), database (All db), agents (AI agent configuration with LLM providers and tools), tools (AI tools for agents and MCP servers), mcp-servers (MCP server definitions exposing tools), unit-testing (Unit tests, mocks, and assertions within functions, APIs, and middleware), workflow-tests (End-to-end workflow tests with data source selection and tags), integrations (External service integrations index - see sub-topics for details), integrations/cloud-storage (AWS S3, Azure Blob, and GCP Storage operations (external buckets, not native Xano storage)), integrations/search (Elasticsearch, OpenSearch, and Algolia search operations), integrations/redis (Redis caching, rate limiting, and queue operations), integrations/external-apis (HTTP requests with api), integrations/utilities (Local storage, email, zip, and Lambda utilities), file-uploads (Uploading files to native Xano storage: file? input, create_attachment, sign_private_url), frontend (Static frontend development and deployment), addons (Reusable subqueries for fetching related data), debugging (Logging, inspecting, and debugging XanoScript execution), performance (Performance optimization best practices), realtime (Real-time channels and events for push updates), security (Security best practices for authentication and authorization), streaming (Streaming data from files, requests, and responses), middleware (Request/response interceptors for functions, queries, tasks, and tools), branch (Branch-level settings: middleware, history retention, visual styling), workspace (Workspace-level settings: environment variables, preferences, realtime)" - removed
Input schema / properties / topic / enumRemoved value: -[ - "survival", - "working", - "readme", - "essentials", - "syntax", - "syntax/string-filters", - "syntax/array-filters", - "syntax/functions", - "types", - "tables", - "functions", - "apis", - "tasks", - "triggers", - "database", - "agents", - "tools", - "mcp-servers", - "unit-testing", - "workflow-tests", - "integrations", - "integrations/cloud-storage", - "integrations/search", - "integrations/redis", - "integrations/external-apis", - "integrations/utilities", - "frontend", - "addons", - "debugging", - "performance", - "realtime", - "security", - "streaming", - "middleware", - "branch", - "workspace" -] - changed
Output schema / properties / documentation / descriptionPrevious value: -"The documentation content (topic or README mode)."New value: +"The documentation content (index, topic, tier, or file_path mode)."
5 tool updates
v2.0.4- First observed
xano_cli_docs - First observed
xano_meta_api_docs - First observed
xano_validate_xanoscript - First observed
xano_version - First observed
xano_xanoscript_docs
TDQS
A4.4/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: CLI docs, knowledge retrieval (list vs get), Meta API docs, XanoScript validation, version info, and XanoScript language docs. No overlapping functionalities.
Naming Consistency3/5
All tools share the 'xano_' prefix but the naming pattern is inconsistent: some use noun_verb (knowledge_get, knowledge_list), others noun_noun (cli_docs, meta_api_docs, xanoscript_docs), one verb_noun (validate_xanoscript), and one simple noun (version).
Tool Count5/5
With 7 tools, the count is well-scoped for a developer-focused MCP server. Each tool provides essential functionality without being overwhelming or too sparse.
Completeness3/5
The tool set covers documentation, knowledge management, code validation, and version info, but lacks tools for executing CLI commands or performing actual workspace operations, which may require agent workarounds.
Maintenance
ActivityNo data
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
- ZapierOAuthcom.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAn MCP server that provides AI assistants with comprehensive access to n8n workflow automation nodes, properties, and documentation. It enables models like Claude to search for nodes, access configuration templates, and manage workflows through natural language.MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that empowers AI assistants to build, validate, and manage n8n workflows by providing structured access to documentation for over 1,200 nodes and thousands of templates. It enables deep integration with n8n instances for automated workflow orchestration and management through natural language.123,6061MIT
- AlicenseNot gradedqualityDmaintenanceA production-ready MCP server providing AI assistants with intelligent Supabase database access, featuring dynamic schema discovery, complete user management, and file storage operations.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/xano-inc/xano-developer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server