Skip to main content
Glama

Delete comment or Note

delete_comment
Destructive

Delete a comment, Note, or Note reply you wrote on Substack. Removes your own content while leaving others' replies intact; use remove_comment to delete comments on your own posts.

Instructions

Delete one of your own comments, Notes or Note replies.

Deletes something you wrote: a comment under a post, a Note or a reply to a Note. Replies other people wrote under it stay, under a deleted placeholder. Someone else's comment returns an error; on your own posts remove it with remove_comment.

Input Schema

NameRequiredDescriptionDefault
comment_idYesID of your comment, Note or Note reply.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, so the description doesn't need to restate permanence. Instead it adds genuinely new behavior: other people's replies survive under a deleted placeholder, and deleting another user's comment fails with an error. That post-deletion state and failure mode are unavailable anywhere in the structured fields.

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

Conciseness4/5

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

Front-loaded with the action and short overall. The middle sentence ('Deletes something you wrote: a comment under a post, a Note or a reply to a Note') largely re-enumerates what sentence one already listed, a small redundancy that keeps it out of the top band.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter destructive delete with annotations covering the safety profile and no output schema, the description supplies everything an agent needs: ownership precondition, error case, child-object outcome, and the sibling to use instead.

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

Parameters3/5

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

Schema coverage is 100% with a single well-described comment_id, so the schema carries the load. The description adds only the ownership constraint ('your own'), which is a marginal but real addition above the schema's neutral 'ID of your comment'.

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

Purpose5/5

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

States a specific verb (Delete) plus the exact resource set — comment, Note, Note reply — and scopes it to 'your own'. An agent can immediately tell this apart from remove_comment, which is named explicitly.

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

Usage Guidelines5/5

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

Explicit when-to-use (things you wrote), when-not (someone else's comment returns an error), and the alternative (use remove_comment on your own posts). This is the full routing pattern with no inference required.

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