Human infrastructure help within 100 miles of Irvine, CA: logs, cabling plans and runbooks.
Scored across 3 tools
Each tool maps to a clearly distinct operation: listing available services, submitting a task request, and checking the status of an existing task. There is no meaningful overlap in purpose, and the descriptions reinforce the boundaries between discovery, creation, and status lookup.
All tools use snake_case with a predictable verb_noun pattern: get_human_task_status, list_human_services, request_human_task. The naming is consistent and readable, with the 'human' domain qualifier applied throughout.
Three tools are well matched to a narrow human task desk: browse services, submit a request, and check status. The surface is minimal but sufficient for the stated workflow, with no unnecessary or redundant tools.
The core lifecycle is covered: list services, request a task, and check task status. Minor gaps remain, such as cancelling or updating a submitted request, and retrieving final deliverables or task details beyond status, but these are not fatal for the stated review-request workflow.
Read the status of your own task using its ID and private task token. Never reveals other requests.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| task_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the meaningful access-control fact that the token authorizes only the caller's own request ('Never reveals other requests'), which is behavioral context the annotations do not provide.
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; the core action leads and the security constraint follows. Nothing wasted.
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 output schema, an agent calling this would benefit from knowing what status values come back and whether polling is expected. The description covers purpose and security but leaves the return contract entirely unspecified.
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 two parameters, so the description must compensate. It identifies what task_id and task_token mean and flags the token as private/secret, but gives no format, sourcing, or length guidance beyond what the schema's types already imply.
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 ('Read the status of your own task') and scopes it to the caller's own task, which distinguishes it from list_human_services and request_human_task. It stops short of naming those siblings, but the verb+resource is unambiguous.
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 phrase 'your own task' hints that this is the follow-up to a submission, but there is no explicit when-to-use statement, no mention of when to prefer list_human_services, and no note on how to obtain the task_token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Ron Long’s human infrastructure services within 100 miles of Irvine, Orange County, CA and intake requirements. Custom quotes; payments disabled. No system access granted.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely new behavioral context beyond them: custom quotes, payments disabled, and no system access granted — useful constraints an agent would not otherwise know. It stops short of describing the result payload.
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?
Three short clauses with the scope front-loaded and constraints after; nothing is padded. The terse, telegraphic phrasing ('Custom quotes; payments disabled.') borders on cryptic but stays compact.
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 output schema, the description should hint at what comes back; 'services ... and intake requirements' gestures at the fields but gives no structure, pagination, or format. The behavioral constraints compensate partially, but an agent still doesn't know the shape of the response.
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 takes zero parameters, so per the baseline this scores 4. The description correctly frames the scope (fixed geography, fixed provider) as intrinsic rather than something the caller can vary.
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 ('List') and resource ('human infrastructure services') plus a geographic scope (within 100 miles of Irvine, CA) and includes intake requirements. The resource term is somewhat idiosyncratic jargon, but an agent can tell this is a catalog-listing tool and not the sibling request/status 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?
There is no explicit when-to-use guidance, no mention of the siblings request_human_task or get_human_task_status, and no stated preconditions. Usage is only implied by the fact that it lists services.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a real task request to Ron Long using previously delegated authority. Job location must be within 100 miles of Irvine, Orange County, CA. Creates a review request, not a booking or charge. Never include credentials. Save the returned private task token.
| Name | Required | Description | Default |
|---|---|---|---|
| deadline | Yes | Requested deadline including time zone | |
| job_city | Yes | Job city and state; must be within 100 miles of Irvine, Orange County, California | |
| agent_name | Yes | ||
| budget_usd | Yes | ||
| payer_name | Yes | ||
| service_id | Yes | ||
| description | Yes | ||
| contact_email | Yes | ||
| idempotency_key | Yes | ||
| job_postal_code | Yes | ||
| delegation_confirmed | Yes | ||
| authorized_to_request | Yes | ||
| service_area_confirmed | Yes | ||
| system_access_delegated | No | Required true for terminal work; owner-delegated access is verified before work. | |
| estimated_distance_miles | Yes | Estimated straight-line miles from Irvine; owner verifies before acceptance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorld, non-read-only, idempotent and non-destructive, so the bar is lower. The description still adds real behavioral value: no booking or charge occurs, credentials must never be included, and the returned private task token must be saved — none of which the annotations convey.
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?
Five short sentences, front-loaded with purpose, then constraints, then the token-handling instruction. Every sentence carries information an agent needs; the only minor cost is that the terse style leaves several required fields unexplained rather than that it wastes 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 15-parameter, 14-required submission tool with no output schema and low schema coverage, the description is thin. An agent still has no guidance on budget limits, service type selection, why three booleans must be true, or how the idempotency key should be generated beyond the regex.
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 15 parameters at only 27% schema description coverage, the description needs to compensate heavily but does not. It touches only the location constraint and a credentials warning; budget, service_id enum values, the three const-true confirmation booleans, system_access_delegated, and the idempotency key format are all left to the schema or undocumented entirely.
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 — 'Submit a real task request to Ron Long' — and clearly signals this creates a review request rather than a booking or charge. It is distinguishable from get_human_task_status and list_human_services, though it never names those siblings explicitly.
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 clear preconditions for use: previously delegated authority, job location within 100 miles of Irvine, and a statement that this produces a review request rather than a commitment. It does not explicitly compare against the sibling tools or state when-not-to-use, which keeps it below a 5.
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_human_task_statuslist_human_servicesrequest_human_taskHuman field services for AI agents: site photos, equipment checks, remote hands and coordination.
Hire a real human for real-world verification, product testing, AI output review, and errands.
Agents commission Humans for real-world tasks. San Diego, invite-only; elsewhere, register interest.
Independent owner-side QA for structured-cabling certification closeout evidence.
Add one secure layer between your agents and this server.
