compass-mcp

by chrischall

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.14.0
Disambiguation4/5
Most tools target clearly distinct operations: search, single fetch, batch fetch, compare, address resolution, photos, price history, agent listings, and financial calculators. A few overlaps exist—compass_get_property vs compass_bulk_get vs compass_compare_properties all fetch property records, and compass_get_price_history duplicates data already on compass_get_property—but the descriptions are detailed enough to guide correct selection.
Naming Consistency4/5
Naming is predominantly verb_noun with a consistent compass_ prefix: search_properties, get_property, calculate_mortgage, resolve_addresses, register_session. Minor deviations include compass_healthcheck (noun-only), compass_bulk_get (inverted order), and compass_get_by_address (prepositional object instead of a clear noun), but the overall pattern remains predictable.
Tool Count3/5
18 tools sits in the heavy range for an MCP server, and not every tool fully earns its place: compass_get_saved_homes and compass_get_saved_searches are unsupported stubs that only throw errors, and the three session-management tools plus healthcheck add infrastructure overhead. The core property tools are reasonable, but the set feels slightly over-scoped.
Completeness4/5
The read-only real-estate domain is well covered: search, property details, photos, price history, comparable rentals, agent listings, address resolution, batch fetching, and mortgage/affordability calculators are all present. Minor gaps remain—saved homes/searches are unsupported, and compass_search_properties cannot paginate beyond the first SSR page without manual price-banding—but agents can work around these with the documented strategies.
Average 4.5/5 across 18 of 18 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 69 commits in the last 12 weeks
- Last stable release on September 4, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare read-only/idempotent, the description adds substantial behavioral detail: the three-rung fallback strategy, WAF workaround, normalization/verification process, exact response shape including matched_via values, no-match error behavior, and URL-stability preference. This goes far beyond the annotations and gives the agent a precise model of edge cases. No contradiction 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the purpose and then proceeds through matching rungs, verification, response, and failure cases in a logical order. It is long but mostly dense; the main deductions are for internal issue references (#78/#79, #71, #45) and WAF details that add context but are not directly actionable for invoking the tool.
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?
With no output schema, the description fully compensates by specifying the return object fields, the possible matched_via values, the failure return shape, and the URL-form preference. It also covers the multi-rung resolution process and read-only safety, so an agent has everything necessary to call the tool correctly.
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 the baseline applies; the schema already documents each parameter. The description adds only general matching semantics such as normalization and whole-token equality, not per-parameter guidance or format requirements, so it does not meaningfully raise the baseline.
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 first sentence states a specific action — resolving a free-text street address to a Compass listing's canonical URL and identifiers — so the tool's purpose is unmistakable. It clearly distinguishes itself from search/get-property siblings in spirit, though it never names the closest sibling, compass_resolve_addresses.
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 is for free-text address resolution and notes it is read-only and safe to call repeatedly, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. The closest sibling, compass_resolve_addresses, is never mentioned, leaving some routing responsibility to the agent.
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.
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?
The description goes well beyond the readOnlyHint/idempotentHint annotations: it specifies the exact return envelope, explains that active listings carry the same normalized fields as compass_get_property, discloses that closed deals are omitted by default unless include_closed: true, and states it is read-only and safe to call repeatedly. This gives an agent a detailed behavioral model without needing an output schema.
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 fairly long but well-structured with labeled sections (CLOSED DEALS, CHAINING), front-loaded primary behavior, and no wasted sentences. The only mild redundancy is 'Read-only; safe to call repeatedly,' which duplicates the annotations, but it is brief and harmless.
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 tool with no output schema, the description provides a thorough return shape, field-level normalization guidance, default behavior, optional parameters, and chaining context. It covers the one-of slug/profile_url requirement in prose, and the schema covers the view parameter in detail. No major operational gaps remain.
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?
The input schema already provides 100% description coverage for all four parameters, so the baseline is 3. The description adds extra value by clarifying that slug and profile_url are interchangeable alternatives, giving a concrete slug example, and specifying that include_closed appends a closed_deals array with the same normalized shape. This is meaningful but not exhaustive enough to merit a 5.
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 opens with a specific verb and resource: 'Fetch the listings represented by a Compass agent from their profile page.' It also gives concrete examples of accepted identifiers ('paige-mcguirk', full URL) and distinguishes the data from what sibling tools return by referencing compass_get_property normalization and compass_search_properties' lack of listing agent info.
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 gives clear context for when to use the tool: when you need an agent's full listing set, optional closed deals, or want to chain property → agent → other listings. It contrasts with compass_search_properties implicitly, but it does not explicitly state when NOT to use this tool versus alternatives like compass_get_property for a single property, so it falls short of a 5.
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?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses the full set of diagnostic outputs (bridge role, port, version, extension link state, elapsed time, hint) and the failure categories it distinguishes. It also explicitly states 'Read-only, no auth required,' giving agents confidence about side effects and access.
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 dense but every clause earns its place: the mechanism, the exact diagnostics returned, the failure-mode hint, the invocation condition, and the safety note. It front-loads the core behavior and avoids filler.
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?
With no parameters and no output schema, the description compensates fully by enumerating the return fields and their possible values, and by explaining how to interpret the result. An agent has enough information to decide when to call this tool and what the response will tell it.
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?
The tool has zero parameters, and schema coverage is 100% because the schema is empty. The description reasonably does not discuss parameters; per the baseline for zero-parameter tools, this is adequate.
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 names a specific verb ('Round-trips'), a precise resource (public www.compass.com URL through the fetchproxy bridge), and a concrete deliverable (diagnostics). It clearly differentiates itself from sibling property-lookup tools by framing itself as an end-to-end healthcheck rather than a data query.
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 gives an explicit trigger condition: 'Call this when a real tool fails and you want to know which hop broke.' It does not name sibling alternatives, but the contrast with the domain-specific sibling tools is clear from the diagnostic framing.
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?
Beyond the readOnly/idempotent/openWorld annotations, it discloses a concrete pagination defect (#87), exact page capacity, offset/next_offset semantics, URL canonicalization behavior, compact-view field omission, and pid-vs-lid URL stability. This is exactly the behavioral context an agent needs to avoid re-fetching page 1 forever.
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 long, but the structure is front-loaded and the detail is mostly load-bearing. A few repetitions (page ~41, issue #87) and a redundant read-only sentence cost it a point, but the density of actionable warnings justifies the length.
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?
With no output schema, the description correctly takes on the burden of explaining return fields, URL variants, pagination limits, workarounds, and image-access options. An agent has everything needed to call it correctly and avoid the pagination trap.
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?
Even though schema coverage is only 56%, the description compensates with decisive parameter meaning: limit is capped by page capacity, offset is honored only within that page, and price_min/price_max/beds_min/beds_max are framed as banding controls. It also explains view=full's effect on CDN image fields, which the schema alone does not convey.
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 opening sentence states a specific action ('Search Compass listings') on a specific resource with location and optional filters, which immediately distinguishes it from listing-detail and mortgage siblings. It further specifies the output content (address, price, beds/baths, URLs), so an agent knows exactly what the tool produces.
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 gives strong usage context: it explains the ~41-listing SSR-page cap, tells the agent to use price/beds banding to reach beyond page one, and directs gallery needs to compass_get_property_photos. It does not explicitly enumerate sibling tools to prefer or discard in every case, so it falls just short of a full when-vs-alternatives map.
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

compass-mcp MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![compass-mcp MCP server — quality and maintenance score on Glama](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 — quality and maintenance score on Glama](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