Create a new RSS feed entry with optional metadata, media, authors, and lifecycle state; automatically assigns a permanent urn:uuid ID when omitted, enabling deterministic publishing.
Create a definitely-new entry. Generates a permanent urn:uuid ID if omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| entry | Yes | ||
| expected_revision | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that a permanent urn:uuid ID is generated if omitted, which is useful, but it does not disclose what happens when an ID is supplied that already exists, whether creation is idempotent, or any validation or error behavior.
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 a single focused sentence that front-loads the core purpose and adds the most important behavioral detail. There is no filler or redundancy.
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?
The tool has a complex FeedEntry input schema, no annotations, and a sibling set of lifecycle-related tools, so the description should clarify revision semantics, ID-collision behavior, and the relationship to update_entry. None of that is present, leaving an agent under-equipped for correct invocation in non-trivial cases.
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%, so the description must compensate. It adds meaning only for the `id` subfield of `entry` (generation when omitted) and says nothing about `expected_revision` or the overall meaning of the `entry` payload beyond what the schema already names.
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 ('Create') and resource ('entry'), and the qualifier 'definitely-new' clearly distinguishes this from update_entry or republish_entry. It also signals the operation is an insert, not an upsert, which fully disambiguates the tool's core purpose.
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 explicit guidance about when to choose create_entry over update_entry, correct_entry, or republish_entry. The phrase 'definitely-new' implies the tool is for new entries rather than modifications, but no exclusions or alternative routing are stated, leaving an agent to infer the selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.