Book a free consultation or home valuation with SimpliCity Real Estate in Lincoln, Nebraska.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 3 of 3 tools scored.
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.
get_business_infoAbout SimpliCity Real EstateAInspectStructured 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_consultationBook a real estate consultationAInspectRequest 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_home_valuationRequest a home valuationAInspectRequest 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!