Morning (Green Invoice) MCP

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real context beyond that: reads execute immediately while other changes require review and chat confirmation before execution, clarifying the approval workflow this tool participates in.

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 compact sentences with no filler, and the core discovery statement is front-loaded ahead of the workflow notes. Slightly opaque phrasing ('observed native draft endpoints') costs it a point.

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 tool whose behavior hinges on an unexplained 'mode' enum and a 'group' filter, with no output schema and no parameter documentation anywhere, the description is not complete enough for an agent to invoke 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 0% for two parameters, and the description mentions neither 'mode' (enum read/approval/special) nor 'group'. The 'mode' enum in particular is central to behavior and is left entirely unexplained, so the description fails to compensate for the coverage gap.

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?

The verb 'Discover' plus 'reviewed Morning operations: published API plus observed native draft endpoints' gives a rough sense that this lists/retrieves operations, but 'Morning' is undefined jargon and 'discover' is ambiguous (list? describe? enumerate?). It does not clearly distinguish itself from siblings like api_operation_schema or read_morning.

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?

It hints at a workflow ('Reads run immediately; saved editable drafts have a dedicated immediate tool; other changes must be reviewed and confirmed in chat'), which is useful routing context. However, it never names the 'dedicated immediate tool' and gives no explicit when-to-use guidance against the many sibling tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, covering the safety profile. The description adds the useful workflow note that it should be read before advanced requests, but says nothing about the return format or what 'reviewed fields' actually contain.

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 short sentences with no filler, and the retrieval purpose plus the ordering hint are front-loaded. Efficient, though the first sentence is cryptic rather than precise.

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 an openWorld, no-output-schema tool whose only parameter is undocumented, the description is too thin. It neither explains the operationId input nor what the returned schema/requirements contain, leaving the agent under-equipped 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 0% and the single required parameter operationId is entirely undocumented. The description does not mention operationId, its format, or where to obtain it, so it fails to compensate for the schema gap.

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?

The verb is clear ('Get') but the resource is muddled: 'reviewed fields, source and review requirements' does not plainly say it returns an API operation's schema/metadata. An agent can roughly infer it retrieves schema-like info for an operation, but the phrasing is vague and does not clearly distinguish it from the sibling api_operations.

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?

'Read this before advanced requests' is a real, if terse, usage cue establishing a prerequisite/ordering relationship. However it never names the alternative tool (api_operations) or defines what qualifies as an 'advanced request', so the guidance stays 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.

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so "it does not create records" largely restates existing metadata. It does add useful context that the check touches authentication and a read endpoint, but says nothing about failure modes, rate limits, or what the result signifies.

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 short sentences, front-loaded with the core purpose and no filler. Slightly muddled by mixing a purpose statement with a parameter explanation in the same breath.

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 single optional boolean with no output schema, the description covers intent and part of the flag's effect, but omits what the returned status actually tells the agent and when to set verifyMorning=true. Annotations cover the safety profile, so the remaining gap is moderate.

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 0%, so the description must carry the one parameter, and it partially does by explaining that verifyMorning exercises authentication and a read endpoint. It never states what the default (false) path does versus true, leaving the behavior only half specified.

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?

"Check local configuration" gives a verb and a resource, but "local configuration" is vague for something called connection_status and doesn't clearly convey that this reports connectivity/auth state. No sibling is named or distinguished, so the agent must infer how this differs from request_status or read_morning.

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 offers no when-to-use context, no preconditions, and no alternatives among the many sibling status/read tools. The only guidance is an implicit hint about the verifyMorning flag, which is parameter-level rather than usage-level.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered and the description's 'Read' is consistent with it. The description adds the content scope (types and defaults) but says nothing about return format, pagination, or what the integer input represents. With annotations carrying the safety burden, this is adequate but thin.

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 short sentences, zero waste, with the primary purpose front-loaded and the sibling routing second. Nothing could be cut without losing information.

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 one-parameter read tool with no output schema and annotations covering safety, the description gives the general subject matter but omits both the meaning of the required 'type' input and any indication of the shape of what is returned. It is minimally workable but has clear gaps.

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 0% and the single parameter is an untyped-semantics integer named 'type'. The description never explains what this integer identifies (a document type id?) or how it affects the result, so it fails to compensate for the schema gap.

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 ('Read') and resource ('document types and business defaults'), which is more informative than the bare name 'document_options'. It also implicitly distinguishes itself from prepare_morning_action, though the phrase 'business defaults' remains somewhat abstract.

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 names the alternative ('Use prepare_morning_action for full document fields'), giving a condition that routes the agent. It stops short of stating when this tool is the right choice versus the many other document siblings (get_document, search_documents), so it is clear but not exhaustive.

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

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

