MCP Near Me

Start a service request

start_service_request

Idempotent

Use this immediately when the user asks to book a supported local service. Pass the complete user intent and every public service detail already stated. The tool determines the vertical, creates the server-side request, and returns a vertical-specific introduction plus either one intake field batch or matching data when intake is already complete. In one customer-facing reply, lead with the introduction and immediately continue with the returned next step; do not wait for acknowledgment. Send provider_hint only when the user explicitly named a company. Do not collect contact PII.

Input Schema

TableJSON Schema

Name	Required	Description
`answers`	No
`user_intent`	Yes
`provider_hint`	No
`vertical_hint`	No	Optional exact live vertical ID. Omit it when uncertain and let the server classify user_intent.
`idempotency_key`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedSep 8, 2026

changedInput schema / properties / answers / additionalProperties
```
Previous value: -{}New value: +false
```

addedInput schema / properties / answers / properties

Added value: +{
+  "appliance_type": {
+    "description": "Appliance type. Use the exact key appliance_type."
+  },
+  "brand": {
+    "description": "Brand. Use the exact key brand."
+  },
+  "model": {
+    "description": "Model. Use the exact key model."
+  },
+  "problem_description": {
+    "description": "Problem. Use the exact key problem_description."
+  },
+  "selected_time_key": {
+    "description": "Exact time key returned by MCP Near Me after the user chooses an arrival window.",
+    "minLength": 1,
+    "type": "string"
+  },
+  "zip_code": {
+    "description": "ZIP. Use the exact key zip_code."
+  }
+}

removedInput schema / properties / answers / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```

addedInput schema / properties / vertical_hint / description

Added value: +"Optional exact live vertical ID. Omit it when uncertain and let the server classify user_intent."

addedInput schema / properties / vertical_hint / enum

Added value: +[
+  "appliance_repair",
+  "commercial_kitchen_refrigeration_repair"
+]

removedInput schema / properties / vertical_hint / maxLength
```
Removed value: -100
```
removedInput schema / properties / vertical_hint / minLength
```
Removed value: -3
```

First observedSep 1, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare idempotentHint=true and readOnly=false, which are consistent with the description's claim of creating a request. The description adds valuable behavioral context: it returns a vertical-specific introduction and a next step, instructs how to format the reply, and warns against collecting PII. This goes beyond the annotations and gives agents clear expectations.

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

Conciseness5/5

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

The description is front-loaded with the action trigger and then flows logically through usage, behavior, and constraints. Every sentence adds value; there is no redundancy or filler. The structure is clear and easily digestible for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description does not need to explain return values. It covers the essential context: when to use, what to pass, what to expect in return, and how to respond. It is sufficiently complete for a tool with this complexity, though it could benefit from a brief mention of error handling or fallback behavior.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20%, so the description must compensate. It does explain the purpose of user_intent (complete intent) and provider_hint (only when named), and hints at answers via 'every public service detail already stated'. However, it does not clarify idempotency_key or the structure of nested answers beyond what the schema keys show. The description adds some meaning but leaves gaps for agents.

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

Purpose5/5

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

The description clearly states the tool's purpose: to start a service request when the user asks to book a local service. It specifies the action (creates server-side request), the resource (service request), and distinguishes itself from siblings by being the immediate entry point. The phrase 'Use this immediately' differentiates it from other booking-related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a clear trigger condition ('when the user asks to book a supported local service') and gives specific usage constraints: pass complete user intent, send provider_hint only when a company is named, and do not collect contact PII. While it doesn't explicitly name alternatives, the instruction to use it immediately implies it is the first step, which is sufficient guidance.

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

All MCP Near Me tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?