objekts Production Desk

Estimate visual production

estimate_production

Read-onlyIdempotent

Use the objekts Production Desk estimate engine only when the user explicitly asks about price, cost, budget, quote, or budget fit. Set scopeType to WHOLE_PRODUCTION or BOUNDED_SHOT_POST and pass a short verbatim scopeEvidence phrase. Use USER_EXPLICIT when the requested object itself is clear: for example, a request to make/price a finished commercial is whole-production, while a request to make/fix/price named shots or scene post work is bounded. Use INFERRED only when the requested object is genuinely ambiguous; then the tool returns no price until clarified, or you may calculate clearly labeled SCENARIO estimates. Pass runtimeSeconds when known. It packages objekts production-estimation methodology and computes a non-binding estimate from production units, scope type, runtime, hard locks, continuity, versioning and deadline pressure. Do not collect contact information for this tool.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes
`units`	Yes
`scopeType`	Yes	WHOLE_PRODUCTION for the complete production being priced; BOUNDED_SHOT_POST for only named shots/scenes/post tasks. Never silently reinterpret one as the other.
`exclusions`	No
`scopeBasis`	Yes	One concise sentence stating exactly what the estimate includes. Never imply a bounded shot/post scope is the price of the whole commercial.
`versioning`	No
`assumptions`	No
`deadlineDays`	No
`scopeDecision`	Yes	USER_EXPLICIT when the user request itself clearly targets either a finished commercial/film/video deliverable or a bounded shot/scene/post task. Literal words like whole/only are not required when the requested object is already clear. SCENARIO is for a clearly labeled hypothetical. INFERRED is only for genuinely ambiguous scope and returns no price until clarified.
`scopeEvidence`	Yes	For USER_EXPLICIT, copy a short verbatim phrase from the user's request; do not paraphrase, add words, or summarize. The phrase must make the requested object clear: a finished deliverable or a bounded shot/scene/post task. For SCENARIO/INFERRED, briefly state that this is a scenario or inferred interpretation.
`runtimeSeconds`	Yes	Final master runtime in seconds when known. Use null only when runtime is genuinely unknown; for whole-production pricing, runtime is a material pricing input.
`targetBudgetMax`	No
`targetBudgetMin`	No
`externalBidItems`	No
`includeDepartments`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	Yes
`currency`	Yes
`rangeMax`	Yes
`rangeMin`	Yes
`budgetFit`	No
`scopeType`	Yes
`confidence`	Yes
`exclusions`	Yes
`scopeBasis`	Yes
`assumptions`	Yes
`costDrivers`	Yes
`departments`	Yes
`scheduleFit`	No
`scopeDecision`	Yes
`scopeEvidence`	Yes
`runtimeSeconds`	Yes
`timelineMaxDays`	Yes
`timelineMinDays`	Yes
`unknownCostExposure`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed18 schema fields changedOct 2, 2026

addedInput schema / properties / assumptions / items / maxLength
```
Added value: +1000
```
addedInput schema / properties / assumptions / maxItems
```
Added value: +50
```
addedInput schema / properties / exclusions / items / maxLength
```
Added value: +1000
```
addedInput schema / properties / exclusions / maxItems
```
Added value: +50
```
addedInput schema / properties / externalBidItems / items / properties / label / maxLength
```
Added value: +300
```
addedInput schema / properties / externalBidItems / items / properties / reason / maxLength
```
Added value: +1000
```
addedInput schema / properties / externalBidItems / maxItems
```
Added value: +50
```
addedInput schema / properties / includeDepartments / maxItems
```
Added value: +20
```

changedInput schema / properties / runtimeSeconds / anyOf