Annotations already flag this as destructive, non-idempotent, and open-world, but the description adds material context they cannot convey: consent is 'an agent instruction, not enforced by this server,' and content/target changes, expiry, and duplicate/uncertain requests 'remain blocked.' It does not explain what the payloadHash protects against, which would have completed the picture.

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?

Front-loads the core action, then the consent workflow, then the blocking caveats. Every sentence carries weight, though the sequence of terse clauses in the final sentences reads slightly compressed.

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 destructive, non-idempotent, non-reversible mutation with no output schema, the description covers the safety path, consent expectations, and blocked conditions thoroughly. The remaining gap is parameter explanation for the two required fields, which the empty schema does nothing to fill.

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% for two required params, so the schema documents neither id nor payloadHash. The description only hints that the action must be 'exact' and that content/target changes are blocked, indirectly implying that payloadHash validates integrity, but it never defines either parameter or the relationship between them.

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 and resource: 'Execute the exact prepared action directly,' which tells the agent this commits a previously prepared draft. It implies a relationship with preview_document_draft ('show its review and PDF') but never names the sibling tool that produces that review, so differentiation is present but indirect.

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?

Explicit when-to-use and when-not-to-use: show review and PDF, ask for confirmation in chat, wait for an explicit reply, and 'If declined, do not call this tool.' This is an unusually complete procedural gating instruction.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds only the weak qualifier 'existing', and says nothing about behavior when the id does not resolve or what the response contains. With annotations doing the heavy lifting, this is adequate but thin.

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?

A single seven-word sentence with no filler and the essential information front-loaded. Concise, though arguably under-specified rather than optimally sized.

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 one-parameter read tool whose annotations cover the safety profile, the description is minimally sufficient for an agent to call it correctly. It omits not-found behavior and any indication of the returned client shape, which are not covered by an output schema.

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% and the description never mentions the 'id' parameter, so it contributes no meaning beyond the schema's UUID pattern. With a single undocumented parameter and the description silent on it, the description fails to compensate for the coverage gap.

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 (Read) and resource (Morning client), which is enough to distinguish it from sibling write tools like prepare_morning_action or save_document_draft. It does not, however, explicitly differentiate itself from search_clients, the most confusable sibling, or note that it retrieves a single client by identifier.

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?

There is no when-to-use guidance and no mention of alternatives such as search_clients or read_morning. The agent must infer from the name and sibling list that this is the single-entity lookup.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the ambiguous fragment 'download links', which is too vague to clarify whether links are fetched, resolved, or returned in the response — no useful behavioral context beyond the annotations.

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?

It is a single short sentence with no waste, which is appropriate sizing, but the garbled construction 'Read a Morning document and download links' is both compact and unclear, so brevity here does not translate into clarity.

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 read tool with one required, undescribed parameter and no output schema, the description should clarify what is returned (document content, download links, metadata). Instead it leaves both the input semantics and the return behavior undefined, so an agent cannot confidently invoke it.

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 single parameter 'id' has 0% schema description coverage, and the description does not explain what the id refers to (document UUID vs slug) or its expected format. The UUID pattern exists only in the schema, so the description leaves the required parameter semantically unexplained.

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 verb ('Read') and a resource ('a Morning document'), which is better than a tautology, but the trailing phrase 'and download links' is ambiguous — it is unclear whether the tool downloads links or returns them. It also fails to distinguish the tool from siblings like get_document_draft, search_documents, or document_options.

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?

There is no indication of when to use this tool versus get_document_draft, search_documents, or document_options. No prerequisites, no exclusions, and no context about what constitutes a 'Morning document' versus a draft.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact — the ID namespace differs from local approval request IDs — but says nothing about what the returned draft looks like or Morning's access requirements.

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 short, front-loaded sentences with no filler; the core purpose comes first and the ID clarification follows. It is efficient, though the second sentence assumes the reader already knows what an approval request ID is.

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 single-parameter read tool whose annotations carry the safety profile and with no output schema to explain, the description covers purpose and the main ambiguity (ID type). The only residual gap is that it doesn't hint at what the draft read returns.

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% and the single id parameter is only constrained by a UUID regex. The description partially compensates by clarifying that the ID refers to a Morning document draft rather than a local approval request ID, which meaningfully narrows what value to pass, though it gives no format example beyond the schema pattern.

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?

