Render the daily log for a job as a PDF: each day's entries in the workers' own words with who wrote them, and the photos they attached. Optional from and to dates (inclusive). Core stores the PDF with its sha256 and returns it (base64).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| job_id | Yes | ||
| include_photos | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description still discloses meaningful behavior beyond the name: the output is a rendered PDF, Core persists it with a sha256, and the payload comes back base64-encoded, which signals a potentially large response. It omits authorization requirements and delivery constraints (e.g., size limits, whether the stored artifact is retrievable later), keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler: purpose and contents first, then the date filter, then the storage/return mechanism. Every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, the description usefully explains the return form (base64 PDF) and the storage side effect. Gaps remain: no mention of permissions or failure modes (invalid job, empty date range), no note on response size practicality, and the unresolved include_photos behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning, but it only clarifies from/to as optional and inclusive. include_photos is never explained — the prose says the PDF contains "the photos they attached," leaving it ambiguous whether that flag defaults on or what omitting it does; job_id and date-format expectations are also unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource ("Render the daily log for a job as a PDF") and specifies exactly what the artifact contains: per-day entries in workers' own words, author attribution, and attached photos. It is readily distinguishable from sibling document tools such as documents_photoReport, documents_get, and documents_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (a single job's daily log, optionally date-bounded) but never says when to prefer this over documents_photoReport, documents_get, or documents_list, nor any prerequisites such as job existence or permissions. The only explicit guidance is that from/to are optional and inclusive, which is filtering guidance rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.