Skip to main content
Glama
awslabs

Threat Modeling MCP Server

Official
by awslabs

update_component

Update existing components in your architecture model, modifying attributes like name, type, version, or configuration. Supports single-item and batch updates to keep threat models accurate.

Instructions

Update an existing component in the architecture. Supports batch operations via the 'items' parameter.

This tool updates one or more existing components in the system architecture. For single item: provide id and fields to update directly. For batch: provide a list of component dicts in the 'items' parameter (each must include 'id').

Args: ctx: MCP context for logging and error handling id: ID of the component to update (required for single item mode) name: New name of the component type: New type of the component service_provider: New provider of the service specific_service: New specific service name version: New version of the component description: New description of the component configuration: New configuration details of the component items: Optional list of component dicts for batch update

Returns: A confirmation message

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoID of the component to update (required for single item mode)
nameNoNew name of the component
typeNoNew type of the component
itemsNoOptional list of components to update in batch. Each dict must contain 'id' and any fields to update. When provided, individual parameters are ignored.
versionNoNew version of the component
descriptionNoNew description of the component
configurationNoNew configuration details of the component
service_providerNoNew provider of the service
specific_serviceNoNew specific service name

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior2/5

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

With no annotations provided, the description carries the full burden. It fails to disclose whether updates are partial or full replacement, behavior on missing ids, or whether batch updates are atomic. The 'Returns' is vague, and key side effects are unaddressed.

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

Conciseness2/5

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

The description front-loads the key purpose but then includes a full Args section that duplicates the input schema descriptions. This redundant documentation adds bloat instead of earning its place.

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

Completeness2/5

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

Despite having an output schema, the description omits critical behavioral details for a complex 9-parameter tool: partial vs full update semantics, error handling for missing components, batch atomicity, and behavior when neither id nor items is provided. These gaps make it incomplete.

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

Parameters4/5

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

Schema description coverage is 100%, but the description adds semantic value by clarifying the relationship between id and items, explaining that single mode requires id while batch mode uses items. This goes beyond the individual 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 clearly states the tool updates existing components in the architecture, with explicit mention of batch operations. It distinguishes itself from sibling tools like add_component and delete_component by focusing on updating existing entities.

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 tool explains two usage modes (single vs batch) and how to structure calls in each. However, it does not explicitly state when to prefer this tool over alternatives, such as using add_component if the component doesn't exist.

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/awslabs/threat-modeling-mcp-server'

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