Names a specific verb (Read) and resource (editable document draft saved in Morning), which distinguishes it from siblings like get_document and preview_document_draft. It does not explicitly differentiate itself from those siblings, but the resource plus source qualifier is clear.

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?

No explicit when-to-use guidance or named alternatives (e.g. preview_document_draft, search_document_drafts). The only routing hint is that the ID differs from a local approval request ID, which implies context but does not tell the agent when to pick this tool.

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

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

Annotations only declare the generic write/not-destructive/openWorld=false profile; the description adds real behavioral context: it is a legacy shortcut, it deliberately skips the Morning draft store, it issues/emails nothing, and its request expires in 24 hours. It does not describe what local state is actually created or whether calls are idempotent, which keeps 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?

Six short sentences with zero filler, front-loaded with the 'Legacy shortcut' qualifier and the preferred alternative. Nothing repeats the annotations or schema, and each clause carries a distinct decision-relevant fact.

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 10-parameter write tool with no output schema, the description covers routing, side effects, and request expiry well. The remaining gap is parameter guidance, but the schema does carry the structural constraints (patterns, enums, min/max), and the return-value burden is low since this only builds a local request.

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% across 10 parameters (6 required), and the description supplies no field-level meaning at all — nothing about requestKey, clientId, the 10/300/305 type values, language, or item fields. Only 'PDF' and 'ILS issuance request' hint at what the payload represents; the agent must infer everything else from the raw schema constraints.

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 and resource ('prepare a local ILS issuance request and PDF') and immediately frames its scope ('without saving a draft in Morning'). Explicitly names the siblings that should be preferred instead, so an agent can distinguish it from save_document_draft and prepare_issue_document_draft without reading 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 routing rule: 'Prefer save_document_draft then prepare_issue_document_draft,' plus the downstream step ('Review it before execute_draft'). It also clarifies what this tool does NOT do (no issuance, no email), which is exactly the when-not guidance an agent needs.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is partly covered. The description usefully adds that nothing is uploaded yet and that expenseId changes whether an existing expense is attached or a new draft is parsed, but it does not describe idempotency, permissions, or what the staged artifact looks like.

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 compact sentences, front-loaded with the core action and the 'no upload' caveat. The second clause is dense but every word carries information; no padding.

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?

With no output schema and zero annotation-level detail on returns, the description covers the primary branching behavior but leaves gaps on what 'staged' produces, how requestKey is used, and how the confirmation step is triggered. Adequate but not complete for a 4-param staging tool.

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% for 4 parameters, so the schema carries no meaning at all. The description explains only the optional expenseId semantics (attach to existing expense vs. create a parsed draft); requestKey (likely idempotency), fileId, and title remain undocumented.

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+resource (prepare a staged file) and explicitly scopes it with 'No upload yet', which separates it from a real upload/execute step. It does not, however, distinguish itself from the close sibling stage_expense_file, leaving the agent to infer which staging tool applies.

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?

'For review and chat confirmation' implies this is the first step of a two-phase flow, but no sibling is named and no explicit when-to-use / when-not-to-use guidance is given. The expenseId sentence describes a branch condition rather than when to pick this tool over stage_expense_file or execute_draft.

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

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

Adds substantial context beyond the annotations: 'Nothing issued yet' clarifies the side-effect boundary, it discloses the returned request id/payloadHash, and it states that changes in Morning invalidate the prior preparation. This is valuable, especially with no output schema. It does not contradict the readOnlyHint=false / destructiveHint=false annotations.

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?

Four short sentences, with the core action and the safety caveat ('Nothing issued yet') front-loaded and the freshness rule last. Each sentence carries distinct information with little waste.

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?

