Export a ConfigSource definition in REST API format to reuse or modify it. Provides the output needed for creating or updating a ConfigSource.
Export a ConfigSource definition (REST API format). Output can be used with create_configsource or update_configsource.
| Name | Required | Description | Default |
|---|---|---|---|
| configsource_id | Yes | ConfigSource ID |
Changes observed during successful MCP inspections.
v4.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive nature. The description adds behavioral value beyond annotations by disclosing the output format and that the result is directly reusable by create/update operations, which is useful for an export tool with no output schema.
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 compact sentences with no filler. The main action and format are stated up front, and the compatibility note earns its place by explaining why an agent would use the output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only export tool, the description plus annotations and schema are sufficient. It tells the agent what is exported, in what format, and how the result is intended to be used, so an agent can invoke it correctly without further assumptions.
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 fully describes the single parameter (configsource_id) with 100% coverage. The description does not add parameter-level detail, so the baseline of 3 applies; the schema carries the burden and does so adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Export') and resource ('ConfigSource definition'), and clarifies the output format (REST API format). It distinguishes itself from 'get_configsource' by explaining the exported artifact is intended for reuse with create_configsource or update_configsource.
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 states a clear usage purpose: producing a definition that can be fed into create_configsource or update_configsource. It does not explicitly contrast this with alternatives like get_configsource or other export tools, so it stops short of full when/to-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.