Skip to main content
Glama

Metis — Focus Decline

focus_decline

Demote an item you don't want to see ranked highly, lowering similar future recommendations without deleting them so you can still audit what was hidden.

Instructions

Say an item does not interest you, so similar ones rank lower in future.

Lower, not gone: declining demotes and folds, it never deletes. Nothing stops
being shown, or you could never audit what you were no longer being offered.

Input Schema

NameRequiredDescriptionDefault
kindNonews
noteNo
slugYes
titleYes
item_idNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

B3.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does real work: it states the effect is demotion/folding, never deletion, and explains why (auditability). That is exactly the kind of 'what actually happens' context an agent needs for a preference-mutating tool. It still omits reversibility (can focus_keep undo it?), scope of the ranking effect, and idempotency.

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

Conciseness3/5

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

The purpose is front-loaded in sentence one, which is good. However, sentences two and three restate the same single idea (not deleted / still shown) twice, so the definition spends roughly half its length on one point.

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?

An output schema exists, so return values need not be explained. But for a five-parameter mutation tool with zero annotation coverage and zero schema descriptions, the description leaves the most failure-prone part — how to identify the item — completely unaddressed.

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

Parameters2/5

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

Schema description coverage is 0% across five parameters (slug, title, kind, note, item_id), and the description names none of them. It never explains whether the item is identified by slug+title vs item_id, what 'kind' defaults to beyond the schema's default, or what 'note' is for. An agent must guess at the identifier contract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

First sentence gives a concrete verb + resource + consequence: 'say an item does not interest you, so similar ones rank lower in future.' That is unambiguous. It does not name the sibling it is the inverse of (focus_keep) or distinguish itself from focus_safe/focus_explore, so it stops short of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The trigger condition is clear enough ('say an item does not interest you'), which implies when to call it. But there is no explicit routing to alternatives — nothing says 'use focus_keep to reverse this' or when to prefer focus_safe vs focus_decline, despite several closely related focus_* siblings in the same group.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools