Plan W-2 event staffing from 345 catalog entries; a coordinator confirms each order.
Scored across 12 tools
Each tool targets a distinct function: availability, city lookup, compliance, plan management, pricing, etc. Even the two rate tools (get_rate_benchmark vs get_role_pricing) are clearly separated by scope (national index vs. city-specific), with explicit cross-references to avoid misuse.
All tool names follow a consistent snake_case verb_noun pattern: get_* for read operations, and action verbs (check_, plan_, request_, save_) for other operations. No camelCase or stylistic deviations, making the API predictable and navigable.
12 tools is well within the ideal 3-15 range. Each tool earns its place by covering a distinct aspect of the staffing workflow—catalog, roles, pricing, compliance, planning, persistence, quoting, and policies—without redundancy.
The tool set covers the full lifecycle from catalog discovery (get_cities, get_roles), through pricing and compliance checks, to plan creation (plan_staffing), persistence (save_staffing_plan/get_plan), and quoting (request_quote/get_quote_status). Deliberate omissions (e.g., no reservation tool) are documented as coordinator-confirmed steps, so there are no dead ends for agents.
Return tier-based lead-time guidance for an event date and configured market. Use for 'What's the typical lead time for brand ambassadors in [city]?' or 'Is this date inside the usual planning window?'. This is not a real-time inventory or order-coverage check: a TempGuru coordinator confirms coverage and final lead time for the specific order after buyer submission. DO NOT use for cost questions (use get_role_pricing) and never present the result as a reservation. check_availability(date='2026-08-14', city='Dallas') ; check_availability(date='2026-07-01', city='Boston', role='brand-ambassadors', count=6) Even a 'rush' window is worth submitting, same-week backfills exist in select markets.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name (e.g., 'Boston') or slug (e.g., 'boston-event-staffing'). | |
| date | Yes | Event date as YYYY-MM-DD; legacy recognizable dates are still accepted. | |
| role | No | Optional role name or slug to include rate context. | |
| count | No | Optional headcount for the event. |
| Name | Required | Description |
|---|---|---|
| city | No | |
| role | No | Rate context when a role was provided; null otherwise. |
| count | No | Echo of the requested headcount. |
| error | No | Present when the date could not be parsed. |
| notes | No | |
| state | No | |
| in_past | No | True when the requested date is already in the past — confirm the date before planning. |
| message | No | Present when city_found is false. |
| city_tier | No | Market tier: hub = 25 major metros, mid = 128 secondary markets, small = 192 tertiary markets. |
| requested | No | Echo of the unmatched city input. |
| city_found | Yes | false = city did not match the configured catalog (see message); true = planning guidance below, not confirmed coverage. |
| event_date | No | Normalized ISO date (YYYY-MM-DD). |
| role_found | No | null = no role requested; false = the requested role didn't match the catalog (see notes). |
| suggestion | No | Closest known city/role for a miss. Confirm with the user before using it; do not auto-apply. |
| catalog_match | No | |
| recommendation | No | Lead-time guidance, NOT a reservation. Even rush is worth submitting. |
| role_suggestion | No | Closest known city/role for a miss. Confirm with the user before using it; do not auto-apply. |
| days_until_event | No | |
| typical_lead_time_hours | No | |
| coverage_confirmation_required | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations covering readOnly/non-destructive, the description adds valuable behavioral context: it clarifies the result is guidance, not a commitment; final coverage requires coordinator confirmation; and results must not be shown as reservations. This exceeds what annotations alone convey, even if it doesn't detail the output structure (which the output schema covers).
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 concise yet information-dense, with the core purpose front-loaded, followed by caveats, a 'DO NOT' that points to a sibling tool, and a strategic hint. Each sentence serves a clear function in guiding correct invocation.
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 the presence of an output schema, full parameter schema coverage, and behavior annotations, the description adds the right amount of extra context—tier-based, not a reservation, coordinator confirmation, and a useful market hint. The tool is well-specified for each aspect an agent needs to decide whether and how to 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?
The input schema already covers all parameters with descriptions (100% coverage). The description adds useful examples demonstrating optional role and count but does not add deeper semantics beyond the schema. The schema handles the parameter documentation well.
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, distinct purpose: return tier-based lead-time guidance for an event date and configured market. It includes concrete example queries and explicitly differentiates itself from real-time inventory checks and cost queries (get_role_pricing), so an agent can clearly tell it apart from sibling 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 explicit when-to-use guidance with natural language examples, explicit exclusions, and names the alternative tool for cost questions. It also includes a hint about rush windows and instructs the agent not to present the result as a reservation. This is thorough and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured market entries by tier, or match one city. Catalog presence is not availability or order coverage; check_availability gives tier-based lead-time guidance only, and a coordinator confirms each order after buyer submission. Use for 'What markets are configured in [state]?', 'Is [city] in the catalog?', or 'Which Canadian markets are listed?'. For 'Do you cover [city]?' pass city='[name]', report the catalog match or suggestion, and preserve the coordinator-confirmation caveat. Use get_role_pricing for rates, check_availability for dates, or plan_staffing for a full plan. get_cities(city='Brooklyn') ; get_cities(state='TX') ; get_cities(tier='hub', country='CA') ; get_cities(limit=25) State accepts 'CA' or 'California'; country accepts US or CA. City resolves nicknames and boroughs. Unfiltered results are capped; use filters or limit. Configured entries are planning data; the public coverage claim is 300+ U.S. and Canadian markets.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional single-city catalog match (nickname/borough aware). Returns catalog_match plus a suggestion; never a coverage promise. | |
| tier | No | Optional filter to one tier only. | |
| limit | No | Optional cap on the number of cities returned (full counts still in total/tier_breakdown). | |
| state | No | Optional 2-letter state code (e.g., 'CA') or full state name. | |
| country | No | Optional country filter: 'US' or 'CA'. |
| Name | Required | Description |
|---|---|---|
| city | No | The matched configured entry, or null when there was no catalog match. |
| note | No | Present when the list was truncated by limit. |
| total | No | Total cities matching the filter (before limit). |
| cities | No | |
| message | No | |
| returned | No | Number of cities in the cities array (after limit). |
| requested | No | |
| suggestion | No | Closest known city/role for a miss. Confirm with the user before using it; do not auto-apply. |
| catalog_check | No | Present when a single-city catalog check was requested. |
| catalog_match | No | Whether the city resolved to a configured catalog entry; not an availability or coverage promise. |
| tier_breakdown | No | |
| catalog_qualification | No | |
| coverage_confirmation_required | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds meaningful behavioral context: configured entries are planning data, catalog presence does not promise availability or coverage, a coordinator must confirm orders, unfiltered results are capped, and the public coverage claim is 300+ markets. This goes well beyond the structured 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?
The description is dense but front-loaded with the core purpose and caveat, followed by use cases, examples, and hints. It is longer than the minimum, but every section earns its place given the semantic pitfalls an agent must avoid. The structure is organized and scannable.
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-only lookup tool with 100% parameter documentation and an output schema, the description supplies all needed context: when to use it, how to answer common user questions, what caveats to preserve, how filters behave, and what sibling tools cover adjacent needs. Nothing material is missing for correct invocation.
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%, but the description still adds value by clarifying accepted formats ('CA' or 'California' for state, 'US' or 'CA' for country), nickname/borough resolution, the meaning of limit caps with full counts retained, and the fact that city matching returns a suggestion rather than a coverage promise. These nuances are not fully captured in 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 opens with a specific verb and resource: 'List configured market entries by tier, or match one city.' It clearly distinguishes this tool from siblings like check_availability and get_role_pricing, and explicitly names the non-goal: catalog presence is not availability or order coverage.
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 concrete query patterns ('What markets are configured in [state]?', 'Is [city] in the catalog?'), provides example calls for several filter combinations, and explicitly names sibling tools for related tasks (get_role_pricing, check_availability, plan_staffing). It even instructs how to handle 'Do you cover [city]?' with the proper caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the event staffing compliance summary for a US state. Returns minimum wage, overtime rules, and state-specific quirks. Perfect for 'What are the W-2 vs 1099 rules for event workers in [state]?', 'What's the minimum wage for event staff in [state]?', or 'Are there compliance gotchas for hiring event workers in [state]?' questions. NOT legal advice, consult employment counsel for binding interpretation. DO NOT use for rates (use get_role_pricing). get_compliance_by_state(state='CA') ; get_compliance_by_state(state='Tennessee') Daily-overtime states (CA, AK, NV, CO) change shift budgeting, flag them in any plan.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code (e.g., 'CA') or full state name (e.g., 'California'). |
| Name | Required | Description |
|---|---|---|
| state | No | |
| w2_note | No | |
| requested | No | |
| state_abbr | No | |
| state_found | No | Present (false) only when the state didn't match. |
| w2_required | No | |
| data_version | No | Version of the compliance dataset used for this result. |
| min_wage_usd | No | 2026 state minimum wage. |
| unique_rules | No | |
| citation_note | No | Operational guidance, not legal advice. |
| currency_note | No | Reminder that wages change annually; verify before relying. |
| min_wage_as_of | No | Effective date of this state's stored minimum wage. |
| min_wage_source | No | Authoritative source URL for the minimum wage figure. |
| available_states | No | |
| data_current_as_of | No | Date the compliance dataset was last verified (YYYY-MM-DD). |
| seventh_day_overtime | No | True where a seventh-consecutive-day premium applies (CA). |
| workers_comp_included | No | |
| liability_coverage_included | No | |
| overtime_daily_double_hours | No | Start of the double-time band (hours/day) where the state has one (CA: 12); null otherwise. |
| overtime_threshold_daily_hours | No | Daily overtime threshold where the state has one (CA, AK, NV, CO); null otherwise. |
| overtime_threshold_weekly_hours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond the annotations: it returns regulatory information, flags that it is not legal advice, and adds a daily-overtime hint (CA, AK, NV, CO). This is meaningful supplementary 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?
The description is front-loaded with the core purpose and return contents, followed by targeted usage examples, an explicit exclusion, and a useful hint. It is slightly verbose due to the example questions, but each part adds practical guidance, so the length is justified.
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-only lookup with a rich schema, an output schema, and annotations already present, the description is complete. It covers what the tool returns, when to use it, when not to use it, the non-advice caveat, and an operational hint about daily-overtime states.
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 single 'state' parameter is already well described as accepting either a two-letter code or full state name. The description adds value with concrete example calls such as state='CA' and state='Tennessee', reinforcing accepted formats and making invocation unambiguous.
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: 'Get the event staffing compliance summary for a US state', and lists what it returns (minimum wage, overtime rules, state-specific quirks). It also distinguishes itself from get_role_pricing by explicitly disclaiming rates, so an agent can clearly separate this tool from its 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?
The description gives concrete example questions that should trigger this tool, explicitly says 'DO NOT use for rates (use get_role_pricing)', and includes a 'NOT legal advice' caveat. This provides clear when-to-use and when-not-to-use guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore a complete non-PII staffing plan created by plan_staffing or save_staffing_plan within the last 30 days. Use when a buyer starts a new conversation, changes agent platforms, or wants to continue a saved plan before requesting a quote. DO NOT guess or enumerate plan IDs; use only the 12-character plan_id the user, plan_staffing, or save_staffing_plan supplied. get_plan(plan_id='ABCDEFGH2345') A not-found result means the plan expired, storage was unavailable, or the ID is wrong; re-run plan_staffing. Review the restored plan with the user before request_quote.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | 12-character lookalike-free plan reference returned by plan_staffing or save_staffing_plan. |
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| plan_id | Yes | |
| snapshot | No | |
| next_steps | Yes | |
| offer_note | No | Published first-order offer note. Snapshot totals remain undiscounted. |
| plan_found | Yes | Discriminator. false means the reference was absent or expired. |
| continuation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and destructive hints, the description discloses the 30-day expiration window, the provenance requirement for plan_id, a do-not-guess/enumerate guardrail, and not-found failure semantics. This adds meaningful behavioral context an agent would not infer from the annotations or schema alone.
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 appropriately triaged: the core purpose and when-to-use are front-loaded, then the warning guardrail, then an example, then failure and workflow hints. Every sentence earns its place and supports correct invocation without redundant 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?
Given the output schema is present, it doesn't need to enumerate return fields. It covers selection criteria, required input provenance, failure interpretation, and post-restore actions, which gives the agent everything needed to call the tool correctly and handle the result appropriately.
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 covers plan_id thoroughly with a regex pattern, length, and source description, so the baseline is high. The description adds value with 'DO NOT guess or enumerate plan IDs', an explicit example call, and a clear statement that only user-supplied or tool-supplied IDs are valid, which strengthens anti-hallucination behavior.
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 ('Restore') and a precise resource ('complete non-PII staffing plan created by plan_staffing or save_staffing_plan within the last 30 days'). This clearly identifies what the tool does and differentiates it from siblings like get_quote_status or plan_staffing.
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 explicit when-to-use conditions: buyer starts a new conversation, changes agent platforms, or wants to continue a saved plan before requesting a quote. It also provides a fallback action on failure ('re-run plan_staffing') and a workflow guardrail ('Review the restored plan with the user before request_quote'), which is strong practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TempGuru's published booking and procurement policies, plus any currently published public offer. Use for real booking questions that otherwise require an email. Values not supported by canonical copy are explicitly marked confirm_with_coordinator with TODO-for-Megan; never infer a missing number. get_policies() ; get_policies(topic='payment-terms') ; get_policies(topic='coi-additional-insured') Choose an advertised topic to return one policy. Narrow lexical aliases remain accepted, and unknown topics return the current available-topic list. This is an operational summary, not a contract.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional canonical policy topic. Choose an advertised enum value; omit for all policies or a broader question. |
| Name | Required | Description |
|---|---|---|
| scope | No | |
| status | Yes | |
| message | No | |
| updated | No | |
| policies | No | |
| requested | No | |
| disclaimer | No | |
| data_version | No | |
| policy_found | Yes | Discriminator. false means the requested topic is not published. |
| todo_for_megan | No | |
| available_topics | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing how unsupported values are marked, instructing agents to never infer missing numbers, noting that unknown topics return an available-topic list, and adding the interpretive caveat that the output is 'an operational summary, not a contract.' These are high-value behavioral details.
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?
Info is front-loaded with the core purpose first, followed by usage guidance and examples. Every sentence contributes context that affects invocation behavior, and the format with examples and hints is efficiently structured without 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?
Given the single optional parameter, rich schema, and annotations, the description is fully complete for invocation. It covers what happens with omission, unknown topics, aliases, unsupported values, and how to treat the response. The output schema exists, so return-value details are not required here.
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 a baseline of 3 applies, but the description adds meaning beyond the enum by explaining that omitting the topic returns all policies or a broader answer, that aliases are accepted, and that unknown topics return the list of available topics. It also provides concrete examples.
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 identifies the resource (TempGuru's published booking and procurement policies plus public offers) and uses a specific verb ('get'). It sets the tool apart from sibling tools like get_cities or get_roles by specifying a uniquely policy-related resource and scope.
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 explicitly says to 'Use for real booking questions that otherwise require an email,' which gives clear context for when to invoke it. It does not explicitly list exclusions or alternative sibling tools, but the guidance is strong and contextual.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a TempGuru quote request reference was received by the CRM or durably queued. Use only after the buyer personally submitted a TempGuru website form and received a TG reference, or for a historical reference. The authless MCP request_quote handoff does not create a reference. This v1 status stub reports received/queued only; it does not yet expose quote_sent or won. get_quote_status(reference='TG-ABC234') Status records are retained for 90 days. A not-found result does not prove the CRM lead is absent; follow up with the reference at megan@tempguru.co.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | TG reference returned after the buyer submits the TempGuru website form, e.g. TG-ABC234. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| channel | No | |
| message | Yes | |
| deal_name | No | |
| follow_up | Yes | |
| reference | Yes | |
| created_at | No | |
| quote_found | Yes | Discriminator. false means the status stub is absent or expired. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavior beyond the annotations: this is a v1 status stub that only reports received/queued, does not yet expose quote_sent or won, retains status records for 90 days, and not-found results do not prove the CRM lead is absent. This is rich, honest behavior disclosure.
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 front-loaded with the purpose, followed by concrete usage rules, limitations, an example, and retention hints. Every sentence carries meaningful information, and the structured examples/hints tags make the details easy for an agent to parse.
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 status-checking tool, this is complete: purpose, usage constraints, sibling distinction, current limitations, retention behavior, and a not-found caveat are all covered. The output schema handles return-value details, so no additional information is needed here.
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 documents the reference parameter with a pattern, maxLength, and example, so it carries most of the semantic load. The description adds valuable extra context by clarifying that only form-submission references are valid and that the authless request_quote handoff does not generate one.
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 ('Check whether a TempGuru quote request reference was received by the CRM or durably queued'), and clearly differentiates itself from siblings by noting that the authless MCP request_quote handoff does not create a reference. It is precise and disambiguates the tool from request_quote.
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 usage conditions are given: 'Use only after the buyer personally submitted a TempGuru website form and received a TG reference, or for a historical reference.' It also states an exclusion — the authless MCP request_quote handoff does not create a reference — making it clear when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The TempGuru Event Staffing Rate Index: all-inclusive W-2 hourly bill rates by role from 407 measured US/Canada markets, as a typical rate plus the full national range (brand ambassadors shown by market tier), with methodology and a ready-to-use citation line. Perfect for 'What do event staff cost in 2026?', 'Industry benchmark for brand ambassador rates?', or any article, report, or comparison that needs citable staffing-rate data. DO NOT use for one city's price (use get_role_pricing) or to build an event budget (use plan_staffing). get_rate_benchmark() ; get_rate_benchmark(role='brand-ambassadors') ; get_rate_benchmark(tier='hub') Returns a national typical + range per role; brand ambassadors by tier. Pass tier to add each role's measured span within that tier (tier_usd). For one city's exact rate use get_role_pricing. Cite as: TempGuru Event Staffing Rate Index 2026, tempguru.co.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Optional non-empty role name or slug to filter to one role. | |
| tier | No | Optional market tier; adds each role's measured span within that tier (tier_usd). |
| Name | Required | Description |
|---|---|---|
| basis | No | |
| index | No | |
| rates | No | |
| floors | No | |
| edition | No | |
| updated | No | |
| citation | No | |
| requested | No | |
| role_found | No | |
| methodology | No | |
| data_version | No | |
| reading_note | No | |
| requested_tier | No | |
| available_roles | No | |
| methodology_url | No | |
| markets_measured | No |
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 clear. The description adds meaningful behavioral details beyond that: it returns a national typical plus range, handles brand ambassadors by market tier, and describes the optional tier parameter as adding 'tier_usd' data for each role.
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 more detailed than average, but every sentence contributes: scope, data source, return value, example use cases, exclusions, citation, and parameter hints are all covered. It is front-loaded with the core result and the guidance to use alternative tools.
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 two optional parameters, an output schema, and clear annotation coverage, this description is complete. It covers the dataset, measurement scope, tier handling, citation format, and appropriate alternatives. An agent can confidently decide when to invoke this tool and understand the shape of the result before even opening the 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 coverage is 100%, so parameter basics are already documented. The description adds extra value by explaining what the tier parameter actually does ('adds each role's measured span within that tier (tier_usd)') and by showing concrete example calls with different parameter combinations, which helps an agent understand how to pass arguments correctly.
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 identifies the resource (TempGuru Event Staffing Rate Index) and the specific output: all-inclusive W-2 hourly bill rates by role from 407 markets, with a typical rate plus the national range. It also explicitly distinguishes itself from related tools like get_role_pricing and plan_staffing by stating what the tool is NOT for.
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 guidance is explicit and actionable. It provides example queries, states when to use the tool ('What do event staff cost in 2026?', 'Industry benchmark'), and gives clear exclusions: do not use for one city's price (use get_role_pricing) or to build a budget (use plan_staffing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the all-inclusive hourly rate range for a specific role in a specific city. Perfect for 'What does it cost to hire brand ambassadors in [city]?', 'How much are registration workers in [city]?', or 'What's the rate for ushers at a [city] stadium event?' questions. All rates include W-2 worker pay, workers comp, general liability, and payroll taxes. DO NOT use for availability or dates (use check_availability) and never present the range as a binding quote. For a multi-role budget, use plan_staffing. get_role_pricing(role='Brand Ambassadors', city='Boston') ; get_role_pricing(role='registration-staff', city='nashville-event-staffing') Role and city accept names or slugs. Brand Ambassadors floor at $40/hour in every market.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name (e.g., 'Boston') or slug (e.g., 'boston-event-staffing'). | |
| role | Yes | Role name (e.g., 'Brand Ambassadors') or slug (e.g., 'brand-ambassadors'). |
| Name | Required | Description |
|---|---|---|
| city | No | |
| note | No | |
| role | No | |
| error | No | |
| state | No | |
| currency | No | |
| city_tier | No | Market tier: hub = 25 major metros, mid = 128 secondary markets, small = 192 tertiary markets. |
| requested | No | Echo of the unmatched input. |
| role_note | No | Caveat about the resolved role (e.g. 'security' maps to unarmed Crowd Control, not licensed security). |
| role_slug | No | |
| city_found | No | Present (false) only when the city didn't match. |
| role_found | No | Present (false) only when the role didn't match. |
| suggestion | No | Closest known city/role for a miss. Confirm with the user before using it; do not auto-apply. |
| all_inclusive | No | |
| pricing_notes | No | |
| available_roles | No | The valid role catalog, returned when the role didn't match. |
| tier_definition | No | |
| fallback_pricing | No | All-tier pricing shown when the city didn't match. |
| hourly_range_low | No | |
| hourly_range_high | No | |
| all_tiers_for_context | No | Rate bands across all three market tiers for context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by explaining that rates are all-inclusive, non-binding, and not a quote, which shapes how the agent should present results.
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 dense but every sentence earns its place: it defines output semantics, gives user-style queries, routes to alternatives, adds exclusion guidance, and provides examples and hints. It is front-loaded with the core 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?
For a simple two-parameter read-only tool with a full output schema, the description is complete: it states the exact inputs, the meaning of the returned range, the non-binding caveat, and alternative tools for related tasks.
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 descriptions already cover 100% of the parameters with names and slug examples. The description adds value beyond the schema with call examples and a useful pricing hint: 'Brand Ambassadors floor at $40/hour in every market.' This helps agents choose valid parameter values.
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: 'Get the all-inclusive hourly rate range for a specific role in a specific city.' It clearly distinguishes itself from siblings like check_availability and plan_staffing through question examples and explicit exclusions.
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 explicit when-to-use guidance with natural language examples, and explicit when-not-to-use guidance: 'DO NOT use for availability or dates (use check_availability)' and 'For a multi-role budget, use plan_staffing.' This leaves little ambiguity about tool routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List event staffing roles TempGuru provides, with descriptions and skill tiers. Perfect for 'What kinds of event workers can I hire?', 'What roles do you staff for trade shows / festivals / corporate events?', or 'Do you have brand ambassadors?' questions. DO NOT use for what a role costs, use get_role_pricing with a city. get_roles() Returned slugs (brand-ambassadors, registration-staff, team-leads) are the exact values the other tools accept.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| roles | Yes | |
| total | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral context beyond annotations: the tool returns slugs that are the exact values other tools accept, and that entries include descriptions and skill tiers. This helps the agent predict integration behavior, meriting a score above baseline.
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 slightly longer than typical for zero parameters but each element earns its place: the first sentence states the core purpose, the question examples clarify usage, the DO NOT sentence provides routing, and the hints add cross-tool integration value. It is structured with clear separation, just slightly verbose.
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 zero-parameter, read-only tool with a high-quality output schema, the description covers everything an agent needs: what the tool does, when to use it, when to avoid it, how it integrates with other tools, and expected content. No meaningful gap remains.
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 100% schema coverage, so no parameter documentation is needed. The description further reinforces this with an example call get_roles() showing it accepts no arguments, which is helpful for the agent. A 4 aligns with the 0-parameter 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?
States a specific verb and resource ('List event staffing roles TempGuru provides') and immediately separates itself from get_role_pricing by explicitly naming it as the alternative for cost questions. The example user questions anchor the resource in concrete intents, leaving no ambiguity about what get_roles returns.
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 explicit when-to-use signals via representative question examples ('What kinds of event workers can I hire?', 'Do you have brand ambassadors?') and explicitly states when not to use it ('DO NOT use for what a role costs, use get_role_pricing with a city'). Names the sibling tool directly, leaving no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CALL THIS FIRST for event staffing requests. Returns a configured-market catalog match, role-level W-2 rate math, estimated totals, tier-based lead-time guidance, and state compliance flags from the event's city, date, roles, and headcount. It does not confirm order coverage or live inventory; a coordinator does that after buyer submission. Use granular tools only for a single rate, date, or state fact. A complete plan may save a non-contact snapshot for 30 days and return plan_id plus continuation. If it returns no plan_id and the buyer needs persistence, call save_staffing_plan once; never save a plan that already has an ID. This tool never accepts or submits contact details, reserves staff, or creates a quote request. Omit roles for the catalog and a suggested mix. Treat totals as planning estimates, not quotes. Branch on status: plan, needs_roles, roles_not_found, or city_not_found; confirm suggestions rather than auto-applying them.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Event city, name or slug (e.g., 'Chicago'). | |
| roles | No | Roles and headcount. Omit to receive the role catalog and a suggested mix. | |
| attendees | No | Expected attendee count. | |
| event_date | No | Event date as YYYY-MM-DD; legacy recognizable dates are still accepted. | |
| event_type | No | trade-show, conference, festival, concert, sporting-event, corporate, brand-activation, or other. | |
| description | No | Optional free-text event description, echoed into the plan. |
| Name | Required | Description |
|---|---|---|
| tip | No | |
| event | No | |
| status | Yes | Discriminator. Branch on this before reading the rest. |
| message | No | |
| plan_id | No | Complete plans only. Non-PII plan reference retained for 30 days when Redis persistence succeeds. |
| lead_time | No | |
| compliance | No | |
| next_steps | No | |
| offer_note | No | Published first-order offer note. Totals remain undiscounted planning estimates. |
| plan_lines | No | |
| suggestion | No | Closest known city/role for a miss. Confirm with the user before using it; do not auto-apply. |
| continuation | No | Complete plans only. Prefilled website handoff; may be present without plan_id when storage fails open. |
| plan_complete | No | status:plan only. false = one or more requested roles could not be priced and are EXCLUDED from all totals (see unpriced_roles) — resolve them and re-plan before presenting a budget or quoting. |
| requested_city | No | |
| staffing_notes | No | |
| unpriced_roles | No | status:plan with plan_complete:false — the requested lines missing from every total. |
| available_roles | No | |
| requested_roles | No | |
| unresolved_roles | No | |
| estimated_total_range | No | |
| overtime_adjusted_total_range | No | Present (non-null) only when daily/weekly OT (or a double-time band) applies to the schedule. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by disclosing side effects like saving a non-contact snapshot for 30 days, returning plan_id and continuation, not confirming coverage, not accepting contact details, and treating totals as estimates. It also tells the caller to branch on specific statuses, giving a clear behavioral contract.
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 dense but every sentence contributes important operational guidance. It is longer than average, but the length is justified by the complexity of the tool's branching, side effects, and exclusions.
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?
It covers main use, limitations, follow-up tools, side effects, parameter behavior, and status branching. With an output schema present, the lacking return-format detail does not create a 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 has 100% documented parameter coverage, so the description is not required to add param-level detail. It does call out inputs like city, date, roles, and headcount and mentions omitting roles for a catalog, but most of this is already captured in the schema descriptions.
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 'CALL THIS FIRST for event staffing requests' and names the concrete outputs: catalog match, W-2 rate math, estimates, lead-time guidance, and compliance flags. It distinguishes itself from granular and persistence tools, making 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance, instructs to use granular tools for single facts, names save_staffing_plan as the persistence fallback, and says never to save a plan that already has an ID. This is strong usage-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use only after the buyer reviews a staffing plan and asks to proceed. Requires the saved non-PII plan_id from plan_staffing or save_staffing_plan and returns a prefilled TempGuru-owned review form. This tool never accepts or transmits names, email, phone, company, or other contact details and never creates a CRM lead or quote reference. The buyer must open form_url, review the plan, enter their own details, and submit it; only that submission creates a lead. This is not a reservation and does not guarantee pricing or availability. If a complete plan has continuation.form_url but no plan_id, give that URL directly instead. Never collect contact details for an MCP call; re-run an expired plan.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | Saved non-PII plan reference returned by plan_staffing or save_staffing_plan. | |
| skill_id | No | Optional canonical TempGuru skill that assembled the plan. | |
| skill_version | No | Optional version of the TempGuru staffing skill used. | |
| source_platform | No | Optional agent/platform attribution, e.g. claude-ai, openclaw, or hermes. |
| Name | Required | Description |
|---|---|---|
| message | Yes | Human-readable outcome to relay to the buyer. |
| plan_id | Yes | |
| form_url | No | Prefilled TempGuru-owned review form. Present only when handoff_ready is true. |
| next_steps | Yes | Safe next actions; no agent-side contact collection. |
| plan_found | Yes | Whether the supplied non-PII plan_id resolved before expiry. |
| handoff_ready | Yes | true when the saved plan resolved and a prefilled buyer form URL was created. |
| buyer_submission_required | Yes | Always true. The buyer, not the agent, must enter contact details and submit the form. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already carry readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful non-obvious behavior: it never transmits contact information, never creates a lead itself, requires the buyer to open and submit the form, and does not reserve or guarantee pricing/availability. There is no contradiction with the annotation object.
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 dense but front-loaded with the trigger condition and key requirement. It is arguably a little long and contains a couple of repeated privacy-related caveats, but each sentence carries a meaningful operational or safety instruction for an agent.
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 the schema covers all parameters, an output schema exists, and annotations cover the read-only behavior, the description supplies what is left: preconditions, fallback behavior, expiration handling, and the PII boundary. The tool is fully covered from the perspective of an agent deciding whether and how to 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?
Schema description coverage is 100%, so the baseline applies. The description does reinforce that plan_id must be a saved non-PII plan reference from plan_staffing or save_staffing_plan, but it adds no new meaning for skill_id, skill_version, or source_platform beyond what the schema already documents.
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 names a specific verb and resource: after a buyer asks to proceed, return a TempGuru-owned pre-filled review form for a saved plan_id. It explicitly states the tool does not create a quote reference or CRM lead, which clearly distinguishes its purpose from quote-status or lead-creation 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?
It gives an explicit trigger condition, required input source, and the buyer's required follow-up action. It also gives concrete when-not guidance by saying to give continuation.form_url directly when no plan_id exists, to never collect contact details, and to re-run an expired plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explicitly save a complete non-contact staffing plan for 30 days so it can be shared, resumed, or linked to a later quote request. Use only when plan_staffing returned plan_complete:true without a plan_id and the user needs persistence. Never call this tool when plan_staffing already returned a plan_id. Provide the same confirmed city, date, event type, attendees, roles, headcount, hours, and days; the server recomputes rates, totals, lead time, and compliance before saving and does not accept caller-supplied pricing or totals. This does not reserve staff, submit contact details, or request a quote. Branch on status: saved is the only outcome with a durable plan_id; plan_incomplete requires revising the inputs; for rate_limited or storage_unavailable, give the buyer continuation.form_url directly because request_quote requires a saved plan_id.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Event city, name or slug (e.g. Chicago). | |
| roles | Yes | Confirmed roles, headcount, hours, and days to recompute and save. | |
| attendees | No | Expected attendee count. | |
| event_date | No | Event date as YYYY-MM-DD; legacy recognizable dates are still accepted. | |
| event_type | No | trade-show, conference, festival, concert, sporting-event, corporate, brand-activation, or other. |
| Name | Required | Description |
|---|---|---|
| status | Yes | Discriminator. Only status:saved means a resumable plan_id exists. |
| message | Yes | |
| plan_id | No | 12-character reference for the saved non-PII snapshot. |
| created_at | No | |
| expires_at | No | Conservative 30-day expiry for the saved snapshot. |
| plan_status | No | Planner branch that prevented persistence. |
| continuation | No | |
| next_actions | Yes | |
| resource_uri | No | Public no-store REST URI that restores the saved artifact. |
| schema_version | No | |
| quote_readiness | No | The buyer must open the handoff form and personally submit their contact details. |
| retry_after_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations by stating the server recomputes rates, totals, lead time, and compliance; does not accept client-supplied pricing; does not reserve staff, submit contact details, or request a quote; and saves for 30 days. The status hints also disclose how different outcomes behave without contradicting 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?
The description is front-loaded with purpose, then states when/not to call, then summarizes behavior, and ends with structured hint branching. Every major sentence earns its place, and the hints are organized in a readable conditional style despite their density.
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 an existing output schema, the description still covers the necessary context: prerequisite conditions, persistence, exclusion of alternatives, server-side behavior, and handling of all possible return statuses. Nothing essential is missing for an agent to decide when and how to call this 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?
With 100% schema description coverage, the schema already documents all parameters. The description adds useful integration context, such as submitting the same confirmed values and the server not accepting pricing or totals, but it does not materially deepen per-field semantics beyond what the schema provides.
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: explicitly save a complete non-contact staffing plan for 30 days with persistence. It clearly distinguishes itself from plan_staffing by saying it is used only when plan_staffing returned plan_complete:true without a plan_id, and it also distinguishes from request_quote by noting it does not request a quote.
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 condition for use ('only when plan_staffing returned plan_complete:true without a plan_id and the user needs persistence') and an explicit exclusion ('Never call this tool when plan_staffing already returned a plan_id'). It also provides alternative routing information via status hints, including when request_quote is not appropriate.
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.
get_policies2 fields changedInput schema / properties / topic / descriptionPrevious value: -"Optional policy topic or title. Omit to return all published topics."New value: +"Optional canonical policy topic. Choose an advertised enum value; omit for all policies or a broader question."Input schema / properties / topic / enumAdded value: +[
+ "minimum-booking-hours",
+ "cancellation-rescheduling",
+ "no-show-backfill",
+ "coi-additional-insured",
+ "payment-terms",
+ "background-checks",
+ "order-confirmation",
+ "quote-response",
+ "offers"
+]get_plan1 field changedOutput schema / properties / offer_noteAdded value: +{
+ "description": "Published first-order offer note. Snapshot totals remain undiscounted.",
+ "type": "string"
+}get_policies5 fields changedOutput schema / properties / policies / items / properties / cap_usdAdded value: +{
+ "type": "number"
+}Output schema / properties / policies / items / properties / codeAdded value: +{
+ "type": "string"
+}Output schema / properties / policies / items / properties / discount_percentAdded value: +{
+ "type": "number"
+}Output schema / properties / policies / items / properties / expiresAdded value: +{
+ "description": "Offer expiry date in YYYY-MM-DD format.",
+ "format": "date",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+ "type": "string"
+}Output schema / properties / policies / items / properties / scopeAdded value: +{
+ "type": "string"
+}plan_staffing1 field changedOutput schema / properties / offer_noteAdded value: +{
+ "description": "Published first-order offer note. Totals remain undiscounted planning estimates.",
+ "type": "string"
+}check_availability3 fields changedOutput schema / properties / catalog_matchAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Output schema / properties / city_found / descriptionPrevious value: -"false = city not in the published footprint (see message); true = guidance below."New value: +"false = city did not match the configured catalog (see message); true = planning guidance below, not confirmed coverage."Output schema / properties / coverage_confirmation_requiredAdded value: +{
+ "const": true,
+ "type": "boolean"
+}get_cities8 fields changedInput schema / properties / city / descriptionPrevious value: -"Optional single-city coverage check (nickname/borough aware). Returns covered yes/no + suggestion."New value: +"Optional single-city catalog match (nickname/borough aware). Returns catalog_match plus a suggestion; never a coverage promise."Output schema / properties / catalog_checkAdded value: +{
+ "const": true,
+ "description": "Present when a single-city catalog check was requested.",
+ "type": "boolean"
+}Output schema / properties / catalog_matchAdded value: +{
+ "description": "Whether the city resolved to a configured catalog entry; not an availability or coverage promise.",
+ "type": "boolean"
+}Output schema / properties / catalog_qualificationAdded value: +{
+ "type": "string"
+}Output schema / properties / city / descriptionPrevious value: -"The matched market (coverage check), or null if not covered."New value: +"The matched configured entry, or null when there was no catalog match."Output schema / properties / coverage_checkRemoved value: -{
- "const": true,
- "description": "Present when a single-city coverage check was requested.",
- "type": "boolean"
-}Output schema / properties / coverage_confirmation_requiredAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Output schema / properties / coveredRemoved value: -{
- "type": "boolean"
-}plan_staffing3 fields changedOutput schema / properties / event / properties / catalog_matchAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Output schema / properties / event / properties / coverage_confirmation_requiredAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Output schema / properties / event / requiredPrevious value: -[
- "city",
- "state",
- "market_tier"
-]New value: +[
+ "city",
+ "state",
+ "market_tier",
+ "catalog_match",
+ "coverage_confirmation_required"
+]check_availability2 fields changedInput schema / properties / date / descriptionPrevious value: -"Event date in ISO format (YYYY-MM-DD) or any date string parseable by Date()."New value: +"Event date as YYYY-MM-DD; legacy recognizable dates are still accepted."Input schema / properties / date / formatAdded value: +"date"plan_staffing3 fields changedInput schema / properties / event_date / descriptionPrevious value: -"Event date, ISO YYYY-MM-DD preferred."New value: +"Event date as YYYY-MM-DD; legacy recognizable dates are still accepted."Input schema / properties / event_date / formatAdded value: +"date"Input schema / properties / event_type / enumAdded value: +[
+ "trade-show",
+ "conference",
+ "festival",
+ "concert",
+ "sporting-event",
+ "corporate",
+ "brand-activation",
+ "other"
+]save_staffing_plan3 fields changedInput schema / properties / event_date / descriptionPrevious value: -"Event date, ISO YYYY-MM-DD preferred."New value: +"Event date as YYYY-MM-DD; legacy recognizable dates are still accepted."Input schema / properties / event_date / formatAdded value: +"date"Input schema / properties / event_type / enumAdded value: +[
+ "trade-show",
+ "conference",
+ "festival",
+ "concert",
+ "sporting-event",
+ "corporate",
+ "brand-activation",
+ "other"
+]request_quote1 field changedInput schema / properties / source_platform / enumPrevious value: -[
- "ai-agent",
- "ai-page",
- "ai-page-zh",
- "baidu-agent",
- "chatgpt-app",
- "chatgpt-gpt",
- "claude-ai",
- "claude-code",
- "claude-desktop",
- "cn-agent",
- "copilot-agent",
- "coze",
- "coze-bot",
- "custom-gpt",
- "gemini",
- "gemini-cli",
- "gemini-gem",
- "hermes",
- "kimi",
- "langchain",
- "lechat-agent",
- "llamaindex",
- "manual-test",
- "meta-ai",
- "mcp-handoff",
- "open-webui",
- "openai-codex",
- "openclaw",
- "perplexity-space",
- "pi",
- "poe-bot",
- "postman",
- "python-client",
- "skill",
- "team-demo",
- "website",
- "website-widget",
- "zhipu-agent",
- "openai-chatgpt",
- "openai-agents-sdk",
- "openai-mcp",
- "cursor",
- "cline",
- "windsurf",
- "perplexity",
- "qwen-ecosystem",
- "deepseek",
- "doubao",
- "mcp-client"
-]New value: +[
+ "ai-agent",
+ "ai-page",
+ "ai-page-zh",
+ "baidu-agent",
+ "chatgpt-app",
+ "chatgpt-gpt",
+ "claude-ai",
+ "claude-code",
+ "claude-desktop",
+ "cn-agent",
+ "copilot-agent",
+ "coze",
+ "coze-bot",
+ "custom-gpt",
+ "gemini",
+ "gemini-cli",
+ "gemini-gem",
+ "hermes",
+ "kimi",
+ "langchain",
+ "lechat-agent",
+ "llamaindex",
+ "manual-test",
+ "meta-ai",
+ "mcp-handoff",
+ "open-webui",
+ "openai-codex",
+ "openclaw",
+ "perplexity-space",
+ "pi",
+ "poe-bot",
+ "postman",
+ "prime-agent",
+ "python-client",
+ "skill",
+ "team-demo",
+ "website",
+ "website-widget",
+ "zhipu-agent",
+ "openai-chatgpt",
+ "openai-agents-sdk",
+ "openai-mcp",
+ "cursor",
+ "cline",
+ "windsurf",
+ "perplexity",
+ "qwen-ecosystem",
+ "deepseek",
+ "doubao",
+ "mcp-client"
+]request_quote3 fields changedInput schema / properties / source_platform / enumAdded value: +[
+ "ai-agent",
+ "ai-page",
+ "ai-page-zh",
+ "baidu-agent",
+ "chatgpt-app",
+ "chatgpt-gpt",
+ "claude-ai",
+ "claude-code",
+ "claude-desktop",
+ "cn-agent",
+ "copilot-agent",
+ "coze",
+ "coze-bot",
+ "custom-gpt",
+ "gemini",
+ "gemini-cli",
+ "gemini-gem",
+ "hermes",
+ "kimi",
+ "langchain",
+ "lechat-agent",
+ "llamaindex",
+ "manual-test",
+ "meta-ai",
+ "mcp-handoff",
+ "open-webui",
+ "openai-codex",
+ "openclaw",
+ "perplexity-space",
+ "pi",
+ "poe-bot",
+ "postman",
+ "python-client",
+ "skill",
+ "team-demo",
+ "website",
+ "website-widget",
+ "zhipu-agent",
+ "openai-chatgpt",
+ "openai-agents-sdk",
+ "openai-mcp",
+ "cursor",
+ "cline",
+ "windsurf",
+ "perplexity",
+ "qwen-ecosystem",
+ "deepseek",
+ "doubao",
+ "mcp-client"
+]Input schema / properties / source_platform / maxLengthRemoved value: -80Input schema / properties / source_platform / minLengthRemoved value: -1get_quote_status1 field changedInput schema / properties / reference / descriptionPrevious value: -"TG reference returned by request_quote, e.g. TG-ABC234."New value: +"TG reference returned after the buyer submits the TempGuru website form, e.g. TG-ABC234."request_quote36 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / attendeesRemoved value: -{
- "description": "Expected event attendance, if known (informs coverage ratios)",
- "exclusiveMinimum": 0,
- "maximum": 5000000,
- "type": "integer"
-}Input schema / properties / attireRemoved value: -{
- "description": "Staff attire requirements",
- "maxLength": 500,
- "type": "string"
-}Input schema / properties / budget_rangeRemoved value: -{
- "description": "Estimated total budget range if calculated, e.g. '$8,400–$12,600'",
- "maxLength": 120,
- "type": "string"
-}Input schema / properties / cityRemoved value: -{
- "description": "City where the event is held",
- "maxLength": 120,
- "minLength": 1,
- "type": "string"
-}Input schema / properties / companyRemoved value: -{
- "description": "Company or organization name",
- "maxLength": 160,
- "minLength": 1,
- "type": "string"
-}Input schema / properties / compliance_notesRemoved value: -{
- "description": "Any compliance flags surfaced by get_compliance_by_state",
- "maxLength": 2000,
- "type": "string"
-}Input schema / properties / contact_emailRemoved value: -{
- "description": "Contact email address for the quote response",
- "format": "email",
- "maxLength": 254,
- "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
- "type": "string"
-}Input schema / properties / contact_nameRemoved value: -{
- "description": "Full name of the contact person",
- "maxLength": 120,
- "minLength": 1,
- "type": "string"
-}Input schema / properties / contact_phoneRemoved value: -{
- "description": "Optional phone number for the coordinator to reach the buyer (event ops is phone-first; include when known)",
- "maxLength": 40,
- "type": "string"
-}Input schema / properties / event_datesRemoved value: -{
- "description": "Event dates as a human-readable string, e.g. 'June 15–17, 2026'",
- "maxLength": 160,
- "minLength": 1,
- "type": "string"
-}Input schema / properties / event_nameRemoved value: -{
- "description": "Name of the event (e.g. 'HIMSS 2026', 'Brand Fest Austin')",
- "maxLength": 200,
- "minLength": 1,
- "type": "string"
-}Input schema / properties / event_typeRemoved value: -{
- "description": "Event type: trade-show, conference, festival, concert, sporting-event, corporate, brand-activation, or other",
- "maxLength": 80,
- "minLength": 1,
- "type": "string"
-}Input schema / properties / locationsRemoved value: -{
- "description": "Additional cities for a multi-city / tour program. The top-level city, dates, and roles describe the primary or first location; each entry here adds another.",
- "items": {
- "properties": {
- "city": {
- "description": "City for this leg of a multi-city program",
- "maxLength": 120,
- "minLength": 1,
- "type": "string"
- },
- "event_dates": {
- "description": "Dates for this location, if they differ from the top-level dates",
- "maxLength": 160,
- "type": "string"
- },
- "roles": {
- "description": "Roles for this location if they differ from the top-level roles",
- "items": {
- "properties": {
- "headcount": {
- "description": "Number of staff needed at this location",
- "exclusiveMinimum": 0,
- "maximum": 10000,
- "type": "integer"
- },
- "role": {
- "description": "Staffing role name",
- "maxLength": 80,
- "minLength": 1,
- "type": "string"
- },
- "shifts": {
- "description": "Shift description for this location",
- "maxLength": 160,
- "type": "string"
- }
- },
- "required": [
- "role",
- "headcount"
- ],
- "type": "object"
- },
- "maxItems": 50,
- "type": "array"
- },
- "venue": {
- "description": "Venue for this location, if known",
- "maxLength": 200,
- "type": "string"
- }
- },
- "required": [
- "city"
- ],
- "type": "object"
- },
- "maxItems": 50,
- "type": "array"
-}Input schema / properties / plan_id / descriptionPrevious value: -"Optional plan_id returned by plan_staffing or save_staffing_plan; links the submitted quote to its saved non-PII plan"New value: +"Saved non-PII plan reference returned by plan_staffing or save_staffing_plan."Input schema / properties / rolesRemoved value: -{
- "description": "Roles and headcount needed for the event",
- "items": {
- "properties": {
- "headcount": {
- "description": "Number of staff needed",
- "exclusiveMinimum": 0,
- "maximum": 10000,
- "type": "integer"
- },
- "role": {
- "description": "Staffing role name, e.g. brand-ambassadors, registration-staff",
- "maxLength": 80,
- "minLength": 1,
- "type": "string"
- },
- "shifts": {
- "description": "Shift description, e.g. '2 days × 8h'",
- "maxLength": 160,
- "type": "string"
- }
- },
- "required": [
- "role",
- "headcount"
- ],
- "type": "object"
- },
- "maxItems": 50,
- "minItems": 1,
- "type": "array"
-}Input schema / properties / skill_id / descriptionPrevious value: -"Optional canonical TempGuru skill slug that assembled this request"New value: +"Optional canonical TempGuru skill that assembled the plan."Input schema / properties / skill_version / descriptionPrevious value: -"Optional version of the TempGuru staffing skill used to assemble this request"New value: +"Optional version of the TempGuru staffing skill used."Input schema / properties / skill_version / patternAdded value: +"^[0-9]{1,4}\\.[0-9]{1,4}\\.[0-9]{1,4}(?:-[0-9A-Za-z.-]{1,24})?(?:\\+[0-9A-Za-z.-]{1,24})?$"Input schema / properties / source_platform / descriptionPrevious value: -"Optional agent/platform attribution, e.g. chatgpt-gpt, claude-desktop, coze"New value: +"Optional agent/platform attribution, e.g. claude-ai, openclaw, or hermes."Input schema / properties / special_requirementsRemoved value: -{
- "description": "Any special requirements: language skills, certifications, overnight shifts, etc.",
- "maxLength": 2000,
- "type": "string"
-}Input schema / properties / venueRemoved value: -{
- "description": "Primary venue name and/or address, when known",
- "maxLength": 200,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "contact_name",
- "contact_email",
- "company",
- "event_name",
- "event_type",
- "city",
- "event_dates",
- "roles"
-]New value: +[
+ "plan_id"
+]Output schema / properties / buyer_submission_requiredAdded value: +{
+ "const": true,
+ "description": "Always true. The buyer, not the agent, must enter contact details and submit the form.",
+ "type": "boolean"
+}Output schema / properties / deal_nameRemoved value: -{
- "description": "CRM deal name, present when submitted.",
- "type": "string"
-}Output schema / properties / errorRemoved value: -{
- "description": "Present when submission failed.",
- "type": "string"
-}Output schema / properties / form_urlAdded value: +{
+ "description": "Prefilled TempGuru-owned review form. Present only when handoff_ready is true.",
+ "format": "uri",
+ "type": "string"
+}Output schema / properties / handoff_readyAdded value: +{
+ "description": "true when the saved plan resolved and a prefilled buyer form URL was created.",
+ "type": "boolean"
+}Output schema / properties / message / descriptionPrevious value: -"Human-readable outcome to relay to the user."New value: +"Human-readable outcome to relay to the buyer."Output schema / properties / next_steps / descriptionPrevious value: -"Present when submitted."New value: +"Safe next actions; no agent-side contact collection."Output schema / properties / plan_foundAdded value: +{
+ "description": "Whether the supplied non-PII plan_id resolved before expiry.",
+ "type": "boolean"
+}Output schema / properties / plan_idAdded value: +{
+ "pattern": "^[A-HJ-NP-Z2-9]{12}$",
+ "type": "string"
+}Output schema / properties / plan_linkedRemoved value: -{
- "description": "true when the supplied plan_id resolved and its saved snapshot was attached to the lead.",
- "type": "boolean"
-}Output schema / properties / referenceRemoved value: -{
- "description": "Short reference code the buyer can quote when following up.",
- "type": "string"
-}Output schema / properties / submittedRemoved value: -{
- "description": "true = lead created in TempGuru's CRM (or durably queued); false = submission failed (see error).",
- "type": "boolean"
-}Output schema / requiredPrevious value: -[
- "submitted",
- "message"
-]New value: +[
+ "handoff_ready",
+ "buyer_submission_required",
+ "plan_found",
+ "plan_id",
+ "message",
+ "next_steps"
+]save_staffing_plan3 fields changedOutput schema / properties / next_actions / items / enumPrevious value: -[
- "share",
- "revise",
- "request_quote",
- "plan_again",
- "retry_save",
- "continue_on_website",
- "request_quote_without_plan_id"
-]New value: +[
+ "share",
+ "revise",
+ "request_quote",
+ "plan_again",
+ "retry_save",
+ "continue_on_website"
+]Output schema / properties / quote_readiness / constPrevious value: -"needs_contact"New value: +"buyer_submission_required"Output schema / properties / quote_readiness / descriptionPrevious value: -"The plan is complete; contact details are still required before request_quote."New value: +"The buyer must open the handoff form and personally submit their contact details."check_availability2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_cities2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_compliance_by_state2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_plan3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / plan_id / descriptionPrevious value: -"12-character lookalike-free plan reference returned by plan_staffing."New value: +"12-character lookalike-free plan reference returned by plan_staffing or save_staffing_plan."Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_policies2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_quote_status2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_rate_benchmark2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_role_pricing2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_roles2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"plan_staffing2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"request_quote3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / plan_id / descriptionPrevious value: -"Optional plan_id returned by plan_staffing; links the submitted quote to its saved non-PII plan"New value: +"Optional plan_id returned by plan_staffing or save_staffing_plan; links the submitted quote to its saved non-PII plan"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"save_staffing_planget_compliance_by_state1 field changedOutput schema / properties / data_versionAdded value: +{
+ "description": "Version of the compliance dataset used for this result.",
+ "type": "string"
+}get_rate_benchmark3 fields changedInput schema / properties / role / descriptionPrevious value: -"Optional role name or slug to filter to one role."New value: +"Optional non-empty role name or slug to filter to one role."Input schema / properties / role / maxLengthAdded value: +100Input schema / properties / role / minLengthAdded value: +1plan_staffing1 field changedOutput schema / properties / compliance / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "jurisdiction": {
- "description": "US state or Canadian province the rules below belong to.",
- "type": "string"
- },
- "min_wage_usd": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "description": "US states only; null for Canadian provinces (coordinator confirms provincial wage floors)."
- },
- "note": {
- "type": "string"
- },
- "overtime_daily_hours": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "overtime_weekly_hours": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "unique_rules": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "jurisdiction",
- "min_wage_usd",
- "overtime_weekly_hours",
- "overtime_daily_hours",
- "unique_rules",
- "note"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "citation_note": {
+ "type": "string"
+ },
+ "currency_note": {
+ "type": "string"
+ },
+ "data_current_as_of": {
+ "description": "Date the jurisdiction dataset was last verified (YYYY-MM-DD).",
+ "type": "string"
+ },
+ "data_version": {
+ "description": "Version identifier for the jurisdiction dataset used by the plan.",
+ "type": "string"
+ },
+ "jurisdiction": {
+ "description": "US state or Canadian province the rules below belong to.",
+ "type": "string"
+ },
+ "min_wage_as_of": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Effective date of the stored wage floor; null when no wage is stored."
+ },
+ "min_wage_source": {
+ "anyOf": [
+ {
+ "format": "uri",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Authoritative wage source; null for Canadian plans where the coordinator confirms the floor."
+ },
+ "min_wage_usd": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "US states only; null for Canadian provinces (coordinator confirms provincial wage floors)."
+ },
+ "note": {
+ "type": "string"
+ },
+ "overtime_daily_hours": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "overtime_weekly_hours": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "unique_rules": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "jurisdiction",
+ "min_wage_usd",
+ "overtime_weekly_hours",
+ "overtime_daily_hours",
+ "unique_rules",
+ "data_version",
+ "data_current_as_of",
+ "min_wage_as_of",
+ "min_wage_source",
+ "currency_note",
+ "citation_note",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]request_quote4 fields changedInput schema / properties / attendeesAdded value: +{
+ "description": "Expected event attendance, if known (informs coverage ratios)",
+ "exclusiveMinimum": 0,
+ "maximum": 5000000,
+ "type": "integer"
+}Input schema / properties / locationsAdded value: +{
+ "description": "Additional cities for a multi-city / tour program. The top-level city, dates, and roles describe the primary or first location; each entry here adds another.",
+ "items": {
+ "properties": {
+ "city": {
+ "description": "City for this leg of a multi-city program",
+ "maxLength": 120,
+ "minLength": 1,
+ "type": "string"
+ },
+ "event_dates": {
+ "description": "Dates for this location, if they differ from the top-level dates",
+ "maxLength": 160,
+ "type": "string"
+ },
+ "roles": {
+ "description": "Roles for this location if they differ from the top-level roles",
+ "items": {
+ "properties": {
+ "headcount": {
+ "description": "Number of staff needed at this location",
+ "exclusiveMinimum": 0,
+ "maximum": 10000,
+ "type": "integer"
+ },
+ "role": {
+ "description": "Staffing role name",
+ "maxLength": 80,
+ "minLength": 1,
+ "type": "string"
+ },
+ "shifts": {
+ "description": "Shift description for this location",
+ "maxLength": 160,
+ "type": "string"
+ }
+ },
+ "required": [
+ "role",
+ "headcount"
+ ],
+ "type": "object"
+ },
+ "maxItems": 50,
+ "type": "array"
+ },
+ "venue": {
+ "description": "Venue for this location, if known",
+ "maxLength": 200,
+ "type": "string"
+ }
+ },
+ "required": [
+ "city"
+ ],
+ "type": "object"
+ },
+ "maxItems": 50,
+ "type": "array"
+}Input schema / properties / skill_id / enumPrevious value: -[
- "event-staffing-ordering",
- "event-staffing-compliance",
- "staffing-plan-from-event-brief",
- "urgent-event-backfill",
- "staffing-agency-partner-growth"
-]New value: +[
+ "event-staffing-ordering",
+ "event-staffing-compliance",
+ "staffing-plan-from-event-brief",
+ "urgent-event-backfill",
+ "staffing-agency-partner-growth",
+ "multi-city-activation-planner",
+ "event-staffing-procurement",
+ "tempguru-pro-operations"
+]Input schema / properties / venueAdded value: +{
+ "description": "Primary venue name and/or address, when known",
+ "maxLength": 200,
+ "type": "string"
+}check_availability1 field changedOutput schema / properties / city_tier / descriptionPrevious value: -"Market tier: hub = 25 major metros, mid = 129 secondary markets, small = 191 tertiary markets."New value: +"Market tier: hub = 25 major metros, mid = 128 secondary markets, small = 192 tertiary markets."get_cities2 fields changedOutput schema / properties / cities / items / properties / tier / descriptionPrevious value: -"Market tier: hub = 25 major metros, mid = 129 secondary markets, small = 191 tertiary markets."New value: +"Market tier: hub = 25 major metros, mid = 128 secondary markets, small = 192 tertiary markets."Output schema / properties / city / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "country": {
- "description": "US or CA.",
- "type": "string"
- },
- "name": {
- "type": "string"
- },
- "slug": {
- "type": "string"
- },
- "state": {
- "type": "string"
- },
- "state_abbr": {
- "type": "string"
- },
- "tier": {
- "description": "Market tier: hub = 25 major metros, mid = 129 secondary markets, small = 191 tertiary markets.",
- "enum": [
- "hub",
- "mid",
- "small"
- ],
- "type": "string"
- },
- "url": {
- "description": "City detail page on tempguru.co.",
- "type": "string"
- }
- },
- "required": [
- "slug",
- "name",
- "state",
- "state_abbr",
- "country",
- "tier",
- "url"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "country": {
+ "description": "US or CA.",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "state": {
+ "type": "string"
+ },
+ "state_abbr": {
+ "type": "string"
+ },
+ "tier": {
+ "description": "Market tier: hub = 25 major metros, mid = 128 secondary markets, small = 192 tertiary markets.",
+ "enum": [
+ "hub",
+ "mid",
+ "small"
+ ],
+ "type": "string"
+ },
+ "url": {
+ "description": "City detail page on tempguru.co.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "state",
+ "state_abbr",
+ "country",
+ "tier",
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]get_planget_policiesget_quote_statusget_role_pricing1 field changedOutput schema / properties / city_tier / descriptionPrevious value: -"Market tier: hub = 25 major metros, mid = 129 secondary markets, small = 191 tertiary markets."New value: +"Market tier: hub = 25 major metros, mid = 128 secondary markets, small = 192 tertiary markets."plan_staffing2 fields changedOutput schema / properties / continuationAdded value: +{
+ "additionalProperties": false,
+ "description": "Complete plans only. Prefilled website handoff; may be present without plan_id when storage fails open.",
+ "properties": {
+ "form_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "form_url",
+ "note"
+ ],
+ "type": "object"
+}Output schema / properties / plan_idAdded value: +{
+ "description": "Complete plans only. Non-PII plan reference retained for 30 days when Redis persistence succeeds.",
+ "pattern": "^[A-HJ-NP-Z2-9]{12}$",
+ "type": "string"
+}request_quote5 fields changedInput schema / properties / plan_idAdded value: +{
+ "description": "Optional plan_id returned by plan_staffing; links the submitted quote to its saved non-PII plan",
+ "maxLength": 12,
+ "pattern": "^[A-HJ-NP-Z2-9]{12}$",
+ "type": "string"
+}Input schema / properties / skill_idAdded value: +{
+ "description": "Optional canonical TempGuru skill slug that assembled this request",
+ "enum": [
+ "event-staffing-ordering",
+ "event-staffing-compliance",
+ "staffing-plan-from-event-brief",
+ "urgent-event-backfill",
+ "staffing-agency-partner-growth"
+ ],
+ "type": "string"
+}Input schema / properties / skill_versionAdded value: +{
+ "description": "Optional version of the TempGuru staffing skill used to assemble this request",
+ "maxLength": 40,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / source_platformAdded value: +{
+ "description": "Optional agent/platform attribution, e.g. chatgpt-gpt, claude-desktop, coze",
+ "maxLength": 80,
+ "minLength": 1,
+ "type": "string"
+}Output schema / properties / plan_linkedAdded value: +{
+ "description": "true when the supplied plan_id resolved and its saved snapshot was attached to the lead.",
+ "type": "boolean"
+}check_availability4 fields changedOutput schema / properties / in_pastAdded value: +{
+ "description": "True when the requested date is already in the past — confirm the date before planning.",
+ "type": "boolean"
+}Output schema / properties / role_foundAdded value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "null = no role requested; false = the requested role didn't match the catalog (see notes)."
+}Output schema / properties / role_suggestionAdded value: +{
+ "additionalProperties": false,
+ "description": "Closest known city/role for a miss. Confirm with the user before using it; do not auto-apply.",
+ "properties": {
+ "kind": {
+ "enum": [
+ "city",
+ "role"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "slug",
+ "name"
+ ],
+ "type": "object"
+}Output schema / properties / suggestion / descriptionPrevious value: -"Closest known city/role for a miss; retry with this slug."New value: +"Closest known city/role for a miss. Confirm with the user before using it; do not auto-apply."get_cities1 field changedOutput schema / properties / suggestion / descriptionPrevious value: -"Closest known city/role for a miss; retry with this slug."New value: +"Closest known city/role for a miss. Confirm with the user before using it; do not auto-apply."get_compliance_by_state2 fields changedOutput schema / properties / overtime_daily_double_hoursAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Start of the double-time band (hours/day) where the state has one (CA: 12); null otherwise."
+}Output schema / properties / seventh_day_overtimeAdded value: +{
+ "description": "True where a seventh-consecutive-day premium applies (CA).",
+ "type": "boolean"
+}get_role_pricing2 fields changedOutput schema / properties / role_noteAdded value: +{
+ "description": "Caveat about the resolved role (e.g. 'security' maps to unarmed Crowd Control, not licensed security).",
+ "type": "string"
+}Output schema / properties / suggestion / descriptionPrevious value: -"Closest known city/role for a miss; retry with this slug."New value: +"Closest known city/role for a miss. Confirm with the user before using it; do not auto-apply."plan_staffing21 fields changedInput schema / properties / attendees / maximumPrevious value: -9007199254740991New value: +5000000Input schema / properties / city / maxLengthAdded value: +120Input schema / properties / description / maxLengthAdded value: +2000Input schema / properties / event_date / maxLengthAdded value: +40Input schema / properties / event_type / maxLengthAdded value: +80Input schema / properties / roles / items / properties / days / maximumPrevious value: -9007199254740991New value: +365Input schema / properties / roles / items / properties / headcount / maximumPrevious value: -9007199254740991New value: +10000Input schema / properties / roles / items / properties / hours_per_shift / descriptionPrevious value: -"Hours per shift (default 8)."New value: +"Hours per shift (default 8, max 24)."Input schema / properties / roles / items / properties / hours_per_shift / maximumAdded value: +24Input schema / properties / roles / items / properties / role / maxLengthAdded value: +80Input schema / properties / roles / maxItemsAdded value: +50Output schema / properties / compliance / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "min_wage_usd": {
- "type": "number"
- },
- "note": {
- "type": "string"
- },
- "overtime_daily_hours": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "overtime_weekly_hours": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "state": {
- "type": "string"
- },
- "unique_rules": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "state",
- "min_wage_usd",
- "overtime_weekly_hours",
- "overtime_daily_hours",
- "unique_rules",
- "note"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "jurisdiction": {
+ "description": "US state or Canadian province the rules below belong to.",
+ "type": "string"
+ },
+ "min_wage_usd": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "US states only; null for Canadian provinces (coordinator confirms provincial wage floors)."
+ },
+ "note": {
+ "type": "string"
+ },
+ "overtime_daily_hours": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "overtime_weekly_hours": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "unique_rules": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "jurisdiction",
+ "min_wage_usd",
+ "overtime_weekly_hours",
+ "overtime_daily_hours",
+ "unique_rules",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / overtime_adjusted_total_range / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "currency": {
- "enum": [
- "USD",
- "CAD"
- ],
- "type": "string"
- },
- "high": {
- "type": "number"
- },
- "low": {
- "type": "number"
- },
- "note": {
- "type": "string"
- }
- },
- "required": [
- "low",
- "high",
- "currency",
- "note"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "currency": {
+ "enum": [
+ "USD",
+ "CAD"
+ ],
+ "type": "string"
+ },
+ "high": {
+ "type": "number"
+ },
+ "includes_double_time": {
+ "description": "True when a 2x band (CA/BC >12h/day, CA 7th consecutive day) is included.",
+ "type": "boolean"
+ },
+ "low": {
+ "type": "number"
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "low",
+ "high",
+ "currency",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / overtime_adjusted_total_range / descriptionPrevious value: -"Present (non-null) only when daily/weekly OT applies to the schedule."New value: +"Present (non-null) only when daily/weekly OT (or a double-time band) applies to the schedule."Output schema / properties / plan_completeAdded value: +{
+ "description": "status:plan only. false = one or more requested roles could not be priced and are EXCLUDED from all totals (see unpriced_roles) — resolve them and re-plan before presenting a budget or quoting.",
+ "type": "boolean"
+}Output schema / properties / suggestion / descriptionPrevious value: -"Closest known city/role for a miss; retry with this slug."New value: +"Closest known city/role for a miss. Confirm with the user before using it; do not auto-apply."Output schema / properties / unpriced_rolesAdded value: +{
+ "description": "status:plan with plan_complete:false — the requested lines missing from every total.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "days": {
+ "type": "number"
+ },
+ "headcount": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "hours_per_shift": {
+ "type": "number"
+ },
+ "role": {
+ "type": "string"
+ },
+ "suggestion": {
+ "additionalProperties": false,
+ "description": "Closest known city/role for a miss. Confirm with the user before using it; do not auto-apply.",
+ "properties": {
+ "kind": {
+ "enum": [
+ "city",
+ "role"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "slug",
+ "name"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "role"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / unresolved_roles / items / properties / daysAdded value: +{
+ "type": "number"
+}Output schema / properties / unresolved_roles / items / properties / headcountAdded value: +{
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / unresolved_roles / items / properties / hours_per_shiftAdded value: +{
+ "type": "number"
+}Output schema / properties / unresolved_roles / items / properties / suggestion / descriptionPrevious value: -"Closest known city/role for a miss; retry with this slug."New value: +"Closest known city/role for a miss. Confirm with the user before using it; do not auto-apply."request_quote16 fields changedInput schema / properties / attire / maxLengthAdded value: +500Input schema / properties / budget_range / maxLengthAdded value: +120Input schema / properties / city / maxLengthAdded value: +120Input schema / properties / company / maxLengthAdded value: +160Input schema / properties / compliance_notes / maxLengthAdded value: +2000Input schema / properties / contact_email / maxLengthAdded value: +254Input schema / properties / contact_name / maxLengthAdded value: +120Input schema / properties / contact_phone / maxLengthAdded value: +40Input schema / properties / event_dates / maxLengthAdded value: +160Input schema / properties / event_name / maxLengthAdded value: +200Input schema / properties / event_type / maxLengthAdded value: +80Input schema / properties / roles / items / properties / headcount / maximumPrevious value: -9007199254740991New value: +10000Input schema / properties / roles / items / properties / role / maxLengthAdded value: +80Input schema / properties / roles / items / properties / shifts / maxLengthAdded value: +160Input schema / properties / roles / maxItemsAdded value: +50Input schema / properties / special_requirements / maxLengthAdded value: +2000get_cities13 fields changedInput schema / properties / cityAdded value: +{
+ "description": "Optional single-city coverage check (nickname/borough aware). Returns covered yes/no + suggestion.",
+ "type": "string"
+}Input schema / properties / countryAdded value: +{
+ "description": "Optional country filter: 'US' or 'CA'.",
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "description": "Optional cap on the number of cities returned (full counts still in total/tier_breakdown).",
+ "exclusiveMinimum": 0,
+ "maximum": 9007199254740991,
+ "type": "integer"
+}Output schema / properties / cityAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "country": {
+ "description": "US or CA.",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "state": {
+ "type": "string"
+ },
+ "state_abbr": {
+ "type": "string"
+ },
+ "tier": {
+ "description": "Market tier: hub = 25 major metros, mid = 129 secondary markets, small = 191 tertiary markets.",
+ "enum": [
+ "hub",
+ "mid",
+ "small"
+ ],
+ "type": "string"
+ },
+ "url": {
+ "description": "City detail page on tempguru.co.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "state",
+ "state_abbr",
+ "country",
+ "tier",
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The matched market (coverage check), or null if not covered."
+}Output schema / properties / coverage_checkAdded value: +{
+ "const": true,
+ "description": "Present when a single-city coverage check was requested.",
+ "type": "boolean"
+}Output schema / properties / coveredAdded value: +{
+ "type": "boolean"
+}Output schema / properties / messageAdded value: +{
+ "type": "string"
+}Output schema / properties / noteAdded value: +{
+ "description": "Present when the list was truncated by limit.",
+ "type": "string"
+}Output schema / properties / requestedAdded value: +{
+ "type": "string"
+}Output schema / properties / returnedAdded value: +{
+ "description": "Number of cities in the cities array (after limit).",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / suggestionAdded value: +{
+ "additionalProperties": false,
+ "description": "Closest known city/role for a miss; retry with this slug.",
+ "properties": {
+ "kind": {
+ "enum": [
+ "city",
+ "role"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "slug",
+ "name"
+ ],
+ "type": "object"
+}Output schema / properties / total / descriptionPrevious value: -"Number of cities matching the filter."New value: +"Total cities matching the filter (before limit)."Output schema / requiredRemoved value: -[
- "total",
- "tier_breakdown",
- "cities"
-]get_compliance_by_state4 fields changedOutput schema / properties / currency_noteAdded value: +{
+ "description": "Reminder that wages change annually; verify before relying.",
+ "type": "string"
+}Output schema / properties / data_current_as_ofAdded value: +{
+ "description": "Date the compliance dataset was last verified (YYYY-MM-DD).",
+ "type": "string"
+}Output schema / properties / min_wage_as_ofAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Effective date of this state's stored minimum wage."
+}Output schema / properties / min_wage_sourceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Authoritative source URL for the minimum wage figure."
+}check_availability1 field changedOutput schema / properties / suggestionAdded value: +{
+ "additionalProperties": false,
+ "description": "Closest known city/role for a miss; retry with this slug.",
+ "properties": {
+ "kind": {
+ "enum": [
+ "city",
+ "role"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "slug",
+ "name"
+ ],
+ "type": "object"
+}get_rate_benchmark2 fields changedInput schema / properties / tier / descriptionPrevious value: -"Optional market tier filter."New value: +"Optional market tier; adds each role's measured span within that tier (tier_usd)."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "available_roles": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "basis": {
+ "type": "string"
+ },
+ "citation": {
+ "type": "string"
+ },
+ "data_version": {
+ "type": "string"
+ },
+ "edition": {
+ "type": "string"
+ },
+ "floors": {
+ "type": "string"
+ },
+ "index": {
+ "type": "string"
+ },
+ "markets_measured": {
+ "additionalProperties": false,
+ "properties": {
+ "hub": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "mid": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "small": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "small",
+ "mid",
+ "hub"
+ ],
+ "type": "object"
+ },
+ "methodology": {
+ "type": "string"
+ },
+ "methodology_url": {
+ "type": "string"
+ },
+ "rates": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "by_tier_usd": {
+ "additionalProperties": false,
+ "properties": {
+ "hub": {
+ "type": "string"
+ },
+ "mid": {
+ "type": "string"
+ },
+ "small": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "small",
+ "mid",
+ "hub"
+ ],
+ "type": "object"
+ },
+ "national_range_usd": {
+ "type": "string"
+ },
+ "role": {
+ "type": "string"
+ },
+ "role_key": {
+ "type": "string"
+ },
+ "tier": {
+ "enum": [
+ "hub",
+ "mid",
+ "small"
+ ],
+ "type": "string"
+ },
+ "tier_usd": {
+ "type": "string"
+ },
+ "typical_usd": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "role",
+ "role_key"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "reading_note": {
+ "type": "string"
+ },
+ "requested": {
+ "type": "string"
+ },
+ "requested_tier": {
+ "enum": [
+ "hub",
+ "mid",
+ "small"
+ ],
+ "type": "string"
+ },
+ "role_found": {
+ "const": false,
+ "type": "boolean"
+ },
+ "updated": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_role_pricing1 field changedOutput schema / properties / suggestionAdded value: +{
+ "additionalProperties": false,
+ "description": "Closest known city/role for a miss; retry with this slug.",
+ "properties": {
+ "kind": {
+ "enum": [
+ "city",
+ "role"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "slug",
+ "name"
+ ],
+ "type": "object"
+}plan_staffing1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "available_roles": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "roles": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "skill_tier": {
+ "type": "number"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "typical_shift_length_hours": {
+ "type": "number"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "roles"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "compliance": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "min_wage_usd": {
+ "type": "number"
+ },
+ "note": {
+ "type": "string"
+ },
+ "overtime_daily_hours": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "overtime_weekly_hours": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "state": {
+ "type": "string"
+ },
+ "unique_rules": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "state",
+ "min_wage_usd",
+ "overtime_weekly_hours",
+ "overtime_daily_hours",
+ "unique_rules",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "estimated_total_range": {
+ "additionalProperties": false,
+ "properties": {
+ "basis": {
+ "type": "string"
+ },
+ "currency": {
+ "enum": [
+ "USD",
+ "CAD"
+ ],
+ "type": "string"
+ },
+ "high": {
+ "type": "number"
+ },
+ "low": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "low",
+ "high",
+ "currency",
+ "basis"
+ ],
+ "type": "object"
+ },
+ "event": {
+ "additionalProperties": false,
+ "properties": {
+ "attendees": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "city": {
+ "type": "string"
+ },
+ "description": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "event_date": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "event_type": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "market_tier": {
+ "type": "string"
+ },
+ "state": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "city",
+ "state",
+ "market_tier"
+ ],
+ "type": "object"
+ },
+ "lead_time": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "days_until_event": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "event_date": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "recommendation": {
+ "enum": [
+ "yes",
+ "tight",
+ "rush",
+ "very-rush"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "event_date",
+ "days_until_event",
+ "recommendation",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "message": {
+ "type": "string"
+ },
+ "next_steps": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "overtime_adjusted_total_range": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "currency": {
+ "enum": [
+ "USD",
+ "CAD"
+ ],
+ "type": "string"
+ },
+ "high": {
+ "type": "number"
+ },
+ "low": {
+ "type": "number"
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "low",
+ "high",
+ "currency",
+ "note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Present (non-null) only when daily/weekly OT applies to the schedule."
+ },
+ "plan_lines": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "days": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "estimated_total_range": {
+ "additionalProperties": false,
+ "properties": {
+ "high": {
+ "type": "number"
+ },
+ "low": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "low",
+ "high"
+ ],
+ "type": "object"
+ },
+ "headcount": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "hourly_range": {
+ "additionalProperties": false,
+ "description": "All-inclusive hourly rate band (worker pay + payroll taxes + workers comp + liability).",
+ "properties": {
+ "high": {
+ "description": "Upper end of the hourly rate range.",
+ "type": "number"
+ },
+ "low": {
+ "description": "Lower end of the hourly rate range.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "low",
+ "high"
+ ],
+ "type": "object"
+ },
+ "hours_per_shift": {
+ "type": "number"
+ },
+ "role": {
+ "type": "string"
+ },
+ "role_slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "role",
+ "role_slug",
+ "headcount",
+ "hours_per_shift",
+ "days",
+ "hourly_range",
+ "estimated_total_range"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "requested_city": {
+ "type": "string"
+ },
+ "requested_roles": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "staffing_notes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "status": {
+ "description": "Discriminator. Branch on this before reading the rest.",
+ "enum": [
+ "plan",
+ "needs_roles",
+ "roles_not_found",
+ "city_not_found"
+ ],
+ "type": "string"
+ },
+ "suggestion": {
+ "additionalProperties": false,
+ "description": "Closest known city/role for a miss; retry with this slug.",
+ "properties": {
+ "kind": {
+ "enum": [
+ "city",
+ "role"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "slug",
+ "name"
+ ],
+ "type": "object"
+ },
+ "tip": {
+ "type": "string"
+ },
+ "unresolved_roles": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "role": {
+ "type": "string"
+ },
+ "suggestion": {
+ "additionalProperties": false,
+ "description": "Closest known city/role for a miss; retry with this slug.",
+ "properties": {
+ "kind": {
+ "enum": [
+ "city",
+ "role"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "slug",
+ "name"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "role"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}request_quote3 fields changedInput schema / properties / contact_phoneAdded value: +{
+ "description": "Optional phone number for the coordinator to reach the buyer (event ops is phone-first; include when known)",
+ "type": "string"
+}Output schema / properties / referenceAdded value: +{
+ "description": "Short reference code the buyer can quote when following up.",
+ "type": "string"
+}Output schema / properties / submitted / descriptionPrevious value: -"true = lead created in TempGuru's CRM; false = submission failed (see error)."New value: +"true = lead created in TempGuru's CRM (or durably queued); false = submission failed (see error)."get_rate_benchmarkArrange US physical gifts and branded merchandise with human quote and payment approval.
Staff scheduling — manage staff, shifts, assignments, certifications, and requests via AI.
Hire real humans for tasks agents can't do alone. 36 tools for the full hiring lifecycle.
Event registration at scale: events with photos, waitlists, virtual queues, and dynamic pricing.
Add one secure layer between your agents and this server.
