Skip to main content
Glama

Update news

update_news

Correct or rewrite a published news entry: fix a headline, refresh a weekly report, or clear a stale teaser with targeted field updates.

Instructions

Correct or rewrite a published news entry.

Use it to fix a headline, refresh a weekly report in place, or clear a stale teaser. Only the parameters you pass are sent, so a concurrent edit to another field survives.

Returns the updated entry in the same shape as get_news.

Pitfalls: summary and description REPLACE the stored text — there is no append. The entry's project and author are fixed at creation and cannot be updated here; publish a new entry instead. News carries no lockVersion upstream, so there is nothing to echo and no lock parameter: a simultaneous edit by somebody else is silently overwritten, which is why reading with get_news first is worth it. The 'manage news' permission is required, so a 403 is about the account or a disabled news module.

Cross-references: get_news for the current text and for can_manage; delete_news when the entry should disappear entirely; create_news to publish a follow-up instead of rewriting history.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoNew headline, up to 256 characters. Omit to leave it alone; it cannot be cleared, because news requires a title.
news_idYesNumeric news id from list_news or get_news.
summaryNoNew teaser (plain text, up to 255 characters); REPLACES the existing one. Pass null or an empty string to clear it. Omit the parameter entirely (the default) to leave it untouched.__unchanged__
descriptionNoNew markdown body; REPLACES the existing text rather than appending to it, so read the current one with get_news first if you mean to extend it. Pass null or an empty string to clear it. Omit to leave it untouched.__unchanged__

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoNews id — what get_news, update_news and delete_news consume.
titleNoHeadline of the announcement.
authorNoUser who published it ({id, name}); set by the server.
projectNoProject the announcement belongs to ({id, name}).
summaryNoShort teaser OpenProject shows under the headline; may be empty. The full body is NOT here — read it with get_news(news_id=...).
can_manageNoTrue when this account may change or delete this entry (OpenProject renders the update/delete links only with the 'manage news' permission). False means update_news and delete_news would fail with 403.
created_atNoISO 8601 UTC publication timestamp.
updated_atNoISO 8601 UTC timestamp.
descriptionNoThe announcement body as markdown (raw); html is dropped. Empty string when the entry has only a headline and summary.
Behavior5/5

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

Discloses important behaviors beyond annotations: partial-update semantics, summary/description replace rather than append, no lockVersion leading to silent overwrites, and required 'manage news' permission with 403 interpretation. This adds rich context not covered by readOnlyHint/idempotentHint flags.

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

Conciseness5/5

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

Well-structured and front-loaded: the main purpose appears first, followed by use cases, pitfalls, and cross-references. Every sentence adds value, and the length is appropriate given the complexity of the tool's behavior.

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?

Despite having an output schema (so return format need not be detailed), the description covers concurrency, replacement semantics, fixed fields, permission requirements, and related tools. It is complete for a complex update operation.

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

Parameters4/5

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

Schema covers 100% of parameters with detailed meanings, so the baseline is 3. The description adds extra context about partial-parameter transmission and the absence of a lock parameter, enhancing understanding beyond the schema, but the schema already carries most of the burden.

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?

Begins with 'Correct or rewrite a published news entry,' giving a specific verb and resource. The description lists concrete use cases (fix headline, refresh report, clear teaser) and cross-references get_news, delete_news, and create_news, clearly distinguishing it from sibling tools.

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?

Explicitly states when to use ('Use it to fix a headline...') and when not to: project/author cannot be changed (publish a new entry), delete_news for removal, create_news for follow-ups. This gives clear context and explicit alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kar-thik/openproject-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server