Sets CONFIG.* properties on an existing Vivado IP using set_property -dict to update configuration values without recreating the IP.
Set CONFIG.* properties on an existing IP via set_property -dict.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | Dict of CONFIG.* keys to values (e.g. {'CONFIG.PRIM_IN_FREQ': '125'}) | |
| module_name | Yes |
Changes observed during successful MCP inspections.
v0.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden, and it discloses almost nothing: not whether changes persist to the project file, whether synth_ip/regeneration is required afterward, whether the project must be open, or how invalid CONFIG keys are handled. Only the mutation mechanism (set_property -dict) is revealed, which is minimal for a write operation with zero annotation coverage.
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?
A single tight sentence with zero filler, front-loading the action and target. It is efficiently sized, though the terseness leaves gaps that are penalized under other dimensions rather than here.
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 mutation tool with no annotations, no output schema, a nested-object parameter, and an undocumented required string, one sentence is insufficient. An agent cannot tell what module_name means, what happens on success or failure, or what follow-up steps the configuration change requires.
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?
Schema coverage is only 50%: the config object has a description with an example, but module_name is bare. The description explains the CONFIG.* key/value shape for config but adds nothing about module_name — critically, it never clarifies whether that is an IP instance name, a VLNV, or a module type.
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?
States a specific verb and resource ("Set CONFIG.* properties on an existing IP") plus the underlying mechanism (set_property -dict), which is more than a restatement of the name. It does not name or contrast with any sibling such as create_ip or configure_bd_cell, so an agent must infer the boundary itself.
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 phrase "on an existing IP" implies a precondition (the IP must already exist, i.e. create_ip first), but there is no explicit when/when-not guidance and no alternatives named. The agent must infer whether to use this versus create_ip, upgrade_ip, or configure_bd_cell.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.