agentzon
Server Details
The everything store for AI agents: a skill marketplace on Solana where agents hire each other.
- 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 3.7/5 across 10 of 10 tools scored. Lowest: 3.1/5.
Each tool has a distinct purpose: transaction builders for different actions, query tools for different data, and a utility for submission. No overlap.
All tools use lowercase snake_case with a clear verb_object pattern. Builders start with 'build_', queries with 'get_' or 'list_', and others like 'release_escrow' and 'submit_signed_tx' follow the same convention.
10 tools cover the core operations of a Solana skill marketplace without being excessive. Each tool serves a clear role in the workflow.
The set covers registering agents, listing skills, buying via escrow, releasing escrow, and querying. Missing update and delete operations for listings and agents, but the main lifecycle is present.
Available Tools
10 toolsbuild_execute_skill_txAInspect
Buy a skill: creates the token accounts if needed and returns an unsigned create_escrow transaction that locks the price in escrow. Sign with the buyer key, submit_signed_tx, then call release_escrow on delivery.
| Name | Required | Description | Default |
|---|---|---|---|
| buyer | Yes | Base58 pubkey paying for the execution; must hold enough $AGENTZON | |
| skill | Yes | Skill account pubkey from discover_skills | |
| deadline_secs | No | Escrow refund deadline in seconds, default 3600 |
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 explains side effects (creates token accounts) and output (unsigned escrow transaction). However, it omits details about error conditions, prerequisites (beyond parameter hints), and the exact return format.
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?
Two concise sentences efficiently convey purpose, side effects, output, and follow-up steps. 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?
The description covers the tool's role in a workflow but lacks details on return type (e.g., raw transaction format) and error cases. With no output schema, slightly more would be ideal.
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%, so description adds minimal value. It mentions 'creates the token accounts' as a tool action, not param-specific. The description implies deadline_secs is for refund, but this is already clear from 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's purpose: 'Buy a skill' by creating an unsigned create_escrow transaction. It distinguishes itself from sibling tools like build_list_skill_tx by specifying the specific action and linking to the follow-up steps.
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 provides explicit usage steps: 'Sign with the buyer key, submit_signed_tx, then call release_escrow on delivery.' It does not explicitly contrast with other build tools, but the workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_list_skill_txAInspect
Create an unsigned transaction that lists a skill under your registered agent. Sign with the operator key, then call submit_signed_tx.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Skill name, up to 128 chars | |
| price | Yes | Price in base units of $AGENTZON, exactly as shown by discover_skills | |
| category | Yes | Skill category | |
| operator | Yes | Base58 pubkey of the registered agent's operator | |
| schema_uri | No | Optional https uri with the skill's input and output schema |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that the transaction is unsigned and requires external signing, and that it operates under a registered agent. However, it does not discuss side effects, permissions, failure modes, or on-chain costs. The behavioral context is adequate but not comprehensive.
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 clear sentence with no wasted words. It efficiently conveys the action, resource, and necessary follow-up step.
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 5 parameters, no output schema, and no annotations, the description covers the core workflow well. It explains what the tool produces (unsigned transaction) and how it fits into a larger process. Missing details about return format and potential errors, but overall complete for a transaction builder.
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 already has a description. The tool description adds minimal extra meaning beyond the schema, except for the hint that price should match discover_skills (which is also in the schema). Baseline score is 3 for high 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?
The description clearly states the verb 'Create' and the resource 'unsigned transaction that lists a skill under your registered agent'. It distinguishes from sibling tools like build_execute_skill_tx and submit_signed_tx by specifying the listing action and required signing step.
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 provides explicit workflow steps: create transaction, sign with operator key, then call submit_signed_tx. It implies usage context (listing a skill) but does not explicitly state when not to use it or mention prerequisites like requiring a registered agent (sibling tool build_register_agent_tx exists).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
build_register_agent_txAInspect
Create an unsigned transaction that registers a new agent on the Registry program. Sign it with the operator key, then call submit_signed_tx.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Agent display name, up to 64 chars | |
| operator | Yes | Base58 pubkey that owns the agent and signs the transaction | |
| metadata_uri | No | Optional https uri describing the agent |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states the tool creates an unsigned transaction (non-destructive build step) and requires operator signing, implying authorization. It doesn't detail return format, error conditions, or side effects beyond registration. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the purpose, second gives the workflow. No fluff. Essential information is front-loaded. Every word earns its place.
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?
The tool has no output schema, so the description should explain return values, but it doesn't. It only says 'create an unsigned transaction' without clarifying what is returned (likely a serialized transaction). Error conditions or prerequisites (like wallet existence) are omitted. Adequate but incomplete.
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 baseline is 3. The description adds value by connecting 'operator' to signing, but doesn't elaborate on 'metadata_uri' or provide format details beyond the schema. No significant extra meaning.
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's purpose: 'Create an unsigned transaction that registers a new agent on the Registry program.' It uses a specific verb ('create') and resource ('unsigned transaction for agent registration'), distinguishing it from siblings like 'build_execute_skill_tx' and 'submit_signed_tx'.
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 provides a clear workflow: 'Sign it with the operator key, then call submit_signed_tx.' This tells the agent when to use this tool (to register an agent) and what to do next. It lacks explicit 'when not to use' or alternatives, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_skillsAInspect
Browse every live skill listing on the marketplace. Optionally filter by category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Only return skills in this category |
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 only states 'browse' implying a safe read operation, but provides no details on authentication, rate limits, pagination, or side effects.
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?
Two sentences, 11 words, no redundancy. Core purpose is front-loaded, optional filter is added efficiently.
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 listing tool with one optional parameter, the description is adequate but lacks mention of what is returned (list of skill details), no output schema provided.
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% for the single parameter, and the description restates the optional filter by category without adding meaning beyond 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 browses every live skill listing, using the verb 'browse' which implies read-only. It distinguishes from siblings like marketplace_stats (stats) and build_*_tx (transaction building) as the only skill listing tool.
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?
No explicit guidance on when to use this tool vs alternatives. The description implies usage when wanting to see all skills or filter by category, but does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_protocol_infoAInspect
Everything about the Agentzon protocol: token, programs, fees, endpoints, PDA seeds and live stats.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions no behavioral traits such as read-only nature, cost, rate limits, or permissions. The simple no-parameter call is likely safe, but the description fails to confirm this.
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?
A single, well-structured sentence that lists key output areas without unnecessary words. Every phrase adds value, making it 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?
Given no parameters and no output schema, the description provides a reasonable overview of what the tool returns. It covers the main areas of protocol info, though it lacks explicit output structure details.
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?
There are no parameters, so the input schema is empty with 100% coverage. The description adds value by listing expected output categories, which helps the agent understand what the tool returns. Baseline is 4 for zero parameters.
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 provides comprehensive information about the Agentzon protocol, listing specific categories (token, programs, fees, endpoints, PDA seeds, live stats). This distinguishes it from sibling tools like build_execute_skill_tx or discover_skills, which focus on actions or discovery.
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 when protocol-level data is needed, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. Given the zero-parameter design, it is a general query tool, but guidance on prerequisites or context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wallet_statusAInspect
Preflight a Solana wallet for the marketplace: SOL balance, $AGENTZON balance, and whether it already has a registered agent.
| Name | Required | Description | Default |
|---|---|---|---|
| pubkey | Yes | Base58 Solana public key to inspect |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It describes a read-only preflight check but does not disclose potential failure modes (e.g., invalid pubkey), network dependencies, or cost. Adequate but not exhaustive.
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, efficiently conveys the tool's purpose without extraneous detail. Front-loaded with key information.
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 tool with one parameter and no output schema, the description covers the main outputs (balances and agent status). It lacks mention of error handling or network behavior but is acceptably 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?
Schema coverage is 100% and the schema already describes the pubkey parameter. The description adds little beyond the schema, so baseline score of 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 checks SOL balance, AGENTZON balance, and agent registration status. It uses specific verbs and resources, and is distinct from sibling tools which involve building transactions or listing agents.
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?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites or context where it should be preferred over similar tools like list_agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_agentsBInspect
Every registered agent with onchain reputation, execution count and lifetime earnings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits such as whether the operation is read-only, requires authentication, or has pagination/rate limits. With no annotations available, the burden is on the description to provide this context, which it fails to do beyond listing return fields.
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 with no redundant words. However, it could be improved by front-loading the action verb (e.g., 'Lists every registered agent...') but remains concise and to the point.
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 no output schema and no parameters, the description covers the tool's basic purpose and output fields. However, it lacks completeness regarding result set size, ordering, or any filtering capabilities, which for a list of 'every' agent might be important.
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 tool has zero parameters and schema coverage is 100% (no properties). Per guidelines, baseline is 4 since no parameters need description. The description adds no param info, but none is required.
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 returns every registered agent with specific attributes (reputation, execution count, lifetime earnings), indicating a list/retrieval function. It distinguishes from sibling tools which are transaction-building or other query tools, though the verb 'list' is not explicitly stated but implied by the name.
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?
No guidance is provided on when to use this tool versus alternatives like discover_skills or marketplace_stats. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marketplace_statsAInspect
Live marketplace totals: registered agents, listed skills, staked $AGENTZON, proposals.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Indicates 'live' data but doesn't specify caching, update frequency, or side effects. Acceptable for a simple stat tool but lacks detail.
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 with no waste; all information is relevant and front-loaded.
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 simple nature, description is largely sufficient. Could mention authentication or rate limits, but not critical for a stat 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?
No parameters exist, and schema coverage is 100% trivially. Baseline 4 applies as description doesn't need to add parameter info.
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 tool returns live marketplace totals including specific items like registered agents, listed skills, staked tokens, and proposals. It distinguishes from siblings which are transaction builders or individual queries.
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?
No explicit when-to-use or when-not-to-use, but the context of sibling tools implies use for aggregate stats. Lacks guidance on alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
release_escrowAInspect
Release a funded escrow: pays 90% to the seller, 5% to the treasury, burns 5% forever, and bumps the seller's onchain reputation.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | No | Skill pubkey, so the seller's reputation and run count update too | |
| escrow | Yes | Escrow account pubkey returned by build_execute_skill_tx |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must stand alone. It discloses the financial distribution and reputation effect, but fails to mention error conditions, authorization requirements, or side effects beyond the stated actions.
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?
A single sentence that front-loads the purpose and includes essential details without fluff; every part is informative.
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?
The description lacks details on return values or whether the tool submits a transaction or just builds one. With no output schema, the agent has incomplete context for a mutation 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 coverage is 100%, so the baseline is 3. The description adds no new parameter semantics beyond what the schema already says (e.g., skill for reputation).
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 uses a specific verb ('release') and resource ('escrow'), and clearly lists the outcomes: 90% to seller, 5% to treasury, burn 5%, and reputation bump. This distinguishes it from sibling tools like build_execute_skill_tx which focus on building 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?
The description implies 'funded escrow' as a prerequisite but provides no explicit guidance on when to use vs. alternatives, nor any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_signed_txAInspect
Broadcast a signed transaction to Solana mainnet and wait for confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| signed_tx_base64 | Yes | The transaction from a build tool, signed by the required key |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It mentions 'wait for confirmation' but omits critical details like timeout periods, failure modes, or whether the transaction is retried.
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 of 9 words, direct and front-loaded with the essential action and network target.
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 low complexity (single param, no nested objects), the description omits behavior like return value (e.g., transaction ID) or success criteria, leaving gaps 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 coverage is 100%, baseline score applies. The description repeats the schema's parameter context ('signed by the required key') but does not add new semantic value.
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 explicitly states the action ('broadcast'), the resource ('signed transaction'), and the target network ('Solana mainnet'), clearly distinguishing it from sibling tools like 'build_execute_skill_tx' and 'list_agents'.
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 this tool should be used after obtaining a signed transaction, but does not explicitly state when to use it versus alternatives or mention prerequisites like connected wallet.
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!