Autonomous AI workforce of 33 specialist departments delivering finished, Director-reviewed business deliverables with Proof Before Pay. Powered by prepaid agent wallets.
Scored across 7 tools
Each tool targets a distinct action or resource: ordering (submit_brief), retrieving output (get_deliverable), checking a single order (get_order_status) versus all orders (list_my_orders), payment (accept_and_pay), wallet info, and department browsing. Boundaries between get_order_status and list_my_orders are clear from their descriptions.
Consistent verb_noun snake_case pattern throughout: get_deliverable, get_order_status, get_wallet, list_departments, list_my_orders, submit_brief. accept_and_pay is a minor compound deviation but still fits the verb-first convention.
Seven tools is well-scoped for a task-based ordering and payment workflow, covering discovery, ordering, tracking, retrieval, and payment without redundancy.
The full lifecycle is covered: browse departments, submit order, track status, list orders, retrieve deliverable, accept/pay, and check wallet. Minor gaps like cancel/refund or re-submit operations exist but core workflows are complete.
Accept a ready deliverable. Pays automatically from the client's prepaid agent wallet when auto-pay is on and within limits; otherwise returns a secure payment link for a human.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false, openWorldHint=true and destructiveHint=false; the description goes well beyond that by disclosing that money moves from a prepaid agent wallet, that a balance/limit check gates automatic payment, and that a secure human payment link is returned otherwise. It does not say whether acceptance is reversible or what happens if the deliverable is not ready.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler, front-loading the action and then the conditional payment outcome. Every clause carries 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 mutating tool with no output schema, the description covers the important outcome paths (auto-pay vs. payment link) well enough for an agent to act. It leaves minor gaps around failure cases (deliverable not ready, payment declined) and the resulting order state.
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?
There is one required parameter (order_id) with 0% schema description coverage, and the description never mentions it or explains its role in acceptance or payment. With low coverage the description was expected to compensate, and it does not, even though the UUID format hints at the value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource ("Accept a ready deliverable") and immediately explains the two possible payment outcomes, which no sibling (get_deliverable, get_order_status, get_wallet, submit_brief) duplicates. It is clearly differentiable in practice, though it never explicitly names an alternative tool.
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 trigger condition (deliverable must be "ready" and auto-pay on/within limits), but frames it as a behavioral branch rather than guidance about when to choose this tool versus alternatives. No exclusions or prerequisites beyond the auto-pay state are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full deliverable once paid, or the watermarked preview while it awaits acceptance.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the content returned is conditional on payment state, with a watermarked preview until acceptance. It stops short of describing failure modes (unknown order, unauthorized access).
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 sentence with zero waste, and the two conditional outcomes are front-loaded so the agent immediately knows what to expect from the call.
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, the description usefully describes the returned artifact and its two forms, which is the main thing an agent needs. It omits error/edge behavior for an unpaid, nonexistent, or foreign order, leaving a modest gap for a one-parameter read 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%, so the description is the only place order_id could be explained — and it isn't. The parameter name is largely self-describing and the schema supplies a strict UUID pattern, which limits the damage, but the description adds no meaning about which order id is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (return) and resource (deliverable), and clarifies that the returned artifact differs by payment state. Sibling differentiation is only implicit — it never names accept_and_pay or get_order_status as the relevant alternatives, so an agent must infer the relationship from 'once paid'.
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 when each variant applies (paid vs awaiting acceptance), which gives useful context for interpreting the result. However, it never states prerequisites, what to do if payment hasn't happened, or that accept_and_pay is the tool that transitions the state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show an order's status and step-by-step production progress.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds only that the result includes step-by-step production progress, with no detail on what the progress steps are, staleness of the data, or failure behavior for an unknown order id.
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?
One tight sentence with the primary output ('status') front-loaded ahead of the secondary one ('production progress'). Nothing is wasted, though it is short enough that a little more routing guidance would fit without bloat.
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 read-only, single-parameter tool this is nearly adequate, but with no output schema the description carries the burden of describing returns and only gestures at them ('status and step-by-step production progress') without indicating shape or fields.
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%, but the single parameter's name and uuid format/pattern make its meaning self-evident without prose. The description adds no extra semantics such as where to source the order_id, so it neither compensates for nor worsens 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 ('Show') and resource ('an order's status') plus the scope of returned data ('step-by-step production progress'). It is distinguishable from the read-only siblings by operating on a single order rather than listing them, though it never names list_my_orders as the contrasting alternative.
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, no prerequisites, and no mention of the natural alternative (list_my_orders for browsing, get_deliverable for deliverable detail). An agent must infer from the name that this is the per-order lookup path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the prepaid agent wallet balance, auto-pay status and spend limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds useful content about what information is exposed (balance, auto-pay status, spend limits), but says nothing about auth requirements, whose wallet is returned, or freshness of the balance.
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 the resource and the returned fields front-loaded. No filler, no repetition of the tool name or title.
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?
There is no output schema, so the description carries the burden of describing the return value, which it does by listing the three data groups. It falls just short of fully specifying what the values mean (e.g. possible auto-pay states, currency or limit format).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics for the description to clarify. The baseline of 4 applies; the description neither omits nor misrepresents anything about inputs.
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 ('Show') and a specific resource ('prepaid agent wallet') and enumerates the fields returned (balance, auto-pay status, spend limits). The resource is clearly distinct from the sibling tools (accept_and_pay, get_order_status, submit_brief), though the description never explicitly contrasts itself with them.
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 or when-not-to-use guidance is given. It implies the natural context (checking funds before accept_and_pay) but never states it, and no alternative tool is named for related balance-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Ordinal department with its id, fixed price, turnaround and deliverable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and a closed-world scope, so the safety profile is covered. The description adds genuinely new information by disclosing the payload of each row (id, fixed price, turnaround, deliverable), which matters because there is no output schema. It omits any note on ordering, volume, or whether the catalog is static.
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?
One sentence, front-loaded with the action, followed immediately by the fields returned. Every clause carries content and there is no filler or repetition of the title.
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 parameters, no output schema, and annotations covering the safety profile, the return-field enumeration is the one piece of information the agent genuinely needs, and it is supplied. Minor gaps remain around ordering and result size, but nothing blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics for the description to compensate for. The single sentence stays focused on the resource rather than inventing filter behavior that does not exist.
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 (List) and resource (Ordinal departments) and even enumerates the returned fields (id, fixed price, turnaround, deliverable), so the agent knows exactly what this yields. It does not explicitly contrast itself with siblings like list_my_orders or get_deliverable, so it falls just short of the top band.
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, no prerequisites, and no named alternatives among the sibling tools. Usage is only inferable from the purpose statement, and nothing tells the agent when this is preferable to calling get_deliverable or list_my_orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your 50 most recent orders with their status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety and repeatability are covered. The description adds the cap of 50 items and that status is included, but says nothing about ordering, pagination, or what happens beyond 50 orders.
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 the scope and return field, no filler. Every word 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 no-argument read-only list tool with no output schema, the description tells the agent what it gets (orders plus status) and how many. Only the lack of tie-in to sibling tools leaves a minor 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 tool takes zero parameters, so per the baseline the description has nothing extra to document. The implicit fact that results are capped at 50 is the only parameter-like constraint and it is stated.
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 ('List') and resource ('orders') with scope ('50 most recent') and returned field ('status'). It does not, however, distinguish itself from the sibling get_order_status or explain why one would list rather than fetch a single order.
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 get_order_status. The 50-most-recent scope is a hint about behavior but not a selection criterion an agent can act on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Order a department deliverable. Work starts immediately; nothing is charged until you accept the finished result.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | Full brief: context, facts, figures and required sections. | |
| title | Yes | Short project title. | |
| deadline | No | Optional deadline, e.g. 2026-12-31. | |
| extra_info | No | Optional constraints or formatting notes. | |
| department_id | Yes | Department id from list_departments. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare that this is a non-read-only, non-destructive, closed-world mutation. The description adds genuinely useful behavioral context beyond that: work begins immediately on submission and no charge occurs until the result is accepted, which resolves the agent's main risk question about cost and timing. It does not say what is returned or whether a submission can be cancelled.
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 action and immediately followed by the two facts that most affect a caller's decision (immediate work start, deferred charge). No filler.
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 low-complexity, flat 5-parameter tool with no output schema, the description covers the essential ordering semantics and the payment model. It omits what the call returns (an order/deliverable id) and does not point to get_order_status or accept_and_pay as the follow-up step, which would help an agent complete the workflow.
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 all five parameters are already documented (brief contents, title, optional deadline, optional formatting notes, department_id from list_departments). The description adds no parameter-level 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?
Names a specific verb+resource pair ('Order a department deliverable') that an agent can distinguish from the read-only siblings (get_deliverable, get_order_status, list_my_orders) and from accept_and_pay. It stops short of explicitly naming which sibling to use instead, so it is clear but not fully differentiated.
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: this is the entry point for commissioning work from a department, and the mention of accepting a 'finished result' hints the lifecycle continues in accept_and_pay. There is no explicit when-to-use statement, no prerequisite called out (the department_id source is only in the schema), and no when-not guidance.
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.
accept_and_payget_deliverableget_order_statusget_walletlist_departmentslist_my_orderssubmit_brief
Add one secure layer between your agents and this server.