MCP Near Me

Start a service request

start_service_request

Idempotent

Start a new supported service request immediately with the user's full intent and known public facts. Returns the vertical introduction and next intake/matching step, including availability when intake is complete; no separate lookup is needed. Use provider_hint only for an explicitly named company.

Input 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

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 21, 2026
- changedInput schema / properties / answers / properties / appliance_type / description
```
Previous value: -"Appliance type. Use the exact key appliance_type."New value: +"Appliance type"
```
- changedInput schema / properties / answers / properties / brand / description
```
Previous value: -"Brand. Use the exact key brand."New value: +"Brand"
```
- changedInput schema / properties / answers / properties / model / description
```
Previous value: -"Model. Use the exact key model."New value: +"Model"
```
- changedInput schema / properties / answers / properties / problem_description / description
```
Previous value: -"Problem. Use the exact key problem_description."New value: +"Problem"
```
- changedInput schema / properties / answers / properties / zip_code / description
```
Previous value: -"ZIP. Use the exact key zip_code."New value: +"ZIP"
```

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

B3.2/5.0

Behavior3/5

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description only needs to add context. It does add workflow behavior - the call chains into 'the vertical introduction and next intake/matching step' and surfaces availability when intake completes - but says nothing about permissions, failure modes, or how the required idempotency_key is consumed.

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

Conciseness4/5

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

Two sentences plus a short parameter rule; the purpose and immediate-effect claim is front-loaded. It is efficient, though the return-value clause is somewhat redundant given an output schema exists.

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

Completeness3/5

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

A mutating, idempotent tool with a nested parameter object and an output schema - so return values need not be described. The description covers purpose, chaining behavior, and one parameter rule, but leaves the mandatory idempotency_key and the required user_intent input unaddressed, which are the two parameters an agent must supply correctly.

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

Parameters2/5

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

Schema description coverage is only 20% across 5 parameters (nested answers object), so the description must carry the load. It clarifies only provider_hint ('only for an explicitly named company'); user_intent, idempotency_key, and the answers sub-fields (brand, model, zip_code, appliance_type, problem_description) get no added meaning beyond their bare schema descriptions.

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

Purpose4/5

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

States a specific verb and resource ('Start a new supported service request immediately') and clarifies the input posture ('with the user's full intent and known public facts'). It is distinguishable from create_service_booking in spirit, but it never names or contrasts with the closest siblings (render_service_request_form, update_service_request), so an agent must infer the boundary.

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

Usage Guidelines3/5

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

Provides one concrete routing cue ('no separate lookup is needed') and one narrow parameter rule ('Use provider_hint only for an explicitly named company'). There is no explicit when-not guidance and no alternative tool is named, so usage is implied rather than specified.

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?