Read, create, update and delete records; inspect objects, fields and schema in your Knack database.
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.
Average 4.1/5 across 9 of 9 tools scored.
Each tool targets a distinct operation: CRUD for records, listing fields/objects/records, fetching application schema, and a generic request. No overlap in purpose.
All tools use 'knack_' prefix with verb_noun pattern (create_record, delete_record, etc.). The exception is 'knack_request' which lacks a verb, causing slight inconsistency.
9 tools is well-scoped for a Knack integration, covering essential CRUD, listing, schema retrieval, and an escape hatch.
Core CRUD operations are present, plus listing and schema. Missing batch operations or advanced filtering, but the generic request tool fills some gaps.
knack_create_recordCreate a recordAMUTATES Knack data — creates a new record in an object. Knack API: POST /objects/{object_key}/records. Provide fields as an object keyed by field key, e.g. { "field_1": "Acme", "field_2": 100 }. Auto Increment / Formula / Equation fields are read-only and cannot be set. Returns the created record.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | The record's field values keyed by field key, e.g. { "field_1": "Acme", "field_2": 100 }. Auto Increment / Formula / Equation fields are read-only and cannot be written. | |
| objectKey | Yes | The Knack object (table) key, e.g. "object_1". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true, which the description echoes with 'MUTATES'. It adds value by specifying that Auto Increment/Formula/Equation fields are read-only and cannot be set, and mentions the return of the created record.
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 concise (two sentences plus API note) and front-loads the key action. Every sentence provides essential information without 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?
Given two parameters, full schema coverage, destructiveHint annotation, and no output schema, the description covers mutation behavior, parameter format, and return value. It is complete for the tool's context.
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% but the description adds meaningful examples for the `fields` parameter and explains that certain field types are read-only. This enhances understanding 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 it creates a new record in a Knack object, using the verb 'MUTATES' and 'creates'. It distinguishes from siblings like update/delete by specifying creation.
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 use for creating records but does not explicitly state when to use or when not to use this tool over alternatives. No exclusion criteria or sibling differentiation is provided beyond the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
knack_delete_recordDelete a recordAMUTATES Knack data — permanently DELETES a record (irreversible). Knack API: DELETE /objects/{object_key}/records/{record_id}. Knack returns { delete: true } on success.
| Name | Required | Description | Default |
|---|---|---|---|
| recordId | Yes | The record id (a hex string returned by Knack). | |
| objectKey | Yes | The Knack object (table) key, e.g. "object_1". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true, but the description adds valuable behavioral context: the deletion is permanent/irreversible, the API endpoint is shared, and the success response format is given. This provides transparency beyond the annotation, though it could mention idempotency or error cases.
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: two sentences that front-load the mutating and destructive nature, followed by the API call and response format. No extraneous information, every sentence 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?
For a simple delete tool with no output schema and two well-described parameters, the description covers the operation's effect, API method, and success response. It lacks mention of error conditions or permission requirements, but given the tool's simplicity and the presence of annotations (destructiveHint), it is reasonably 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?
Input schema has 100% coverage and clearly describes the two parameters (recordId as hex string, objectKey as table key). The description does not add additional parameter semantics beyond the schema, which is acceptable given full schema description 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 that the tool deletes a record permanently, using strong verbs like 'MUTATES' and 'DELETES'. It explicitly distinguishes from sibling tools (e.g., knack_create_record, knack_update_record) by specifying the irreversible nature and the API operation.
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 deleting records when permanent removal is intended, mentioning irreversibility as a caution. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., soft delete or update). No exclusions or alternatives are provided, leaving the agent to infer from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
knack_get_applicationGet application schemaAFetch a Knack application's full schema/metadata — its objects (tables), fields, and scenes. Knack API: GET /applications/{app_id}. Returns the raw JSON as-is. app_id defaults to the configured KNACK_APPLICATION_ID.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | No | Optional Knack Application ID; defaults to the configured KNACK_APPLICATION_ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a read-only operation. The description adds that the tool returns the raw JSON as-is, which is valuable for the agent to expect unprocessed data. It also notes the default app_id behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three sentences. The first sentence immediately states the purpose, the second adds API detail, and the third covers parameter default. Every sentence adds value without 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?
Given only one optional parameter, no output schema, and annotations present, the description is mostly complete. It explains the return format (raw JSON) and the default behavior. It could mention the potential size of the response, but overall it provides sufficient context for an AI 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?
The input schema has 100% coverage with a description for appId that matches the description. The description repeats the defaulting behavior but does not add additional semantic meaning beyond what the schema provides. 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 that the tool fetches the full application schema (objects, fields, scenes). It distinguishes itself from sibling tools like knack_get_record or knack_list_fields by targeting the application-level metadata. The verb 'Fetch' and resource 'application schema' are 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 does not explicitly state when to use this tool versus alternatives. While the purpose is clear, there is no guidance on when not to use it or which sibling tool might be more appropriate. The mention of the API endpoint provides technical context but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
knack_get_recordGet a recordAFetch a single record by id. Knack API: GET /objects/{object_key}/records/{record_id}. Returns the bare record (with both field_x and field_x_raw values).
| Name | Required | Description | Default |
|---|---|---|---|
| recordId | Yes | The record id (a hex string returned by Knack). | |
| objectKey | Yes | The Knack object (table) key, e.g. "object_1". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds value by stating 'Returns the bare record (with both field_x and field_x_raw values)', which gives specific information about the return format beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loaded with the purpose, no redundant or extraneous information. 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 simple tool with 2 parameters, no output schema, and read-only nature, the description covers the core behavior and return details. Could mention error behavior (e.g., record not found) but overall adequate.
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% with adequate parameter descriptions (recordId as hex string, objectKey as table key). The tool description does not add new semantics beyond the schema, so 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 'Fetch a single record by id' and provides the API endpoint. It specifies the verb (Fetch) and resource (single record by id), distinguishing it from sibling tools like knack_list_records (multiple records) and knack_create_record/knack_delete_record/knack_update_record (modify).
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 such as knack_list_records or knack_create_record. The description does not mention when not to use it or provide context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
knack_list_fieldsList fields for an objectAList the fields of ONE object as [{ key, name, type, required }]. Fetches GET /applications/{app_id} and returns the fields of the object whose key === objectKey (e.g. "object_1"). app_id defaults to the configured KNACK_APPLICATION_ID.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | No | Optional Knack Application ID; defaults to the configured KNACK_APPLICATION_ID. | |
| objectKey | Yes | The Knack object (table) key, e.g. "object_1". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that it fetches the entire application and filters locally, providing important behavioral context about efficiency and API usage.
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 clear, front-loaded sentences with no waste; 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?
Even without an output schema, the description includes the output format and explains the filtering logic, making it self-contained for this read-only list 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?
With 100% schema coverage, both parameters are described in schema; the description adds the default behavior for appId, increasing 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 clearly states it lists fields for one object with output format, but does not explicitly distinguish from sibling tools like knack_list_objects or knack_get_application.
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 use for retrieving fields of a single object but does not provide when-not-to-use or alternative tools, leaving guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
knack_list_objectsList objects (tables)AList an application's objects (tables) as a compact array [{ key, name, fieldCount }]. Convenience over GET /applications/{app_id}. app_id defaults to the configured KNACK_APPLICATION_ID.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | No | Optional Knack Application ID; defaults to the configured KNACK_APPLICATION_ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
ReadOnlyHint is already provided via annotations, so the description doesn't need to state safety. It adds useful context: the output format (compact array with specific fields) and default appId behavior, which are beyond what annotations convey.
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 with no fluff. It front-loads the core purpose and then adds detail. 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 the tool's simplicity (one optional parameter, no output schema), the description fully covers what the agent needs: what it returns (array of objects with key/name/fieldCount), default behavior, and a reference to the underlying API. No gaps detected.
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 description repeats the schema's information about the default value, adding no new semantic insight. Thus 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 action (list), resource (objects/tables), and output format (compact array with key, name, fieldCount). It distinguishes itself from sibling tools like knack_get_application by specifying it lists objects rather than the whole application.
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 mentions it's a convenience over GET /applications/{app_id} and states the default behavior for appId. However, it does not explicitly compare with alternative tools or provide when-not-to-use guidance, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
knack_list_recordsList recordsAList an object's records. Knack API: GET /objects/{object_key}/records. Returns the paged envelope { total_pages, current_page, total_records, records: [...] } as-is. Records carry both field_x (formatted) and field_x_raw (structured) values. Page with page / rows_per_page (max 1000), sort with sort_field / sort_order, and filter with the filters object.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1). | |
| filters | No | Optional Knack filter object, JSON-stringified into the `filters` query param. Shape: { "match": "and"|"or", "rules": [{ "field": "field_1", "operator": "is", "value": "Acme" }] }. Common operators: contains, does not contain, is, is not, starts with, ends with, higher than, lower than, is blank, is not blank. | |
| objectKey | Yes | The Knack object (table) key, e.g. "object_1". | |
| sort_field | No | Field key to sort by, e.g. "field_25". | |
| sort_order | No | Sort direction: "asc" or "desc". | |
| rows_per_page | No | Records per page (1-1000, default 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true. The description goes beyond by detailing the response envelope (total_pages, current_page, total_records, records) and the fact that records contain both formatted and raw field values. It also explains the filter structure, providing comprehensive behavioral context.
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 concise (three sentences) and front-loaded: first sentence states purpose, second explains response, third covers options. Every sentence earns its place 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?
Given no output schema, the description adequately explains the return envelope and filter structure. A minor gap: it does not mention the default value for rows_per_page (25), but overall completeness is high.
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 value by explaining the paged envelope and the filter object's shape, which provides semantic meaning beyond the schema's parameter descriptions.
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 lists an object's records and references the API endpoint. It distinguishes the tool from siblings like knack_get_record by implying bulk retrieval, but does not explicitly differentiate from single-record retrieval.
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 explains how to use pagination, sorting, and filtering, but does not explicitly state when to use this tool versus alternatives (e.g., when to list vs. get a single record). Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
knack_requestRaw Knack API GETAPower-user escape hatch: GET any Knack API path not wrapped by a dedicated tool (e.g. view-based reads). READ-ONLY — only GET is allowed. Path starts with a slash (e.g. "/objects/object_1/records"). Knack API: GET {path}.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | API path starting with a slash, e.g. "/objects/object_1/records". | |
| query | No | Optional query params object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reinforces readOnlyHint by stating 'READ-ONLY — only GET is allowed', adding detail beyond annotation. No mention of auth, rate limits, or error behavior, but standard for such a tool.
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, each adding distinct information: purpose, restriction, and path format. Extremely concise 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?
No output schema is provided; description does not mention return format or how to handle responses. The query parameter nested object usage is not explained. However, as a raw API tool, it may be acceptable for power users.
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% but description adds value by clarifying path format with example and emphasizing read-only nature. The query parameter is not elaborated, but the description's context about 'escape hatch' aids understanding.
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 'power-user escape hatch' for GET requests to Knack API paths not covered by dedicated tools, which distinguishes it from siblings like knack_list_records.
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 (paths without dedicated tools) and that it is read-only; provides path format example. Does not explicitly list when not to use but context implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
knack_update_recordUpdate a recordAMUTATES Knack data — updates a record. Knack API: PUT /objects/{object_key}/records/{record_id}. Provide fields as an object keyed by field key; only the included fields change, e.g. { "field_1": "Acme Inc" }. Auto Increment / Formula / Equation fields are read-only. Returns the updated record.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | The record's field values keyed by field key, e.g. { "field_1": "Acme", "field_2": 100 }. Auto Increment / Formula / Equation fields are read-only and cannot be written. | |
| recordId | Yes | The record id (a hex string returned by Knack). | |
| objectKey | Yes | The Knack object (table) key, e.g. "object_1". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true, and the description adds that it mutates data and returns the updated record. It also explains the partial update behavior and read-only field types, which are useful beyond the annotation.
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 with no filler. The first sentence states the core action, and the second adds key details and an example. Every sentence is valuable.
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 3-parameter mutation tool with no output schema, the description covers the core behavior, partial update nature, and read-only fields. It could mention error handling or authentication, but what is provided is sufficient for most use cases.
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 parameters. The description adds an example and repeats read-only info, but this is marginal improvement. 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 states 'updates a record' clearly, with the verb 'update' and resource 'record'. It also provides the API endpoint. However, it does not explicitly differentiate from sibling tools like knack_create_record or knack_delete_record, though the context of mutation helps.
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 that only included fields change and that Auto Increment/Formula/Equation fields are read-only. This provides some constraints but does not give when-to-use guidance compared to alternatives (e.g., create vs. update).
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.
No comments yet. Be the first to start the discussion!