Add or update output values in ELN templates by specifying card title, field title, and field name. Manage output items directly with optional ID for updates.
添加或更新输出值。名称格式: raw##{卡片标题}-{字段标题}##{字段名}
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | 已有输出值 ID（更新时传入） | |
| cardTitle | Yes | 卡片标题 | |
| fieldName | Yes | 字段标识 | |
| fieldTitle | Yes | 字段标题 |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation mutates state ('add or update') and gives the name format, but it does not describe what happens on add versus update, whether existing values are overwritten, side effects, return values, or error conditions. Minimal disclosure for a mutation tool 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?
The description is a single concise sentence with the naming format front-loaded. It is efficient, but the concision comes at the cost of clarity given the add/update ambiguity with the sibling tool. The sentence is compact yet leaves important behavioral gaps unfilled.
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, and a naming scheme that depends on parameter formatting, the description is too thin. It fails to disambiguate add versus update against the update_output_item sibling, describe side effects or return values, or explain how the id parameter selects between the two behaviors.
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 description coverage is 100%, so all four parameters are already documented in the schema. The description adds value by explaining how the parameters combine into the naming convention (raw##{card title}-{field title}##{field name}) and hinting that id distinguishes add from update. Beyond that, it does not compensate for the id parameter's conditional role.
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?
The description states a clear verb+resource ('add or update output value') and includes the naming format. However, it is ambiguous: the tool is named add_output_item yet claims to 'update' as well, while a sibling update_output_item exists. This overlap muddies what exactly this tool is for versus its sibling.
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?
No when-to-use or when-not-to-use guidance is given. There is no mention of alternatives such as update_output_item or remove_output_item, and no explanation of the circumstances that call for adding versus updating. The id parameter implicitly signals update behavior, but that is inferential, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.