AFAS MCP Server

Describe an UpdateConnector

afas_describe_update_connector

Read-onlyIdempotent

Retrieves an AFAS UpdateConnector schema by connector_id, covering mandatory and key fields, allowed values, and nested objects for building valid update payloads.

Instructions

Describe an UpdateConnector: its fields (mandatory, key, allowed values) and the nested objects it accepts.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "connector_id": "<connector_id>"
    },
    "name": "afas_describe_update_connector"
  }
}

Input Schema

Name	Required	Description	Default
`connector_id`	Yes	UpdateConnector id as listed by afas_list_connectors, e.g. KnSubject.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered without prose. The description adds useful behavioral detail about what the call exposes (mandatory/key/allowed-value metadata plus nested object shapes), but says nothing about failure behavior for an unknown connector id or whether results are cached.

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?

A single front-loaded sentence that names the operation first and then the payload it yields, with zero filler wording.

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?

With an output schema present, annotations covering safety, and complete parameter documentation, the description is nearly sufficient. The remaining gap is routing: it does not tell the agent how this differs from afas_describe_get_connector or when to follow up with afas_validate_payload.

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 coverage is 100% and the single parameter carries a description naming its source (afas_list_connectors) plus a concrete example (KnSubject). The tool description adds no further meaning, which is acceptable at this coverage level.

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

Purpose4/5

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

States a specific verb and resource ('Describe an UpdateConnector') and enumerates the returned content (mandatory, key, allowed values, nested objects). However, it never contrasts itself with the sibling afas_describe_get_connector, so an agent must infer that this one covers update connectors rather than get connectors.

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

Usage Guidelines3/5

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

Usage is only implied: the description's focus on UpdateConnector fields suggests it is a pre-write metadata lookup, and the parameter description points at afas_list_connectors as the id source. There is no explicit when-to-use or when-not-to-use statement, and no mention of afas_validate_payload as the natural next step.

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

Deploy Server