Update a certification's details by ID, including title, authority, dates, credential URL, and associated skills, to keep your portfolio accurate.
Update an existing certification by ID. Requires write permission.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Certification ID | |
| title | No | ||
| authority | No | ||
| body_html | No | ||
| is_active | No | ||
| skill_ids | No | ||
| issued_date | No | ||
| project_ids | No | ||
| credential_url | No | ||
| expiration_date | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full behavioral disclosure burden. It does disclose a key trait by noting 'Requires write permission,' which is valuable context. Yet it omits other important behavioral details such as whether the update is partial or a full replacement, what happens if the ID is not found, or what the response contains.
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 extremely concise with no filler—two short sentences each add value. The core action is front-loaded, and the permission note is a separate, clear sentence. It could have been more informative while still being concise, but efficiency is strong.
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?
This is a 10-parameter mutation tool with no annotations, no output schema, and no parameter explanations. The description only covers the action and a permission prerequisite, leaving an agent without crucial information about updatable fields, partial vs. full update semantics, return values, or error behavior. This is insufficient for reliable invocation.
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 only 10% (only the 'id' parameter is described in the schema), and the description does not compensate for this gap. Saying 'by ID' adds no meaning beyond the schema's own 'Certification ID' note, and the other nine parameters are left completely unexplained.
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 specific verb ('Update'), a precise resource ('existing certification'), and a key identifier ('by ID'). This clearly distinguishes it from create, delete, get, and list siblings, and makes the tool's primary function immediately obvious.
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 'existing certification' implies this tool is for modifying an already-created resource rather than creating or deleting, and 'Requires write permission' gives a necessary precondition. However, it does not explicitly state when to choose this over alternatives like create_certification or delete_certification, nor does it list any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.