TempGuru Event Staffing
Server Details
W-2 event staffing data for AI agents: 345 US/CA markets, roles, rates, lead times, compliance.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 7 of 7 tools scored.
Each tool serves a distinct, non-overlapping purpose: availability dates, city lists, compliance info, pricing, role listing, comprehensive planning, and quote submission. There is no ambiguity between them.
All tool names follow a consistent verb_noun snake_case pattern (e.g., check_availability, get_cities, request_quote), making them predictable and easy to distinguish.
With 7 tools, the server covers the essential operations for event staffing without being excessive. The number fits the domain perfectly, providing a complete but not overwhelming surface.
The tool set covers the full workflow: discovery (cities, roles, pricing, compliance, availability), planning (plan_staffing), and action (request_quote). Minor gap: lack of a tool to modify or cancel a quote, but the core flow is complete.
Available Tools
8 toolscheck_availabilityCheck AvailabilityARead-onlyInspect
Check expected staffing availability for an event. Returns lead-time guidance based on city tier and how far out the event is. Perfect for 'Can you staff my event on [date] in [city]?', 'What's the lead time for booking brand ambassadors in [city]?', or 'Is it too late to staff a [date] event?' questions. Not a real-time inventory check, TempGuru staffs to demand via a 100,000+ worker W-2 network across 345 markets. 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 in ISO format (YYYY-MM-DD) or any date string parseable by Date(). | |
| role | No | Optional role name or slug to include rate context. | |
| count | No | Optional headcount for the event. |
Output Schema
| 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 | |
| message | No | Present when city_found is false. |
| city_tier | No | Market tier: hub = 25 major metros, mid = 129 secondary markets, small = 191 tertiary markets. |
| requested | No | Echo of the unmatched city input. |
| city_found | Yes | false = city not in the published footprint (see message); true = guidance below. |
| event_date | No | Normalized ISO date (YYYY-MM-DD). |
| recommendation | No | Lead-time guidance, NOT a reservation. Even rush is worth submitting. |
| days_until_event | No | |
| typical_lead_time_hours | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is clear. The description adds valuable behavioral context: it is not real-time inventory but a lead-time estimate based on city tier and event proximity. It explains the staffing model (100,000+ worker network) and what the result should not be used for. No contradiction with 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 concise: 4 lines of core purpose, then examples and hints. Every sentence adds value. No repetition. Front-loaded with the main purpose and use cases.
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 tool's complexity (4 params, 2 required, output schema exists), the description is complete. It explains what the tool returns (lead-time guidance), its limitations, and provides examples. Hints address edge cases. No gaps for agent decision-making.
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?
Input schema has 100% parameter description coverage, so baseline is 3. The description goes beyond schema by explaining how parameters relate to the output (city tier and event date influence lead-time). Examples show usage with actual values. Slightly more than baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and resource 'availability', with specific output: 'Returns lead-time guidance'. It distinguishes from sibling tools like get_role_pricing by explicitly stating 'DO NOT use for cost questions (use get_role_pricing)'. Examples further clarify usage.
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 provides explicit when-to-use scenarios ('Perfect for...' questions) and when-not-to-use ('DO NOT use for cost questions', 'never present the result as a reservation'). It also mentions alternatives (get_role_pricing) and hints encourage use even in rush windows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_citiesGet CitiesARead-onlyInspect
List cities where TempGuru staffs events, with tier classification (hub/mid/small). Perfect for 'What cities do you cover in [state]?', 'Where can I book event staff?', or 'Do you cover [city]?' questions. DO NOT use for rates (use get_role_pricing) or dates (use check_availability). For a full event plan, use plan_staffing instead. get_cities(state='TX') ; get_cities(tier='hub') ; get_cities() State accepts 'CA' or 'California'. US and Canada only, 345 markets total.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Optional filter to one tier only. | |
| state | No | Optional 2-letter state code (e.g., 'CA') or full state name. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Number of cities matching the filter. |
| cities | Yes | |
| tier_breakdown | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds scope (US/Canada, 345 markets) and input format (state accepts code or full name), enhancing behavioral 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?
Description is front-loaded with purpose and examples, but slightly verbose with redundant example syntax and hints. Could be trimmed without losing clarity.
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 list tool with output schema present, the description covers purpose, usage examples, exclusions, and scope (US/Canada). Complete enough for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with enum for tier and description for state. The description adds value with usage examples (get_cities(tier='hub')) and format hints for state ('CA' or 'California').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists cities with tier classification (hub/mid/small), distinguishing it from siblings like plan_staffing and check_availability.
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 (example questions) and when-not-to-use (rates, dates, full event plan) with alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_compliance_by_stateGet Compliance By StateARead-onlyInspect
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'). |
Output Schema
| 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 | |
| min_wage_usd | No | 2026 state minimum wage. |
| unique_rules | No | |
| citation_note | No | Operational guidance, not legal advice. |
| available_states | No | |
| workers_comp_included | No | |
| liability_coverage_included | No | |
| overtime_threshold_daily_hours | No | Daily overtime threshold where the state has one (CA, AK, NV, CO); null otherwise. |
| overtime_threshold_weekly_hours | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds that it returns minimum wage, overtime rules, state-specific quirks, and includes a hint about daily-overtime states. No contradiction.
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?
Well-structured: front-loaded purpose, example questions, disclaimers, code examples, and hints. Slightly verbose but efficient overall.
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 query with one parameter and an output schema present, the description covers purpose, usage boundaries, and behavioral hints (daily-overtime states). Complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description. The description adds example usages (state='CA', state='Tennessee'), providing extra context but not significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the event staffing compliance summary for a US state' with specific verb ('get') and resource ('compliance summary'), distinguishing it from sibling tools like get_role_pricing for rates.
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 example questions and a clear exclusion: 'DO NOT use for rates (use get_role_pricing)'. Also includes a disclaimer about legal advice. Could mention other sibling exclusions but is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rate_benchmarkGet Rate Benchmark (Rate Index)ARead-onlyInspect
The TempGuru Event Staffing Rate Index: all-inclusive W-2 hourly bill rates by role from 233 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. 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 role name or slug to filter to one role. | |
| tier | No | Optional market tier filter. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context: returns typical rate plus national range, brand ambassadors by tier, includes methodology and citation line. No contradictions. Slightly verbose but effective.
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, followed by use cases, exclusions, and examples. However, the hints section repeats some info from description and examples, increasing length but not harming clarity.
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 tool's simplicity (2 optional params, no output schema, read-only), the description fully covers what it does, what it returns, when to use, and even provides a citation line. No gaps.
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% for both parameters. Description adds meaning beyond schema: explains that 'role' filters to one role, 'tier' filters market tier, and specifically mentions brand ambassadors shown by tier. The examples demonstrate usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a national rate index for event staffing roles, with specific verb 'get' and resource 'rate benchmark'. It distinguishes from siblings by explicitly mentioning what it is not for (one city pricing, budget building). Use cases are clearly given.
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?
Explicitly lists when to use ('perfect for articles, reports needing benchmarks') and when not to ('do not use for one city's price or budget building'), with specific alternative tool names (get_role_pricing, plan_staffing). No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_role_pricingGet Role PricingARead-onlyInspect
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'). |
Output Schema
| 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 = 129 secondary markets, small = 191 tertiary markets. |
| requested | No | Echo of the unmatched input. |
| 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. |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. It adds context by stating what rates include (W-2 pay, workers comp, etc.) and clarifying the output is a non-binding range. No contradictions.
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, front-loading the core purpose in the first sentence. Every subsequent sentence adds value: usage contexts, exclusions, inclusions, examples, and hints. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple pricing query tool with 2 parameters and an output schema, the description covers all needed aspects: purpose, usage rules, parameter formatting, behavioral details, and practical hints. It is fully adequate for an LLM to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The description adds examples of acceptable values (names or slugs), shows usage examples, and provides a market-specific hint (Brand Ambassadors floor at $40/hour), significantly enriching the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get the all-inclusive hourly rate range'), identifies the resources ('specific role', 'specific city'), and distinguishes from sibling tools by specifying not to use for availability/dates (check_availability) or multi-role budgets (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 provides explicit when-to-use guidance ('Perfect for...'), when-not-to-use ('DO NOT use for availability or dates'), and alternative tools ('use check_availability', 'use plan_staffing'). It also includes cautionary notes ('never present the range as a binding quote').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rolesGet RolesARead-onlyInspect
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 | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| roles | Yes | |
| total | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by detailing return content (descriptions, skill tiers) and how returned slugs connect to other tools, 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 concise: three sentences plus brief examples and hints, all front-loaded with the core purpose. Every sentence adds value with no unnecessary words.
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 zero parameters, robust annotations, and an existing output schema, the description fully covers the tool's behavior. It also explains how the output (slugs) integrates with sibling tools, ensuring contextual completeness.
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, so the description has no parameter details to add. The baseline for 0 params is 4, and the description does not detract from that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'list[s] event staffing roles' with descriptions and skill tiers, using specific verbs and resource. It successfully distinguishes from siblings by explicitly noting not to use for costs and directing to get_role_pricing.
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 contexts (e.g., 'What kinds of event workers can I hire?') and a clear when-not-to-use statement ('DO NOT use for what a role costs, use get_role_pricing with a city'). This gives concrete guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plan_staffingPlan StaffingARead-onlyInspect
CALL THIS FIRST for any event staffing request. Takes the event shape (city, date, roles + headcount) and returns a complete staffing plan: coverage, per-role rate math with an estimated total range, lead-time guidance, and the state compliance flags that change the plan. Perfect for 'Staff my trade show in [city]', 'What would 6 registration staff for 2 days cost?', or 'Build me a staffing plan' requests. DO NOT use for a single fact, use get_role_pricing for one rate, check_availability for one date, get_compliance_by_state for one state. plan_staffing(city='Chicago', event_date='2026-08-14', event_type='trade-show', roles=[{role:'registration-staff', headcount:6, hours_per_shift:8, days:2}, {role:'team-leads', headcount:1}]) ; plan_staffing(city='Austin', attendees=300) Roles accept names or slugs (brand-ambassadors, registration-staff, team-leads). Omit roles to get the catalog plus a suggested mix. Totals are planning estimates, never binding quotes.
| 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, ISO YYYY-MM-DD preferred. | |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that totals are estimates and not binding quotes, and that roles accept names or slugs. Annotations already declare readOnlyHint=true, which is consistent. The description adds behavioral context (return types, estimate nature) beyond annotations, though it could mention idempotency or side effects.
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?
Every sentence earns its place. The description is front-loaded with the command to call first, uses clear sections for use cases, exclusions, examples, and hints. No redundant words.
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 6 parameters, 1 required, and no output schema, the description sufficiently explains the return value (coverage, rate math, total range, lead-time guidance, compliance flags). It covers parameter behavior and provides examples for complex nested objects.
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 baseline is 3. The description adds value by providing examples, hints about omitting roles to get a catalog, and clarifying that city is required. It explains behavior for optional parameters (e.g., roles omitted returns catalog and suggested mix).
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 'CALL THIS FIRST' and resource 'event staffing request', clearly distinguishing it from siblings like get_role_pricing, check_availability, etc. It defines the output as a complete staffing plan with coverage, rate math, total range, lead-time guidance, and compliance flags.
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?
Explicitly says when to use ('for any event staffing request') and when not to use (for single facts, use other tools), listing alternatives. The 'DO NOT use' clause directly guides the agent away from inappropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_quoteRequest QuoteAInspect
Submit a staffing request to TempGuru. Use this LAST, after building the plan (plan_staffing or the read tools) and after the user explicitly confirms it. Creates a structured lead in TempGuru's CRM, a human coordinator reviews and responds with a binding quote within one business day. Not a reservation; does not guarantee pricing or availability; no payment until the user approves the quote. DO NOT call speculatively or without user confirmation, this writes a real lead. request_quote(contact_name='Jane Doe', contact_email='jane@acme.com', company='Acme', event_name='Acme at HIMSS', event_type='trade-show', city='Chicago', event_dates='Aug 14-15, 2026', roles=[{role:'registration-staff', headcount:6}]) If this tool errors, fall back to https://tempguru.co/get-staffing or megan@tempguru.co / (904) 206-8953.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City where the event is held | |
| roles | Yes | Roles and headcount needed for the event | |
| attire | No | Staff attire requirements | |
| company | Yes | Company or organization name | |
| event_name | Yes | Name of the event (e.g. 'HIMSS 2026', 'Brand Fest Austin') | |
| event_type | Yes | Event type: trade-show, conference, festival, concert, sporting-event, corporate, brand-activation, or other | |
| event_dates | Yes | Event dates as a human-readable string, e.g. 'June 15–17, 2026' | |
| budget_range | No | Estimated total budget range if calculated, e.g. '$8,400–$12,600' | |
| contact_name | Yes | Full name of the contact person | |
| contact_email | Yes | Contact email address for the quote response | |
| compliance_notes | No | Any compliance flags surfaced by get_compliance_by_state | |
| special_requirements | No | Any special requirements: language skills, certifications, overnight shifts, etc. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when submission failed. |
| message | Yes | Human-readable outcome to relay to the user. |
| deal_name | No | CRM deal name, present when submitted. |
| submitted | Yes | true = lead created in TempGuru's CRM; false = submission failed (see error). |
| next_steps | No | Present when submitted. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it creates a real lead, is not a reservation, does not guarantee pricing/availability, and involves a human review within one business day. No contradictions with annotations (readOnlyHint=false, destructiveHint=false) and adds value beyond them.
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?
Well-structured: starts with core action, then usage order, outcome, warnings, example, fallback. Every sentence is informative with no fluff. Front-loaded with key points.
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 12 parameters, 8 required, no enums, and nested objects, the description covers purpose, usage order, behavioral nuances, fallback, and outcome. Output schema exists, so explaining return values is not needed. Complete for the complexity level.
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 baseline is 3. The description adds value with an example showing how to populate roles array, though it does not elaborate on every parameter beyond the schema. The example enhances understanding of complex param usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action 'Submit a staffing request' to TempGuru and distinguishes from sibling tools by specifying to use it last after planning and user confirmation. It provides an example and differentiates from related tools like 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?
Explicitly states when to use (after building plan and user confirmation) and when not to (speculatively) with strong warnings. Also provides fallback instructions if the tool errors, giving clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!