MCP server for Ably — channel history, presence, occupancy, stats, publish, and app management.
Retrieve aggregated usage statistics across the whole account, bucketed by time. Account id is resolved from the control token when ABLY_ACCOUNT_ID is unset. Control API: GET /accounts/{account_id}/stats.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | End of range, ms since epoch (inclusive). | |
| unit | No | Bucket size: minute | hour | day | month. Default minute. | |
| limit | No | Max buckets (<=1000). Default 100. | |
| start | No | Start of range, ms since epoch (inclusive). | |
| account_id | No | Override the account id (defaults to the token's account). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the read-only safety profile, so the description's main added transparency is the account-id resolution behavior from ABLY_ACCOUNT_ID and the Control API endpoint. It does not describe return format, error behavior, or pagination, but for a straightforward read-only stats call the added context is adequate.
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 core purpose is front-loaded, and the additional endpoint and account-resolution details each contribute useful context 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?
For a read-only statistics tool with fully documented parameters and no output schema, the description covers the main action, scope, time bucketing, and account resolution. It does not detail the exact metrics returned, but given the tool's simplicity and the readOnlyHint, the missing return specification is a minor gap.
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 all five parameters are already documented in the input schema. The description adds minor value by explaining the account_id defaulting behavior via the ABLY_ACCOUNT_ID environment variable, but it does not add meaningful semantics 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 names a specific verb ('Retrieve'), resource ('aggregated usage statistics across the whole account'), and a key behavioral detail (bucketing by time). It clearly conveys the account-level scope, which helps distinguish it from related stats tools, though it does not explicitly name or contrast the closest sibling.
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 given about when to prefer this tool over alternatives. The phrase 'across the whole account' implies account scope, but the description never mentions ably_get_stats or any other sibling to clarify the boundary. It also does not state when not to use it or what prerequisites apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status and occupancy metrics for a single channel (connections, publishers, subscribers, presence members). REST: GET /channels/{channel}.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | Channel name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'GET' is consistent with that. It adds useful context by listing the metrics returned (connections, publishers, subscribers, presence members), though it does not describe response format, pagination, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficiently front-loads the purpose and key returned metrics. The REST endpoint is included without unnecessary elaboration, and 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 one-parameter read-only tool with a readOnlyHint annotation, the description is nearly complete: it states the endpoint, the scope, and the substance of the response. The only notable gap is the lack of an output schema or explicit return format, but the listed metrics partially compensate.
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% for the single 'channel' parameter, so the schema already documents it adequately. The tool description does not add parameter-level meaning beyond what the schema provides, so the 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 uses a specific verb ('Get') and resource ('status and occupancy metrics for a single channel'), and the REST path adds precision. It distinguishes from multi-channel tools like list_channels, but does not explicitly differentiate from the overlapping sibling ably_get_presence, which also deals with presence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a single channel' implies when the tool is appropriate, but there is no explicit guidance about when to prefer this over ably_get_presence or ably_get_channel_history. No alternatives or exclusions are named, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve historical messages published to a channel, newest-first by default. REST: GET /channels/{channel}/messages.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Latest message time, ms since epoch (inclusive). | |
| limit | No | Max messages (<=1000). Default 100. | |
| start | No | Earliest message time, ms since epoch (inclusive). | |
| channel | Yes | Channel name, e.g. 'chat:room1'. | |
| direction | No | forwards (oldest-first) or backwards (newest-first, default). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint, so the description only needs to add behavioral nuance. It adds 'newest-first by default' and the REST endpoint, which is useful but does not cover pagination or rate-limit behavior.
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 short sentences with the core behavior first and no filler. The REST endpoint line is helpful context but slightly redundant for an MCP agent, preventing a 5.
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 read-only history tool with fully documented scalar parameters and no output schema, the description is mostly sufficient. A note on the response format or pagination would make it fully complete, but these are not critical blockers.
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 input schema already documents every parameter. The description contributes only 'newest-first by default,' which duplicates the direction parameter's schema text, so it adds no new parameter 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 uses a specific verb ('Retrieve') with a clear resource ('historical messages published to a channel') and states default ordering. This distinguishes it from sibling tools like presence history and channel details without opening the schema.
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 first sentence establishes a clear use case: retrieving past channel messages. It does not name alternatives or explicitly state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the members currently present on a channel (who is online now). REST: GET /channels/{channel}/presence.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max members (<=1000). Default 100. | |
| channel | Yes | Channel name. | |
| clientId | No | Filter to a specific clientId. | |
| connectionId | No | Filter to a specific connectionId. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the REST GET endpoint and clarifies current-state semantics, but does not disclose additional behavior such as response shape, default limit, or filtering implications beyond what the schema already states.
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 front-loaded sentence conveys the resource, semantics, and REST endpoint with no filler. Every word contributes to understanding.
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 read-only list operation with one required parameter, the description, annotations, and fully documented schema provide enough to select and call the tool. There is no output schema, but 'List the members' adequately hints at the return; explicit pagination/response details would make it fully 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 the baseline of 3 applies. The description mentions the channel in the REST path but adds no deeper meaning beyond the schema's own descriptions for limit, clientId, and connectionId.
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?
Uses a specific verb ('List') and resource ('members currently present on a channel'), with plain-language gloss 'who is online now'. This clearly identifies the tool's purpose and distinguishes it from siblings like ably_get_presence_history or ably_get_channel_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'currently present' and 'who is online now' imply real-time presence rather than history, but the description never explicitly says when to use this tool over ably_get_presence_history or other alternatives. No exclusionary guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve historical presence events (enter/leave/update) for a channel. REST: GET /channels/{channel}/presence/history.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Latest event time, ms since epoch (inclusive). | |
| limit | No | Max events (<=1000). Default 100. | |
| start | No | Earliest event time, ms since epoch (inclusive). | |
| channel | Yes | Channel name. | |
| direction | No | forwards or backwards (default backwards). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation, lowering the burden on the description. It adds useful context by naming the event types (enter/leave/update) and the REST method/path, which goes beyond the annotation. However, it does not disclose result shape, pagination behavior, or default direction details, leaving some behavioral aspects to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence plus an endpoint reference, with no filler or redundancy. It front-loads the core purpose (retrieve historical presence events) before giving the REST path.
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 read-only historical lookup with 100% schema parameter coverage, the description is largely complete: it names the resource, event types, and endpoint. No output schema exists, but 'presence events' adequately conveys the return type for invocation purposes. It could mention pagination explicitly, but this is a minor gap given the read-only annotation and detailed schema.
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 covers 100% of parameters with descriptions, so the baseline of 3 applies. The tool description restates that this is for 'a channel' but adds no new parameter-level meaning beyond the schema's already detailed start, end, limit, and direction 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 uses a specific verb ('Retrieve') and a specific resource ('historical presence events (enter/leave/update) for a channel'), which precisely identifies what the tool does. It also includes the REST endpoint, reinforcing the exact operation. The word 'historical' and the event types clearly distinguish it from sibling tools like ably_get_presence (current presence) and ably_get_channel_history (messages).
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 implicitly signals when to use this tool via 'historical presence events' versus alternatives like ably_get_presence, but it does not explicitly state when not to use it or name an alternative for current presence or channel message history. There is no explicit 'use X for current presence' guidance, so the agent must infer routing from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current Ably service time in ms since epoch. Useful for aligning start/end windows to the server clock. REST: GET /time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the REST endpoint and clarifies that the returned time is the Ably server clock. It does not describe response format or rate-limit behavior, but for a zero-parameter read-only call that 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 carry all essential information: the return value, unit of measurement, use case, and REST endpoint. No filler or 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?
For a simple zero-parameter time-checking tool, the description fully tells an agent what the tool returns and why it is useful. The absence of an output schema is acceptable here because the described return value is simple.
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 0 parameters and 100% schema description coverage, so the schema needs no compensation. The baseline of 4 applies because there are no parameters to document.
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 uses specific verb 'Return' with clear resource 'current Ably service time in ms since epoch.' Sibling tools are all different resources, so this tool is immediately distinguishable without needing to compare schemas.
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?
States a clear use case: aligning start/end windows to the server clock. It does not explicitly compare to alternatives, but the sibling tools are unrelated in purpose, so the intended context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve message/connection/channel usage statistics for the app tied to the API key, bucketed by time. REST: GET /stats.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | End of range, ms since epoch (inclusive). | |
| unit | No | Bucket size: minute | hour | day | month. Default minute. | |
| limit | No | Max buckets (<=1000). Default 100. | |
| start | No | Start of range, ms since epoch (inclusive). | |
| direction | No | forwards or backwards (default backwards). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only; the description adds useful context by scoping results to the API key's app, stating time-bucketing, and giving the exact REST endpoint. No destructive or unexpected behavior is hidden.
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?
One tight sentence with the key scope front-loaded, immediately followed by the concrete REST call. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only stats getter with no required parameters and a fully described input schema, the description covers the essential scope and result substance. It does not describe response shape beyond usage statistics and buckets, but annotations and schema carry the rest.
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 every parameter already has a meaningful description. The tool description adds only general time-bucketing context rather than new parameter-level meaning, so it stays at the 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?
Description names a specific verb (retrieve), a concrete resource (message/connection/channel usage statistics), and a clear scope (app tied to the API key). It separates this from account-level or channel-specific operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for the current app's usage stats and mentions time bucketing, but it never states when to prefer it over ably_get_account_stats or any other sibling. No explicit alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all apps in the account (id, name, status, tls-only). Account id is resolved automatically from the control token when ABLY_ACCOUNT_ID is unset. Control API: GET /accounts/{account_id}/apps.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No | Override the account id (defaults to the token's account). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which covers safety. The description adds the field list and the automatic account_id resolution logic, providing useful behavioral context beyond the annotation without contradicting it.
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 filler. The main action and output fields appear first, and the account-id resolution detail and API endpoint follow 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?
Complete for a simple read-only listing tool with one optional parameter, no nested objects, and no output schema. The description covers purpose, behavior, parameter default, and endpoint, leaving nothing an agent needs to call it correctly.
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 documents account_id's override/default behavior. The description adds the nuance that resolution happens via the control token when ABLY_ACCOUNT_ID is unset, which complements 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?
States a specific verb and resource ('List all apps in the account') with the exact fields returned. The sibling tools target other Ably resources (channels, keys, queues), so this definition clearly distinguishes itself.
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?
Clear context for a read-only listing operation, plus the automatic account-id resolution behavior. It doesn't explicitly name alternatives or exclusions, but the sibling set makes the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate channels that are currently active in the app. Requires the API key to have the 'channel-metadata' capability. REST: GET /channels.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | Return channel ids only ('id', default) or full details ('value'). | |
| limit | No | Max channels per page (<=1000). Default 100. | |
| prefix | No | Only return channels whose name starts with this prefix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=true, and the description adds useful behavioral context by disclosing the required API-key capability and the specific REST endpoint. It also scopes the result to currently active channels. No annotation contradiction exists and no destructive behavior is implied.
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 short sentences carry the purpose, scope, permission requirement, and REST verb/path. Every element earns its place; there is no repetition of the title 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?
For a simple list operation with no output schema, the description and annotations cover authentication, scope, and the REST contract. It does not describe the return format or pagination behavior, but the schema documents limit and defaults, and the request is read-only, so the remaining gap is minor.
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?
All three parameters (by, limit, prefix) are fully described in the JSON schema, including defaults and constraints, so the description need not repeat them. The tool description adds no extra parameter semantics beyond the schema, giving the standard baseline of 3.
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 a clear action ('Enumerate channels that are currently active') and identifies the resource ('in the app'), which differentiates it from siblings that handle account stats, channel details, presence, or history. The REST endpoint reference reinforces the operation. This is more than sufficient for an agent to select the correct 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?
The description gives an explicit prerequisite (API key must have 'channel-metadata' capability) and the REST path, but it does not mention alternatives or state when not to use this tool. Context such as 'currently active' implies the use case, yet no comparison to sibling tools like ably_get_channel_details is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the API keys for an app, including their capabilities (but not the full secret). Control API: GET /apps/{app_id}/keys.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | App id (from ably_list_apps). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already provided, the description adds meaningful context: keys are listed with capabilities but the full secret is intentionally excluded. It also identifies this as a Control API GET request, giving an agent a clearer sense of the operation's nature and expected request style.
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 the core action, and contains no filler. Every sentence earns its place by adding either the functional scope or the API endpoint 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?
For a simple one-parameter read-only list operation, the description covers purpose, the endpoint, and an important output limitation. It does not fully describe the response shape, but no output schema exists and the complexity is low, so the provided information is largely sufficient for correct invocation.
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 the single parameter app_id is already documented as 'App id (from ably_list_apps)'. The description adds no additional parameter-level meaning beyond restating the endpoint path, so a 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 states a specific verb and resource: 'List the API keys for an app'. It also clarifies the scope by adding 'including their capabilities (but not the full secret)', which distinguishes this from any secret-returning operation. This is clearly differentiated from sibling tools such as ably_list_channels and ably_list_rules.
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 the tool is for retrieving an app's API keys, but it does not explicitly state when to use it over alternatives or when not to use it. The schema adds context by saying app_id comes from ably_list_apps, but the description itself provides only implied usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the channel namespaces (channel-rule prefixes) configured for an app, e.g. persistence and push settings. Control API: GET /apps/{app_id}/namespaces.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | App id (from ably_list_apps). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this by showing the GET endpoint. It adds useful context about what namespaces are and that the call is scoped to an app, but it does not disclose response shape, pagination, or any other behavioral traits beyond the read-only GET nature.
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-loads the action and resource, and wastes no words. It packs the essential definition, an example, and the REST endpoint into a compact form.
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 read-only single-parameter list operation, the description plus the input schema is sufficient for an agent to make the call correctly. There is no output schema; the description could have noted the return type more explicitly, but 'List ... namespaces' strongly implies the response, so this is not a critical gap.
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 the single app_id parameter already documented, including its provenance from ably_list_apps. The description's endpoint template '/apps/{app_id}/namespaces' reinforces the parameter's role but adds little beyond what the schema provides, so the baseline 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 operation: list channel namespaces configured for an app, adding a clarifying parenthetical and concrete examples. It is specific and unambiguous, but it does not explicitly distinguish itself from sibling list tools such as ably_list_rules or ably_list_channels, so it falls short of full differentiation.
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 given about when to use this tool versus alternatives. The phrase 'Control API' hints at the administrative context, but there are no explicit usage conditions, prerequisites, or comparisons to sibling tools, leaving the agent to infer when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Ably Queues (AMQP/STOMP message queues) provisioned for an app, with their state and messaging stats. Control API: GET /apps/{app_id}/queues.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | App id (from ably_list_apps). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description only needs to add context. It adds the exact REST verb (GET), the control-API nature, and the return content ('state and messaging stats'). This is useful context and does not contradict the 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?
Two sentences, front-loaded with the verb and resource. The parenthetical 'AMQP/STOMP message queues' clarifies the resource type without bloat, and the endpoint line is compact and useful.
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 one-parameter read-only listing tool with a rich schema, the description is nearly complete: endpoint, scope, and response content are mentioned. It does not specify pagination or detailed response structure, but those are not critical for invocation.
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 the app_id parameter is well described as coming from ably_list_apps. The tool description adds no parameter-level detail, so a 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?
Clearly states the operation ('List'), the resource ('Ably Queues (AMQP/STOMP message queues)'), and the scope ('provisioned for an app'). This differentiates it from sibling tools like ably_list_channels and ably_list_namespaces without requiring an agent to open them.
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 gives clear scope ('provisioned for an app') but offers no explicit when-to-use guidance or mention of alternatives. An agent must infer that this is the tool to use for queue listing; there are no exclusion rules or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the integration rules (reactor rules: webhooks, AWS Lambda/SQS/Kinesis, Kafka, Pulsar, etc.) configured for an app. Control API: GET /apps/{app_id}/rules.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | App id (from ably_list_apps). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read-only nature is covered. The description adds the endpoint and the specific rule types included, but does not disclose pagination behavior, output format, or any list-specific constraints. That is acceptable given the read-only annotation, but the description adds only modest behavioral context 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?
Two concise sentences: the first states the resource and examples, the second gives the exact endpoint. Every part earns its place, and the most important information is 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?
For a simple list operation with one clearly documented parameter, the description provides the endpoint, the resource scope, and examples of the rule types. It does not mention pagination or return shape, but no output schema exists and the listing nature is clear enough to call the tool correctly.
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 the single app_id parameter is already documented as 'App id (from ably_list_apps).' The description repeats app_id in the endpoint URL but does not add further semantic detail beyond what the schema already provides. 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?
States a specific verb and resource: list integration rules (reactor rules: webhooks, AWS Lambda/SQS/Kinesis, Kafka, Pulsar, etc.) configured for an app. It also gives the exact Control API endpoint, making the operation unambiguous and clearly distinct from sibling tools that list apps, channels, keys, or queues.
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?
Provides clear context: this lists integration rules for a specific app, and the app_id is supplied from ably_list_apps. It does not explicitly name alternative tools or state when not to use it, but the resource is unique among siblings, so an agent can infer appropriate usage without confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: publish a message to a channel. Every connected subscriber receives it in real time. This is a real, outward-facing side effect — confirm the channel and payload before calling. REST: POST /channels/{channel}/messages.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Message payload (string; send JSON as a stringified value). | |
| name | No | Optional event name for the message. | |
| channel | Yes | Channel name to publish to, e.g. 'chat:room1'. | |
| clientId | No | Optional clientId to attribute the message to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive; the description adds beyond that by stating it is an outward-facing side effect, that all connected subscribers receive the message in real time, and that confirmation is needed before calling. This meaningfully enriches the annotation without contradicting it.
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 short sentences, each earning its place: the operation, the real-time effect, and the caution. The WRITE prefix is front-loaded and the REST endpoint is a useful compact addition.
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 four-parameter write operation with a destructive annotation, the description covers the key behavioral context: it is a real side effect, delivery is real-time to subscribers, and the caller should verify inputs. No output schema exists, but the success semantics are straightforward enough that omitting return details is acceptable.
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 the schema already documents channel, data, name, and clientId adequately. The description adds no new parameter-level detail, but the baseline of 3 applies because the schema carries the full 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 uses a specific verb ('publish') and resource ('message to a channel'), and marks it clearly as a WRITE operation. It also names the observable consequence (subscribers receive it in real time), which distinguishes it from the sibling read/list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The WRITE label and side-effect warning make the intended use clear: this is for publishing, not retrieving data. It doesn't explicitly name excluded alternatives, but among an all-read sibling set the usage context is unmistakable and the caution to confirm channel and payload is practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return details about the configured control token: the account and user it belongs to and its capabilities. Good first call to confirm control-plane access. Control API: GET /me.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already marks this as safe, and the description adds useful behavioral context by disclosing what the call returns (account, user, capabilities) and the underlying endpoint 'GET /me'. It does not discuss failure modes or auth details, but for a read-only identity probe the description carries adequate weight.
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, each earning its place: the first states what the tool returns, the second gives usage guidance and the endpoint. There is no filler or repetition of the title.
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 zero-parameter read-only tool, the description is complete: it explains the resource, the returned information, when to use it, and the API path. No output schema is present, but the expected return surface is adequately described for an agent to invoke and interpret the call.
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 100% schema description coverage, so the description is not required to document parameters. It adds implicit semantic context ('configured control token') beyond the empty schema, which is appropriate for a no-argument call.
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 ('Return') and names the exact resource ('details about the configured control token') and the three facets: account, user, and capabilities. This clearly distinguishes it from the sibling tools, none of which target the token/identity itself.
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?
'Good first call to confirm control-plane access' provides a clear usage context, indicating this tool should be used before other control-plane operations to verify credentials. It does not explicitly name alternative tools or exclusion conditions, but the guidance is sufficient for a zero-parameter identity check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
MCP server for interacting with the Supabase platform
The official MCP Server for the Mux API
MCP server for Sendbird — chat users, channels, members, and messages from your AI client.
The official Planning Center MCP server for interacting with your ministry's data.
Add one secure layer between your agents and this server.
Every tool targets a distinct resource and action: account-level stats, app-level stats, channel details, history, presence, presence history, service time, and each control-plane listing (apps, keys, namespaces, queues, rules) are clearly separated. The only potentially confusing pair is account stats vs app stats, but their descriptions explicitly differentiate account-wide vs API-key-scoped usage.
All tools use a uniform 'ably_' prefix followed by a consistent verb_noun pattern: get_ for single resources, list_ for collections, publish_message for the write action, and whoami for token details. There are no mixed casing styles or inconsistent verb choices.
Fifteen tools is within the ideal range and each one covers a meaningful Ably capability, from control-plane inspection to channel data retrieval and publishing. The count feels justified given the breadth of Ably's API surface, with no redundant or filler tools.
The read side is well covered: stats, channel details, history, presence, and control-plane listings all have dedicated tools, and message publishing provides one write path. However, there are no create/update/delete operations for apps, keys, namespaces, queues, or rules, so lifecycle management is largely absent and an agent could not perform common administrative workflows.
