agent
Server Details
Non-custodial Ethereum swaps and managed liquidity. You sign every tx; FluxIQ holds no funds.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 9 of 9 tools scored. Lowest: 3.4/5.
Each tool has a clearly distinct purpose: build, list, quote, and ping. There is no overlap or ambiguity between any two tools.
All tool names consistently follow a verb_noun pattern (e.g., build_lp_deposit, list_tokens, quote_swap). The naming structure is uniform and predictable.
With 9 tools covering building, listing, quoting, and health check, the count is well-scoped for a non-custodial token operations server. No unnecessary tools and no missing essential ones.
The tool set covers the full lifecycle for its stated domain: building plans for deposit, withdraw, and swap; listing available tokens and vaults; and providing quotes for each action. There are no obvious gaps.
Available Tools
9 toolsbuild_lp_depositAInspect
Build a NON-CUSTODIAL any-token LP deposit plan (approve → Permit2 sign → router.depositAnyToken) for the caller to sign + broadcast. No broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| vault | Yes | Known any-token LP vault address. | |
| chainId | Yes | EVM chain id (mainnet = 1 in v1). | |
| amountIn | Yes | Amount in base units (integer string, e.g. USDC 6dp). | |
| recipient | Yes | Recipient / payer address (the wallet that signs + receives). | |
| inputToken | Yes | Any held token to deposit. | |
| slippageBps | No | Optional slippage budget in basis points (0–10000). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It discloses the non-custodial nature, the three-step plan, and that no broadcast occurs. However, it does not discuss failure modes, gas costs, or dependencies on token approvals, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads key attributes: 'NON-CUSTODIAL' and 'any-token LP deposit plan'. Every word adds value, with no redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (6 parameters, no output schema, no annotations), the description is sufficient to understand the tool's purpose but lacks details on return value structure or edge-case behavior. It adequately covers the core workflow but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The tool description adds context about 'any-token' and the overall plan but does not elaborate on individual parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds a non-custodial any-token LP deposit plan, specifying the sequence of steps (approve, Permit2 sign, router.depositAnyToken) and that it is for the caller to sign and broadcast. It distinguishes itself from sibling tools like build_lp_withdraw by focusing on deposit, and from build_swap by being LP-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating an LP deposit plan that the user must sign and broadcast, with the 'NON-CUSTODIAL' tag suggesting when self-custody is required. It does not explicitly compare to alternatives or state when not to use, but the context of sibling tools and the 'No broadcast' note provide clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_lp_withdrawAInspect
Build a NON-CUSTODIAL any-token LP withdraw plan (approve shares → Permit2 sign → router.withdrawAnyToken) for the caller to sign + broadcast. No broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| vault | Yes | Known any-token LP vault address. | |
| shares | Yes | Vault shares to burn (base-unit integer string). | |
| chainId | Yes | EVM chain id (mainnet = 1 in v1). | |
| recipient | Yes | Recipient / payer address (the wallet that signs + receives). | |
| outputToken | Yes | Token to receive on withdraw. | |
| slippageBps | No | Optional slippage budget in basis points (0–10000). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the non-custodial nature, the sequence of operations, and that execution is left to the caller. However, it does not cover failure modes or fees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key purpose and behavior, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having 6 parameters and no output schema, the description does not explain what the tool returns (e.g., a transaction object or signed data). The lack of output details leaves the agent uncertain about how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds no extra meaning to parameters beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a non-custodial LP withdraw plan, outlining the specific steps (approve shares, Permit2 sign, router.withdrawAnyToken) and that the caller signs and broadcasts. It distinguishes itself from siblings like build_lp_deposit and build_swap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'No broadcast,' implying the tool only constructs the plan, but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. It does not mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_swapAInspect
Build a NON-CUSTODIAL ERC20 swap plan (approve → Permit2 sign → router.swap) for the caller to sign + broadcast. No broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | EVM chain id (mainnet = 1 in v1). | |
| tokenIn | Yes | ERC20 input token (native ETH is not supported). | |
| amountIn | Yes | Amount in base units (integer string, e.g. USDC 6dp). | |
| tokenOut | Yes | ERC20 output token. | |
| recipient | Yes | Recipient / payer address (the wallet that signs + receives). | |
| slippageBps | No | Optional slippage budget in basis points (0–10000). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of disclosing behavioral traits. It clearly states the tool is non-custodial, does not broadcast, and outlines the steps involved. While it does not mention error conditions or validation details, the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key information: non-custodial ERC20 swap plan, the steps, and the fact that no broadcast occurs. No unnecessary words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the operation's purpose and behavior, it lacks details about the output/return value. The agent does not know what the 'plan' looks like (e.g., JSON, transaction data). Given no output schema, this is a gap. However, for a tool with such high schema coverage and clear purpose, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with each parameter having a description. The tool description does not add significant meaning beyond what the schema already provides, but it reinforces the context that tokenIn cannot be native ETH (already in schema). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a non-custodial ERC20 swap plan, outlines the steps (approve, Permit2 sign, router.swap), and explicitly says it does not broadcast. This differentiates it from siblings like quote_swap (read-only quote) and build_lp_deposit/build_lp_withdraw (liquidity operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used when the caller wants to sign and broadcast a swap themselves, but it does not explicitly state when to use this tool vs alternatives like quote_swap or when not to use it. Some implicit guidance is present (non-custodial, no broadcast), but it lacks explicit contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tokensBInspect
List the public swap token allow-list (address/symbol/name/decimals). Public market data only — no user-private reads.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | No | Defaults to mainnet (1). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that data is public and lists returned fields, but lacks details on pagination, rate limits, error behavior, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence of 15 words, front-loading purpose and key details with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list function with no output schema, the description adequately specifies returned fields and data scope. Minor gaps include lack of ordering or size limits, but overall complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (chainId) is fully described in the schema with a default hint. The description adds no additional insight beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'list' and the resource 'public swap token allow-list', and specifies the returned fields (address/symbol/name/decimals). It distinguishes itself from sibling tools like list_vaults or action-oriented tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions 'public market data only — no user-private reads', hinting at appropriate use, but does not explicitly state when to use this tool versus alternatives, nor provides scenarios for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_vaultsAInspect
List the public any-token LP vaults (addresses + token pair). Public market data only — no user-private reads.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | No | Defaults to mainnet (1). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature and return type (addresses + token pair). However, with no annotations, it should ideally mention pagination or error handling; lacks these details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence. Front-loaded with action and object, no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (1 optional param, no output schema). Description covers purpose and output adequately, but could mention if any filtering or ordering is possible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (chainId described as 'Defaults to mainnet (1).'). Tool description adds no additional parameter semantics beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specifies verb 'List', resource 'public any-token LP vaults', and output (addresses + token pair). Distinguishes from sibling tools that involve user interactions or transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states it returns public market data only (not user-private reads). Implicitly suggests when not to use, but does not explicitly mention alternatives like build_lp_deposit for user-specific actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingAInspect
Health check — returns 'pong'.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It accurately describes the tool's behavior as a health check returning 'pong'. No annotations exist to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no extraneous words, front-loaded with the purpose ('Health check') and result ('returns pong').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description fully covers what the tool does and its return value. Complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so no additional parameter information is needed. The description adds no parameter details, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a health check that returns 'pong', distinguishing it from sibling tools which perform more complex operations like building transactions or quoting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Health check' implies it should be used to verify server connectivity. No explicit alternatives or exclusions are needed given its simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_lp_depositAInspect
Read-only any-token LP deposit preview: estimated shares, guaranteed minShares, fee, and refund bps. No broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| vault | Yes | Known any-token LP vault address. | |
| chainId | Yes | EVM chain id (mainnet = 1 in v1). | |
| amountIn | Yes | Amount in base units (integer string, e.g. USDC 6dp). | |
| recipient | Yes | Recipient / payer address (the wallet that signs + receives). | |
| inputToken | Yes | Any held token to deposit. | |
| slippageBps | No | Optional slippage budget in basis points (0–10000). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses read-only behavior, no broadcast, and lists key return values. Provides sufficient behavioral context for an agent to understand the tool's safety and output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with 'Read-only' keyword, no superfluous words. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple quote tool: states output fields, no output schema needed. Minor omission: no mention of prerequisites (e.g., vault must be known from list_vaults), but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra parameter details, only mentions outputs. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'preview' and the resource 'any-token LP deposit', lists specific outputs (estimated shares, minShares, fee, refund bps), and distinguishes from sibling 'build_lp_deposit' by explicitly stating 'No broadcast.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly indicates this is for previewing deposit estimates before broadcasting, as it says 'Read-only' and 'No broadcast.' Does not explicitly name alternatives or when-not to use, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_lp_withdrawAInspect
Read-only any-token LP withdraw preview: estimated and guaranteed token-out for burning vault shares. No broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| vault | Yes | Known any-token LP vault address. | |
| shares | Yes | Vault shares to burn (base-unit integer string). | |
| chainId | Yes | EVM chain id (mainnet = 1 in v1). | |
| recipient | Yes | Recipient / payer address (the wallet that signs + receives). | |
| outputToken | Yes | Token to receive on withdraw. | |
| slippageBps | No | Optional slippage budget in basis points (0–10000). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears the full burden. It clearly discloses the tool is read-only ('No broadcast') and gives preview info. This adequately covers behavioral transparency for a quote tool, though additional details about potential errors or rate limits could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information: read-only, preview, token-out, burning shares, no broadcast. Every word contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description explains what is returned (estimated and guaranteed token-out). Given 6 parameters (all schema-documented), the description covers the essential behavior sufficiently. It could mention the return format or example values, but it's complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds only high-level context ('estimated and guaranteed token-out for burning vault shares') without supplementing parameter-specific meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a read-only preview for withdrawing LP tokens, providing estimated and guaranteed token-out. It distinguishes itself from sibling tools like 'build_lp_withdraw' by explicitly noting 'No broadcast', making its purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before an actual withdraw by calling it a 'preview' and stating 'No broadcast'. While it doesn't explicitly list alternatives, the context of siblings and the term 'preview' provides clear guidance on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_swapAInspect
Read-only ERC20 swap quote: expected out, guaranteed minOut, fee, and a high-level route summary. No broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | EVM chain id (mainnet = 1 in v1). | |
| tokenIn | Yes | ERC20 input token (native ETH is not supported). | |
| amountIn | Yes | Amount in base units (integer string, e.g. USDC 6dp). | |
| tokenOut | Yes | ERC20 output token. | |
| recipient | Yes | Recipient / payer address (the wallet that signs + receives). | |
| slippageBps | No | Optional slippage budget in basis points (0–10000). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden. It clearly states the tool is read-only ('No broadcast') and describes what outputs are returned (expected out, minOut, fee, route summary). It does not cover potential failures or rate limits, but for a quote tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with key information ('Read-only ERC20 swap quote') and efficiently covers purpose, outputs, and behavior without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though there is no output schema, the description summarizes return values (expected out, minOut, fee, route summary). With 6 parameters fully documented in schema and clear sibling context, the description provides sufficient completeness for a straightforward quoting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter has a detailed description. The tool description adds little beyond the schema for parameters themselves, but provides context. Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a read-only ERC20 swap quote tool, listing specific outputs (expected out, minOut, fee, route summary) and explicitly says 'No broadcast.' This distinguishes it from siblings like build_swap (which executes) and quote_lp_deposit/withdraw (for liquidity positions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for previewing a swap before execution) by stating it is read-only and does not broadcast. However, it does not explicitly state when not to use or mention alternatives, though sibling tool names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!