dismiss_skillDismiss a pending or quarantined skill submission. The skill is marked as dismissed and will not be promoted.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Additional notes | |
| reason | Yes | Reason for dismissal | |
| submission_id | Yes | ID of the skill submission to dismiss |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does state a key outcome ('The skill is marked as dismissed and will not be promoted'), which is more than a bare mutation. However, it lacks details on reversibility, permissions, or what happens to the submission record beyond the status change. This is adequate but not rich, so a 3 is appropriate.
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 two sentences with a clear front-loaded action. The first sentence states the purpose and target, and the second adds a critical consequence. Zero wasted words or redundant phrasing.
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 simple tool with an output schema, the description adequately covers the core behavior and outcome. It identifies the applicable submission states and the finality ('will not be promoted'). It does not explicitly discuss how this differs from retract_skill or what happens to the submission entry, but these are minor gaps. Given the tool's simplicity and schema richness, a 4 is justified.
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 the input schema fully documents all three parameters (submission_id, reason, notes). The description adds no additional parameter-level meaning (e.g., relationship between 'reason' and 'dismissal' process). Per calibration, baseline is 3 when schema coverage is high, and no extra semantics are provided.
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 clearly states the tool's function: 'Dismiss a pending or quarantined skill submission.' It specifies the verb (dismiss), the resource (skill submission), and the applicable states (pending or quarantined). The added consequence 'will not be promoted' differentiates it from sibling tools like promote_skill and retract_skill.
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 description gives clear context for when to use the tool: only for pending or quarantined submissions. However, it does not explicitly name alternative tools or state exclusions (e.g., do not use for already promoted submissions). This is clear context without explicit exclusions or sibling tool references, matching a 4.
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.
Several tools have overlapping purposes: check_claim and memory_claim_check are the same function with different tiers, get_freshness_report and memory_freshness_report are duplicates, get_correction_chain and compare_versions both trace history, and investigate_question subsumes many other retrieval tools. This will cause agent misselection.
Most tools follow a verb_noun pattern (get_constraints, declare_constraint, sync_pull, etc.). Exceptions like memory_claim_check, memory_freshness_report, session_debrief, and verify_before_acting deviate but are relatively few. Overall the naming is readable and mostly predictable.
75 tools is excessive for a memory server. Many are highly niche or direct duplicates (e.g., paid/free versions of the same function). The count far exceeds typical well-scoped servers and introduces cognitive overhead without proportional value.
The server covers a wide array of memory, constraint, decision, skill, and sync operations, which is impressive. However, there are notable gaps: no direct delete or edit for memory facts (only corrections/versioning), and no bulk enumeration of all stored items. The redundancy in retrieval tools also suggests an incomplete design.