Skip to main content
Glama

connector-call-update

Create or modify connector calls for REST, SOAP, and SAPRFC integrations by defining HTTP methods, SOAP operations, RFC functions, parameters, headers, and request configurations.

Instructions

Create or update a Connector call

This tool allows to

  • create new connector calls

  • modify existing connector calls

Attention: When updating a call, allways fetch the existing resource first to ensure operating on the latest version. Existing parameters have to be resent when doing an update - otherwise they would be cleared.

Connector Types

Connector type 'REST'

A REST Connector call defines a HTTP request to the configured endpoint address of the Connector.

Call parameters may define the following:

HTTP Method

Parameter name: verb

Type: String

Possible Values: GET, POST, PUT, PATCH, DELETE, HEAD, OPTION

The parameter is mandatory. If not specified differently, use constValue "GET".

Request body format

Parameter name: postFormat

Type: String

Possible Values: JSON, PLAIN, FORM, XML

Request Body

Parameter name: body

It can have an arbitrary data type. The data is converted and Content-Type header is set according to the parameter format.

Request Headers

Parameter name: headParams/<http-header-name>

Type: String

Example: To add a header "X-TEST", define a parameter with the name "headParams/X-TEST".

Path parameters

Parameter name: pathParams[<n>]

Type: Array[String] - that means it must always be given with array index, i.e. pathParams[0].

To form the URL of the call with complete path, all components of the array are joined by "/" and appended to the endpoint URL or the connector.

Defining a path is optional. If omitted, just the endpoint URL is called.

Examples: (assume endpoint URL is http://test-api.com)

  • If pathParams[0] is "data", the address of the call is "http://test-api.com/data".

  • If pathParams[0]="data" and pathParams[1]="customer", the address of the call is "http://test-api.com/data/customer".

URL parameters

Parameter name: queryParams/<query-param-name> (Type: String)

Example: To set the url parameter like in "http://test-api.com?level=4", define a parameter with the name "queryParams/level" and give it a value 4.

Output parameters

A REST Connector must have at least one output parameter

An empty parameter name, or "/" refers to the whole output object.

Use alias "data" for the whole output object.

Connector type 'SOAP'

A SOAP Connector call defines a SOAP operation to be invoked on the configured WSDL service endpoint of the Connector. You can retrieve the configured WSDL for a connector using the resource simplifier://connector/{connectorName}/wsdl

Call parameters may define the following:

Binding Name

Parameter name: bindingName

Type: String

The binding name identifies the specific service binding to use from the WSDL specification.

The parameter is mandatory.

Operation Name

Parameter name: operationName

Type: String

The operation name specifies which SOAP operation to invoke from the binding.

The parameter is mandatory.

Operation parameters

Parameter name: soap/<operationName>/<parameterName>

Type: depends on operation

Example: soap/_-ITIZ_-BUS2038_CREATE/index

Operation parameters contains the SOAP request parameters according to the operation's input schema defined in the WSDL.

URL parameters

Parameter name: queryParams/<query-param-name>

Type: String

Optional parameters can be added as query parameters appended to the SOAP request URL.

Example: To set a URL parameter like in "http://soap-service.com?version=1.0", define a parameter with the name "queryParams/version" and give it a value "1.0".

Output parameters

Parameter name: soap/<response-message-name>/<element>

An empty parameter name, or "/" refers to the whole output object.

Use alias "data" for the whole output object.

The output typically contains the SOAP response parsed according to the operation's output schema defined in the WSDL.

For example, given the following WSDL operation:

<wsdl:operation name="InputOutput">
    <wsp:Policy>
        <wsp:PolicyReference URI="#OP___-ITIZ_-DRAW_READ_ORIGINAL_FILE" />
    </wsp:Policy>
    <wsdl:input message="tns:InputOutput" />
    <wsdl:output message="tns:InputOutputResponse" />
</wsdl:operation>

With the corresponding message and element definitions:

<wsdl:message name="InputOutputResponse">
    <wsdl:part name="parameter" element="tns:InputOutputResponse" />
</wsdl:message>
<xsd:element name="InputOutputResponse">
    <xsd:complexType>
        <xsd:sequence>
            <xsd:element name="InputOutput" type="xsd:base64Binary" />
        </xsd:sequence>
    </xsd:complexType>
</xsd:element>

the resulting object for the / output parameter would look like this:

{
  "soap": {
    "InputOutputResponse": {
      "InputOutput": "some value here"
    }
  }
}

To get the relevant field only, the output parameter name would be /soap/InputOutputResponse/InputOutput

Connector type 'SAPRFC'

An SAP RFC connector call executes a function on the SAP system defined in the endpoint.

As RFC calls only work with existing functions in the SAP system, use the connector wizard to create them by first searching for available calls using the resource simplifier://connector-wizard/{connectorName}/search/{term}/{page}. After selecting the appropriate calls, use the tool connector-wizard-rfc-create to generate the calls.

RFC connector calls should define the following parameters with constant values:

SOAP compatibility mode

Parameter name: configuration/output/soapCompatibility

Type: Boolean

This parameter should be set to false, unless the user specified otherwise.

Use default values in output

Parameter name: configuration/output/useDefaultValues

Type: boolean

This parameter should be set to true, unless the user specified otherwise.

Autocommit

Parameter name: configuration/autocommit

This parameter should be set to true, unless the user specified otherwise.

Additional return information

Parameter name: configuration/operation/additionalReturnInformation

Type: Array of strings

Possible values: IMPORT, CHANGING, TABLE, EXPORT, EXCEPTION

Unless specified otherwise by the user, this should be set to ["IMPORT", "EXPORT", "CHANGING", "TABLE", "EXCEPTION"].

Output parameters

An RFC connector's output parameters depend on the called SAP system function. You should usually let the wizard create them, as it has all the metadata available.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
connectorNameYesName of the Connector to modify calls
connectorCallNameYesName of the Connector call to be added or modified
descriptionNo
validateInNoIf true, validates that all mandatory input parameters are present before execution. Catches missing parameters early with clear validation errors (HTTP 422). If false, allows incomplete requests through, resulting in backend errors (HTTP 500).
validateOutNoIf true, validates and filters the output response against the defined datatype structure, returning only defined fields (type "any" allows all fields). If false, returns the complete raw API response without filtering or validation.
asyncNo
autoGeneratedNo
connectorCallParametersNoCall Parameters define the input and output arguments, specific to the connector type.
Behavior4/5

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

Annotations indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds valuable behavioral context beyond annotations: it warns about the need to fetch existing resources before updates to avoid data loss, explains that parameters must be resent during updates, and details connector-specific behaviors (e.g., REST requires at least one output parameter, SAPRFC calls should use wizards). No contradiction with annotations exists.

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

Conciseness3/5

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

The description is lengthy but well-structured with sections for each connector type. However, it includes extensive examples and XML snippets that may be excessive. The core information is front-loaded ('create or update a Connector call'), but the document could be more concise by summarizing connector-specific details rather than providing exhaustive documentation.

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?

Given the tool's complexity (8 parameters, no output schema, rich annotations), the description is largely complete. It covers purpose, usage guidelines, behavioral nuances, and parameter semantics across connector types. However, it lacks explicit error handling or response format details, which would be helpful given the absence of an output schema.

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

Parameters5/5

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

With schema description coverage at 63%, the description compensates significantly by explaining parameter semantics for connector types (REST, SOAP, SAPRFC). It details parameter purposes (e.g., 'verb' for HTTP method, 'bindingName' for SOAP binding), formats (e.g., 'headParams/<http-header-name>'), and usage examples. This adds substantial meaning beyond the input schema's property descriptions.

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?

The description explicitly states the tool's purpose: 'create new connector calls' and 'modify existing connector calls.' It distinguishes from siblings like connector-call-delete and connector-call-test by specifying creation/update operations, not deletion or testing.

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?

The description provides clear context for when to use this tool: 'When updating a call, always fetch the existing resource first to ensure operating on the latest version.' It also mentions that 'Existing parameters have to be resent when doing an update - otherwise they would be cleared.' However, it doesn't explicitly state when NOT to use this tool or name specific alternatives for different scenarios.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/simplifier-ag/simplifier-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server