Skip to main content
Glama
TsvetanG2

cognigy-ai-mcp-management-server

by TsvetanG2
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript

update_handover_provider

Idempotent

Modify an existing Cognigy.AI handover provider's name or properties. Validates by default with dryRun=true; set dryRun=false to apply the change.

Instructions

Updates an existing Cognigy.AI handover provider. Use this to rename it or change its properties. MUTATING: Set dryRun=false to update.

Input Schema

NameRequiredDescriptionDefault
nameNoNew name for the provider
dryRunNoIf true (default), validates without updating. Set to false to actually update.
projectIdYesThe project ID the handover provider belongs to
propertiesNoProvider properties to set, as key/value pairs (see get_handover_provider for the current keys). Keys not listed are kept.
providerIdYesThe handover provider ID to update

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.2.1
    • removedInput schema / properties / enabled
      Removed value: -{
-  "description": "Enable or disable the provider",
-  "type": "boolean"
-}
    • addedInput schema / properties / projectId
      Added value: +{
+  "description": "The project ID the handover provider belongs to",
+  "type": "string"
+}
    • addedInput schema / properties / properties
      Added value: +{
+  "additionalProperties": {},
+  "description": "Provider properties to set, as key/value pairs (see get_handover_provider for the current keys). Keys not listed are kept.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}
    • removedInput schema / properties / settings
      Removed value: -{
-  "additionalProperties": {},
-  "description": "Updated provider settings",
-  "propertyNames": {
-    "type": "string"
-  },
-  "type": "object"
-}
    • changedInput schema / required
      Previous value: -[
-  "providerId"
-]New value: +[
+  "projectId",
+  "providerId"
+]
  2. First observedv0.1.4

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description still adds meaningful behavior: it flags the operation as MUTATING and warns that the default is a validation-only dry run, which is the single most likely way an agent would mis-invoke this tool. It does not describe error behavior or the effect of partial property updates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with zero waste; the mutation warning and the dryRun caveat are front-loaded rather than buried. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the definition covers purpose, the mutation risk, and the dry-run default, and annotations carry the idempotency/non-destructive profile. Minor gaps remain: nothing about what a dry run returns or how validation failures surface, and no mention that projectId/providerId are required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (all 5 parameters documented, including dryRun's default-true semantics and the nested properties key/value behavior), so the schema does the heavy lifting. The description adds only 'rename it or change its properties', which maps loosely to the name/properties params but adds no format or constraint detail beyond the schema. Baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Updates') and resource ('Cognigy.AI handover provider'), and further narrows scope with 'rename it or change its properties'. This cleanly separates it from the sibling create_/delete_/get_/list_handover_provider tools without the agent needing to open a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this to rename it or change its properties' gives clear context for when the tool applies, and 'Set dryRun=false to update' is an actionable invocation instruction. It stops short of naming alternatives or stating when not to use it (e.g. preferring create_handover_provider for new providers), so it falls just below the top band.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools