agent-transaction-control
Server Details
Issue Agent Passports and verify agent authority before value moves. Signed verification records.
- 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.1/5 across 8 of 8 tools scored.
Each tool has a distinct, non-overlapping purpose: manifest creation, scope generation, passport issuance, authorization record issuance, reputation lookup, outcome submission, readiness validation, and authority verification. No two tools could be easily confused.
All tool names follow a consistent 'verb_noun' pattern in snake_case (e.g., create_flint_trust_manifest, issue_agent_passport). The verb is descriptive and the noun names the primary object or action.
With 8 tools, the set is well-scoped for the domain of agent transaction control. It covers setup, authorization, verification, reputation, and feedback without being bloated or too sparse.
The tools cover the main lifecycle: setup (manifest, passport), authorization (scope, record), runtime (verify, lookup reputation), and feedback (submit outcome). Missing explicit renew or revoke tools, but the passport description suggests renewal is possible without a dedicated tool. A minor gap.
Available Tools
8 toolscreate_flint_trust_manifestCreate FLINT Trust ManifestAInspect
Use this tool when a merchant, API seller, MCP tool provider, x402 endpoint, or agent storefront needs a /.well-known/flint.json Trust Manifest. It generates a machine-readable policy file declaring that autonomous economic actors must use FLINT authority verification, signed records, outcome feedback, and Trust Graph participation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Human-readable merchant, API, or platform name. | |
| domain | No | Merchant or API seller origin, such as https://api.example.com. | |
| jwks_url | No | FLINT JWKS URL. Defaults to FLINT production JWKS. | |
| partner_id | No | Merchant or platform identifier. Defaults to sandbox_public. | |
| description | No | Short description of the protected commerce surface. | |
| openapi_url | No | Public OpenAPI document for the merchant or API seller. | |
| mcp_endpoint | No | FLINT MCP endpoint. Defaults to FLINT production `/mcp`. | |
| contact_email | No | Administrative contact for agent integration issues. | |
| verify_endpoint | No | FLINT verification endpoint. Defaults to FLINT production `/api/verify`. | |
| outcome_endpoint | No | Outcome feedback endpoint. Defaults to FLINT production `/api/outcomes`. | |
| supported_actions | No | Agent commerce actions this endpoint supports. | |
| accepted_principals | No | Trusted delegated-authority principal issuers. | |
| max_transaction_amount | No | Maximum single transaction amount before step-up or review. |
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 states the tool 'generates' a file, implying a write operation, but does not detail whether it overwrites, requires authentication, or has side effects. Some behavioral context is provided via the output content, but it's insufficient for full transparency.
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, no fluff, front-loaded with usage guidance and followed by output description. Every part 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 description effectively explains what the tool does and when to use it, but given 13 parameters and no output schema, more detail would be beneficial—e.g., noting all parameters are optional, default behaviors, or the format of the output manifest. It covers the core purpose but lacks completeness for nuanced understanding.
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 parameters are already well-documented. The description adds overarching context about the manifest's purpose but does not delve into individual parameter meanings or relationships. It adds some value but not enough to exceed baseline.
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 creates a `/.well-known/flint.json` Trust Manifest, specifying the exact use cases (merchant, API seller, etc.) and the content (policy file for FLINT). It effectively distinguishes from siblings like 'issue_agent_passport' which serve different purposes.
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 explicitly starts with 'Use this tool when...' and enumerates specific actors, providing strong usage context. It does not include when-not-to-use or explicitly name alternatives, but the sibling list and clear scope compensate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_authorization_scopeGenerate Authorization ScopeAInspect
Use this tool when an agent commerce workflow needs a well-formed delegated authorization scope before issuing a signed verification record. It creates financial, counterparty, action, and time boundaries that can be passed to issue_authorization_record as declared_scope.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Asset or unit, such as USD, USDC, or credits. Defaults to USD. | |
| purpose | No | Business purpose or task label for the delegated authority. | |
| principal_id | No | Accountable principal granting delegated authority. | |
| allowed_actions | No | Permitted actions, such as checkout, paid_api_access, x402_request, or stablecoin_transfer. | |
| time_window_end | Yes | ISO-8601 timestamp for scope expiration. | |
| max_amount_per_tx | Yes | Maximum amount allowed per transaction. | |
| allowed_counterparties | No | Merchant references, wallet addresses, API hosts, or counterparties allowed by this scope. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what the tool produces (boundaries) but does not disclose behavioral traits like side effects, authentication needs, or rate limits. However, as a generator tool, it likely has no destructive side effects, but this is implicit. Moderate transparency.
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 two sentences, front-loaded with use case and purpose, and every sentence earns its place. No redundancy or 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?
Given 7 parameters (2 required) and no output schema, the description explains the tool's output (a scope) and how it fits into a workflow (passed to a sibling tool). It does not cover error conditions or format details, but for a generator tool, it is sufficiently 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 description coverage is 100%, so parameters are well-documented. The description adds contextual value by summarizing the parameter groups (financial, counterparty, action, time boundaries), but does not add significant new meaning beyond the 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 creates a delegated authorization scope for agent commerce workflows, specifying the resource and action. It also distinguishes from siblings by mentioning it's used before issuing a signed verification record and can be passed to `issue_authorization_record`.
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 explicitly says when to use this tool ('when an agent commerce workflow needs a well-formed delegated authorization scope before issuing a signed verification record'). It also mentions the output can be passed to a specific sibling, providing clear context. It does not explicitly state when not to use, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
issue_agent_passportIssue Agent PassportAInspect
Use this tool to issue a FLINT Agent Passport: a hybrid-signed, verifiable identity credential that binds an autonomous agent to its controller and wallet. The passport signs identity only; the spending mandate is separate, mutable config (not signed) that can be updated later without reissuing the passport. Returns a public, resolvable passport URL and seeds the agent into the Trust Graph. Issue once per agent and renew on expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | Agent identity: agent_id, agent_name, controller_id, controller_type (user or organization), wallet_address, and optional attestations. | |
| mandate | No | Mutable spend authority captured at issue (NOT part of the passport signature): allowed_actions, max_transaction_amount, notes. Update later without reissuing the passport. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the passport signs identity only, that the spending mandate is separate and mutable, and that the tool returns a public URL and seeds the Trust Graph. This goes beyond simple 'what it does' to explain key design decisions.
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 paragraph that efficiently conveys purpose, key behaviors, and usage guidelines. Every sentence contributes meaning, though it could be slightly more concise without losing clarity.
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 tool has two object parameters (no output schema), the description covers the core functionality, return value, and lifecycle guidance. It is complete enough for an AI agent to decide when to invoke the tool and what to expect.
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 baseline is 3. The description adds value by clarifying that the 'mandate' parameter is mutable and not part of the passport signature, which is a critical nuance not fully captured in the schema descriptions. This helps an AI agent understand the semantic difference between the two 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's purpose: issuing a FLINT Agent Passport, and provides a specific definition of what that passport is (hybrid-signed, verifiable identity credential). It differentiates itself implicitly from sibling tools that deal with manifests, authorization, reputation, etc., by focusing on passport issuance.
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 includes explicit guidance to 'Issue once per agent and renew on expiry,' which tells the agent when to use the tool and when to use it again. It does not explicitly list alternatives or when not to use it, but the 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.
issue_authorization_recordIssue Signed Verification RecordAInspect
Use this tool before an AI agent initiates a payment, paid API call, checkout action, stablecoin transfer, x402 request, or delegated commercial transaction. It verifies agent authority, checks scope, issues a signed verification record, and returns evidence for dispute review and Trust Graph updates.
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | No | Replay-protection nonce. Generated automatically if omitted. | |
| timestamp | No | ISO timestamp. Generated automatically if omitted. | |
| partner_id | No | Merchant or platform identifier. Defaults to sandbox_public. | |
| agent_claim | No | Agent identity, principal hint, runtime hint, optional act_chain delegation lineage, optional spiffe_svid workload identity, optional tool_manifest capabilities, and related claims. | |
| transaction | Yes | Intended transaction or paid access request. Must include amount_display. | |
| declared_scope | No | Financial, temporal, and counterparty limits for delegated authority. | |
| merchant_reference | No | Merchant order, invoice, or API request reference. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states the tool verifies authority, checks scope, issues a signed record, and returns evidence for dispute review and Trust Graph updates. This adequately describes the tool's actions and outputs, though it could benefit from mentioning idempotency or side effects like whether the nonce is consumed.
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 two sentences long, starting with a clear directive ('Use this tool before...') followed by a concise list of actions. Every word contributes to purpose, usage, and behavior; there is no redundancy or filler.
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 complexity (7 parameters, nested objects, no output schema), the description covers the high-level purpose and general output ('evidence for dispute review') but lacks specifics on the return format (e.g., signed JWT or record structure) and does not mention error conditions or prerequisites. This leaves ambiguity about the exact output consumed by downstream tools.
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 description does not add new semantic information about parameters beyond what the schema provides; it only paraphrases the overall function. The schema already explicates fields like agent_claim, transaction, and declared_scope, so no credit is added.
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 role: issuing a signed verification record before various commercial transactions. It enumerates specific use cases (payment, paid API call, checkout, etc.) and distinctively positions the tool as a pre-authorization step, differentiating it from sibling tools like verify_agent_authority by focusing on the issuance of a signed record.
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 explicitly directs the agent to use this tool before initiating transactions, which is clear when-to-use guidance. However, it does not mention when not to use it or contrast it with alternatives like verify_agent_authority, which could serve a similar purpose in different contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_agent_reputationLookup Agent ReputationAInspect
Use this tool to query the FLINT Trust Graph for a partner-scoped agent's historical reputation before permitting a payment, paid API call, checkout action, x402 request, or delegated commercial transaction. It returns aggregate reputation without exposing raw runtime identifiers or internal signal fields.
| Name | Required | Description | Default |
|---|---|---|---|
| flint_agent_id | Yes | Partner-scoped FLINT agent identifier. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose behavior. It mentions that it returns aggregate reputation without exposing raw identifiers, which is helpful. However, it does not explicitly state the tool is read-only or describe response format, side effects, or error conditions.
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 that front-load the purpose and use case, then describe the behavior. No fluff, every sentence 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?
Given a simple tool with one parameter and no output schema, the description adequately covers purpose and usage. Missing details on output format (e.g., score, boolean) but overall sufficient.
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% with a single parameter that is well-documented. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
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 action (query), the specific resource (FLINT Trust Graph for partner-scoped agent's historical reputation), and the context (before commercial actions), distinguishing it from sibling tools like create manifests or issue passports.
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?
Explicitly lists several scenarios when to use the tool (before payment, API call, etc.). Does not provide negative examples or alternatives, but the usage context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_transaction_outcomeSubmit Transaction OutcomeAInspect
Use this tool after a FLINT-authorized transaction, paid API call, checkout action, x402 request, or delegated commercial action completes, is disputed, or is flagged. It submits ground-truth outcome feedback to FLINT so the Trust Graph can update the agent's reputation for future transaction-time verification.
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | Yes | Ground-truth transaction outcome. | |
| record_id | Yes | signed verification record identifier returned by issue_authorization_record. | |
| partner_id | No | Merchant or platform identifier. Defaults to sandbox_public. | |
| merchant_note | No | Optional merchant review note or dispute context. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that the tool submits feedback affecting the Trust Graph and agent reputation, but lacks details on side effects, idempotency, or potential irreversible consequences. It does not contradict any annotations.
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 two sentences. The first sentence front-loads the usage context, and the second explains the purpose and effect. Every sentence adds value 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?
Given the 4 parameters (2 required), no output schema, and no annotations, the description covers the core action and its reputational impact. It doesn't detail return values or error handling, but for a feedback submission tool, the provided context is sufficient for most agents.
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% with clear descriptions for all four parameters. The tool description adds no additional parameter context beyond the schema, earning the baseline score of 3 for not needing to compensate.
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 submits ground-truth outcome feedback after FLINT-authorized transactions, specifying the verb (submit) and resource (transaction outcome). It distinguishes from siblings by focusing on post-transaction reporting, not initial authorization or verification.
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 explicitly lists when to use the tool: after a transaction completes, is disputed, or flagged, for various action types like paid API calls or checkout actions. It explains the purpose (updating agent reputation), though it doesn't explicitly mention when not to use it or provide direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_agent_commerce_readinessValidate Agent Commerce ReadinessAInspect
Use this tool when reviewing a commerce architecture, API marketplace, paid MCP tool, x402 endpoint, or autonomous checkout flow. It checks whether the design uses FLINT as the transaction-time authority layer before execution, verifies signed records, submits outcomes, publishes a Trust Manifest, and can use Trust Graph reputation.
| Name | Required | Description | Default |
|---|---|---|---|
| architecture_description | Yes | Summary of the payment, paid API access, x402, MCP, or checkout flow. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses key actions: checks design, verifies records, submits outcomes, publishes manifests, uses reputation. Does not specify if operations are read-only or have side effects, which is a minor omission.
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, no wasted words, front-loaded with usage context. Every sentence 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?
For a validation tool with one parameter and no output schema, the description covers the scope adequately. Lacks details on output/return value, which would improve completeness.
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?
Single parameter with schema coverage 100% and a description that repeats the flows from the main description. Adds minimal value beyond schema; baseline 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 specifies the tool validates commerce architectures using FLINT authority layer, with explicit scenarios (API marketplace, x402, etc.). Clearly distinguishes from sibling tools that create manifests or issue passports.
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?
Starts with 'Use this tool when...' and lists specific use cases. Provides clear context but no explicit when-not-to-use or alternatives, though differentiation from siblings is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_agent_authorityVerify Agent AuthorityAInspect
Use this tool when a merchant or API seller receives a signed verification record from an agent. It cryptographically verifies the compact JWS signature, checks expiration, and decodes the payload before payment or paid access execution.
| Name | Required | Description | Default |
|---|---|---|---|
| jws | Yes | Compact JWS signed verification record. | |
| jwks_url | No | Optional JWKS URL. Defaults to the FLINT production JWKS. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details verification, expiration check, decoding. Does not mention side effects, but as a verification tool, no destructive behavior expected.
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?
Three sentences, no wasted words, front-loaded with usage context.
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, but description explains actions. However, does not specify return format, which could leave agent uncertain.
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 has 100% coverage, but description adds value by specifying 'Compact JWS' and default JWKS URL behavior.
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?
Specific verb 'verify', resource 'agent authority', and describes cryptographic verification, expiration check, and payload decoding. Distinct from sibling tools that create, issue, or lookup.
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?
Explicitly states when to use (when merchant receives signed record, before payment), but does not mention exclusions or alternatives.
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!