Skip to main content
Glama
midnight480

saga-event-space-mcp-server

by midnight480

list_announcements

Get event space announcements filtered by level and active status. Specify criteria to retrieve relevant updates.

Instructions

お知らせの一覧を取得します。レベルやアクティブ状態で絞り込みが可能です。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
levelNoお知らせレベルで絞り込み
limitNo取得件数
offsetNoオフセット
active_onlyNoアクティブなお知らせのみ表示(true/false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates filtering by level and active status, which is already visible in the input schema, and does not disclose default active_only behavior, ordering, pagination limits, authorization needs, or response shape. It is not misleading, but it adds minimal behavioral context.

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 a single front-loaded sentence that states the core purpose first and then the key filtering capability. There is no filler or redundant wording.

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

Completeness3/5

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

The tool is a simple read/list operation with fully documented parameters, so the description is mostly functional. However, with no output schema and no annotations, it omits useful context such as returned fields, default values for active_only/limit, and maximum page size, which prevents it from being fully 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?

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds little beyond echoing the level and active_only filters and does not clarify defaults, value semantics for active_only, or pagination constraints.

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 clearly states the action ('一覧を取得します' – retrieves a list) and the resource ('お知らせ' – announcements), and mentions available filters. This unambiguously distinguishes it from sibling write operations like create_announcement/update_announcement/delete_announcement and from list_release_notes.

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

Usage Guidelines3/5

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

The usage context is implied by the resource name and read-style verb, but the description gives no explicit 'when to use' or 'when not to use' guidance. It does not mention alternatives or exclusion criteria, leaving the agent to infer that this is the appropriate read tool for announcements.

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