Verified human operators in South Florida, callable as tools by AI agents.
Scored across 8 tools
Most tools are clearly separated by purpose: item handoff, environment assessment, property inspection, technical survey, physical test, location verification, witnessing, and human stand-in. The closest overlaps are stand_in vs witness_event vs test_action, which all involve physical presence, but their descriptions distinguish interactive role, passive recording, and defined pass/fail action.
Six of eight names follow a verb_noun pattern (collect_item, inspect_property, test_action, verify_location, witness_event) with stand_in as a phrasal verb variant. environment_assessment and technical_survey are noun phrases, which is a minor deviation but still readable and predictable.
Eight tools is well-scoped for a physical-task API covering distinct task types. Each tool represents a meaningful capability and none feels redundant or trivial.
The surface covers a broad set of physical-agent tasks: collection, assessment, inspection, survey, testing, verification, witnessing, and stand-in presence. Minor lifecycle gaps like task status, cancellation, or rescheduling are not exposed, but the core task types are well covered.
Pick up or hand over a physical item: documents, a device, a sample kit, a key, a check. Returns a chain-of-custody log with photos at both ends and signatures captured. Declared contents only; no cash, controlled items, weapons or hazardous materials.
| Name | Required | Description | Default |
|---|---|---|---|
| deadline | No | ||
| budget_cap | No | ||
| pickup_address | Yes | ||
| dropoff_address | Yes | ||
| item_declaration | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it discloses the return artifact (chain-of-custody log with photos at both ends and signatures), and sets a clear eligibility boundary (declared contents only; prohibited item classes). It omits failure handling, cost/authorization expectations, and what happens if the deadline or budget cap cannot be met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero waste: the action and item examples come first, the return artifact second, the eligibility restriction last. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter mutation-style tool with no annotations and no output schema, the description covers the return artifact and the key eligibility restriction well. It is incomplete on the two optional parameters (deadline, budget_cap) and on operational behavior such as failure or handover verification, which an agent would need to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across five parameters, so the description must compensate and largely does not. It clarifies 'item_declaration' as declared contents and implies pickup/dropoff meaning, but says nothing about how 'deadline' or 'budget_cap' affect behavior, nor about address formats or constraints.
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+resource combination ('pick up or hand over a physical item') and gives concrete examples (documents, device, sample kit, key, check), so the agent knows exactly what the tool does. It does not explicitly contrast with any sibling, but the siblings are in an entirely different domain, so confusion risk is low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the item examples and the prohibition list ('no cash, controlled items, weapons or hazardous materials'), which functions as a when-not condition. However, there is no explicit guidance on when to choose this tool over alternatives, no prerequisites, and no discussion of deadline or budget-cap implications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clinically informed environment assessment by a nurse: home-safety and discharge-readiness, assisted-living and facility inspections, medically credible incident witness. Structured assessment to the customer's instrument with photos. Attestation states an environment report, not clinical care or diagnosis.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| deadline | No | ||
| budget_cap | No | ||
| instrument | Yes | The customer's assessment instrument or checklist |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses that a nurse performs the work, that output includes photos plus a structured report to the customer's instrument, and that the attestation explicitly excludes clinical care or diagnosis — an important scope limit. It says nothing about how budget_cap or deadline affect execution, failure modes, or turnaround, which matters for a commissioned assessment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences that front-load the who/what and then the deliverable and attestation scope. Every clause carries information, though the long comma-separated scenario list is slightly crammed and would read better as separate sentences.
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 who performs it, the deliverable (structured report with photos) and the liability boundary, which is good for a tool with no output schema and no annotations. But with four parameters and only one documented, plus no explanation of deadline or budget cap behavior, an agent cannot confidently set the inputs.
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 only 25% — only 'instrument' is documented, and the description merely echoes that ('assessment to the customer's instrument'). The three other parameters (address, deadline, budget_cap) get no semantic clarification in either the schema or the description, so the description fails to compensate for the low coverage.
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+resource ('environment assessment') and qualifies it ('clinically informed ... by a nurse'), which distinguishes it from the generic inspect_property and technical_survey siblings. The enumerated scenarios (home-safety, discharge-readiness, facility inspection, incident witness) sharpen the scope, though the phrase 'environment assessment' alone is broad.
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?
Lists concrete scenarios where this applies (home-safety/discharge-readiness, assisted-living and facility inspections, incident witnessing), which implies when to use it. However, it never states when NOT to use it or explicitly routes to the closest siblings like inspect_property or technical_survey, leaving the agent to infer differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Structured condition report for a property, unit, vehicle, equipment, job site or storm damage: 30-100 photos to a checklist, measurements where asked, a defect list with severity, a one-page report, signed attestation.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| deadline | No | ||
| checklist | Yes | ||
| budget_cap | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose some process and deliverables: 30-100 photos, checklist-driven measurements, defect severity, a one-page report, and a signed attestation. It does not state whether the tool mutates data, requires authorization, has cost or duration implications, or how the attestation is handled. The disclosure is useful but incomplete for an unannotated tool.
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 a single front-loaded sentence with a clear colon-delimited list of report components. It is dense but efficient and avoids repetition. It could be slightly more scannable, but every clause adds a concrete deliverable.
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?
This is a multi-parameter tool with no annotations, no output schema, and zero schema description coverage. The description explains some outputs but leaves critical inputs—address, checklist format, deadline semantics, budget_cap behavior—unexplained. Given the complexity, an agent lacks enough context to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across four parameters, so the description must compensate. It only vaguely gestures at 'checklist' and 'measurements where asked' and never explains address, deadline, or budget_cap. The required address and checklist parameters are especially underspecified given their importance.
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 what the tool produces: a 'Structured condition report' covering properties, units, vehicles, equipment, job sites, or storm damage. It enumerates concrete report components (photos, checklist, measurements, defect list, report, attestation), making the purpose specific. It does not, however, distinguish itself from siblings like technical_survey or environment_assessment, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the subjects listed—property, unit, vehicle, equipment, job site, storm damage—but there is no explicit guidance on when to choose this over technical_survey, environment_assessment, or other siblings. No exclusions or prerequisites are stated. An agent can infer it is for condition inspections but must guess about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Be the human for an agent-run process: let the technician in, sign for the delivery, attend the walkthrough, answer the inspector's questions from a script; safety officer on site for a robot deployment (nurse). Returns video, the script as executed, and a written outcome.
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | ||
| address | Yes | ||
| budget_cap | No | ||
| specialist | No | ||
| scheduled_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose the return payload (video, script as executed, written outcome), which is valuable given there is no output schema. However, for a costly real-world action that dispatches a person to an address, it says nothing about permissions, geographic constraints, cancellation, cost mechanics, or what happens if the human cannot complete the script.
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?
It is a single dense sentence with semicolon-separated use cases; nothing is truly wasted, but the list of vignettes crowds out the parameter and behavioral detail an agent actually needs before invoking it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% parameter documentation, the description must do all the work. It covers the return shape but leaves three of five parameters undefined and omits any operational constraints for what is an irreversible, real-world dispatch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters. The description explains 'script' (questions answered from a script) and implies 'address' (on site), but budget_cap, specialist, and scheduled_at are entirely undocumented in both schema and description — the agent must guess at their meaning and format.
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 concrete verb and resource — dispatch a physical human to act on an agent's behalf — and grounds it with vivid examples (letting a technician in, signing for a delivery, attending a walkthrough). It's clear what the tool does, though it never explicitly contrasts with the nearest sibling, witness_event.
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 examples imply when to use it (situations requiring a physical human presence), which is more than nothing. But there is no when-not guidance, no mention of prerequisites, and no differentiation from witness_event or verify_location, which an agent would need to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Technical survey by an engineer: robot-deployment site readiness (power, network, bay, floor, elevator, access), building systems and equipment condition, measured reports for lenders and boards, documentation packs for a licensed engineer's milestone work. Attestation states a qualified observation, not a stamped engineering opinion.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| deadline | No | ||
| checklist | Yes | ||
| budget_cap | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It adds an important caveat that the attestation is a qualified observation rather than a stamped engineering opinion, but it does not explain whether invoking the tool schedules an engineer, creates a work order, incurs cost against budget_cap, or has any 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?
The description is concise and reasonably front-loaded, with the survey scope stated first and the attestation caveat second. The first sentence is dense, but there is little wasted text.
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 four-parameter tool with no annotations and no output schema, the definition is incomplete. It explains the survey domain but omits operational behavior, parameter guidance, expected return, scheduling implications, and cost/deadline handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the four parameters. It provides domain context that may loosely inform the checklist, but it never mentions address, deadline, checklist structure, or budget_cap, leaving all parameter semantics undocumented.
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 identifies the resource as a technical survey and lists its domains, but it does not state the action the tool performs, such as creating, requesting, or recording a survey. It also does not explicitly distinguish itself from siblings like inspect_property or environment_assessment, leaving the agent to infer the intended operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage contexts such as robot-deployment readiness, building systems condition, lender/board reporting, and licensed-engineer milestone work. However, it gives no explicit when-to-use guidance, no exclusions, and no comparison to the sibling inspection or assessment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a defined physical action and report: open the door with the code, test the lock, run the appliance, stand where the robot will stand and measure. Returns video of the action, pass/fail against the written criteria, and measurements.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| address | Yes | ||
| deadline | No | ||
| budget_cap | No | ||
| pass_criteria | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the return artifacts (video recording, pass/fail verdict against written criteria, measurements), which is genuinely useful since no output schema exists. It says nothing about prerequisites (site access, codes, whether a human or robot executes), what happens when the action fails or the deadline passes, or how budget_cap constrains the run — significant gaps for a real-world physical operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the verb front-loaded, examples inline, then the outputs. No filler; the example list is a bit dense but each clause adds distinguishing detail.
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?
A consequential real-world action tool with zero annotations, no output schema, and 0% parameter coverage needs far more: execution model, failure/timeout behavior, cost implications of budget_cap, and deadline semantics are all absent. The return-value sentence is the only thing preventing a 1.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters, so the description must compensate. It only hints at two of them — 'action' via examples and 'pass_criteria' as 'written criteria' — while 'address', 'deadline', and 'budget_cap' are never mentioned, leaving format and semantics (is address a street address, a unit, a coordinate?) undefined.
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 ('perform a defined physical action') plus the reporting outcome (video, pass/fail against written criteria, measurements), and the examples (open door with code, test lock, run appliance, stand-and-measure) make the resource concrete. It never names or contrasts with a sibling, and 'stand where the robot will stand and measure' overlaps noticeably with stand_in, so an agent cannot fully rule out the alternatives from this text alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use statement and no mention of the sibling tools (stand_in, verify_location, environment_assessment, witness_event) that overlap in domain. Usage is only inferable from the example actions and the presence of pass_criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm a physical fact: a business is open and operating, a property exists and matches its listing, signage, occupancy, condition, an address is real. Returns geotagged timestamped photos, a 60-second egocentric clip, a yes/no with confidence score, and a two-line signed attestation.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| criteria | Yes | ||
| deadline | No | ||
| checklist | No | ||
| budget_cap | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses return artifacts: geotagged timestamped photos, a 60-second clip, a yes/no confidence score, and a signed attestation. However, it omits important operational traits such as execution model, permissions, cost implications, privacy considerations, and how deadline or budget constraints affect behavior.
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 two tight sentences, front-loading the purpose before listing return artifacts. The examples and return details are relevant, though the list of verifiable facts is somewhat broad.
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?
This is a complex physical-verification tool with five parameters, no annotations, no output schema, and 0% schema description coverage. The description explains the purpose and return artifacts, but it leaves parameter meanings and key operational constraints unexplained, so it is not complete enough for reliable 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 description coverage is 0% for five parameters, and the description does not explain any parameter semantics. It does not clarify what 'criteria' should contain, what 'checklist' is for, how 'deadline' is used, or what 'budget_cap' constrains, leaving the schema's bare types as the only guidance.
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, 'Confirm,' and clearly identifies the resource as physical facts about a location, with concrete examples such as business operation, property existence, signage, occupancy, and address validity. It does not explicitly differentiate itself from siblings like inspect_property or witness_event, but the overall purpose is clear.
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 examples imply when the tool is useful, such as verifying a business is open or a property matches its listing, but there is no explicit guidance on when to choose this tool versus alternatives. No exclusions, prerequisites, or sibling routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Be present and record: a delivery, an installation, a signing, a meter reading, a robot demo, an inventory count. Returns continuous egocentric video, timestamps, and a written sequence of what happened.
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | ||
| address | Yes | ||
| budget_cap | No | ||
| specialist | No | ||
| scheduled_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the core behavior: physical presence recording and return of continuous egocentric video, timestamps, and a written sequence. It omits important behavioral details such as privacy/consent implications, duration, permissions, cancellation, and what budget_cap or specialist affect.
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 compact and front-loaded, with the action first and the return values second. The examples are useful rather than noisy, though the opening phrase 'Be present and record' is slightly less precise than a direct verb-resource statement.
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?
The tool has five parameters, three required, no annotations, no output schema, and 0% schema description coverage. The description covers the return format and gives event examples, but it does not adequately explain required inputs, optional parameters, scheduling, or operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all five parameters. The description implicitly gives examples for the 'event' parameter, but it does not explain address, scheduled_at, budget_cap, or specialist, leaving most parameter meaning undocumented.
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, 'be present and record,' and gives concrete event examples plus the returned artifacts. It is clearly distinguishable from siblings like inspect_property or technical_survey, though it does not explicitly name or contrast those alternatives.
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 listed event types imply when the tool is appropriate, such as deliveries, installations, signings, and inventory counts. However, there is no explicit guidance on when to use this instead of siblings like stand_in or verify_location, and no exclusions or prerequisites are stated.
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.
collect_itemenvironment_assessmentinspect_propertystand_intechnical_surveytest_actionverify_locationwitness_eventHire a verified local human for small real-world tasks your AI agent can't do.
Human-as-a-Service for AI agents. Delegate tasks that need a real human, get results via API.
Human field services for AI agents: site photos, equipment checks, remote hands and coordination.
Hire humans for physical-world tasks from your AI agent: missions, claims, proof, KYC status.
Add one secure layer between your agents and this server.