Skip to main content
Glama
SVerITG

Metis

by SVerITG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Metis · News Radar — Generate Daily Insight

generate_daily_insight

Prepares the writing instructions and source context needed to draft a daily, weekly, or catchup brief, returning the exact save call and date key for later storage.

Instructions

Prepare everything needed to write a brief: the writing recipe and the context.

The session half of the daily-brief round-trip, for machines whose dashboard
cannot call the API itself. Returns the SAME instructions and the SAME
context the dashboard's own generator uses (metis_mcp.tools.brief_prompt and
assemble_*_context), so a brief written here reads like one written there:
continuous prose, the freshness contract, and a coverage footer that keeps
tomorrow's brief from repeating today's lead. Write the brief by following
the instructions exactly, then pass it, footer included, to save_daily_brief
with the date key this returns.

Args:
    period: "daily" (default), "weekly", or "catchup".

Returns:
    The writing instructions, the context, and the exact save call to make.

Input Schema

NameRequiredDescriptionDefault
periodNodaily

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.5
    • addedInput schema / properties / period
      Added value: +{
+  "default": "daily",
+  "title": "Period",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it states that the tool returns writing instructions, context, and the exact save call, and clarifies that it prepares rather than saves. It also discloses that the output mirrors the dashboard generator so the brief reads consistently. Auth and rate-limit behavior are not disclosed, but the essential behavioral contract is present.

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 core action and structured as a workflow from generation to save. It is somewhat verbose, especially the parenthetical implementation module names, but the detail is mostly useful for a non-trivial round-trip tool.

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?

Complete for a one-parameter tool with an output schema. The description covers purpose, usage context, return contents, and the exact next step, so an agent has enough to invoke it and understand the resulting artifacts.

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 coverage is 0%, so the description must compensate. It does by documenting the single period parameter's default ("daily") and allowed values ("weekly", "catchup"), though it does not explain the semantic difference between weekly and catchup.

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 and resource: "Prepare everything needed to write a brief: the writing recipe and the context." It distinguishes itself as the "session half" of the daily-brief round-trip and names save_daily_brief as the downstream tool, so an agent can tell it apart from save_daily_brief and get_daily_insight.

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

Usage Guidelines4/5

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

Explains the context for use: machines whose dashboard cannot call the API itself, and gives the exact next step of passing the written brief to save_daily_brief with the returned date key. It does not explicitly contrast with get_daily_insight or get_briefing_coverage, but the workflow is clear.

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

Deploy Server

Other Tools