Integration Infrastructure Agents Actually Control
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.6/5 across 18 of 18 tools scored. Lowest: 1.8/5.
Every tool has a clearly distinct purpose: workflow lifecycle, invocation, logging, metrics, KV store, secrets, connections, and documentation. Even similar tools like get_logs vs get_invocation are well-differentiated by descriptions.
Most tools follow a consistent verb_noun pattern (create_workflow, get_workflow, list_workflows). The KV tools (kv_get, kv_set, kv_list, kv_delete) are internally consistent but deviate from the dominant verb_noun style by using a noun_verb prefix.
With 18 tools, the count is slightly above the typical 3-15 range, but the broad platform scope (workflow management, invocation, logging, metrics, KV, secrets, connections, docs) justifies each tool's existence. No tool feels redundant.
Workflows have create, read, update (via update_draft), list, and publish, but lack a delete operation. Secrets support create and list but no delete/update, and connections only have list. These lifecycle gaps create potential dead ends for agents.
create_workflowBInspectCreate a workflow. The workflow ID (UUID) is assigned automatically. For AI agent workflows, call get_agent_framework_docs first and use Mastra (bun) or LangGraph (python).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| language | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions automatic ID assignment, but omits other behavioral traits such as authentication requirements, destructive actions, or side effects. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences: purpose, ID automation, and agent workflow guidance. No wasted words, and key 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 tool with two parameters and no output schema, the description covers basic usage. However, it lacks advanced context such as error handling, idempotency, or behavior on duplicate names, which would be expected for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds little beyond the schema. It links language to framework (bun→Mastra, python→LangGraph) but does not clarify constraints, formats, or other parameter meaning. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a workflow and that the ID is auto-assigned. It distinguishes from siblings by advising to call get_agent_framework_docs first for AI agent workflows, but does not explicitly differentiate from other creation tools like publish_workflow.
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?
It indicates when to use the tool (creating workflows) and provides a prerequisite for AI agent workflows (call get_agent_framework_docs). However, it lacks explicit when-not-to-use scenarios or alternatives for non-AI workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_workflow_triggerAInspectCreate a disabled workflow trigger. Enable it only after representative testing and exact-version publication.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| environment | Yes | ||
| workflow_id | Yes | ||
| change_types | No | ||
| connection_id | Yes |
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 discloses that the trigger is created disabled and warns about enabling, which is useful. However, it does not describe side effects, permission requirements, or what the trigger does when enabled, leaving gaps.
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 short sentences with no waste. The first sentence states the action, and the second delivers a critical safety warning. This is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers only the core action and the disabled initial state. It omits explanations of parameters, trigger behavior, prerequisites, and return values. Given the tool has 5 parameters, no output schema, and no annotation, this is insufficient for correct autonomous use.
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 provides no information about any of the five parameters (model, environment, workflow_id, change_types, connection_id). With schema description coverage at 0%, the agent has no semantic guidance for these inputs, and the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Create a disabled workflow trigger,' clearly stating the action (create) and resource (workflow trigger). This distinguishes it from sibling tools like update_workflow_trigger and delete_workflow_trigger, and the disabled state adds specificity.
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 second sentence, 'Enable it only after representative testing and exact-version publication,' provides contextual guidance on the intended workflow: the trigger is created disabled and should only be enabled after testing and publication. However, it does not explicitly mention alternatives or situations where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_workflow_triggerAInspectPermanently delete a workflow trigger (admin scope).
| Name | Required | Description | Default |
|---|---|---|---|
| trigger_id | Yes | ||
| workflow_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses correctness-critical behavior: the deletion is permanent ('permanently delete') and requires administrative privileges ('admin scope'). This adds meaningful context beyond the simple action, though it does not detail idempotency or response 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?
The description is extremely concise: one short sentence, front-loaded with the verb and object. Every word adds value ('permanently' and 'admin scope' are both informative). No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation with no output schema and no annotations, the description covers the core purpose, irreversibility, and permission. However, it lacks any mention of return behavior, error conditions, or relationship to the workflow (e.g., that the trigger must belong to the specified workflow). It is adequate but not comprehensive.
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 schema has 0% description coverage and the description does not mention parameters at all. The agent must rely solely on parameter names (workflow_id, trigger_id) without any clarification on their semantics or relationship. The description provides zero added value for understanding the two required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('permanently delete') on a specific resource ('workflow trigger') and adds the admin scope. It distinguishes itself from sibling tools like create_workflow_trigger and update_workflow_trigger by clearly indicating deletion.
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 when to use the tool (when you need to delete a workflow trigger) via the verb and resource, but does not explicitly state when not to use it or mention alternatives. The phrase 'admin scope' hints at a prerequisite but does not provide direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_framework_docsAInspectReturns Mastra (Bun) and LangGraph (Python) patterns for AI agent workflows.
Call this BEFORE create_workflow / update_draft when building chatbots, tool-using agents, or multi-step LLM flows. Do not hand-roll custom agent loops — use the preinstalled frameworks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the returned data but does not disclose any side effects, authorization needs, rate limits, or idempotency. For a read-only document retrieval, this is acceptable but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and usage guidance. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a straightforward purpose, the description is sufficiently complete for a documentation-retrieval tool. It could mention output format, but the current content covers key context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema coverage is 100%. The description adds meaning by explaining the context of the returned content (patterns for agent workflows) beyond the empty schema, which is 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?
Clearly states the tool returns Mastra and LangGraph patterns for AI agent workflows, using specific verbs and resources, and distinguishes itself from sibling tools by specifying when to call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call (before create_workflow/update_draft for chatbots, tool agents, multi-step flows) and what not to do (avoid hand-rolling loops), providing clear guidance and alternative behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_trigger_docsAInspectRead the Nango sync event envelope and reliability contract before writing an event workflow.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. The verb 'Read' clearly signals a non-destructive read operation, and the resource naming indicates the content type. It lacks details like output format, but for a documentation reader this is reasonable and not misleading.
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, front-loaded sentence that immediately states the action and resource. Every word earns its place, and it avoids unnecessary elaboration or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description sufficiently covers the purpose and timing of use. It contextualizes the tool within the workflow creation process, though it could have briefly explained what the 'reliability contract' entails for slightly richer completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information, which is appropriate since there are none. It does not need to compensate for any schema gaps.
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 ('Read') and resource ('Nango sync event envelope and reliability contract'), clearly distinguishing this documentation tool from sibling doc tools like get_integration_docs and get_agent_framework_docs. It tells the agent exactly what content it will access.
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 'before writing an event workflow' provides a clear contextual trigger for when this tool should be used. It does not explicitly name alternatives or exclusions, but the context is sufficiently aligned with the workflow-related sibling tools to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_integration_docsAInspectGet API endpoints, base URL, and a working code example for a specific integration provider. Call this before writing workflow code that uses an integration.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Provider slug, e.g. github, salesforce, slack, hubspot, notion, linear, stripe, zendesk, airtable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description transparently states the tool returns endpoints, base URL, and code examples. The name 'get' implies a read-only operation, and no side effects are expected. It adequately informs the agent of its 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?
The description consists of two clear, front-loaded sentences with no superfluous content. Every sentence adds value: the first states the action and result, the second gives usage timing.
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 doc retrieval tool with one parameter and no output schema, the description is fully complete. It tells the agent what the tool returns, when to use it, and what input is needed. No further detail is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already thoroughly describes the 'provider' parameter with examples (github, salesforce, etc.). The description adds no additional meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'API endpoints, base URL, and a working code example' for a 'specific integration provider'. The verb 'Get' and resource 'integration provider docs' are specific, and the tool is well-distinguished from siblings like 'get_agent_framework_docs' by focusing on integration providers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this before writing workflow code that uses an integration', providing clear context on when to use it. While it doesn't mention when not to use or list alternatives, the instruction is sufficient for this simple doc retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_invocationAInspectGet a single invocation by ID, including status, output, error, stderr, and duration. Use this to poll an async invocation (invoke_workflow with invoke_mode=async returns an invocation_id) until status is 'completed', 'failed', 'timeout', or 'oom_killed'.
| Name | Required | Description | Default |
|---|---|---|---|
| invocation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what is returned (status, output, error, etc.) but does not mention safety, side effects, or rate limits. However, the name and context imply read-only 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 sentences, front-loaded with purpose, followed by usage. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the purpose, return fields, and usage context. It could mention what happens if the invocation is not found, but given the simplicity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter. It only mentions 'by ID' without defining the format or source of the ID, though the usage guidance links to invoke_workflow. This is insufficient for a parameter with zero schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a single invocation by ID', listing specific fields. It distinguishes from siblings by focusing on invocations versus workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: to poll an async invocation from invoke_workflow until a terminal status. This is a clear guidance with a concrete example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_logsAInspectList past invocations for a workflow (status, output, error, stderr, duration, mode). Use get_invocation for the full record of a single run by ID. Note: streamed debug logs (console.log/print) are live-only and not stored here.
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | ||
| limit | No | ||
| status | No | ||
| end_time | No | ||
| snippet_id | No | Deprecated alias for workflow_id. | |
| start_time | No | ||
| workflow_id | Yes | Workflow ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adds context by noting what fields are returned and that streamed debug logs are excluded. However, it does not disclose permissions, rate limits, or pagination behavior, leaving some gaps.
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, each serving a distinct purpose: stating the function and providing alternatives/limitations. It is front-loaded and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is too sparse. It omits parameter details, output format, ordering, and error handling, making it insufficient for an agent to use 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?
The description provides no information about the tool's parameters beyond implying workflow_id is needed. With only 29% schema coverage, the description fails to compensate for the many undocumented parameters such as limit, status, env, start_time, and end_time.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists past invocations for a workflow, specifying the fields returned (status, output, error, stderr, duration, mode). It distinguishes itself from the sibling tool get_invocation, which is for a full record of a single run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends get_invocation as an alternative for a full record and warns that streamed debug logs are not stored. This provides clear usage context, though it could be more explicit about when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_metricsCInspectGet aggregate and time-series metrics for a workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | ||
| snippet_id | No | Deprecated alias for workflow_id. | |
| workflow_id | Yes | Workflow ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose that this is a read-only operation, nor does it mention permission requirements, data size considerations, or response structure. The minimum expectation for a metrics tool is to indicate it is non-destructive, which is not done.
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 at one sentence, but this brevity comes at the cost of completeness. It is not wasteful, but it could be expanded slightly to improve clarity 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?
For a tool with 3 parameters and no output schema or annotations, the description is insufficient. It does not explain the difference between aggregate and time-series metrics, the structure of the response, or any usage context, leaving the agent with significant gaps.
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 67%, but the tool description adds no parameter information. It does not explain the window enum options or clarify that snippet_id is deprecated beyond what the schema already provides. The missing window description could have been supplemented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves aggregate and time-series metrics for a workflow, using the specific verb 'Get' and resource 'metrics'. It distinguishes from sibling tools like get_workflow and get_logs, but doesn't specify what kind of metrics, leaving some ambiguity.
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 get_logs or get_invocation. There is no mention of prerequisites, context, or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_workflowAInspectGet a workflow by ID, including its version history (with code) and the active version per environment. Use this to read the current code before editing an existing workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| snippet_id | No | Deprecated alias for workflow_id. | |
| workflow_id | Yes | Workflow ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool returns version history and active version, implying a read operation. It could mention permissions or safety, but overall it is transparent for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first states the core function, the second gives usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return values (version history with code, active version per environment). For a simple read tool with 2 parameters, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by noting that 'snippet_id' is a deprecated alias for 'workflow_id', providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a workflow by ID' and specifies what is included (version history with code, active version per environment). This distinguishes it from sibling tools like list_workflows.
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 says 'Use this to read the current code before editing an existing workflow,' which provides a clear use case and context. However, it does not explicitly exclude other uses or compare to specific siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoke_workflowBInspectInvoke a workflow synchronously, asynchronously, or as a stream. tenant_slug is optional; when omitted the tenant is inferred from the API key.
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | ||
| input | No | ||
| version | No | ||
| snippet_id | No | Deprecated alias for workflow_id. | |
| invoke_mode | No | ||
| tenant_slug | No | Tenant slug. Optional — inferred from the API key when omitted. | |
| workflow_id | No | Workflow ID (UUID). | |
| callback_url | No | ||
| snippet_slug | No | Deprecated alias for workflow_id. | |
| workflow_slug | No | Deprecated alias for workflow_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It mentions the three invoke modes but does not describe side effects (e.g., whether it's destructive), error handling, or response format. Deprecated parameters are not acknowledged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that front-load the core purpose. Every sentence adds value without extraneous 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?
Given 10 parameters, no output schema, and no annotations, the description is too sparse. It fails to cover important context such as output behavior, error handling, or how to use the callback_url parameter. Deprecated alias parameters are also unmentioned.
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 50%, and the description adds minimal semantics beyond the schema. It clarifies that tenant_slug is optional and inferred from the API key, but does not explain other critical parameters like env, input, version, or callback_url.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Invoke' and the resource 'workflow', and specifies three invocation modes (synchronous, asynchronous, stream). This distinguishes it from sibling tools like create_workflow or get_workflow.
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 indicates when to use the tool (invoking a workflow) and notes that tenant_slug can be omitted. However, it lacks guidance on when to choose sync vs async vs stream, and does not mention alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kv_deleteAInspectDelete a value from the tenant-wide KV store. The default namespace is shared by every workflow in the tenant. This cleanup operation is idempotent and returns deleted: false when the key is already missing.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to delete. | |
| namespace | No | Optional namespace; omitted means the tenant-wide default namespace. |
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 discloses idempotency and the return value when a key is missing, which is useful behavioral context. It does not mention authentication or other side effects, but for a simple delete operation, this 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, front-loaded with the action, and every sentence provides meaningful information without padding.
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 simple two-parameter schema and no output schema, the description covers the operation's core behavior including idempotency and return semantics. It doesn't delve into edge cases or permissions, but it is sufficiently complete for the tool's scope.
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%, providing a baseline of 3. The description adds extra meaning to the namespace parameter by explaining the default namespace is tenant-wide and shared by every workflow, enhancing the schema's basic description.
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 and resource: 'Delete a value from the tenant-wide KV store.' It clearly identifies the operation and distinguishes it from sibling tools like kv_get, kv_set, and kv_list by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying it operates on the tenant-wide KV store and notes the default namespace is shared across workflows. However, it does not explicitly name alternative tools or when-not scenarios, 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.
kv_getAInspectGet a JSON value from the tenant-wide KV store. The default namespace is shared by every workflow in the tenant. Returns null when the key is missing; a stored JSON null is indistinguishable from a missing key, so use kv_list with a prefix when that distinction matters.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to retrieve. | |
| namespace | No | Optional namespace; omitted means the tenant-wide default namespace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses critical behavior: returns null for missing keys, and a stored JSON null is indistinguishable from missing. Also clarifies namespace semantics (shared tenant-wide default). This goes beyond schema and provides essential runtime 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 concise sentences: first states purpose, second delivers crucial caveat. No wasted words, well-structured for quick comprehension.
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 key-value get with no output schema, the description covers the essential information: return value semantics, namespace behavior, and a fallback strategy for ambiguous null cases. Completely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described adequately. The description adds meaningful context on the default namespace being tenant-wide and shared by all workflows, enhancing understanding of the namespace parameter beyond the schema's 'optional' note.
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?
Specifies the action (Get) and resource (JSON value from tenant-wide KV store). Distinguishes from siblings by clarifying tenant-wide scope and the singular key-based retrieval, contrasting with kv_list/kv_set/kv_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (retrieve by key) and when to prefer an alternative: use kv_list with a prefix when missing vs null distinction matters. This is clear practical guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kv_listAInspectList KV metadata without values. Omit namespace to list every namespace, or provide one to filter it. The default namespace is shared by every workflow in the tenant.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum entries to return. | |
| offset | No | Number of entries to skip. | |
| prefix | No | Optional literal key prefix. | |
| namespace | No | Optional namespace. Omit to list every namespace; provide default to list only the tenant-wide default namespace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that values are not returned and explains the shared default namespace behavior, which is useful context. However, it does not mention pagination defaults or potential side effects, though the schema covers limit/offset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action and key differentiator ('without values'), followed by namespace guidance. No wasted words or redundant restatement of the schema.
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 annotations and no output schema, the description covers the essential behavior for a list operation. It explains the namespace filtering and default scope, but omits details like pagination behavior or explicit read-only status. This is adequate for a simple list tool but not exhaustively complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters. The description adds extra clarity for the namespace parameter (omit vs provide, default namespace shared), but does not add meaning for limit, offset, or prefix 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 states the action (list) and resource (KV metadata) with a clear qualifier 'without values', distinguishing it from kv_get. It also explains the namespace behavior, making the tool's purpose unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs how to use namespace to either list all namespaces or filter by one, and clarifies the default namespace scope. It implicitly differentiates from kv_get by noting it returns no values, though it does not explicitly name alternatives or when to avoid using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kv_setAInspectSet a JSON value in the tenant-wide KV store. The default namespace is shared by every workflow in the tenant. ttl_seconds is optional, measured in seconds, and omitting it stores the value without an expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to set. | |
| value | Yes | Any JSON value, including an object, array, string, number, boolean, or null. | |
| namespace | No | Optional namespace; omitted means the tenant-wide default namespace. | |
| ttl_seconds | No | Optional time to live in seconds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses ttl behavior (omitting stores without expiry) and that the default namespace is shared, but does not explicitly state that setting an existing key overwrites it or mention response/error behavior. This is partial disclosure.
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, followed by important namespace and TTL details. No 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 mutation tool with no output schema, the description covers the main purpose, namespace behavior, and TTL semantics. It falls short of explaining the return value, overwrite behavior, or any error cases, leaving minor gaps.
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, establishing a baseline of 3. The description adds useful context beyond the schema: ttl_seconds is optional and omitting stores without expiry, and the default namespace is shared across workflows. This justifies a 4.
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 'Set a JSON value in the tenant-wide KV store,' using a specific verb and resource. It distinguishes from sibling tools like kv_get, kv_delete, and kv_list by focusing on the set operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this operates on a tenant-wide KV store and notes the shared default namespace, but it does not explicitly mention when to use this versus alternatives like set_secret or kv_delete. However, the purpose is unambiguous, so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_connectionsCInspectList OAuth integrations connected for this tenant.
IMPORTANT — how to use integrations in workflow code:
Bun/TypeScript: import { integration } from '@velane/integrations' const client = integration('github') // provider slug const user = await client.get('/user') // GET const issue = await client.post('/repos/org/repo/issues', // POST { title: 'Bug', body: 'Details' }) await client.patch('/repos/org/repo/issues/1', { state: 'closed' }) await client.delete('/repos/org/repo/labels/old')
Python: from velane.integrations import integration client = integration("salesforce") cases = client.get("/services/data/v60.0/sobjects/Case/describe") result = client.post("/services/data/v60.0/sobjects/Case", {"Subject": "Login issue", "Status": "New"})
Methods: .get(path) .post(path, body) .patch(path, body) .put(path, body) .delete(path) All methods return parsed JSON. Paths are the provider's native API paths. @velane/integrations is always available — no install, no credentials needed in code. Call get_integration_docs(provider) to look up endpoints for any provider.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 50). | |
| offset | No | Number of results to skip for pagination. | |
| provider | No | Filter by provider/alias substring, e.g. 'github'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It does not explicitly state that the tool is read-only or safe, nor does it discuss pagination or output format beyond the schema parameters. The code examples are not behavioral traits of this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bloated with lengthy code examples (Bun/TypeScript and Python) that are not directly about the tool's function. This reduces conciseness and front-loading is poor; the essential purpose is only in the first sentence.
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 no output schema and no annotations, the description should fully explain what the tool returns and how to use its output. It does not describe the response format or that the output includes provider slugs needed for integration client. The code examples hint at usage but do not complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it merely restates filter option for provider. The extensive code examples do not pertain to 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 first sentence clearly states the tool lists OAuth integrations for the tenant, which is specific and distinguishes it from sibling tools like list_secrets and get_integration_docs.
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. The description includes code usage examples for integrations, but does not address when to invoke this tool specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_integration_event_modelsAInspectDiscover deployed Nango sync models for a connection. manual_entry=true means this Nango installation cannot enumerate them.
| Name | Required | Description | Default |
|---|---|---|---|
| connection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It does reveal an important limitation (manual_entry=true prevents enumeration), but it does not state whether this is a read-only operation, any required permissions, or what happens when the tool cannot enumerate (e.g., error vs empty result).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the main purpose, and adds a caveat as a second sentence. Every word contributes, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description adequately states the purpose and a key limitation. It implies the return value (sync models) but does not describe the response format or edge cases beyond manual_entry=true.
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 0%, and there is only one parameter, connection_id. The phrase 'for a connection' implies that connection_id is the connection identifier, but the description does not explicitly map it to the parameter or explain expectations (e.g., format or existence).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Discover') and the resource ('Nango sync models') scoped to a connection. This differentiates it from sibling tools like list_connections and list_workflows, which focus on other resource types.
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?
Usage is implied by the resource type (sync models for a connection), but there is no explicit guidance on when to use this tool versus alternatives. The manual_entry=true caveat highlights a limitation but does not provide selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_secretsAInspectList secret metadata for the authenticated tenant.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behaviors. It only says 'list', implying read-only, but missing details like pagination, rate limits, permission requirements, or whether all secrets are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, directly states action and scope. Efficiently 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?
Lacks output schema and doesn't specify what metadata is included (e.g., name, timestamps) or if pagination applies. Adequate for a simple list but could be more 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?
No parameters exist, so baseline is 4. The description adds the tenant scope ('for the authenticated tenant'), providing context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'secret metadata', with the scope 'for the authenticated tenant'. It distinguishes from sibling tools like 'set_secret' (write) and 'list_workflows' (different resource).
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 'set_secret' or other list tools. No mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_workflowsAInspectList workflows available to the authenticated tenant.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It states the tool lists workflows but does not mention pagination, sorting, or whether it returns all workflows without filtering. For a simple list tool, this is adequate but minimal.
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, front-loaded sentence that conveys the purpose without any unnecessary words. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and is a list operation, the description is minimally sufficient. However, it lacks details on potential pagination, filtering, or limitations, which would improve completeness 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 tool has no parameters, and schema description coverage is 100% (empty schema). The description adds no parameter info, which is acceptable since there are none. Per guidelines, baseline is 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists workflows available to the authenticated tenant. It uses a specific verb ('List') and resource ('workflows'), distinguishing it from sibling tools like get_workflow (single workflow) or create_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like get_workflow or invoke_workflow. While the purpose is clear, an agent would benefit from knowing that this tool lists all workflows, while get_workflow retrieves a specific one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_workflow_triggersBInspectList Nango sync triggers and recent delivery state for a workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| workflow_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior; it states the tool lists triggers and delivery state, but does not discuss side effects, return format, error handling, or whether this is a read-only operation. The read-only nature is implied by 'List' but not explicit.
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 sentence with only essential words; the verb is front-loaded and every phrase adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The low complexity (one required param, no output schema, no annotations) is covered minimally by the description, but the meaning of 'recent delivery state' and response structure are not described, so completeness is partial. For a simple listing tool it is adequate, but not fully informative.
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 single parameter workflow_id is mentioned implicitly via 'for a workflow', but the description adds no details about the parameter's format, requiredness, or relationship to other tools. The schema provides only the type and required flag, so the description partially compensates by linking the parameter to the tool's purpose.
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 the specific verb 'List' and identifies both the resource ('Nango sync triggers') and scope ('for a workflow'), clearly distinguishing it from sibling tools that create/update/delete triggers and from list_workflows.
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 offers no explicit guidance on when to use this tool versus alternatives, and does not mention any exclusions, prerequisites, or alternative tools. The prepositional phrase 'for a workflow' gives some context but does not explain when to choose this tool over, say, list_workflows or create_workflow_trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_workflowCInspectPublish a workflow version to an environment.
| Name | Required | Description | Default |
|---|---|---|---|
| env | Yes | ||
| snippet_id | No | Deprecated alias for workflow_id. | |
| workflow_id | Yes | Workflow ID. | |
| version_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits like side effects, permissions needed, or reversibility, but it only says 'publish', which is vague. It does not explain what happens to existing versions or whether the operation is destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, but it could include more details without being verbose. It is concise but slightly under-specified.
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 partial schema coverage, the description does not provide enough context about return values, error conditions, or prerequisites for a mutation tool, leaving the agent with limited understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. With 50% schema coverage, the description does not clarify the role of each parameter or how they affect the publish action, leaving gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (publish), the resource (a workflow version), and the destination (an environment), distinguishing it from sibling tools like create_workflow or invoke_workflow.
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 (e.g., after creating a version) or when to avoid it (e.g., if the environment already has a published version). No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_secretDInspectCreate a secret.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| value | Yes | ||
| snippet_id | No | Deprecated alias for workflow_id. | |
| workflow_id | No | Optional workflow ID scope. | |
| environments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only states 'Create a secret' without revealing mutation behavior, idempotency, permission requirements, or side effects. The optional parameters (workflow_id, environments) are not explained in the description.
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 three words, the description is severely under-specified for a tool with 5 parameters. This is not conciseness but omission.
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 mutation tool with 5 parameters, no output schema, and no annotations, the description is completely inadequate. Missing return behavior, error conditions, permission scope, and parameter semantics.
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 40% (only 2 of 5 parameters have descriptions). The description adds no parameter information at all. Parameters like name, value, and environments are completely undocumented in both schema and description.
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 is a tautology: 'Create a secret.' It restates the tool's action without specifying what a secret is or differentiating it from sibling tools like list_secrets. The agent has no context on scope or semantics.
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 set_secret versus alternatives like list_secrets or create_workflow. Missing prerequisites, conditions for overwriting, or environment constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_draftCInspectCreate a new workflow version from source code.
Built-in imports (no install needed): Integrations — Bun: import { integration } from '@velane/integrations' Python: from velane.integrations import integration AI agents — Bun: Mastra — import { Agent } from '@mastra/core/agent' Python: LangGraph — from langgraph.graph import StateGraph
For chat/tool-using/LLM agent workflows you MUST use Mastra or LangGraph. Call get_agent_framework_docs before writing agent code. Do not hand-roll custom agent loops.
Call list_connections / get_integration_docs for OAuth provider APIs. For agent workflows set higher limits via timeout_ms, max_memory_mb (e.g. 512), max_cpu_percent.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| snippet_id | No | Deprecated alias for workflow_id. | |
| timeout_ms | No | ||
| workflow_id | Yes | Workflow ID. | |
| input_schema | No | ||
| max_memory_mb | No | ||
| output_schema | No | ||
| max_cpu_percent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the action without detailing side effects, such as whether an existing draft is modified or a new version is created, or what permissions are 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 long but front-loaded with the main purpose. It includes useful import examples but contains redundant guidance likely belonging to other tools, and the purpose contradicts the tool name.
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 8 parameters and no output schema, the description should explain return values, error scenarios, and resource limitations. It only provides code-writing tips, leaving many behavioral aspects undocumented.
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 low (25%), with only workflow_id and snippet_id described. The description adds no further details on parameters like code, input_schema, timeout_ms, etc., failing to compensate for the schema gaps.
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 says 'Create a new workflow version from source code', but the tool is named 'update_draft', creating a mismatch between name and action. It does not clearly state the tool's purpose or distinguish it from sibling 'create_workflow'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidance on imports and when to use AI agent frameworks, but does not specify when to use this tool over alternatives like create_workflow or invoke_workflow. No exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_workflow_triggerCInspectEnable, disable, or update a workflow trigger.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| enabled | Yes | ||
| trigger_id | Yes | ||
| environment | Yes | ||
| workflow_id | Yes | ||
| change_types | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral details, yet it only names generic actions. It does not explain prerequisites, side effects, or how fields like change_types behave.
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, front-loaded sentence with no wasted words, though it could be more helpful by adding structured parameter or usage 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?
Given the complexity of 6 required parameters, no schema descriptions, no annotations, and no output schema, this one-liner is far from adequate for correct tool 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?
The schema has 0% description coverage for six required parameters, and the description provides zero insight into what workflow_id, trigger_id, model, environment, change_types, or enabled mean.
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 specific verbs 'Enable, disable, or update' with the resource 'workflow trigger', making the tool's function clear and distinct from siblings like create_workflow_trigger or delete_workflow_trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for modifying an existing trigger's state, but does not explicitly contrast it with create/delete alternatives or specify when to choose this tool over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
