Unfavorite an expert
unfavorite_expertRemoves an expert from your favorites.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| expertId | Yes |
unfavorite_expertRemoves an expert from your favorites.
| Name | Required | Description | Default |
|---|---|---|---|
| expertId | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the description needs only to add context — but it adds none beyond restating the operation. It says nothing about what happens if the expert was not favorited, whether auth is required, or what the call returns.
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 short sentence with the action and object front-loaded — no filler. Its brevity is appropriate, though it tips into under-specification rather than tight completeness.
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 one-parameter mutation with annotations covering the safety profile and no output schema, the minimal description is close to sufficient. Still, it omits the parameter's meaning and the no-op/error case for an expert not in favorites, which an agent would want before calling.
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 0% and the description never mentions expertId, so nothing clarifies that it is the identifier of the expert to remove or what format/limits apply (the schema only enforces 1–128 chars). The parameter's meaning is guessable from the name but not documented.
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 uses a specific verb and resource ("Removes an expert from your favorites"), so the operation is unambiguous. It does not reference the obvious counterpart avorite_expert or list_favorites, so sibling differentiation is left to the tool name alone.
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?
There is no guidance on when to use this versus avorite_expert or how to discover existing favorites via list_favorites. The use case is only inferable from the name, and prerequisites (e.g. the expert must already be favorited) are unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.