The return payload is explained well enough to bridge the missing output schema, and annotations cover the safety profile. However, with 0% parameter documentation and no clarification of how id/title/requestKey are obtained, the definition is not complete for an agent trying to invoke 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 0% across three required parameters (id, title, requestKey), yet the description never explains what any of them mean or where they come from. It references recipients and PDF, but those are not the actual parameters, leaving the agent to infer the UUID/payloadHash wiring from the schema alone.

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+resource: preparing issuance of the current saved Morning draft, including recipients and PDF. An agent can tell this is the pre-issue preparation step, not the actual issuance, and the mention of 'Morning draft' differentiates it from generic document tools. It stops short of explicitly naming sibling alternatives like preview_document_draft or prepare_document.

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?

Clearly routes the agent: use this before execute_draft, only after the user confirms in chat, and re-run it if the Morning draft changes. That gives a concrete workflow position and a freshness condition. It lacks explicit when-NOT-to-use guidance relative to the other prepare/preview siblings.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, covering the safety profile. The description adds genuinely new behavioral context: this is a non-executing preparation step and each change requires a fresh requestKey, which hints at idempotency/replay protection not expressed in the annotations.

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 compact sentences with the core purpose front-loaded and no filler. The entity-type enumeration is somewhat long but earns its place by defining scope.

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 complex two-phase, mutation-capable dispatcher with five nested/opaque parameters and 0% schema coverage, the description covers the essentials (no execution, schema-first, fresh key) but omits anything about what is returned or the shape of body/parameters. No output schema exists, so more could reasonably be said.

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 compensate. It clarifies the requestKey freshness requirement and points to the operation schema for operationId, but leaves title, body, and parameters — the actual write payload — entirely undocumented.

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 (prepare) and the scope of a reviewed write operation, enumerating the entity types it covers (clients, suppliers, items, expenses, documents, payments, charges, merges, deletions). This is clear, though it does not differentiate itself from sibling 'prepare_*' tools like prepare_document or prepare_issue_document_draft.

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?

'No execution. Use the operation schema first' gives an explicit prerequisite and routes the agent to the api_operation_schema sibling, implying execute_draft handles execution. There are no explicit when-not conditions or named alternatives, but the prepare/execute split is inferable.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description usefully adds that nothing is issued or emailed and that output is a local PDF the agent should surface to the user. It does not mention permission requirements, file location, or behavior when the draft is unsaved, which keeps it from 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?

Three short sentences, front-loaded with the action and resource, then the negative scope, then the agent instruction. No filler or restatement of the tool name.

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 single-parameter read-style tool with no output schema, the description covers the action, the non-issue boundary, and what the agent should do with the result. It is only slightly incomplete in not clarifying the id parameter's meaning or the unsaved-draft case.

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% for the single required 'id' parameter, so the description carries the full burden and only hints at it via 'the current saved Morning draft'. It never states that the id is the draft identifier or what happens if it is invalid, so the parameter remains semantically thin.

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?

The description states a specific verb and resource ('Generate a local PDF from the current saved Morning draft') and draws a clear boundary with the issuing/emailing path, which separates it from prepare_issue_document_draft and execute_draft. It stops short of naming those siblings explicitly, so an agent still has to infer which tool handles the issue step.

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?

'Does not issue or email it' functions as an explicit when-not, and 'Show this preview to the user' tells the agent what to do with the result. The phrase 'current saved' draft implies the draft must be saved first, but no alternative tool is named for the issue path, leaving the routing partly implicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the constraint that arbitrary URLs, tokens, headers, or writes are not allowed, which is useful context beyond annotations, but it still does not disclose what the read/preview actually does, what it returns, or its limitations. With annotations carrying the safety profile, this is a modest addition, not rich transparency.

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?

It is a single efficient sentence with no waste, but it is so terse that it omits essential information, so conciseness comes at the cost of under-specification rather than being a virtue.

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 tool with a generic operationId-driven input schema, nested objects, no output schema, and many siblings, the description is far too thin. An agent has no idea what a 'reviewed read/preview' entails, what operationId values are valid, or how this differs from the sibling read and preview tools.

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% for the three parameters (operationId, body, parameters), so the description must carry the burden, yet it never mentions any parameter, its format, or what operationId selects. The mention of 'URLs, tokens, headers' hints at operation shape but does not explain the parameters.

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?

The description says 'Run a reviewed read/preview operation' which gestures at a read/preview capability, but it never states what resource is read or previewed or what 'morning' refers to. It is vague enough that an agent cannot distinguish this tool from siblings like get_document or preview_document_draft.

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?

