Weekly client reports: accomplishments, hours, blockers. Free.
Scored across 4 tools
The two report-building tools (create_weekly_report and render_report_text) could be confused because they share inputs and purpose, but explicit 'Do NOT use' notes clarify their distinct outputs. report_templates and week_bounds are clearly separate utilities.
All names use snake_case, but the verb style is mixed: create_weekly_report and render_report_text start with verbs, while report_templates and week_bounds are noun phrases. This is readable but not a consistent verb_noun pattern.
Four tools is well within the ideal 3–15 range for a focused report generation utility. Each tool serves a distinct purpose (build structured, render text, list templates, compute week bounds) without redundancy.
The surface covers structured and text report generation, template listing, and date calculation, which are the core needs. A minor gap is that report_templates lists layouts but no tool lets you apply a specific template when creating a report, though this may be outside scope.
Build a structured weekly client report (report ID, week start/end, accomplishments, hours, blockers, next-week plan) as data fields. Nothing is stored. Use when the report data will be processed or shown as fields. Do NOT use for a ready-to-send text version; use render_report_text.
| Name | Required | Description | Default |
|---|---|---|---|
| blockers | No | Open issues blocking progress, one per entry, e.g. ["Waiting on API review"]. Default none. | |
| next_week | No | Planned tasks for next week, one per entry. Default none. | |
| week_start | Yes | First day of the reported week, YYYY-MM-DD (normally the Monday; use week_bounds to find it), e.g. 2026-09-28. The week ends 6 days later. | |
| client_name | Yes | Client the report is for, e.g. "Globex" | |
| hours_logged | No | Total hours worked this week, >= 0, e.g. 32. Omit if not tracked. | |
| accomplishments | Yes | What was done this week, one short item per entry (at least one), e.g. ["Shipped login", "Fixed 3 bugs"] |
| Name | Required | Description |
|---|---|---|
| blockers | Yes | Blockers (empty array if none). |
| week_end | Yes | Week end date, week_start + 6 days, YYYY-MM-DD. |
| next_week | Yes | Next-week plan items (empty array if none). |
| report_id | Yes | Report identifier, WR-YYYYMMDD-NNNN. |
| week_start | Yes | Week start date as given, YYYY-MM-DD. |
| client_name | Yes | Client name as given. |
| hours_logged | Yes | Hours logged, or null when not provided. |
| accomplishments | Yes | Accomplishments as given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a genuinely non-redundant behavioral fact — 'Nothing is stored' — clarifying this is a pure computation with no persistence, which the annotations do not convey. It stops short of noting any auth or rate-limit behavior, so it is strong but not exhaustive.
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?
Three sentences, front-loaded with the core action and output shape, followed by the usage condition and the negative routing. No filler, no repetition of schema detail.
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?
An output schema exists, so return values need not be described, and the description covers purpose, field structure, persistence behavior, and sibling routing. For a 6-parameter creation tool with full schema coverage, nothing an agent needs to call it correctly is missing.
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 100%: every parameter has its own description with format, examples, and defaults (e.g. week_start pattern and 'use week_bounds to find it', hours_logged 'Omit if not tracked'). The description only restates the field list, adding no syntax or format meaning beyond the schema, so the baseline of 3 applies.
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 precise verb+resource ('Build a structured weekly client report') and enumerates the exact fields produced (report ID, week start/end, accomplishments, hours, blockers, next-week plan). It also explicitly distinguishes itself from the sibling render_report_text, so an agent can choose without opening either schema.
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?
Gives both a positive trigger ('Use when the report data will be processed or shown as fields') and an explicit exclusion with the alternative named ('Do NOT use for a ready-to-send text version; use render_report_text'). This is textbook when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a weekly client report from the same inputs as create_weekly_report and return it as plain text (header, accomplishments, hours, blockers, next week) ready to paste into an email or chat. Use when the user wants a readable report to send. Do NOT use when structured fields are needed; use create_weekly_report.
| Name | Required | Description | Default |
|---|---|---|---|
| blockers | No | Open issues blocking progress, one per entry, e.g. ["Waiting on API review"]. Default none. | |
| next_week | No | Planned tasks for next week, one per entry. Default none. | |
| week_start | Yes | First day of the reported week, YYYY-MM-DD (normally the Monday; use week_bounds to find it), e.g. 2026-09-28. The week ends 6 days later. | |
| client_name | Yes | Client the report is for, e.g. "Globex" | |
| hours_logged | No | Total hours worked this week, >= 0, e.g. 32. Omit if not tracked. | |
| accomplishments | Yes | What was done this week, one short item per entry (at least one), e.g. ["Shipped login", "Fixed 3 bugs"] |
| Name | Required | Description |
|---|---|---|
| text | Yes | The weekly report rendered as multi-line plain text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds real behavioral value by disclosing that inputs are shared with create_weekly_report and that output is formatted text with fixed sections, though it omits any note on rendering/formatting failure modes or length limits.
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 sentences, front-loaded with what is produced before the usage routing. Every clause earns its place: format, use case, exclusion, alternative.
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?
An output schema exists, so return-value structure is handled, and the description still sketches the text sections. Annotations cover the safety/idempotency profile, params are fully documented, and the sibling routing is explicit — an agent has everything needed to call it correctly.
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 100% with 6 documented parameters, so the schema carries the semantics (formats, defaults, required items). The description only notes inputs mirror create_weekly_report, adding no per-parameter meaning; baseline 3 applies.
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 specific verb (build/render) and resource (weekly client report) plus the exact output artifact (plain text with header, accomplishments, hours, blockers, next week). It explicitly distinguishes itself from create_weekly_report, so an agent can route between them without opening either schema.
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?
Gives the positive condition (user wants a readable report to send/paste into email or chat) and the negative condition (Do NOT use when structured fields are needed), naming the alternative create_weekly_report. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the built-in report layouts (freelancer weekly, agency client update, standup digest) and the sections each one covers. Use when the user asks what report styles exist or which sections to include. Do NOT use to build a report; use create_weekly_report or render_report_text.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| templates | Yes | Built-in report templates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the layouts are built-in and that section coverage is returned, which is useful but modest; it discloses no additional operational traits such as caching or refresh behavior. With annotations carrying the safety burden, a 3 is appropriate.
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?
Three short sentences: what it returns, when to use it, when not to and what to use instead. Front-loaded with the resource and zero wasted words.
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 no-parameter read-only listing tool with an output schema already documenting the return shape, the description supplies everything needed: the content returned, the trigger, and the routing to the correct sibling for report generation.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies no inputs are required.
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?
Specific verb (List) plus resource (built-in report layouts) with concrete examples of the layouts and a statement of what each entry covers (sections). It is clearly distinguishable from the sibling build/render tools 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit positive trigger (user asks what report styles exist or which sections to include) and an explicit negative trigger with named alternatives (do NOT use to build a report; use create_weekly_report or render_report_text). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Monday-to-Sunday week containing a given date (UTC). Use to turn a date like 'Oct 2' into the week_start for a report. Do NOT use to build the report itself; use create_weekly_report or render_report_text.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Any date in the week, YYYY-MM-DD, e.g. 2026-10-02 |
| Name | Required | Description |
|---|---|---|
| week_end | Yes | Sunday of that week, YYYY-MM-DD. |
| week_start | Yes | Monday of that week, YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, providing safety profile. The description adds the crucial UTC timezone context, which affects behavior. However, it doesn't describe output format or edge cases (e.g., handling of invalid dates), so it's not fully complete.
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 sentences, zero waste. The core purpose is front-loaded, followed by usage guidance and exclusions. Every sentence earns its place.
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?
A complete definition for a simple, single-parameter tool with full schema coverage and annotations. The presence of an output schema means return values need not be detailed. The description covers purpose, usage, and exclusion cases adequately.
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 coverage is 100%, so the schema fully documents the single parameter (date with format and example). The description mentions 'given date (UTC)' but adds no syntactic or semantic details beyond what the schema provides. Baseline 3 is appropriate.
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 specific verb ('return'), resource ('Monday-to-Sunday week'), and scope ('containing a given date (UTC)'). The description clearly distinguishes this tool from siblings by naming create_weekly_report and render_report_text.
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?
Explicitly states when to use ('turn a date like 'Oct 2' into the week_start for a report') and when not to ('Do NOT use to build the report itself'), naming alternative tools. This leaves no ambiguity for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_weekly_report11 fields changedInput schema / properties / accomplishments / descriptionPrevious value: -"A list of accomplishments achieved during the week"New value: +"What was done this week, one short item per entry (at least one), e.g. [\"Shipped login\", \"Fixed 3 bugs\"]"Input schema / properties / accomplishments / minItemsAdded value: +1Input schema / properties / blockers / descriptionPrevious value: -"A list of issues or obstacles encountered during the week"New value: +"Open issues blocking progress, one per entry, e.g. [\"Waiting on API review\"]. Default none."Input schema / properties / client_name / descriptionPrevious value: -"The name of the client for whom the report is being generated"New value: +"Client the report is for, e.g. \"Globex\""Input schema / properties / client_name / minLengthAdded value: +1Input schema / properties / hours_logged / descriptionPrevious value: -"The total number of hours worked during the week"New value: +"Total hours worked this week, >= 0, e.g. 32. Omit if not tracked."Input schema / properties / hours_logged / minimumAdded value: +0Input schema / properties / next_week / descriptionPrevious value: -"A list of tasks planned for the next week"New value: +"Planned tasks for next week, one per entry. Default none."Input schema / properties / week_start / descriptionPrevious value: -"The start date of the week in YYYY-MM-DD format"New value: +"First day of the reported week, YYYY-MM-DD (normally the Monday; use week_bounds to find it), e.g. 2026-09-28. The week ends 6 days later."Input schema / properties / week_start / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "accomplishments": {
+ "description": "Accomplishments as given.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "blockers": {
+ "description": "Blockers (empty array if none).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "client_name": {
+ "description": "Client name as given.",
+ "type": "string"
+ },
+ "hours_logged": {
+ "description": "Hours logged, or null when not provided.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "next_week": {
+ "description": "Next-week plan items (empty array if none).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "report_id": {
+ "description": "Report identifier, WR-YYYYMMDD-NNNN.",
+ "type": "string"
+ },
+ "week_end": {
+ "description": "Week end date, week_start + 6 days, YYYY-MM-DD.",
+ "type": "string"
+ },
+ "week_start": {
+ "description": "Week start date as given, YYYY-MM-DD.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "report_id",
+ "client_name",
+ "week_start",
+ "week_end",
+ "accomplishments",
+ "hours_logged",
+ "blockers",
+ "next_week"
+ ],
+ "type": "object"
+}render_report_text11 fields changedInput schema / properties / accomplishments / descriptionPrevious value: -"A list of accomplishments achieved during the week"New value: +"What was done this week, one short item per entry (at least one), e.g. [\"Shipped login\", \"Fixed 3 bugs\"]"Input schema / properties / accomplishments / minItemsAdded value: +1Input schema / properties / blockers / descriptionPrevious value: -"A list of issues or obstacles encountered during the week"New value: +"Open issues blocking progress, one per entry, e.g. [\"Waiting on API review\"]. Default none."Input schema / properties / client_name / descriptionPrevious value: -"The name of the client for whom the report is being generated"New value: +"Client the report is for, e.g. \"Globex\""Input schema / properties / client_name / minLengthAdded value: +1Input schema / properties / hours_logged / descriptionPrevious value: -"The total number of hours worked during the week"New value: +"Total hours worked this week, >= 0, e.g. 32. Omit if not tracked."Input schema / properties / hours_logged / minimumAdded value: +0Input schema / properties / next_week / descriptionPrevious value: -"A list of tasks planned for the next week"New value: +"Planned tasks for next week, one per entry. Default none."Input schema / properties / week_start / descriptionPrevious value: -"The start date of the week in YYYY-MM-DD format"New value: +"First day of the reported week, YYYY-MM-DD (normally the Monday; use week_bounds to find it), e.g. 2026-09-28. The week ends 6 days later."Input schema / properties / week_start / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "text": {
+ "description": "The weekly report rendered as multi-line plain text.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text"
+ ],
+ "type": "object"
+}report_templates1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "templates": {
+ "description": "Built-in report templates.",
+ "items": {
+ "properties": {
+ "id": {
+ "description": "Template id, e.g. freelancer-weekly.",
+ "type": "string"
+ },
+ "name": {
+ "description": "Human-readable template name.",
+ "type": "string"
+ },
+ "sections": {
+ "description": "Sections the template covers, in order.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "sections"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "templates"
+ ],
+ "type": "object"
+}week_bounds3 fields changedInput schema / properties / date / descriptionPrevious value: -"The date in YYYY-MM-DD format."New value: +"Any date in the week, YYYY-MM-DD, e.g. 2026-10-02"Input schema / properties / date / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "week_end": {
+ "description": "Sunday of that week, YYYY-MM-DD.",
+ "type": "string"
+ },
+ "week_start": {
+ "description": "Monday of that week, YYYY-MM-DD.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "week_start",
+ "week_end"
+ ],
+ "type": "object"
+}create_weekly_report1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "accomplishments": {
- "description": "List of accomplishments for the week.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "blockers": {
- "description": "List of blockers encountered during the week.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "client_name": {
- "description": "The name of the client for whom the report is generated.",
- "type": "string"
- },
- "hours_logged": {
- "description": "Total hours logged for the week.",
- "type": "number"
- },
- "next_week": {
- "description": "List of plans for the next week.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "report_id": {
- "description": "Unique identifier for the generated report.",
- "type": "string"
- },
- "report_text": {
- "description": "The formatted text of the weekly report.",
- "type": "string"
- },
- "week_start": {
- "description": "The start date of the week for which the report is generated.",
- "type": "string"
- }
- },
- "required": [
- "report_id",
- "client_name",
- "week_start",
- "accomplishments",
- "report_text"
- ],
- "type": "object"
-}New value: +nullrender_report_text1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "accomplishments": {
- "description": "The list of accomplishments for the week.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "blockers": {
- "description": "The list of blockers encountered during the week.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "client_name": {
- "description": "The name of the client for whom the report is generated.",
- "type": "string"
- },
- "hours_logged": {
- "description": "The total hours logged for the week.",
- "type": "number"
- },
- "next_week": {
- "description": "The list of tasks planned for the next week.",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "report_text": {
- "description": "The generated plain text report.",
- "type": "string"
- },
- "week_start": {
- "description": "The start date of the week covered by the report.",
- "type": "string"
- }
- },
- "required": [
- "report_text",
- "client_name",
- "week_start",
- "accomplishments"
- ],
- "type": "object"
-}New value: +nullreport_templates1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "results": {
- "description": "List of report templates entries.",
- "items": {
- "properties": {
- "created_at": {
- "description": "Timestamp when the template was created",
- "format": "date-time",
- "type": "string"
- },
- "description": {
- "description": "Brief description of the report template",
- "type": "string"
- },
- "template_id": {
- "description": "Unique identifier for the report template",
- "type": "string"
- },
- "template_name": {
- "description": "Name of the report template",
- "type": "string"
- },
- "template_type": {
- "description": "Type of the report template (e.g., freelancer, agency, standup)",
- "type": "string"
- },
- "updated_at": {
- "description": "Timestamp when the template was last updated",
- "format": "date-time",
- "type": "string"
- }
- },
- "required": [
- "template_id",
- "template_name",
- "template_type"
- ],
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "results"
- ],
- "type": "object"
-}New value: +nullweek_bounds1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "endDate": {
- "description": "The end date of the week (Sunday) in YYYY-MM-DD format.",
- "type": "string"
- },
- "startDate": {
- "description": "The start date of the week (Monday) in YYYY-MM-DD format.",
- "type": "string"
- }
- },
- "required": [
- "startDate",
- "endDate"
- ],
- "type": "object"
-}New value: +nullcreate_weekly_report7 fields changedInput schema / properties / accomplishments / descriptionAdded value: +"A list of accomplishments achieved during the week"Input schema / properties / blockers / descriptionAdded value: +"A list of issues or obstacles encountered during the week"Input schema / properties / client_name / descriptionAdded value: +"The name of the client for whom the report is being generated"Input schema / properties / hours_logged / descriptionAdded value: +"The total number of hours worked during the week"Input schema / properties / next_week / descriptionAdded value: +"A list of tasks planned for the next week"Input schema / properties / week_start / descriptionAdded value: +"The start date of the week in YYYY-MM-DD format"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "accomplishments": {
+ "description": "List of accomplishments for the week.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "blockers": {
+ "description": "List of blockers encountered during the week.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "client_name": {
+ "description": "The name of the client for whom the report is generated.",
+ "type": "string"
+ },
+ "hours_logged": {
+ "description": "Total hours logged for the week.",
+ "type": "number"
+ },
+ "next_week": {
+ "description": "List of plans for the next week.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "report_id": {
+ "description": "Unique identifier for the generated report.",
+ "type": "string"
+ },
+ "report_text": {
+ "description": "The formatted text of the weekly report.",
+ "type": "string"
+ },
+ "week_start": {
+ "description": "The start date of the week for which the report is generated.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "report_id",
+ "client_name",
+ "week_start",
+ "accomplishments",
+ "report_text"
+ ],
+ "type": "object"
+}render_report_text7 fields changedInput schema / properties / accomplishments / descriptionAdded value: +"A list of accomplishments achieved during the week"Input schema / properties / blockers / descriptionAdded value: +"A list of issues or obstacles encountered during the week"Input schema / properties / client_name / descriptionAdded value: +"The name of the client for whom the report is being generated"Input schema / properties / hours_logged / descriptionAdded value: +"The total number of hours worked during the week"Input schema / properties / next_week / descriptionAdded value: +"A list of tasks planned for the next week"Input schema / properties / week_start / descriptionAdded value: +"The start date of the week in YYYY-MM-DD format"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "accomplishments": {
+ "description": "The list of accomplishments for the week.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "blockers": {
+ "description": "The list of blockers encountered during the week.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "client_name": {
+ "description": "The name of the client for whom the report is generated.",
+ "type": "string"
+ },
+ "hours_logged": {
+ "description": "The total hours logged for the week.",
+ "type": "number"
+ },
+ "next_week": {
+ "description": "The list of tasks planned for the next week.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "report_text": {
+ "description": "The generated plain text report.",
+ "type": "string"
+ },
+ "week_start": {
+ "description": "The start date of the week covered by the report.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "report_text",
+ "client_name",
+ "week_start",
+ "accomplishments"
+ ],
+ "type": "object"
+}report_templates1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "results": {
+ "description": "List of report templates entries.",
+ "items": {
+ "properties": {
+ "created_at": {
+ "description": "Timestamp when the template was created",
+ "format": "date-time",
+ "type": "string"
+ },
+ "description": {
+ "description": "Brief description of the report template",
+ "type": "string"
+ },
+ "template_id": {
+ "description": "Unique identifier for the report template",
+ "type": "string"
+ },
+ "template_name": {
+ "description": "Name of the report template",
+ "type": "string"
+ },
+ "template_type": {
+ "description": "Type of the report template (e.g., freelancer, agency, standup)",
+ "type": "string"
+ },
+ "updated_at": {
+ "description": "Timestamp when the template was last updated",
+ "format": "date-time",
+ "type": "string"
+ }
+ },
+ "required": [
+ "template_id",
+ "template_name",
+ "template_type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}week_bounds2 fields changedInput schema / properties / date / descriptionAdded value: +"The date in YYYY-MM-DD format."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "endDate": {
+ "description": "The end date of the week (Sunday) in YYYY-MM-DD format.",
+ "type": "string"
+ },
+ "startDate": {
+ "description": "The start date of the week (Monday) in YYYY-MM-DD format.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "startDate",
+ "endDate"
+ ],
+ "type": "object"
+}create_weekly_reportrender_report_textreport_templatesweek_boundsWeekly client reports: change, % change, targets, status, printable page and email text. Free.
Free client billing for consultants and small agencies. Your AI assistant logs hours, timers and expenses, creates invoices and records payments, and Otis keeps the records, numbering and totals correct.
Freelance business manager — clients, proposals, invoices, time tracking, scope, and follow-ups.
Free time tracking for teams: log hours in plain words, run timers, see where your time went.
Add one secure layer between your agents and this server.
