compass-mcp

by chrischall

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.12.3
Disambiguation5/5
Each tool has a clearly distinct purpose. compass_search_properties searches with filters, compass_get_property fetches a single property, compass_get_agent_listings gets agent-specific listings, etc. Even the unsupported tools are uniquely named and do not overlap with others.
Naming Consistency5/5
All tools follow the consistent compass_verb_noun pattern, e.g., compass_search_properties, compass_get_property, compass_calculate_mortgage. The only minor deviation is compass_healthcheck, but it is still a recognizable term.
Tool Count4/5
With 18 tools, the set is well-scoped for a real estate property MCP. However, two tools (compass_get_saved_homes, compass_get_saved_searches) are non-functional and merely throw errors, slightly inflating the count without adding utility.
Completeness4/5
The tool set covers most important read-only operations: search, property details, agent listings, price history, photos, comparisons, mortgage calculations, address resolution, and bulk operations. The session management is a plus, but the missing implementation of saved homes/searches is a notable gap.
Average 4.6/5 across 18 of 18 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 135 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool's behavior: it throws an error. Annotations indicate readOnly, openWorld, idempotent, which are consistent with a read-only stub that fails. No contradiction.
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?
Two sentences that immediately state the limitation and the error behavior. No wasted words.
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?
For a stubbed tool, the description is complete: it explains the limitation and the error. No output schema is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter semantics.
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?
The description clearly states that the tool is not yet supported and throws an error. This conveys the tool's purpose as a placeholder that provides feedback, which is a valid purpose even if not functional.
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?
The description implies the agent should not rely on this tool as it will throw an error. However, it does not explicitly state when to use it or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining the calculation is local (no network), uses the 28/36 rule, and lists the output (max price, binding constraint, PITI). This supplements the readOnlyHint and idempotentHint annotations well.
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 concise (5 sentences) and front-loaded with purpose, then inputs/outputs, then comparison and behavior. No wasted words; each sentence provides essential information.
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?
The description covers the core calculation and output but omits default values for DTI ratios (assumed 28/36) and does not handle error conditions. Given no output schema, the output description helps, but missing parameter details reduce completeness.
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?
With 0% schema description coverage, the description must document parameters. It lists 8 of 10 parameters (missing front_end_dti and back_end_dti) and doesn't specify units (e.g., interest rate as decimal or percent). This leaves ambiguity for an AI agent.
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 solves for maximum home price under the 28/36 DTI rule, lists inputs and outputs, and distinguishes itself from sibling tools like zillow-mcp and redfin-mcp. It specifies it's a pure local calculation, no network, which sets it apart.
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?
The description implies when to use this tool (wanting to calculate affordability) and mentions it's identical to other MCPs, but does not explicitly exclude alternatives like compass_calculate_mortgage or state when not to use it. However, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, openWorldHint), the description discloses that the tool throws a clear error, which is valuable behavioral information for an agent considering invocation.
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 extremely concise: two sentences that convey the limitation and behavior without any wasted words. It is front-loaded with the status.
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?
Given the tool's unsupported state, the description is functionally complete. However, it lacks differentiation from sibling compass_get_saved_searches and does not explain what 'saved homes' means compared to saved searches, which could help agents decide when to use this tool in the future.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to add parameter semantics. The schema coverage is 100%, and the description appropriately omits parameter details.
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?
The description clearly states the tool's intended purpose (get saved homes) but immediately clarifies it is not yet supported, which accurately informs the agent of its current non-functional state.
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?
The description implies the tool should not be used ('not yet supported'), but does not explicitly suggest alternative tools like compass_get_saved_searches or compass_search_properties, leaving the agent without guidance on what to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds extensive behavioral details: the three resolution rungs with API endpoints, verification logic, fallback behavior, return format with matched_via field, and URL stability preference. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose, including technical details like API endpoints and issue numbers. While front-loaded with the main action, it could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple resolution rungs, verification, fallback), the description is thorough. It details the return format, error handling, and URL stability preference. No output schema exists, but the description compensates fully.
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 coverage is 100% (all parameters described in schema). The description adds the term 'free-text' for address but does not explain parameter interactions or provide meaning beyond the schema. Baseline of 3 is appropriate since schema already covers parameters.
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 it resolves a street address to a Compass listing's canonical URL and identifiers. It uses specific verbs and resources and distinguishes from siblings like compass_resolve_addresses (batch) and compass_search_properties (broader search).
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?
The description explains the three-step resolution process and when each rung is used. It mentions the tool is read-only and safe to call repeatedly. However, it does not explicitly state when not to use it or name alternatives like compass_resolve_addresses for batch resolving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint=false, but the description adds useful edge-case behavior (empty sessions and null active_session_id) that annotations do not cover.
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?
Two sentences with no wasted words. Front-loaded with main action, followed by edge case. Every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema, but the description fully explains the return values and edge cases. No additional information is necessary for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds value by explaining output fields (sessions array, active_session_id) and their behavior in edge cases, meeting the baseline for zero-parameter tools.
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 it returns all registered sessions and the active session ID, using a specific verb and distinct resource. It differentiates from sibling tools like compass_register_session and compass_set_active_session which are mutations.
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?
The description implies usage for retrieving session context but does not explicitly state when to use or not use this tool versus alternatives. However, sibling tools are clearly separate (registering or setting sessions), making context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, and the description reinforces this by stating 'Re-registering the same account_identity updates the existing session rather than creating a duplicate.' It also discloses that the first registered session becomes the default active_session_id, adding context beyond annotations.
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 three sentences with no filler, front-loaded with the core action. Every sentence adds value: registration/refresh behavior, idempotency, default active session, and mark_active option.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and good annotations, the description covers the return value (session_id), default behavior, and idempotency. It is complete for a registration tool, especially with sibling tools covering other session management aspects.
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 100%, so baseline is 3. The description adds operational context for parameters (e.g., 'Pass mark_active: true to make the newly-registered session active') but does not introduce new meaning beyond what the schema descriptions already provide for each parameter.
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 'Register (or refresh) an authenticated Compass session' using a specific verb and resource. It distinguishes from siblings by explaining the key behavior of re-registering the same account_identity updating the session, which is unique among tools like compass_set_active_session and compass_get_session_context.
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?
The description explains when to use the tool (registering or refreshing a session) and mentions the first session becomes default and the mark_active option. However, it does not explicitly contrast with alternatives like compass_set_active_session for changing the active session, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: local-only, no network call, automatic PMI when LTV > 80%, default down payment of 20%.
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?
Three sentences, front-loaded with purpose and output, no fluff. Every sentence adds value.
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?
Explains output components (PITI breakdown components, total interest) and key constraints. Does not detail exact output structure or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (40%), but description compensates by explaining key relationships (down_payment vs percent, property tax options, PMI condition). Does not cover all parameters (e.g., hoa_monthly, insurance_annual).
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?
Clearly states it is a local-only mortgage payment calculator returning PITI breakdown and total interest, with specific verb 'calculate' and resource 'mortgage'. Distinguishes from siblings like compass_calculate_affordability.
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?
Provides clear context: local-only, no network call, parameter choices (down_payment OR down_payment_percent). Does not explicitly contrast with siblings or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining data extraction ('Lifts the target's city/state/zip'), the honest-empty behavior, and the output fields. It aligns with readOnlyHint and idempotentHint.
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?
Three sentences, front-loaded with purpose, each sentence provides essential information without redundancy. Efficient and clear.
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?
The description adequately covers inputs (parameters with defaults), outputs (list of rentals with key fields), and edge cases (empty result behavior). However, it does not define 'nearby' proximity or mention pagination, though the tool appears simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context: explains how `url` is used to extract location, and explicitly states the default for `limit` (20) not in schema. This adds meaning beyond the schema.
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 verb 'Surface' and the resource 'nearby rental listings for a Compass property', and distinguishes it from siblings by specifying it's for comparable rentals, not general search or property details.
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?
The description explains when to use (evaluating STR viability) and describes behavior when no results are returned ('rentals: []' with locality preserved). However, it does not explicitly contrast with sibling tools like compass_search_properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. The description adds extensive behavioral details: the three search rungs (autocomplete, freetext, fallback), candidate verification policy, error types (no-match, timeout, bridge_down), retryability, and note that bulk amplifies corruption. This enriches the annotations without contradiction.
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?
The description is relatively long but well-structured: first sentence gives core purpose, then response shapes, then search algorithm, then error handling, then bulk note. Every sentence adds value for a complex tool. Could be slightly more concise, but it's appropriate for the detail needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bulk resolution, multiple response types, matching algorithm, retry logic), the description is highly complete. It covers return value shapes, edge cases (timeout, bridge_down), retry guidance, and match verification. Without an output schema, this is essential and well done.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameters described in schema. The description adds meaning by explaining that the 'addresses' array can hold up to 100 inputs, each with optional zip/city/state and required address. It also details the response structure for each input, going beyond the schema definitions.
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 resolves up to 100 street addresses to Compass listing URLs. It uses specific verbs ('resolve', 'returns') and resources ('street addresses', 'Compass listing URLs'). The sibling tools list includes compass_get_by_address (single address) and compass_bulk_get, so the description implicitly distinguishes by scale and purpose.
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?
Provides clear guidance on when to use: for bulk resolution of addresses, up to 100 per call. It explains the three response shapes and the retry behavior for timeouts/bridge_down, which helps the agent decide when to retry. However, it does not explicitly say 'use this instead of compass_get_by_address for multiple addresses' but the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint false and idempotentHint true, matching the description of a state-modifying but safe operation. The description provides additional context on routing subsequent calls, which is helpful beyond annotations.
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?
Two concise sentences that fully convey the tool's function without wasted words. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the essential behavior, interaction with other tools (compass_register_session), and the override mechanism, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with session_id described; the description adds crucial context that it must come from compass_register_session, enhancing the schema's documentation.
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 uses specific verbs ('Switch', 'route through by default') and resource ('active session'), and distinguishes from sibling tools by explaining that this sets the default while other tools can override with explicit session_id.
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?
Explicitly states when to use (to set default session) and mentions that tools with explicit session_id override, implying when not to rely on this tool. References compass_register_session as prerequisite, but no explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only, idempotent, and open-world nature beyond annotations. Describes return format, normalized fields, and opt-in closed deals. No annotation contradictions.
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?
Well-structured with sections (CLOSED DEALS, CHAINING). Every sentence adds distinct value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and rich annotations, the description covers return shape, chaining, read-only safety, and parameter defaults comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context: explains slug/profile_url relationship with examples, default for include_closed, and purpose. Adds value beyond schema.
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?
Clearly states the tool fetches an agent's listings from their profile page. Distinguishes from siblings by noting how agent slug is surfaced in compass_get_property results but not in compass_search_properties, enabling chaining.
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?
Explains when to use (fetch agent listings), how to identify agent via slug or profile_url, and the opt-in closed deals. Provides chaining guidance but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds rich behavioral context: the round-trip nature, detailed diagnostics (role, port, version, elapsed time, hint), and failure mode differentiation. No contradiction.
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?
Three sentences, front-loaded with the core action and output, followed by usage guidance and extra behavioral notes. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no output schema, but description fully covers return values (diagnostics list) and usage context. All important aspects are addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline is 4. No parameter info needed beyond what the empty schema already conveys.
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?
Clearly states the action ('round-trips a small public www.compass.com URL') and the resource ('fetchproxy bridge'), with output diagnostics listed. Distinguishes from siblings as no other sibling does healthcheck.
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?
Explicitly says 'Call this when a real tool fails and you want to know which hop broke,' providing a concrete use case. Also mentions read-only and no auth required, though does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits beyond annotations: pagination limitation (#87), SSR page extraction, offset behavior, and the difference between sha-based and pid-based URLs. It adds significant context not present in annotations (readOnlyHint, idempotentHint, openWorldHint), and does not contradict them.
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 well-structured and front-loaded with the core purpose. Every sentence adds necessary detail (pagination workaround, return fields, stable URL advice). Despite length, it is efficient and earns its content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description thoroughly explains return values, pagination, and banding strategy. It covers all essential aspects for an agent to use the tool effectively, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%. The description adds meaning for limit and offset by explaining pagination caps, and for location as free-text. It also explains the banding strategy for beds_min/max and price_min/max, though not their individual semantics. This adds value beyond the schema.
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 'Search Compass listings by location (city, ZIP, neighborhood) and optional filters,' specifying the verb, resource, and scope. It also distinguishes itself from siblings like compass_get_property and compass_get_agent_listings by detailing its unique search and pagination behavior.
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?
The description explicitly explains when to use banding (price_min/max, beds_min/max) to reach beyond the first page, and declares the tool as read-only and safe to call repeatedly. However, it does not directly compare to sibling tools or state 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent. Description adds valuable behavioral details: per-target error handling (one bad target doesn't fail all), concurrent calls, default omission of description and summary, and resolution behavior for listing_id_sha.
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?
While lengthy, the description is well-structured with main purpose first, then parameter details and behavioral notes. Some redundancy exists but is justified by complexity. Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description fully explains the response structure: full per-property record, extracted_features populated, description and summary opt-in, error handling per row. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. Description adds context: url preferred over listing_id_sha, explanation of sha resolution, and rationale for default false on include_description and include_summary. Adds value beyond schema.
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 fetches multiple Compass properties and aligns facts side-by-side. It specifies input options (url or listing_id_sha) and distinguishes from sibling compass_bulk_get for unbounded fetches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (comparing 2–25 properties) and when to use alternatives (compass_bulk_get for unbounded fetches without summary). Also notes cap raised from 8 to 25.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses redirect following, omission of raw description by default, derived fields like lot_size_acres and extracted_features, and that url returns the _lid/ form. It agrees with annotations (readOnlyHint, idempotentHint).
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?
The description is detailed but well-structured with clear paragraphs. It could be slightly more concise, but all sentences add value. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description thoroughly enumerates return fields (address, beds/baths, sqft, etc.), derived values, and optional inclusion of raw description. It covers behavior for both input methods and URL forms completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions, but the description adds valuable context on URL forms and the difference between sha and pid identifiers. It goes beyond the schema, justifying a 4.
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 'Fetch a property's full Compass record.' It uses a specific verb and resource, distinguishing from sibling tools like compass_search_properties (list) and compass_get_by_address (by address).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly explains two input methods (url vs listing_id_sha) and advises on stability: sha-based URLs go stale, pid is better for long-lived references. It also notes the tool is read-only and safe to call repeatedly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: read-only nature, idempotency, redirect behavior for sha-only, and return format. Annotations already indicate safe/read-only, but description enriches with specific behavioral details.
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?
Concise, well-structured, and front-loaded. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without output schema, description explicitly states return shape (`{ listing_id_sha, count, photos }`). Covers default behavior and optional parameter. Sufficient for agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: explains why `url` is preferred (no round-trip), details sha-only behavior and redirect, and clarifies default for `include_all_categories`. Schema coverage is 100%, but description adds valuable context.
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?
Description clearly states it retrieves the full photo gallery for a Compass listing, specifying the data source (listing.media[]) and distinguishing it from sibling tools like compass_get_property.
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?
Provides clear usage instructions: pass either `url` or `listing_id_sha`, explains sha-only redirect behavior, and mentions optional `include_all_categories`. Lacks explicit when-not-to-use but is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description aligns with annotations (readOnlyHint, idempotentHint). Adds behavioral context: sha-only calls require an internal redirect, and the tool is safe to call repeatedly. No contradiction; annotations already safe, description adds useful detail.
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?
Well-structured with the core purpose up front. Every sentence adds value, though slightly verbose (e.g., describing the normalized schema in detail). Could be more concise but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully describes the return structure (three arrays) and the normalized event schema with an enum. It also notes that most data is on compass_get_property, providing complete context for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning: 'url (preferred — no resolver round-trip needed)' and explains that listing_id_sha resolves internally via site search. This helps the agent choose between parameters.
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 uses specific verbs and resources: 'Full listing history for a Compass property' with event types (Listed/Sold/Pending/Price Change/Delisted). It distinguishes the tool from siblings by noting that most data is on compass_get_property and this tool is for the merged/normalized timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: 'call this tool only when you want the merged + normalized timeline' and when not to: 'most of this data is already returned inline on compass_get_property'. Also explains how to pass parameters (url preferred, listing_id_sha works alone).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses batch size limit (200), concurrency, error handling (one bad target doesn't fail whole call), retryable flag, default omission of description, and always-included extracted_features. Adds significant context beyond annotations, no contradictions.
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?
Front-loaded with main purpose; each sentence adds distinct value (error handling, retry, concurrency, alternative tool). No fluff, efficient paragraph despite covering many aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: purpose, input, output format, error handling, retry logic, default behavior, parallelism, and relation to siblings. Complete for complex bulk fetch tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds meaning: explains output format per target, retryable conditions, default value of include_description, and references compass_get_property for target shape. Adds behavioral details not in schema.
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?
Clearly states 'Fetch up to 200 Compass listings in a single call' with specific verb and resource. Distinguishes from sibling tools by referencing compass_compare_properties and compass_get_property for shape. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use (for bulk fetch) and when not (for summary table, use compass_compare_properties). Provides retry guidance for timeout/bridge_down errors, and notes targets have same shape as compass_get_property. Clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![compass-mcp MCP server](https://glama.ai/mcp/servers/chrischall/compass-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/compass-mcp)

Score Badge

Copy to your README.md:

[![compass-mcp MCP server](https://glama.ai/mcp/servers/chrischall/compass-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/compass-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/compass-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server