No when-to-use, when-not-to-use, or alternative is mentioned. The only constraint given is a negative one ('No arbitrary URLs, tokens, headers or writes'), which does not tell the agent when this tool is the right choice over the many sibling read/preview tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral value by warning against retrying executing/needs_check requests, but never explains what statuses can come back, what "Morning" means here, or why checking it first matters.

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 terse sentences with the purpose front-loaded and zero filler. The density comes at the cost of legibility — unexplained terms like "Morning" and "needs_check" are packed in without context.

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?

No output schema and no param documentation, so the description must carry the load — yet it never states what status values are returned or what the caller should do with each one. For a status-inspection tool, that is a substantive gap despite the useful retry warning.

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?

One required parameter ("id", uuid) at 0% schema description coverage, and the description adds nothing about it — it never says whether the id identifies a draft, a request, or a status lookup. With annotations already covering safety, the burden here is on explaining this identifier, and the description does not.

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 verb and resource ("Read local draft status"), which is better than a tautology, but "local draft status" and "request" are never mapped to the sibling tools (get_document_draft, search_document_drafts, preview_document_draft). An agent cannot tell from the description alone how this differs from the other draft-reading tools.

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?

Provides an explicit when-not directive ("Never retry executing or needs_check requests") and routes to an alternative ("check Morning first", presumably read_morning). The normal when-to-use case is left implicit, and the jargon is unexplained, so it falls short of a full 5.

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

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

Annotations cover the safety profile (readOnly=false, destructive=false, openWorld=true), and the description adds real non-obvious behavior: idempotency via requestKey ('reuse only for identical content') and a caution to verify uncertain outcomes before retrying. It doesn't state auth requirements or what the response returns, 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?

Front-loaded with purpose and exclusions in the first sentence, then parameter semantics in short clauses. Every sentence adds information; phrasing like 'directly in Morning' and 'check uncertain outcomes' is slightly opaque but not wasteful.

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 write tool with no output schema and 0% schema description coverage, the description covers the mutation's effects, its non-effects, and the idempotency contract. Missing only details an agent might want about the returned draft or failure modes.

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 0%, so the description must carry the load, and it does for the three non-obvious parameters: body follows createDocumentDraft, draftId switches to update-existing mode, and requestKey carries strict reuse semantics. Only 'title' is left to the schema, but it is self-evident.

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+resource ('Save an editable, unissued document draft') and immediately delimits it against adjacent operations ('Does not issue, send email or create a client'), which maps directly onto siblings like prepare_issue_document_draft and preview_document_draft. An agent can distinguish it without opening a 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 explicit when-not guidance (no issue, no email, no client creation) and conditional behavior for draftId (update vs. create). It lacks naming of a specific alternative sibling to use instead for issuing, but the exclusion set makes the routing clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing else – no mention of result count, pagination behavior, or match semantics for the name parameter.

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?

A single short sentence with no filler. It is efficient, though perhaps too sparse given the tool's ambiguous role among its siblings.

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 search tool with two undocumented params and no output schema, the description is far too thin. It doesn't say what is returned or how matching works, so an agent cannot confidently call it.

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 compensate but does not. It never explains that 'name' is a match query or that 'page' controls result pagination, leaving both parameters undocumented in prose and schema.

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 verb (Search/Find) and resource (clients), which is enough to know it returns matching clients. But 'existing Morning clients' and the name 'search_clients' don't differentiate it from the sibling get_client, nor does it clarify what a 'Morning client' is.

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?

No indication of when to use this versus get_client or the other search_* siblings. The agent must infer that this is keyword-find while get_client presumably fetches one by id.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so safety profile is covered. Description adds the 'editable' and 'Morning' context, which is useful, but omits pagination behavior, result sorting, and whether it searches by content or metadata. With annotations carrying the main 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?

A single, front-loaded sentence with zero waste. Every word contributes to the purpose.

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?

Adequate for a basic read-only search tool with annotations covering safety and a simple schema, but the description offers no guidance on when to use it versus related draft tools, no mention of pagination, and no indication of result format. It is minimally viable but with clear gaps.

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 0%, but only 2 parameters exist (page, pageSize) with defaults and constraints. The description does not mention pagination at all, which is a gap, but for a simple paginated search the schema's default values are fairly self-explanatory. Baseline 3 applies for low param count with minimal compensation needed.

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?

