Skip to main content
Glama

AMZ Vault

by com.amz-vault
OverviewDiscussionsAdmin

Workforce: Report

workforce_report

Submit the results of a workforce packet. Required: task_id (from the packet) and summary (plain-language account of what was done and found). Strongly recommended: headline - ONE sentence (max 200 chars) the owner reads on their Today page: what you found or did, no scope preamble. Optional: findings (structured detail), proposal_ids (anything staged during the packet — these route to the dashboard approval queue), messages (notes to other departments: {to_dept, type, severity, body, scope}).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
summaryYesShort plain-language account of the work.
task_idYesThe packet's task_id.
findingsNoStructured detail backing the summary.
headlineNoOne owner-facing sentence (max 200 chars): the finding or the action, e.g. "Negated 14 zero-order terms; $118/mo of waste stops." No scope or window preamble.
messagesNoCross-department notes: {to_dept, type, severity, body, scope}.
proposal_idsNoStaged-change ids created in this packet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / headline
      Added value: +{
+  "description": "One owner-facing sentence (max 200 chars): the finding or the action, e.g. \"Negated 14 zero-order terms; $118/mo of waste stops.\" No scope or window preamble.",
+  "type": "string"
+}
  2. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations are terse (readOnlyHint=false, destructiveHint=false, openWorldHint=false) and describe no side effects, so the description carries most of the load — and it adds real value by disclosing that proposal_ids route into the dashboard approval queue and that messages are delivered to other departments. It stops short of saying whether submission is idempotent or reversible.

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?

A single dense paragraph that front-loads the required parameters before the optional ones. Efficient, though the inline enumeration of field semantics makes it slightly heavy for a submission tool.

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?

No output schema exists, so the description would ideally say what submission returns, and it does not. However, it does cover required inputs, priority levels, and the downstream effects of the optional routing fields, which is most of what an agent needs for a 6-parameter mutation.

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 already 100%, so a 3 is the baseline, but the description goes further by ranking parameters (required / strongly recommended / optional), restating the 200-char one-sentence constraint on headline with its owner-facing intent, and explaining the routing semantics of proposal_ids and messages.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Submit the results of a workforce packet'), which cleanly distinguishes it from the read-oriented siblings workforce_status and workforce_check_in. It does not explicitly name those siblings, but the action/read split is inferable from the verb.

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?

Implies the context of use (after completing a packet) and prioritizes fields as required/strongly recommended/optional, but never states when to call this versus an alternative or what prerequisite state must hold before submitting. Guidance is implied rather than explicit.

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

All AMZ Vault toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources