Unified.to MCP Server
Server Details
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
- 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 2/5 across 19 of 19 tools scored. Lowest: 1/5.
Tool names are distinct by resource and action, e.g., create_unified_connection vs list_unified_issues. However, the excessively wordy descriptions with many synonyms could confuse an agent into thinking there are more differences than exist.
All tools follow the verb_unified_noun pattern (create, get, list, remove, update). The verbs are consistent, and the naming is predictable and uniform.
19 tools is slightly on the upper end of reasonable for a unified API platform. It covers key resources but is not excessive; each tool has a clear purpose.
CRUD is complete for connections and webhooks, but environments lack an update tool, and issues only have get/list. Integrations and API calls have limited operations, leaving notable gaps.
Available Tools
19 toolscreate_unified_connectionDInspect
create connection. add connection. insert connection. build connection. generate connection. provision connection. instantiate connection. establish connection.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | No | An authentication object that represents a specific authorized user's connection to an integration | |
| is_paused | No | Whether this integration has exceed the monthly limit of the plan | |
| categories | Yes | The Integration categories that this connection supports | |
| environment | No | ||
| permissions | Yes | Array | |
| auth_aws_arn | No | the AWS ARN / secretID for the stored auth field | |
| workspace_id | No | (reference to KmsSpace) | |
| external_xref | No | customer's user ID | |
| last_healthy_at | No | (ISO-8601 / YYYY-MM-DDTHH:MM:SSZ format) | |
| integration_name | No | ||
| integration_type | Yes | The integration type | |
| last_unhealthy_at | No | (ISO-8601 / YYYY-MM-DDTHH:MM:SSZ format) | |
| auth_gcp_secret_name | No | the Google Cloud Secret Manager name for the stored auth field | |
| auth_hashi_vault_path | No | the HashiCorp Vault path for the stored auth field | |
| auth_azure_keyvault_id | No | the Azure Key Vault ID for the stored auth field |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral information. Since no annotations are present, the description must cover side effects, idempotency, permissions, or safety, but it does not. The tool likely creates a resource, but no details are given.
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 short but not effective. It is a list of synonyms that wastes space without adding useful information. Conciseness should be about efficiency in conveying meaning, which is absent here.
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 is completely inadequate for a tool with 15 parameters, nested objects, no output schema, and no annotations. It gives no context about how to construct a request, what the response looks like, or what constitutes a successful creation.
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 description adds no value to the parameters already described in the input schema. With 87% schema coverage, the baseline is 3, but the description is purely synonymous and does not clarify parameter intent or usage. It fails to explain the meaning of auth, categories, or permissions beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists multiple synonyms for 'create connection' but does not specify what a connection is or how this tool differs from sibling tools like create_unified_environment or create_unified_webhook. The verb is clear but the resource and scope are vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or which sibling tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_unified_environmentCInspect
create new environments. add new environments. insert new environments. build new environments. generate new environments. provision new environments. instantiate new environments. establish new environments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description offers no behavioral insights beyond the fact that the tool creates something. It does not disclose authentication needs, side effects, rate limits, or the nature of the created environment.
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 highly repetitive, using eight different verbs all meaning essentially the same thing. It could be condensed to a single clear sentence. The lack of structure and redundancy wastes the agent's scanning time.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no parameters and no output schema, the description fails to provide any context about what constitutes an environment, how creation behaves, or what the outcome is. It is completely inadequate for an agent to decide whether to invoke this 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?
The input schema has no parameters, and the description does not add any meaning beyond that. With 100% schema coverage for zero parameters, a baseline of 4 would apply, but the description's synonym list adds no value, so a 3 is appropriate as it is minimally adequate.
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 is a list of synonyms for 'create' (e.g., 'add', 'insert', 'build') that redundantly restate the tool name without specifying what an 'environment' is or how it differs from sibling tools like create_unified_connection. It lacks a clear verb+resource with 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 provided on when to use this tool versus alternatives. The description does not mention any prerequisites, context, or exclusion criteria for creating environments compared to connections, webhooks, etc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_unified_webhookDInspect
create webhook subscription. add webhook subscription. insert webhook subscription. build webhook subscription. generate webhook subscription. provision webhook subscription. instantiate webhook subscription. establish webhook subscription. create callback subscription. create hook subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | ||
| runs | No | An array of the most revent virtual webhook runs | |
| event | Yes | ||
| db_url | No | ||
| fields | No | ||
| db_type | No | ||
| filters | No | ||
| hook_url | No | The URL of the webhook | |
| interval | No | The interval (in minutes) to check for updated/new objets | |
| db_schema | No | ||
| is_paused | No | ||
| checked_at | No | The last date/time that a check was done on this object (ISO-8601 / YYYY-MM-DDTHH:MM:SSZ format) | |
| is_healthy | No | ||
| environment | No | ||
| object_type | Yes | The object to return (eg | |
| webhook_type | No | ||
| workspace_id | No | (reference to KmsSpace) | |
| connection_id | Yes | ||
| db_name_prefix | No | ||
| page_max_limit | No | ||
| integration_type | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states that it 'creates' a webhook, implying mutation. It fails to disclose side effects, authentication needs, rate limits, or any behavioral traits beyond the verb.
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 redundant list of eight synonyms, wasting space without adding information. It is not concise and fails to front-load useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 21 parameters, low schema coverage, no output schema, and no annotations, the description is completely inadequate. It provides no context about the webhook's purpose, required inputs, or expected behavior.
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 schema description coverage at 29% (low) and 21 parameters, the description adds no value. It does not mention any parameter names, constraints, or relationships, leaving the agent to rely solely on the incomplete 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 is a list of synonyms for 'create webhook subscription' (e.g., 'add', 'insert', 'build'), which is a tautology. It does not clarify what a webhook subscription is or what the tool accomplishes beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like list_unified_webhooks, update_unified_webhook, or remove_unified_webhook. No context about prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_unified_apicallCInspect
retrieve specific api call by its id. get specific api call by its id. fetch specific api call by its id. read specific api call by its id. look up specific api call by its id. access specific api call by its id. query specific api call by its id. pull specific api call by its id. return one specific api call by its id. retrieve specific api conversation by its id. retrieve specific api interaction by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the apicall to get |
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 only states 'retrieve' (read operation) but does not disclose any behavioral traits like error handling, required permissions, or rate limits.
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 repetitive with 11 variations of the same phrase. It should be a single clear sentence. This is wasteful and harms readability.
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 get-by-id tool, the description states the basic purpose. However, it lacks context about return value (no output schema), and does not mention that it retrieves a full resource or that the ID is a required path parameter.
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 'id' described. The description adds nothing beyond 'by its id' and is repetitive, so it meets the baseline for high coverage but adds little 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 uses clear verb+resource ('retrieve specific api call by its id') and the tool name matches. However, it redundantly repeats the same idea in 11 variations without distinguishing from siblings like list_unified_apicalls or other get 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?
No guidance on when to use this tool versus alternatives. It's implied you use it when you have an ID, but no explicit context, prerequisites, or when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_unified_connectionCInspect
retrieve connection. get connection. fetch connection. read connection. look up connection. access connection. query connection. pull connection. return one connection.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the connection to get |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only repeats the tool's name in verb form. Does not disclose idempotency, error behavior, or authentication needs. For a simple read, even minimal context (e.g., 'Returns a single connection object') would help.
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 highly redundant, listing nine synonyms of 'get'. This wastes tokens and adds no value. A single sentence such as 'Retrieve a single unified connection by ID.' would be clearer and more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations. The description does not explain what a 'connection' is, the expected return format, or any constraints. A minimal complete description would specify that it returns a connection object or reference sibling tools for related operations.
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 clear 'id' description. The tool description adds no extra parameter meaning. Baseline 3 is appropriate because the schema already documents the parameter adequately.
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 multiple synonyms for 'retrieve', indicating a single connection retrieval, but fails to define what a 'unified connection' is or differentiate it from listing (sibling list_unified_connections). It is clear in verb but vague in resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., list_unified_connections for multiple, create_unified_connection for creation). No when-not or precondition advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_unified_issueDInspect
retrieve support issue. get support issue. fetch support issue. read support issue. look up support issue. access support issue. query support issue. pull support issue. return one support issue.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the issue to get |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but does not. It fails to indicate idempotency, read-only nature, authentication needs, rate limits, or destructive potential. The description only states the obvious.
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 verbose, repetitive list of synonyms (nine separate phrases) that wastes space. A single sentence would suffice. This is not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain what is returned (e.g., issue fields, success/error conditions). It does not. Also lacks context among siblings (e.g., listing vs. single retrieval).
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% (single parameter 'id' has a description). The tool description adds no extra meaning beyond the schema. Baseline of 3 is appropriate because the schema already documents the parameter.
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 merely lists synonyms of 'retrieve' and 'support issue' (e.g., 'get', 'fetch', 'read'), which adds no clarity beyond the tool's name. It does not distinguish this single-issue retrieval from the sibling list_unified_issues tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., list_unified_issues). There is no mention of when not to use it, prerequisites, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_unified_webhookCInspect
retrieve webhook by its id. get webhook by its id. fetch webhook by its id. read webhook by its id. look up webhook by its id. access webhook by its id. query webhook by its id. pull webhook by its id. return one webhook by its id. retrieve callback by its id. retrieve hook by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the webhook to get |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only repeats the basic retrieval action without disclosing behavioral traits like error handling, idempotency, authentication requirements, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly repetitive, using 11 different phrasings for the same concept. It wastes space and offers no structured information. A single sentence would suffice.
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 lack of output schema and annotations, the description should compensate by detailing return values, error scenarios, or behavior. It fails to do so, leaving the agent with minimal context about what the response contains.
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 'id' parameter described as 'The ID of the webhook to get'. The description adds no extra meaning beyond the schema, 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 redundantly lists over ten synonyms for 'get by id' without differentiating from sibling tools like list_unified_webhooks. It is a tautology that merely restates the tool's name and function without clarifying scope or uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_unified_webhooks or other get tools. The description offers no context about prerequisites, common use cases, or selection heuristics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_unified_apicallsDInspect
returns api calls. returns api conversations. returns api interactions.
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | ||
| sort | No | ||
| type | No | Filter the results to just this type | |
| error | No | Filter the results for API Calls with errors | |
| limit | No | ||
| order | No | ||
| offset | No | ||
| webhook_id | No | Filter the results to just this webhook | |
| is_billable | No | Filter the results for only billable API Calls | |
| updated_gte | No | Return only results whose updated date is equal or greater to this value (ISO-8601 / YYYY-MM-DDTHH:MM:SSZ format) | |
| connection_id | No | Filter the results to just this integration | |
| external_xref | No | Filter the results to only those integrations for your user referenced by this value | |
| integration_type | No | Filter the results to just this integration |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'returns' without disclosing any behavioral traits such as pagination, read-only nature, or required permissions.
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 three short sentences that are essentially repetitive, stating the same thing three times. It is not efficient and wastes space without adding 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 13 parameters, no output schema, and no annotations, the description is grossly inadequate. It fails to explain the filtering options, response format, or any usage context, making it nearly useless for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter explanation. While schema coverage is 62%, the description does not compensate for the undocumented parameters or provide context for the filtering capabilities.
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 is vague and repetitive: 'returns api calls. returns api conversations. returns api interactions.' It does not clearly state that this tool lists API calls, and it fails to distinguish from sibling tools like get_unified_apicall or list_unified_connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of context, filters, or when to prefer other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_unified_connectionsDInspect
list all connections. enumerate all connections. browse all connections. show all connections. view all connections. fetch all connections. index all connections. return all all connections. get all connections. fetch all connections. index all connections.
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | ||
| sort | No | ||
| limit | No | ||
| order | No | ||
| offset | No | ||
| categories | No | Filter the results on these categories | |
| updated_gte | No | Return only results whose updated date is equal or greater to this value (ISO-8601 / YYYY-MM-DDTHH:MM:SSZ format) | |
| external_xref | No | Filter the results to only those integrations for your user referenced by this value |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description fails to disclose behavioral traits such as read-only nature, authentication, rate limits, pagination, or data volume. The schema hints at pagination but the description does not mention 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?
The description is extremely repetitive, listing multiple synonyms without adding value. It is not concise and poorly structured.
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, no annotations, and 8 parameters with low schema description coverage, the description is completely inadequate. It does not explain return values, pagination, or the env parameter.
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 38% (3 of 8 parameters have descriptions). The tool description adds no additional meaning for parameters; it does not compensate for the low 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 is a repetitive list of synonyms for 'list all connections' (tautology). It does not clarify what a 'connection' is or distinguish this tool from siblings like list_unified_environments or list_unified_integrations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Siblings include other list tools, but the description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_unified_environmentsCInspect
returns all environments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It does not mention whether the operation is read-only, if there is pagination, filtering, or any side effects. The description only states the basic function.
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 words) and front-loaded. No unnecessary words. However, it could be slightly expanded to include the scope (e.g., 'all environments in the current workspace') without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks critical context such as return format, pagination, filtering options, and whether it returns a list or details. For a list tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, resulting in 100% schema description coverage. The description adds no parameter-level detail but accurately reflects that the tool takes no parameters. 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 'returns all environments' clearly states the tool's action and resource. It distinguishes from siblings like create_unified_environment or list_unified_connections, though it could specify the verb 'list' for consistency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_unified_connections or get_unified_environment. There is no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_unified_integrationsCInspect
returns all integrations.
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | ||
| type | No | Filter the results for only this integration type | |
| limit | No | ||
| active | No | Filter the results for only the workspace's active integrations | |
| offset | No | ||
| summary | No | ||
| categories | No | Filter the results on these categories | |
| updated_gte | No | (ISO-8601 / YYYY-MM-DDTHH:MM:SSZ format) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only says 'returns all integrations,' without revealing potential side effects, authentication needs, rate limits, or handling of pagination/filters. This is insufficient for safe invocation.
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?
At 3 words, the description is extremely concise but under-specified. It front-loads the purpose but omits critical details, making it insufficient rather than efficiently complete.
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 8 parameters, no annotations, and no output schema, the description is severely lacking. It provides no context on return structure, filtering, or how to use parameters effectively, making it inadequate for a tool of this complexity.
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 50%, meaning half of the parameters lack descriptions. The tool description adds no parameter information, so it does not compensate for the gaps. An agent would struggle to understand parameters like 'env' or 'summary' without additional context.
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 'returns all integrations,' which is a clear verb+resource indicating retrieval. However, it does not distinguish this tool from sibling tools like list_unified_connections, which also list entities. It lacks specificity on scope or usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., list_unified_connections). No use cases, prerequisites, or exclusions are mentioned, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_unified_issuesDInspect
list support issues. enumerate support issues. browse support issues. show support issues. view support issues. fetch support issues. index support issues. return all support issues.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| order | No | ||
| offset | No | ||
| updated_gte | No | Return only results whose updated date is equal or greater to this value (ISO-8601 / YYYY-MM-DDTHH:MM:SSZ format) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description offers no behavioral details such as pagination, sorting, or filtering behavior. The agent receives no information about the tool's operational characteristics beyond the name.
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 unnecessarily verbose, repeating the same idea eight times (e.g., 'list', 'enumerate', 'browse', etc.). It wastes tokens without adding 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 five parameters and no output schema, the description is severely lacking. It fails to explain what a 'support issue' is, how the tool behaves, or what the response looks like. The tool is completely underspecified.
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 description does not mention any parameters or their meanings. With schema description coverage at only 20%, the description fails to compensate, leaving the agent without context for how to use parameters like 'sort', 'limit', 'order', 'offset', or 'updated_gte'.
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 is a list of synonyms for 'list' and 'support issues', essentially restating the tool name without adding specificity. It does not distinguish from sibling tools like list_unified_connections or list_unified_environments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools exist for creating, getting, updating, and deleting, but there is no indication of when listing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_unified_webhooksDInspect
returns all registered webhooks. returns all registered callbacks. returns all registered hooks.
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | ||
| sort | No | ||
| limit | No | ||
| order | No | ||
| object | No | Filter the results for webhooks for only this object | |
| offset | No | ||
| created_lte | No | Return only results whose created date is equal or less to this value | |
| updated_gte | No | Return only results whose updated date is equal or greater to this value (ISO-8601 / YYYY-MM-DDTHH:MM:SSZ format) | |
| connection_id | No | Filter the results to just this integration | |
| integration_type | No | Filter the results to just this integration |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'returns all' without mentioning that results can be filtered by object, date range, pagination, etc. No mention of idempotency, rate limits, or read-only 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?
Three short, redundant sentences (essentially same meaning). Under-specification rather than conciseness; important capabilities are omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters with enums and filters, yet the description is a single repetitive phrase. It is completely inadequate for an AI agent to understand how to effectively use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (5 of 10 parameters have descriptions). The description adds no value beyond the schema; it does not explain how parameters like env, sort, limit, order, offset affect the results. For the uncovered parameters, the description provides no compensation.
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 repeats 'returns all registered webhooks/callbacks/hooks' without adding specificity. It does not distinguish from sibling tools like list_unified_apicalls or list_unified_connections, and fails to indicate that the tool supports filtering and pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other list tools. The description only states what it returns but does not clarify context such as prerequisites or alternatives like create_unified_webhook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_unified_connectionCInspect
remove connection. delete connection. destroy connection. erase connection. drop connection. purge connection. deprovision connection. unlink connection.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the connection to remove |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only implies a destructive action without detailing consequences (e.g., irreversibility, cascading effects, required permissions). The repetitive synonyms add no 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 a list of eight synonyms, which is repetitive and wasteful. A single sentence stating 'Remove a connection' would be more concise. The structure does not front-load key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is incomplete. It lacks context about the tool's effect on the system, any dependencies, or when it is appropriate to use compared to other remove 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?
Schema coverage is 100% with a clear description for the 'id' parameter. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses multiple synonyms (remove, delete, destroy, etc.) which redundantly restate the action of removing a connection. The purpose is clear but lacks specificity to distinguish from sibling tools like remove_unified_environment or remove_unified_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as remove_unified_environment. No prerequisites, scenarios, or restrictions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_unified_environmentCInspect
remove an environment. delete an environment. destroy an environment. erase an environment. drop an environment. purge an environment. deprovision an environment. unlink an environment.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the environment to remove |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as irreversibility, cascading effects, or permissions. The description merely repeats the action of removal.
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 repetitive, listing eight synonyms unnecessarily. It could be condensed to a single phrase without loss of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool, the description lacks detail on side effects, return values, or error conditions. It is minimally complete but insufficient for an agent to fully understand implications.
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 a clear description for 'id'. The tool description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists multiple synonyms for removal, making it clear that the tool removes an environment. However, it adds little beyond the tool name 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?
No guidance on when to use this tool versus alternatives like remove_unified_connection or remove_unified_webhook. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_unified_webhookCInspect
remove webhook subscription. delete webhook subscription. destroy webhook subscription. erase webhook subscription. drop webhook subscription. purge webhook subscription. deprovision webhook subscription. unlink webhook subscription. remove callback subscription. remove hook subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the webhook to remove |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description merely states the action without revealing behavioral traits such as whether the removal is permanent, reversible, or requires confirmation. The list of synonyms adds no new behavioral insight.
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 highly redundant, repeating the same concept in ten different ways. It could be condensed to a single sentence, wasting tokens and failing to be concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one required parameter, no output schema, and no annotations. The description is minimal and does not explain the effect of removal, error scenarios, or any side effects. It lacks completeness for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'id', which already describes its purpose. The description does not add any additional meaning beyond what the schema provides, meeting 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?
The description uses multiple synonyms for 'remove' and specifies 'webhook subscription', making the action clear. However, it does not distinguish from sibling removal tools like remove_unified_connection or remove_unified_environment beyond the resource name, which is already evident from the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks any context about prerequisites, when removal is appropriate, or when a different tool might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_unified_connectionDInspect
update connection. modify connection. edit connection. change connection. revise connection. patch connection. amend connection. refresh connection.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the connection to update | |
| auth | No | An authentication object that represents a specific authorized user's connection to an integration | |
| is_paused | No | Whether this integration has exceed the monthly limit of the plan | |
| categories | Yes | The Integration categories that this connection supports | |
| environment | No | ||
| permissions | Yes | Array | |
| auth_aws_arn | No | the AWS ARN / secretID for the stored auth field | |
| workspace_id | No | (reference to KmsSpace) | |
| external_xref | No | customer's user ID | |
| last_healthy_at | No | (ISO-8601 / YYYY-MM-DDTHH:MM:SSZ format) | |
| integration_name | No | ||
| integration_type | Yes | The integration type | |
| last_unhealthy_at | No | (ISO-8601 / YYYY-MM-DDTHH:MM:SSZ format) | |
| auth_gcp_secret_name | No | the Google Cloud Secret Manager name for the stored auth field | |
| auth_hashi_vault_path | No | the HashiCorp Vault path for the stored auth field | |
| auth_azure_keyvault_id | No | the Azure Key Vault ID for the stored auth field |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, required permissions, or potential consequences. It merely states it updates a connection without any additional 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 repetitive (8 synonyms) and lacks structure. It is under-specified and wastes space without adding information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, nested objects, no output schema), the description is completely inadequate. It fails to provide necessary context 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 high (88%), so baseline is 3. The description adds no value to parameters; it doesn't mention or explain any 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 only lists synonyms for 'update connection' without specifying what kind of connection or what updates are performed. It fails to distinguish from sibling tools like create_unified_connection or get_unified_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives, no prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_unified_webhookCInspect
update webhook subscription. modify webhook subscription. edit webhook subscription. change webhook subscription. revise webhook subscription. patch webhook subscription. amend webhook subscription. refresh webhook subscription. update callback subscription. update hook subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the webhook to update | |
| meta | No | ||
| runs | No | An array of the most revent virtual webhook runs | |
| event | Yes | ||
| db_url | No | ||
| fields | No | ||
| db_type | No | ||
| filters | No | ||
| hook_url | No | The URL of the webhook | |
| interval | No | The interval (in minutes) to check for updated/new objets | |
| db_schema | No | ||
| is_paused | No | ||
| checked_at | No | The last date/time that a check was done on this object (ISO-8601 / YYYY-MM-DDTHH:MM:SSZ format) | |
| is_healthy | No | ||
| environment | No | ||
| object_type | Yes | The object to return (eg | |
| webhook_type | No | ||
| workspace_id | No | (reference to KmsSpace) | |
| connection_id | Yes | ||
| db_name_prefix | No | ||
| page_max_limit | No | ||
| integration_type | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear full responsibility for behavioral disclosure. It only states 'update', implying mutation, but does not explain whether updates are partial or full, required fields, side effects (e.g., triggers, notifications), or error conditions. Given 22 parameters, more behavioral context is needed.
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 excessively repetitive, listing nine synonyms for 'update' plus two alternative phrasings. This wastes space and provides no new information. A single concise sentence like 'Update a webhook subscription's settings' would suffice.
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?
With 22 parameters, no output schema, and no annotations, the description is highly incomplete. It does not explain the result of the update, error modes, or how to use the parameters effectively. The high complexity demands a more thorough description.
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 only 32%, meaning many parameters lack schema descriptions. The tool description adds no parameter-level details, failing to compensate for this low coverage. It does not explain which parameters are updatable or how they affect the webhook subscription.
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 synonyms like 'modify', 'edit', 'change', etc., to indicate updating a webhook subscription. It communicates the basic action (update) but lacks specificity about what aspects can be updated (e.g., url, event, filters). With siblings like update_unified_webhook_trigger, clearer differentiation would improve clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_unified_webhook_trigger or create_unified_webhook. There is no mention of prerequisites, conditions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_unified_webhook_triggerDInspect
trigger webhook. trigger callback. trigger hook.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the webhook to update |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description fails to disclose behavioral traits such as side effects (triggering vs updating), required permissions, or idempotency.
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?
Extremely short but lacks substance; the repetition of 'trigger' wastes space without conveying useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one parameter and no output schema, the description should clearly state the action and purpose. It fails to do so, leaving the agent uncertain about the tool's function.
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 no meaning beyond the schema; it even contradicts the schema's description ('The ID of the webhook to update') by using 'trigger'.
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 name implies 'update' but the description says 'trigger webhook' three times, creating confusion about whether the tool updates or triggers a webhook. It does not distinguish from sibling 'update_unified_webhook'.
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 mention of when to use this tool versus alternatives like 'update_unified_webhook' or 'trigger' actions. No usage context provided.
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!