Clear verb 'search' + resource 'document drafts' with scope 'editable' and location 'in Morning'. Distinguishes from siblings like get_document_draft (single fetch) and search_documents (probably finalized documents), though explicit sibling differentiation is absent.

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?

No when-to-use guidance, no alternatives named, no exclusions. The agent must infer that this is for finding drafts vs. fetching a specific draft by ID.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a cryptic domain caveat about status vs. unpaid debt, which gestures at how results should be interpreted but gives no actionable behavior (pagination, result limits, filter interactions, auth).

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?

It is short and front-loads the purpose sentence, which is good. The second sentence, however, is cryptic and does not obviously earn its place for selecting or invoking the tool, leaving the definition under-specified rather than concise.

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 6-parameter search tool with no output schema and no parameter documentation anywhere, the description omits filtering semantics, pagination, result scope, and draft-vs-finalized distinction. It is far too thin to let an agent 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?

Six parameters (page, type, status, toDate, fromDate, clientId) have 0% schema description coverage and the description supplies no parameter meaning whatsoever. With the schema carrying no semantics and the description failing to compensate, an agent cannot know what values type/status expect or how the date range behaves.

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?

"Find Morning documents" gives a verb and a resource, so the basic operation is discernible. However, it does not scope which documents (issued vs. draft) and does nothing to separate it from siblings such as search_document_drafts or get_document. The second sentence describes a domain caveat, not the tool's purpose, so it adds no differentiation.

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?

There is no statement of when to use this tool, when not to, or which sibling to prefer for draft vs. finalized documents. The only quasi-guidance, "Open status alone does not prove unpaid debt," is a data-interpretation remark, not an invocation condition.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds one useful boundary — that this tool surfaces parsed drafts but does not finalize them (that happens elsewhere). It does not disclose pagination behavior despite a page parameter, so it adds only modest context.

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 short, front-loaded sentences with no filler. The brevity is a virtue, though the second sentence's 'Morning' reference is cryptic enough that its clarity is slightly compromised.

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 search tool with two undocumented parameters, no output schema, and no explanation of what can be searched or how results are paged, the description leaves major gaps. An agent cannot confidently determine what this returns or how to narrow results.

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 the burden for the two parameters, and it does not. The phrase 'parsed expense drafts' loosely gestures at the drafts boolean but never explains it, and the page/pagination parameter is entirely 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 verb (read) and resources (expenses / parsed expense drafts), so the basic action is inferable. But the name says 'search' while the description never describes any search/filter criteria, and it does not differentiate this from siblings like search_document_drafts or search_clients. The 'Morning' reference is opaque and does not sharpen the purpose.

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 only guidance is 'Finalize parsed drafts in Morning,' which hints that finalization belongs to another tool but never states when to call this tool versus alternatives. No conditions, no exclusions, no routing beyond a single vague pointer.

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

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

Annotations mark it as readOnlyHint=false and destructiveHint=false, but the description adds little about the state it creates, lifecycle, or cleanup of staged files. The 20 MB limit and accepted formats are useful constraints, but the agent still doesn't know where files are staged, whether they persist, or how they are consumed.

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 tightly written sentences with the local-only scope and binding constraint (20 MB) front-loaded. No redundant or filler text.

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 tool with 3 undocumented parameters, no output schema, and an ambiguous workflow position among many document-related siblings, the description is too thin. It should clarify parameter relationships, what happens after staging, and how it differs from prepare_expense_upload and save_document_draft.

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% and none of the three parameters (name, base64, filePath) are documented in the schema. The description mentions 'filePath or name plus base64' and constraints for filePath, which helps, but the 180-char name limit and the base64 28M length limit are not explained and the relationship between parameters remains unclear.

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?

The description gives a specific verb+resource ('Stage a PDF/JPEG/PNG') and adds the key distinguishing detail that staging is local and not in Morning, which separates it from sibling tools that prepare uploads or save drafts. However it doesn't explicitly name which sibling picks up the staged file, leaving some ambiguity in the workflow.

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?

There is no explicit when-to-use guidance or statement of what to do next with the staged file, nor does it name alternatives like prepare_expense_upload or save_document_draft. The 'not in Morning' phrasing implies a local staging step but never says when or why an agent should choose this path.

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