Previous value: -[
-  {
-    "exclusiveMinimum": 0,
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 36000,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / scopeDecision / description

Previous value: -"USER_EXPLICIT only when the user explicitly distinguishes full/whole/turnkey production from only/just/bounded shots or post. SCENARIO when calculating a clearly labeled hypothetical. INFERRED when the model had to guess the scope; INFERRED calls return no price and require one clarification question."New value: +"USER_EXPLICIT when the user request itself clearly targets either a finished commercial/film/video deliverable or a bounded shot/scene/post task. Literal words like whole/only are not required when the requested object is already clear. SCENARIO is for a clearly labeled hypothetical. INFERRED is only for genuinely ambiguous scope and returns no price until clarified."

changedInput schema / properties / scopeEvidence / description

Previous value: -"A short verbatim phrase from the user's request that supports USER_EXPLICIT, or a short explanation that this is a labeled SCENARIO/INFERRED interpretation."New value: +"For USER_EXPLICIT, copy a short verbatim phrase from the user's request; do not paraphrase, add words, or summarize. The phrase must make the requested object clear: a finished deliverable or a bounded shot/scene/post task. For SCENARIO/INFERRED, briefly state that this is a scenario or inferred interpretation."

changedInput schema / properties / units / items / properties / hardLocks / maximum
```
Previous value: -9007199254740991New value: +100
```
changedInput schema / properties / units / items / properties / quantity / maximum
```
Previous value: -9007199254740991New value: +1000
```
changedInput schema / properties / units / items / properties / recurringEntities / maximum
```
Previous value: -9007199254740991New value: +100
```
addedInput schema / properties / units / maxItems
```
Added value: +200
```
changedInput schema / properties / versioning / properties / derivedVersions / maximum
```
Previous value: -9007199254740991New value: +1000
```
changedInput schema / properties / versioning / properties / newProductionUnits / maximum
```
Previous value: -9007199254740991New value: +1000
```
changedInput schema / properties / versioning / properties / recomposedVersions / maximum
```
Previous value: -9007199254740991New value: +1000
```

Changed12 schema fields changedOct 2, 2026

addedInput schema / properties / runtimeSeconds

Added value: +{
+  "anyOf": [
+    {
+      "exclusiveMinimum": 0,
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Final master runtime in seconds when known. Use null only when runtime is genuinely unknown; for whole-production pricing, runtime is a material pricing input."
+}

addedInput schema / properties / scopeBasis

Added value: +{
+  "description": "One concise sentence stating exactly what the estimate includes. Never imply a bounded shot/post scope is the price of the whole commercial.",
+  "maxLength": 600,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / scopeDecision

Added value: +{
+  "description": "USER_EXPLICIT only when the user explicitly distinguishes full/whole/turnkey production from only/just/bounded shots or post. SCENARIO when calculating a clearly labeled hypothetical. INFERRED when the model had to guess the scope; INFERRED calls return no price and require one clarification question.",
+  "enum": [
+    "USER_EXPLICIT",
+    "SCENARIO",
+    "INFERRED"
+  ],
+  "type": "string"
+}

addedInput schema / properties / scopeEvidence

Added value: +{
+  "description": "A short verbatim phrase from the user's request that supports USER_EXPLICIT, or a short explanation that this is a labeled SCENARIO/INFERRED interpretation.",
+  "maxLength": 300,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / scopeType

Added value: +{
+  "description": "WHOLE_PRODUCTION for the complete production being priced; BOUNDED_SHOT_POST for only named shots/scenes/post tasks. Never silently reinterpret one as the other.",
+  "enum": [
+    "WHOLE_PRODUCTION",
+    "BOUNDED_SHOT_POST"
+  ],
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "mode",
-  "units"
-]New value: +[
+  "mode",
+  "scopeType",
+  "scopeDecision",
+  "scopeEvidence",
+  "runtimeSeconds",
+  "scopeBasis",
+  "units"
+]

addedOutput schema / properties / runtimeSeconds

Added value: +{
+  "anyOf": [
+    {
+      "exclusiveMinimum": 0,
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / scopeBasis
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / scopeDecision

Added value: +{
+  "enum": [
+    "USER_EXPLICIT",
+    "SCENARIO",
+    "INFERRED"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / scopeEvidence
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / scopeType

Added value: +{
+  "enum": [
+    "WHOLE_PRODUCTION",
+    "BOUNDED_SHOT_POST"
+  ],
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "mode",
-  "currency",
-  "confidence",
-  "rangeMin",
-  "rangeMax",
-  "timelineMinDays",
-  "timelineMaxDays",
-  "departments",
-  "costDrivers",
-  "assumptions",
-  "exclusions",
-  "unknownCostExposure"
-]New value: +[
+  "mode",
+  "scopeType",
+  "scopeDecision",
+  "scopeEvidence",
+  "runtimeSeconds",
+  "scopeBasis",
+  "currency",
+  "confidence",
+  "rangeMin",
+  "rangeMax",
+  "timelineMinDays",
+  "timelineMaxDays",
+  "departments",
+  "costDrivers",
+  "assumptions",
+  "exclusions",
+  "unknownCostExposure"
+]

First observedOct 2, 2026

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is clear. The description adds that the estimate is non-binding, that INFERRED returns no price until clarified, and that it packages production-estimation methodology. It also says not to collect contact info. However, it doesn't cover important behaviors like output format details (though output schema exists) or any rate/performance characteristics. It adds some context but not rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a dense wall of text with procedural instructions that overlap heavily with the parameter descriptions in the schema. It buries the high-level purpose in detailed scope-decision rules. It is not front-loaded: the core purpose appears only near the end. Many sentences could be trimmed or moved to parameter descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool with 15 parameters, 33% schema coverage, nested objects, and a critical required 'units' array. The description does not explain the meaning of 'mode' (ROM, SCOPED_ESTIMATE, etc.), the structure of 'units', or the roles of many other parameters. While an output schema exists, the input side is severely under-documented, and the description fails to fill that gap. It assumes the user will infer from the schema alone, which is inadequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (only 5 of 15 parameters have descriptions in the schema), yet the description focuses on scopeDecision, scopeType, scopeEvidence, and runtimeSeconds, which are already documented in the schema. It provides no meaning for the many undocumented parameters like mode, units (and its nested fields), exclusions, versioning, assumptions, deadlineDays, targetBudgetMin/Max, externalBidItems, includeDepartments. The description fails to compensate for the low schema coverage, leaving the majority of parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool computes a non-binding production estimate from production units, scope, runtime, etc., and names the 'objekts Production Desk estimate engine'. However, it doesn't explicitly contrast with siblings, which are all about production briefs (create/update/delete/status/upload), and the overall purpose is obscured by the procedural scopeDecision guidance. It's clear enough but not sharply distinguished from the production-brief tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit usage conditions: 'use only when the user explicitly asks about price, cost, budget, quote, or budget fit', which is a strong when-to-use signal. It also provides detailed guidance for setting scopeType and scopeDecision (USER_EXPLICIT vs INFERRED vs SCENARIO), though it doesn't name the sibling tools or state when not to use it in favor of them.

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

All objekts Production Desk tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.