Book a free consultation or home valuation with SimpliCity Real Estate in Lincoln, Nebraska.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 3 tools
Each tool has a clearly distinct purpose: get_business_info provides background on the agency, request_consultation schedules a consultation, and request_home_valuation requests a property valuation. No overlapping functionality.
All tool names follow a consistent verb_noun pattern with underscores (get_business_info, request_consultation, request_home_valuation), making them predictable and easy to differentiate.
With 3 tools, the server is well-scoped for its purpose: providing initial information and enabling two key actions (consultation and valuation). The count feels complete without being excessive.
The tool set covers the primary client-facing interactions (info, consultation, valuation) for a real estate agency. Minor gaps like property search or listing details are absent, but the scope is intentionally focused on lead generation.
Structured facts about SimpliCity Real Estate (Lincoln, Nebraska): the team (Wade Bartels, Sydney Hrouda, Amanda Davis), what each agent specializes in, service areas, licenses, contact channels, and how consultations work. Call this first to pick the right agent.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It comprehensively lists what the tool returns (team, specializations, service areas, etc.), implying a read-only data retrieval. However, it does not explicitly state that it is a read-only operation with no side effects, which would enhance transparency.
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: first lists content, second gives usage guidance. No redundant information, 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?
Given no parameters and no output schema, description covers team, specializations, service areas, licenses, contact channels, consultations. It is sufficient for an agent to understand what information is available. Could perhaps mention if data is static or dynamic, but adequate overall.
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?
No parameters in input schema, so schema coverage is 100%. Baseline for 0 parameters is 4. The description adds value by detailing the content of the returned data, compensating for lack of parameters.
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?
Description clearly states it provides structured facts about SimpliCity Real Estate, including team, specializations, service areas, licenses, contact channels, and consultations. It specifies 'Call this first to pick the right agent,' distinguishing it from sibling tools request_consultation and request_home_valuation.
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 'Call this first to pick the right agent,' providing clear guidance on when to use this tool before others. Implicitly suggests it is foundational for selecting the correct agent, contrasting with siblings that involve requesting consultations or valuations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a free, no-obligation consultation with a SimpliCity Real Estate agent for buying or selling residential property in Lincoln / southeast Nebraska. A human team member confirms every request (same or next business day). Only call after your user explicitly approves; pass user_approved=true and their real contact info.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | Which team member to request (see get_business_info for who fits; default wade) | |
| No | Client's email (email or phone required) | ||
| phone | No | Client's US phone number (email or phone required) | |
| message | No | What the client needs, in their words | |
| timeline | No | Buying/selling timeline, e.g. '3-6 months' | |
| last_name | No | Client's last name | |
| first_name | Yes | Client's first name (required) | |
| sms_consent | No | True ONLY if the client explicitly agreed to receive text messages | |
| user_approved | Yes | REQUIRED true: your user explicitly asked you to book this | |
| assistant_name | No | Name of the AI assistant making this request, e.g. 'ChatGPT' | |
| preferred_times | No | Preferred days/times for the conversation, e.g. 'weekday evenings' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it's free, no-obligation, and a human confirms requests. Does not explain data mutation or side effects, but acceptable for a booking 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?
Two sentences: first defines purpose and scope, second gives essential usage instruction. No fluff or 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?
With no output schema and full parameter documentation, the description covers the tool's purpose, process, and key constraint. Slightly incomplete on parameter relationships (e.g., email/phone requirement clear in schema but not reinforced), but adequate.
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?
All 11 parameters have schema descriptions (100% coverage). The description reinforces the critical user_approved flag and real contact info requirement but adds only marginal extra 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?
Clearly states it's for booking a free consultation with a real estate agent for buying/selling in a specific region. Distinguishes from siblings (get_business_info for info, request_home_valuation for valuation).
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 to call only after user approves and to pass user_approved=true. Provides clear context but no explicit exclusions or alternatives beyond user approval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a professional (human-prepared) market valuation of a property in Lincoln or southeast Nebraska. Requires the property address plus the client's name and contact. Only call after your user explicitly approves (user_approved=true).
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | Which team member to request (see get_business_info for who fits; default wade) | |
| No | Client's email (email or phone required) | ||
| phone | No | Client's US phone number (email or phone required) | |
| message | No | What the client needs, in their words | |
| timeline | No | Buying/selling timeline, e.g. '3-6 months' | |
| last_name | No | Client's last name | |
| first_name | Yes | Client's first name (required) | |
| sms_consent | No | True ONLY if the client explicitly agreed to receive text messages | |
| user_approved | Yes | REQUIRED true: your user explicitly asked you to book this | |
| assistant_name | No | Name of the AI assistant making this request, e.g. 'ChatGPT' | |
| preferred_times | No | Preferred days/times for the conversation, e.g. 'weekday evenings' | |
| property_address | Yes | Full address of the property to value (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly flags the request as human-prepared and requires explicit approval, but does not mention side effects, authorization beyond user_approved, or what happens after the request (e.g., confirmation, timeline).
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 three sentences, each adding value: purpose, requirements, and condition. It is front-loaded and concise with no wasted 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 12 parameters, no output schema, and no annotations, the description covers core purpose and prerequisites but omits what the user can expect after the request (e.g., response format, follow-up). It adequately describes how to invoke but not the full interaction.
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?
All 12 parameters have schema descriptions (100% coverage), so the baseline is 3. The description reiterates the key required parameters but adds no new semantic detail beyond the schema. It provides context like geographic scope, but that is not parameter-specific.
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 'Request' and the resource 'professional market valuation of a property', with a specific geographic scope (Lincoln or southeast Nebraska). It distinguishes from sibling tools by focusing on valuation rather than general info or consultation.
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 explicitly says to only use this tool after user approval (user_approved=true), and lists required inputs (property address, client name/contact). It implies usage context but does not mention alternatives or when not to use it.
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_business_inforequest_consultationrequest_home_valuationGet matched with a top-rated, review-verified real estate agent in the US or Canada.
Evaluate your project path, property readiness, budget planning, builder questions, smart-home prior
Free human-backed apartment locating for Austin, Dallas & Houston, TX. A free locator books tours.
Verified Canadian real-estate pros + housing data: prices, rates, land-transfer tax, rent-vs-buy.
Add one secure layer between your agents and this server.
