Skip to main content
Glama

company_assignment

Assign workers to jobs by priority, due date, and money at stake, using each worker's remaining weekly hours to prevent double-booked schedules and report staffing shortages.

Instructions

Staff every open job at once so a person's hours are given only once. Takes the jobs and worker profiles (and optionally a taxonomy and a match report; else the bundle's report is built now), orders the jobs by the plan's priority, then due date, then money at stake, and allocates each job's fit workers in rank order from what remains of their weekly hours across overlapping jobs. A job that cannot be filled is short by a stated number of hours and names who would have covered it had an earlier job not taken them, so the owner can reorder. Reports each worker's load and peak week and how many double bookings the per-job report would have made. Deterministic; read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nowNo
engineNo
operationNobuild
entity_refNo
project_idYes
bundle_jsonNo
payload_jsonNo{}

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.4

TDQS

A3.8/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavior: it states the operation is deterministic and read-only, explains the ordering logic (priority, due date, money at stake), describes allocation rules (rank order, remaining weekly hours), and details the outputs (worker load, peak week, double-booking count). It also notes that unfillable jobs are reported with shortfall hours and alternate coverage. This is exemplary transparency for a read-only operation.

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

Conciseness4/5

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

The description is dense but well-structured: it opens with the core purpose, then details the algorithm, edge-case handling, and outputs. Every sentence contributes necessary information (ordering, allocation, shortfall reporting, determinism). It is longer than average, but the complexity of the tool justifies the length. Slight redundancy (e.g., 'reads-only' after 'deterministic') could be trimmed, but overall it is efficiently written.

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?

Despite having an output schema, the description does not explain how to supply inputs (jobs, worker profiles, taxonomy) via the available parameters. The tool has 7 parameters, none of which are documented in the schema, and the description offers no mapping. The agent cannot determine what to put in bundle_json or payload_json. The output behavior is described, but the input side is critically incomplete, making the tool difficult to use reliably.

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

Parameters1/5

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 for parameter understanding. However, the description does not map its concepts to the actual parameters (project_id, now, engine, operation, entity_ref, bundle_json, payload_json). It mentions 'jobs and worker profiles' and optional 'taxonomy and a match report' but never links these to any schema field. The parameters remain opaque, leaving the agent unable to construct a valid call from the description alone.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Staff every open job at once so a person's hours are given only once.' It explains the resource being acted upon (jobs and workers) and the outcome (allocation). It is distinct from any sibling tool, as no other listed tool performs staffing or assignment. The verb 'Staff' and the concrete explanation make the purpose unmistakable.

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?

The description implicitly conveys when to use the tool: when you want to allocate worker hours to open jobs, especially with priority/due-date ordering. It mentions optional inputs (taxonomy, match report) but does not explicitly state when to avoid using it or name alternative tools. Since no sibling performs this function, the lack of exclusions is acceptable, but the description would benefit from an explicit statement of its scope (e.g., 'Use when you need a consolidated assignment across all open jobs').

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

Deploy Server

Other Tools