Deliverables with a due date and a sign-off: what has slipped, and what is ready to bill.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 12 tools
Most tools target distinct resources (schedules, deliverables, license, reporting), but deliverable_status could be confused with deliverable_add since both track deliverable state changes; however, status is specifically for moving between states while add creates. The schedule_* tools are clearly separated.
All tools follow a consistent verb_noun pattern: deliverable_add, deliverable_delete, deliverable_status, delivery_schedule_*, late_report, license_*, milestone_payload. CamelCase is used consistently, and verbs are meaningful (add, delete, status, get, list, create, render, activate, status).
With 12 tools, the count is well-scoped for a domain covering schedules, deliverables, reporting, and licensing. Each tool serves a distinct purpose, and the count feels neither excessive nor thin.
The tool set covers the full lifecycle: create and delete schedules, add/delete/status deliverables, get/list/render schedules, and generate reports/invoices. Licensing tools are included for tier management. Missing update for schedules is minor and arguably intentional for immutability.
Add one dated deliverable and return its D number and the new counts. value_minor is NET of VAT in whole MINOR units. A due date before the reference document's own date is refused. It starts as planned.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| due_date | Yes | The day it is due, YYYY-MM-DD. It cannot fall before the reference document's own date | |
| schedule | Yes | The schedule id, e.g. DS-2026-0001, the reference it delivers, e.g. WO-2026-0001, or its title | |
| tax_rate | No | VAT percent for this deliverable, overriding the shared business profile's default | |
| description | Yes | What is being handed over, as the client would recognise it, e.g. Wireframes for the five main pages | |
| value_minor | No | What this deliverable is worth, net of VAT, in whole minor units. 90000 is EUR 900.00. Leave it out when the job is a lump sum and this deliverable carries no price of its own | |
| duplicate_ok | No | Add it even though this schedule already carries the same description due on the same day. Default false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return value, the refusal condition for due dates before the reference document's date, and the initial status ('It starts as planned'). This is strong, though it does not cover other potential failure modes or side effects beyond the stated validation rule.
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, each carrying real information: the action and output, unit semantics, a validation constraint, and the initial lifecycle state. There is no filler or repeated schema boilerplate.
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 7-parameter tool with no output schema and no annotations, the description covers the essential non-schema facts: what is returned, one critical validation rule, and initial status. It does not fully explain all possible responses or failure modes, but the rich parameter schema covers the remaining input details.
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 high at 86%, so the schema already documents most parameters. The description mostly restates value_minor's net-of-VAT/minor-units semantics rather than adding new parameter-level meaning, so it earns the baseline 3 rather than higher.
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 action ('Add one dated deliverable'), a concrete resource, and what the tool returns ('its D number and the new counts'). This clearly distinguishes it from sibling tools like deliverable_delete and deliverable_status.
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?
Usage is implied by the verb 'Add' and the tool's name, but there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The sibling tools are mutually exclusive enough that an agent can infer intent, but the description leaves that inference unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one deliverable still planned with no history. One started, delivered or accepted is refused, naming when: add a corrected deliverable instead. The D number on a schedule is never reissued.
| Name | Required | Description | Default |
|---|---|---|---|
| schedule | Yes | The schedule id, e.g. DS-2026-0001, the reference it delivers, e.g. WO-2026-0001, or its title | |
| deliverable | Yes | The deliverable id, e.g. D01, or its description when only one carries it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden, and it does a solid job: it discloses that the API refuses deletion once history exists and that D numbers are never reissued. It does not mention permissions or whether the deletion is reversible beyond the D-number statement, but the core refusal and numbering behavior are clearly exposed.
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?
The description is compact and front-loaded: the core action and condition appear in the first sentence, and the follow-up rule is one short sentence. The phrase 'naming when' is slightly awkward and could be misread, but it does not create significant bulk or confusion.
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 simple two-parameter mutation tool with no annotations and no output schema, the description covers the essential invocation context: what may be deleted, what will be refused, and what to do instead. It does not describe success/error responses, but the refusal behavior and numbering policy give an agent enough guidance 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%, so the parameters are already fully documented in the input schema. The description adds preconditions and consequences rather than new parameter-level meaning, so the baseline of 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?
The description uses a specific verb and resource: 'Delete one deliverable still planned with no history.' It clearly delimits scope by excluding started, delivered, or accepted deliverables, so an agent can distinguish it from siblings like deliverable_add and deliverable_status.
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 gives an explicit when-not-to-use condition: a deliverable started, delivered, or accepted is refused. It also names the alternative action: 'add a corrected deliverable instead,' which maps directly to the sibling deliverable_add. This leaves no ambiguity about which tool to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a dated move on one deliverable: planned, in_progress, delivered, then accepted with a note. An out-of-order move, or a date before the reference document, is refused. The date drives lateness.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | The day it happened, YYYY-MM-DD. Default today. This is the date every late reading is taken against, not the day you type it | |
| note | No | What happened. On accepted this is the acceptance note, e.g. Signed off by the client on the call, no snags | |
| status | Yes | The status to move to | |
| schedule | Yes | The schedule id, e.g. DS-2026-0001, the reference it delivers, e.g. WO-2026-0001, or its title | |
| deliverable | Yes | The deliverable id, e.g. D01, or its description when only one carries it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful behavior: out-of-order moves are refused, dates before the reference document are refused, and the date drives lateness. However, it does not explain the results of a successful move, response shape, or permissions, and its mention of 'planned' as a move step is inconsistent with the status enum, which omits 'planned'.
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?
The description is three terse sentences with the core action firstholmes and then the key constraints. Every sentence earns its place; there is no fluff or redundancy.
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 description captures the workflow and the schema covers parameter semantics, so a plausible call can be made. But as a mutating tool with no annotations and no output schema, it leaves important context undefined: what a 'reference document' is, what a successful call returns, and how to reconcile the 'planned' state being absent from the status enum.
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% and the schema already documents all five parameters, including defaults, format, and allowed enums, so the baseline is 3. The description adds cross-parameter meaning around date ordering and status sequence, but it does not clarify the 'reference document' or expand on note requirements beyond what the schema states.
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 ('Record') and resource ('a dated move on one deliverable'), and enumerates the lifecycle states (planned, in_progress, delivered, accepted). This clearly distinguishes it from siblings like deliverable_add/delete, which add or remove deliverables rather than changing status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for recording dated deliverable status transitions cherry-picked from a lifecycle, but it never explicitly says when to prefer it over alternatives or when not to use it. The refusal rules hint at valid usage, but an agent must infer the intended trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a delivery schedule against a quote, work order or change order and return its DS-YYYY-NNNN number: the reference, its own date, the client, a title and the currency. Free tier: 3 open.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| title | Yes | What the job is, in one line, e.g. Website rebuild, phase one | |
| client | Yes | The client the work is delivered to, as named on the reference document | |
| currency | No | ISO code the deliverables are priced in. Defaults to the shared business profile's currency | |
| reference | Yes | The quote, work order or change order this schedule delivers, by its id, e.g. WO-2026-0001, Q-2026-0003 or CO-2026-0001 | |
| reference_date | Yes | The date on the reference document itself, YYYY-MM-DD. No due date and no delivery may fall before it | |
| reference_kind | No | What the reference is. Inferred from the id when omitted: WO- is a work order, CO- a change order, anything else a quote |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the return value and a free-tier limit, but it does not explain side effects of 'opening', whether opening is reversible, what happens when the free tier is exhausted, or any validation requirements beyond what the schema states. For a mutating tool, this is a meaningful gap.
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 with no filler; the action, target, return value, and key constraint are all present. The 'Free tier: 3 open' phrasing is slightly cryptic but compact and informative enough for an agent to infer a limit.
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 7-parameter creation tool with no output schema, the description provides the return shape and a limit, but it omits behavioral context like what 'open' entails, error conditions, and how to distinguish this from delivery_schedule_document or deliverable_add. High schema coverage mitigates the parameter side, but the missing operational context leaves it at minimum viable.
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 86%, so the baseline is 3. The description lists 'the reference, its own date, the client, a title and the currency', but these are return fields rather than parameter explanations, and most parameter details are already in the schema. It adds little semantic value beyond the 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?
The description states a specific verb ('Open'), a resource ('delivery schedule'), and the acceptable parent documents ('quote, work order or change order'), plus the concrete DS-YYYY-NNNN return value. This clearly distinguishes it from siblings like delivery_schedule_get, delivery_schedule_list, and delivery_schedule_delete.
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 intended use is implied by the description: call this when you need to open a schedule against a reference document. However, it never names alternatives or says when not to use it, and the sibling tools are not referenced. The 'Free tier: 3 open' line is a usage constraint but not guidance about choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a schedule carrying no deliverables, freeing an open slot. One holding any is refused, naming them, since they record what was owed. The DS number is never reissued. Free on every tier.
| Name | Required | Description | Default |
|---|---|---|---|
| schedule | Yes | The schedule id, e.g. DS-2026-0001, the reference it delivers, e.g. WO-2026-0001, or its title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does well: it discloses the refusal behavior, the fact that refusal names the deliverables, the irreversible nature of the deletion ('The DS number is never reissued'), and the cost/access profile ('Free on every tier').
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, each adding a distinct behavioral fact: deletion condition, refusal behavior, numbering policy, and availability. No filler or repetition.
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 destructive tool with no output schema and no annotations, the description covers the precondition, the failure mode, the consequence, and the access policy. An agent has enough information 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 100%, so the schema already fully documents the single 'schedule' parameter and its accepted formats. The description adds no additional parameter-level meaning, making the baseline 3 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 ('Delete'), a specific resource ('schedule'), and the condition that qualifies it ('carrying no deliverables'). It also differentiates itself by explicitly stating that non-empty schedules are refused, which distinguishes it from deliverable_delete and other siblings.
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 clear context: only empty schedules may be deleted, and a schedule holding deliverables will be refused. It implies the user should first remove deliverables (via deliverable_delete), though it does not explicitly name the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render one schedule as a plain-text document for the client: every deliverable with its due date, status, delivered and accepted dates and value, the counts as at a date, and a sign-off block. Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Read the schedule as at this date, YYYY-MM-DD. Defaults to today | |
| schedule | Yes | The schedule id, e.g. DS-2026-0001, the reference it delivers, e.g. WO-2026-0001, or its title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation via 'render' and describes the document contents, but it does not disclose whether any permissions are required, how the document is returned (string vs file), or any error behavior. It does not contradict annotations (none exist), but it leaves some behavioral aspects unstated.
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?
The description is a single sentence that front-loads the action and resource, then lists the document contents efficiently. It is concise and avoids fluff, though the trailing 'Pro.' appears to be an artifact or placeholder, which slightly detracts from professionalism but does not obscure meaning.
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 simple render tool with full schema coverage and no output schema, the description adequately explains what the document contains and the return type ('plain-text document'). It lacks details like return format (string vs file) or potential errors, but these are minor for a straightforward read operation. It is sufficiently complete for an agent 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 coverage is 100%, so both parameters are already documented. The description adds minimal semantic value beyond the schema—it mentions 'as at a date' which maps to as_of, and 'counts as at a date' reinforces that, but it does not provide additional formatting or constraints. The baseline of 3 applies because the schema does the heavy lifting.
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 uses a specific verb ('Render') and resource ('one schedule') and clearly states the output type ('plain-text document for the client'). It enumerates the content (deliverables, due dates, status, counts, sign-off block), which distinguishes it from sibling tools like delivery_schedule_get that likely return structured data. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case ('for the client') but does not explicitly state when to use this over sibling tools or any exclusions. There is no mention of alternatives or conditions, leaving the agent to infer from the 'plain-text document' wording. It is not misleading, but it offers no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one schedule in full as at a date: every deliverable with due date, status, delivered and accepted dates, note and value, plus what is late and the totals. The answer names the as_of it used.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Read the schedule as at this date, YYYY-MM-DD. Defaults to today | |
| schedule | Yes | The schedule id, e.g. DS-2026-0001, the reference it delivers, e.g. WO-2026-0001, or its title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure. It does this well by enumerating what the response includes (each deliverable's fields, late status, totals) and noting that the chosen as_of is reported. It doesn't explicitly state read-only safety or error behavior, but the extra output context is valuable.
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 with zero wasted words. The core action is front-loaded, and the detail about response contents is packed efficiently. Every clause 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?
For a two-parameter read-only tool with no output schema, the description covers the essential response structure and the as_of handling. It does not mention error cases or return format, but given the simplicity, an agent has enough to invoke and interpret the tool 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 coverage is 100% with both parameters already described. The description adds only a rephrasing of as_of ('as at a date') and mentions the answer will name the as_of used, which is output behavior rather than parameter semantics. It does not exceed the schema's baseline.
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 specifies a concrete verb ('Return') and a precise resource ('one schedule in full as at a date'), clearly distinguishing this from a list operation. It does not explicitly name sibling tools, so it stops short of a perfect 5, but the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for fetching one schedule's full details, but it never explicitly states when to use it versus delivery_schedule_list or delivery_schedule_document. There are no when-not-to-use instructions or named alternatives, so guidance remains 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.
List schedules oldest reference first with client, currency and counts as at a date: late, still owed, accepted. Filter by client, reference and state open or complete. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Read the schedule as at this date, YYYY-MM-DD. Defaults to today | |
| limit | No | Maximum schedules returned, default and ceiling 500 | |
| state | No | open for a job with a deliverable that is not yet accepted, complete for one where every deliverable is | |
| client | No | Only schedules whose client name contains this text | |
| reference | No | Only the schedule against this quote, work order or change order |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does useful work: it discloses the ordering, as-at date semantics, count categories, and that the tool is 'Free'. It does not explicitly state read-only/no side effects, but 'List' plus the absence of mutation language makes that reasonably clear.
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?
The description is two tight sentences with the core verb/resource front-loaded and each clause carrying information: ordering, output fields, date, filters, and cost. There is no filler or repetition.
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 five-optional-parameter list tool with no output schema, the description plus the high-coverage schema provides enough to invoke it correctly. It names the returned client/currency/counts and the as-of behavior, though it could be strengthened by mentioning pagination or pointing to delivery_schedule_get for a single schedule.
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% and every parameter already has a clear description. The tool description reinforces the client/reference/state filter concepts but adds little meaning beyond the schema, so the 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?
The description opens with a specific action and resource, 'List schedules', and adds distinctive scope and ordering details: 'oldest reference first', 'client, currency and counts as at a date', and filterable states. This clearly separates it from the get/create/delete siblings even though no sibling is named.
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 guidance on when to choose this list tool over delivery_schedule_get, late_report, or the other siblings. The filtering and listing language implies use for multiple schedules, but no when-not or alternative direction is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What has slipped as at a date: every deliverable still owed past its due date, worst first, with value at risk per currency, and what was delivered late kept apart. A reference with no schedule is refused.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Read lateness as at this date, YYYY-MM-DD. Defaults to today. Everything in the answer is as at this date, not as at now | |
| limit | No | Maximum rows per section, default and ceiling 500 | |
| client | No | Only schedules whose client name contains this text | |
| reference | No | Only the schedule against this quote, work order or change order | |
| include_delivered_late | No | Include what was handed over after its due date but is no longer outstanding. Default true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the sorting order ('worst first'), the separation of delivered-late items, the inclusion of value at risk per currency, and the refusal condition for references without a schedule. It does not mention whether the operation is read-only, but as a report this is implied. It also does not cover rate limits or auth, but for a report tool the disclosed behaviors are meaningful and go beyond a generic 'get late items'.
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?
The description is exceptionally concise: two sentences that front-load the core purpose and then add a key constraint. There is no filler or redundant phrasing. Every sentence earns its place—the first defines what the tool returns and how it is organized, the second states an error condition. This is model-efficient.
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?
Given there is no output schema, the description must explain the return structure. It does: it says the result lists deliverables with value at risk, separates delivered-late items, and is sorted worst-first. It also covers the refusal condition. However, it does not mention what happens with empty results, pagination behavior (though the limit parameter implies it), or the exact format of currency values. These are minor gaps for a report tool, so it is fairly complete but not exhaustive.
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 input schema provides 100% description coverage for all five parameters, so the baseline is 3. The tool description itself does not add any additional parameter-level guidance (e.g., format hints, interdependencies, or defaults beyond the schema). It does not repeat or elaborate on the parameters, so it adds no extra value over the 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?
The description clearly states what the tool does: it lists overdue deliverables ('every deliverable still owed past its due date') as of a given date, with specific ordering ('worst first') and grouping ('delivered late kept apart'). It also includes value at risk per currency, which adds specificity. This distinguishes it from siblings like delivery_schedule_list (which lists schedules) and deliverable_status (which likely shows individual status), so an agent can tell them apart without opening the 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?
The description does not explicitly mention when to use this tool versus alternatives. It implies its use for checking lateness or slippage, but there is no 'use this when...' or 'instead of...' guidance. The refusal condition (reference with no schedule) is a constraint, not usage direction. So it relies on the agent to infer from the purpose, which is a moderate level of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn Pro on for this connection with key, an MCPL1.. issued at checkout for this server or the bundle. Data under your token stays; a wrong or expired key changes nothing. license_status confirms it.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | License key from checkout, MCPL1.<payload>.<signature> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that data under the token stays and that a wrong or expired key changes nothing, which is valuable non-destructive and failure-mode context for an activation mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences front-load the action and key requirement, then add side-effect guarantees and a pointer to verification. No wasted words or repetition beyond the schema format.
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 activation tool with no output schema and no annotations, the description covers the action, key eligibility, non-destructive behavior, failure mode, and how to confirm success. It could add explicit return-value expectations, but license_status confirms it largely covers that gap.
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 schema already fully documents the key parameter, so the baseline is 3. The description adds meaningful semantics by explaining the key must be issued at checkout for this server or bundle and that invalid keys are no-ops, going beyond the schema's simple format description.
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 uses a specific action, 'Turn Pro on for this connection,' with a clear resource (license/Pro status) and key format. It also distinguishes itself from the sibling license_status by focusing on activation rather than checking status.
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 clearly conveys when to use the tool: when activating Pro with a checkout-issued key for this server or bundle. It also references license_status as the follow-up confirmation step, though it stops short of explicitly saying 'use license_status instead to check current status.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report this endpoint's licence state for your token as JSON: the product, the tier free or pro, why it is not Pro, and the checkout URL. Call it to explain a free-tier refusal. No arguments, nothing changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states 'No arguments, nothing changes,' indicating a read-only, side-effect-free operation. It does not detail error handling or authentication requirements, which are minor omissions for a simple status check, but the core behavioral trait (no mutation) is clearly communicated.
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?
The description is two sentences, tightly packed with all essential information. It is front-loaded with the primary action and output, then adds the use case and side-effect note. Every sentence earns its place with no redundancy or fluff.
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 no input parameters and no output schema, the description fully covers what an agent needs: the return format (JSON with product, tier, reason, checkout URL), the trigger condition, and the lack of side effects. Nothing essential 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?
The tool has zero parameters, and the description confirms 'No arguments.' Per the scoring rules, 0 parameters earns a baseline of 4. The description adds no parameter-specific meaning because none exist, and it correctly reiterates the absence of arguments, aligning with the empty 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?
The description states a specific verb and resource: 'Report this endpoint's licence state for your token as JSON'. It explicitly enumerates the returned fields (product, tier, reason, checkout URL), making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like license_activate by focusing on status reporting rather than activation.
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 gives a clear trigger for use: 'Call it to explain a free-tier refusal.' This tells the agent when to invoke this tool. It does not explicitly discuss alternatives or exclusions, but the purpose is distinct enough from siblings that the guidance is adequate; it could be improved by noting it is the only read-only license info tool, though that is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build the delivered-and-accepted deliverables as invoice_create-ready items in MAJOR units and quote_create-ready items in MINOR units, with VAT at the shared profile rate. Writes nothing. Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Bill what had been accepted by this date, YYYY-MM-DD. Defaults to today | |
| schedule | Yes | The schedule id, e.g. DS-2026-0001, the reference it delivers, e.g. WO-2026-0001, or its title | |
| tax_rate | No | VAT percent for deliverables with no rate of their own, overriding the shared business profile's default | |
| issue_date | No | The invoice issue date, YYYY-MM-DD. Default today |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose the important read-only trait ('Writes nothing') and the profile-rate VAT behavior. It does not describe the return shape, error behavior, or whether any external lookup happens, so transparency is adequate but incomplete.
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?
The core purpose is front-loaded in a single dense sentence and the read-only note is a useful second beat. Minor deduction for the unexplained 'Pro.' fragment, which adds no 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?
The definition is adequate for selecting and invoking the tool because inputs are fully documented and the output target is clear. Without an output schema, though, the description should say more about the returned payload shape, and it also does not explain what happens when no accepted milestones exist.
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 already documents all four parameters. The description adds context that the result is prepared for invoice/quote and uses the shared profile VAT rate, but it does not add details about how as_of, schedule, tax_rate, or issue_date map into the output beyond the 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 specific verb ('Build') and a specific resource ('delivered-and-accepted deliverables'), and precisely defines the output as invoice_create-ready items in MAJOR units and quote_create-ready items in MINOR units with VAT. This clearly distinguishes it from sibling schedule/deliverable management 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?
The description implies the tool is for turning accepted milestones into invoice/quote payload items, and the 'Writes nothing' note signals a read-only utility. However, it never explicitly says when to prefer it over sibling tools or when not to use it, leaving the agent to infer the decision.
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.
deliverable_adddeliverable_deletedeliverable_statusdelivery_schedule_createdelivery_schedule_deletedelivery_schedule_documentdelivery_schedule_getdelivery_schedule_listlate_reportlicense_activatelicense_statusmilestone_payloadStatements of account, aging buckets and dunning letters from your invoices.
Your personal action-item list — what you owe and what you're owed. AI proposes; you approve.
Verify work against acceptance criteria; signed receipts attest what passed and was earned.
View client requests, prepare actions and approve work within your firm's permissions.
Add one secure layer between your agents and this server.