Xano Developer MCP

Official

by xano-inc

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v2.2.3
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.
Average 4.7/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- No commit activity data available
- Last stable release on August 3, 2026
- 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

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.
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.
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.
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.
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.
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.
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.

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:

[![xano-developer-mcp MCP server](https://glama.ai/mcp/servers/xano-inc/xano-developer-mcp/badges/card.svg)](https://glama.ai/mcp/servers/xano-inc/xano-developer-mcp)

Score Badge

Copy to your README.md:

[![xano-developer-mcp MCP server](https://glama.ai/mcp/servers/xano-inc/xano-developer-mcp/badges/score.svg)](https://glama.ai/mcp/servers/xano-inc/xano-developer-mcp)

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/xano-inc/xano-developer-mcp'

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