Skip to main content
Glama

Report task: keep a page updated on schedule

report_task

Report task: keep one page updated on a schedule (daily, weekdays or weekly) at the same link, with the new version pushed to WeChat. When the author says what to cover, what time, who can view and who to notify, call action=create (add trial=true to run one trial right away; without proposal_id a new page is created, so pass title). A trial usually takes 5–15 minutes; the author is notified in WeChat and only the author can see the result. When the author has looked and says to switch it on, call action=enable — a successful trial is required first, and by default that trial becomes the page’s first version. Afterwards use update for the time, the request, an extra line (request_append), who can view or who is notified — pass only what changes; pause (optionally until=a date, resuming that day), resume, delete, list, trial to run another trial, and runs when the author asks whether it went out on time or why one did not. Every action returns say: a sentence to relay to the author as-is; do not invent facts. Ask the author before switching to passcode or public. Speak times in the author’s local clock.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNocreate 且新建一页时:这一页的名字,例如「24好玩 · 行业日报」
trialNocreate:建好立刻试跑一次
untilNopause:暂停到哪天(YYYY-MM-DD,作者当地日期),那天的钟点自动恢复;不给就一直暂停到说「恢复」
actionYescreate 建 · trial 试跑 · enable 开启 · update 改设置 · pause 暂停 · resume 恢复 · delete 删除 · list 看有哪些 · runs 看每一次发了没有
notifyNo新版本发出后提醒谁;缺省三项都提醒
requestNo作者的要求,一段大白话:要看什么、多少条、什么不要。最多 800 字。update 时整段替换
task_idNo要操作的报告任务(create / list 不用;不知道就先 list)
scheduleNo时间表;update 时只传要改的那几项
templateNo用法模板,缺省 daily-brief(行业日报)
visibilityNo谁能看:private 仅工作区成员(缺省)· passcode 凭口令 · public 所有人。改成后两种之前先问作者
proposal_idNocreate:更新哪一页;不给就新建一页
request_appendNoupdate:在原要求后面补一句,不替换原文
publish_trial_as_first_versionNoenable:把最近一次整理成了的试跑发成这一页的新版本(缺省 true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only supply the generic safety profile (non-readonly, non-destructive, non-idempotent), but the description adds real behavioral context: a trial takes 5-15 minutes, only the author sees the trial result, every action returns a 'say' sentence to relay verbatim, and the author must be consulted before passcode/public. The local-clock instruction and 'do not invent facts' rule further constrain behavior beyond structured fields.

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-loads the purpose and covers nine actions plus lifecycle in a single dense paragraph with no filler sentence. It would read more clearly as a short bulleted lifecycle, but every clause carries information useful for correct invocation.

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

Completeness4/5

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

For a nine-action, thirteen-parameter tool with no output schema, it covers the create→trial→enable→manage lifecycle, prerequisites, and the 'say' return contract. The only residual gap is that the full task_id workflow (list-then-operate) is implied rather than spelled out, though the schema notes it.

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 100%, so the baseline is 3, but the description adds real meaning: proposal_id absent means a new page (so title is needed), update takes only what changes, request_append adds rather than replaces, and until resumes on the given date. These clarify usage of key parameters beyond their schema descriptions.

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 (keep one page updated on a schedule at the same link, pushed to WeChat) and enumerates the full action set. An agent can distinguish this from siblings like push_to_wechat or publish_version without opening any schema.

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?

Gives explicit when-to-use mapping for essentially every action: create when the author specifies coverage/time/visibility/notify, enable only after a successful trial, update for later changes, runs when the author asks whether it went out. Prerequisites (a successful trial is required first) and the passcode/public confirmation rule are stated outright.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources