Skip to main content
Glama

Get news entry

get_news
Read-onlyIdempotent

Read the full OpenProject news entry, including markdown body and metadata, by providing its numeric ID. Ideal after a summary, to access complete content and edit permissions.

Instructions

Read one news entry in full, including the markdown body.

Use it after list_news when the summary is not enough — this adds description, the announcement's complete text as markdown (html is dropped), plus updated_at.

Returns {id, title, summary, description, project, author, created_at, updated_at, can_manage}. author is the account that published the entry and cannot be changed; can_manage says whether editing or deleting it would be permitted.

Pitfalls: a 404 here means "no such entry, or you may not read news in its project" — the news module is enabled per project, so a missing entry is not always a wrong id. Comments people left on the announcement are not exposed by API v3 and are not included.

Cross-references: list_news produces the id; update_news changes the text; delete_news removes the entry for good.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
news_idYesNumeric news id from list_news. It is the same id as in the UI's /news/{id} URL; the headline is not an id.

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?

The description discloses several behavioral traits beyond the readOnlyHint annotation: it returns specific fields, 'author' cannot be changed, 'can_manage' indicates edit/delete permission, HTML is dropped, and comments are not exposed. This provides rich context not available from annotations alone.

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?

The description is longer than average but well-structured: it opens with the core purpose, then covers return value, pitfalls, and cross-references. Every sentence adds valuable information, and the front-loading makes it easy to scan.

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 simple read operation with one parameter, the description is complete. It covers return fields, permission hints, error semantics, and exclusions. Since an output schema exists, the description need not explain return values in detail, but it does so anyway, making it self-sufficient.

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?

The schema already fully describes the only parameter news_id, including its numeric type and source from list_news. The description reinforces this by saying 'list_news produces the id' but adds no new semantic meaning beyond the schema, so a baseline of 3 is appropriate.

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?

The description starts with 'Read one news entry in full, including the markdown body,' which clearly states the action and resource. It also distinguishes from siblings by noting it is used after list_news and that update_news/delete_news are cross-references.

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 after list_news when the summary is not enough.' It also provides alternatives (update_news, delete_news) and includes a pitfall about 404 semantics, which helps avoid misuse.

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