cupix-compass
Server Details
Explore and analyze Cupix construction site data: 360 images, progress, and insights.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 6 of 6 tools scored. Lowest: 3/5.
Each tool has a distinct purpose: progress analysis, SQL query, context management, project listing, visual search, and project focus setting. No overlap.
All tool names use a consistent lowercase-with-hyphens verb_noun pattern (e.g., analyze-progress-and-forecasts, set-focus-project), making them predictable.
With 6 tools, the set is well-scoped for core workflows: project selection, data query, progress analysis, and photo search. Neither too many nor too few.
Covers essential analysis and retrieval operations, but lacks data modification tools (create/update/delete). Minor gap given the analytical focus.
Available Tools
6 toolsanalyze-progress-and-forecastsAnalyze construction progress and forecasts from SiteInsights and/or Work in Place (WIP) intelligence.ARead-onlyInspect
Analyze Work In Place (WIP) progress from SiteInsights(SI) — completion rates, delays, and forecasts. Generates a progress report: overall completion, progress by category/vendor/level, delay analysis, and estimated completion dates. WORKFLOW:
Default: call this tool with NO arguments. The server resolves team_domain/facility_key from the saved current project (set via
set-focus-project). Do NOT calllist-my-projectsagain just to obtain these values — the saved selection is the source of truth.Only when the response indicates the current project is missing, run
list-my-projects→ ask the user →set-focus-project, then retry.Pass explicit arguments only when the user clearly wants to analyze a different project than the saved one.
Args: team_domain: Omit by default. Pass only to override the current project. facility_key: Omit by default. Pass only to override the current project. user_intent: REQUIRED. Pass the user's original question or request verbatim. Used for analytics only, does not affect results.
Returns: Progress analysis report with completion rates and forecasts
| Name | Required | Description | Default |
|---|---|---|---|
| team_domain | No | ||
| user_intent | No | ||
| facility_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the tool is safe to call. The description adds valuable behavioral details: it uses the saved current project, requires user_intent for analytics, and explains the default behavior. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a list of report contents, and a WORKFLOW section with bullet points. It is appropriately sized, though slightly verbose. The key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers default invocation, parameter usage, exception handling, and differentiation from siblings. It is fully sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides essential meaning for each parameter: team_domain and facility_key are optional overrides, user_intent is required (despite schema default) for analytics. This compensates for the missing schema descriptions, though the required vs. optional discrepancy is minor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes Work In Place progress from SiteInsights, generating a report with completion rates, delays, and forecasts. It distinguishes itself from sibling tools like list-my-projects or set-focus-project by focusing on analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow: default invocation with no arguments, when to override parameters, and fallback procedure using list-my-projects and set-focus-project. It clearly differentiates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ask-about-project-dataAsk about anything in your projects: properties, BIM and drawing files, annotations, and capture details.ARead-onlyInspect
Query the construction project database using natural language (Text-to-SQL).
Converts natural language into SQL to retrieve captures, annotations, progress metrics,
schedules, and other project records.
Pass the user's question as-is without modification.
For trade visibility, use analyze-progress-and-forecasts instead.
WORKFLOW:
Default: call this tool with only
query. The server resolves team_domain/facility_key from the saved current project (set viaset-focus-project). Do NOT calllist-my-projectsagain just to obtain these values.Only when the response indicates the current project is missing, run
list-my-projects→ ask the user →set-focus-project, then retry.Pass explicit team_domain/facility_key only when the user clearly wants to query a different project than the saved one. Available tables:
progresses: SI progress metrics (level, category, phase, workarea, cost, dates)
captures: Camera captures metadata (level, camera_model, capture_state, user_email)
records: Capture events with timestamps (captured_at, state, id)
photo_notes: Photonotes (description, state, user_email, created_at)
voice_notes: Voicenotes (level, description, state, user_email, created_at)
facilities: Site info (name, address, size, location, bim_count, created_at)
users: User profiles (name, email)
workareas: Spatial zones (level, name, user_name)
Args: query: Natural language question (pass as-is, no SQL syntax) team_domain: Omit by default. Pass only to override the current project. facility_key: Omit by default. Pass only to override the current project. user_intent: REQUIRED. Pass the user's original question or request verbatim. Used for analytics only, does not affect results.
Returns: Query results as tab-separated text
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| team_domain | No | ||
| user_intent | No | ||
| facility_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations. While annotations already declare readOnlyHint=true, the description elaborates that the tool converts natural language to SQL, lists available tables, and states the return format (tab-separated text). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (workflow, available tables, args, returns). It is front-loaded with the core purpose and key usage notes. Every sentence adds value, and the length is appropriate for the tool's complexity. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, multiple tables, workflow dependencies), the description is comprehensive. It covers purpose, usage guidelines, parameter semantics, workflow, available tables, and return format. The presence of an output schema is noted, and the description succinctly explains the return type. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does: each parameter is described in detail—'query' (pass as-is), 'team_domain' and 'facility_key' (omit by default, only for override), and 'user_intent' (REQUIRED, verbatim, for analytics only). This provides complete semantic understanding beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: query the construction project database using natural language (Text-to-SQL). It specifies the action ('Query the project database'), the resource ('construction project database'), and explicitly distinguishes from the sibling tool 'analyze-progress-and-forecasts' by noting that for trade visibility, that tool should be used instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides comprehensive guidelines: it explains the default workflow (only pass query), when to explicitly set team_domain/facility_key (only for overriding the current project), and a step-by-step procedure for handling missing current project (run list-my-projects, ask user, set-focus-project, then retry). It also explicitly names the sibling tool for an alternative use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check-current-projectSee which project the conversation is currently focused on.BRead-onlyInspect
Return the currently saved team_domain and facility_key for this user.
| Name | Required | Description | Default |
|---|---|---|---|
| user_intent | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description's claim of returning saved values is consistent and non-contradictory. However, the description does not disclose behavior for edge cases (e.g., no project set) or any side effects, relying heavily on annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence), but it omits important details about the parameter and potential edge cases. Conciseness is fine, but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description provides the core purpose and return fields. However, it fails to address the role of the user_intent parameter or clarify behavior when no project is set, leaving gaps in an otherwise simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (user_intent) with 0% description coverage, and the description does not explain its purpose or usage. This leaves the AI agent without guidance on how to fill or omit it, which is critical for a tool with undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state that the tool retrieves the current project focus, returning team_domain and facility_key. This distinguishes it from sibling tools like set-focus-project or list-my-projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives. While the title hints at its purpose, there is no 'when-not to use' guidance or comparison with siblings like set-focus-project or list-my-projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-my-projectsBrowse all the CupixWorks projects you have access to.ARead-onlyInspect
List construction projects the user can access within a team.
Use this tool ONLY when the user wants to switch project or has no
saved current project. If check-current-project returns a
saved facility_key, do NOT call this tool — call the analysis tool
directly with no arguments.
Required workflow when this tool IS appropriate:
Present the returned projects to the user.
Wait for the user to select one.
Call
set-focus-projectwith team_domain and facility_key to persist the selection so future sessions skip this step.Then invoke analysis tools.
Args: team_domain: Team domain. Optional; if omitted, falls back to the saved current project, otherwise returns the team list so the caller can pick a team first. user_intent: REQUIRED. Pass the user's original question or request verbatim. Used for analytics only, does not affect results.
Returns: str: Accessible facilities with their keys and names.
| Name | Required | Description | Default |
|---|---|---|---|
| team_domain | No | ||
| user_intent | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds context like fallback behavior when team_domain is omitted and that user_intent is for analytics only. No side effects are mentioned, but the safe read nature is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, front-loaded usage guidelines, and concise parameter explanations. Every sentence provides value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and annotations, the description covers all necessary context: when to use, parameter behavior, return format, and post-call workflow, making it fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully explains both parameters: team_domain's optional fallback logic and user_intent's required verbatim pass-through for analytics, adding meaning beyond the schema's default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list) and resource (construction projects the user can access), and the workflow steps distinguish it from sibling tools like check-current-project and set-focus-project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('ONLY when the user wants to switch project or has no saved current project') and when not to ('If check-current-project returns a saved facility_key, do NOT call this tool'), plus provides a required workflow sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search-site-photosFind what matters in geo-tagged 360° site photos by content, like site context, safety risks, quality issues, and key objects.ARead-onlyInspect
Search 360° captures (panoramic site photos) by visual content analysis.
Searches what is VISUALLY SEEN in 360° captures — safety hazards, quality issues, work types,
objects, equipment, materials, and physical site conditions.
Do NOT use for capture counts or statistics — use ask-about-project-data instead.
WORKFLOW:
Default: call this tool with only
query(and optionally date filters / limit). The server resolves team_domain/facility_key from the saved current project (set viaset-focus-project). Do NOT calllist-my-projectsagain just to obtain these values.Only when the response indicates the current project is missing, run
list-my-projects→ ask the user →set-focus-project, then retry.Pass explicit team_domain/facility_key only when the user clearly wants to search a different project than the saved one.
Date filtering: Only use start_date/end_date when the user explicitly mentions dates. Format: YYYY-MM-DD. Omit entirely for general queries without date context.
Args: query: Keywords or phrases describing what to find in 360° captures team_domain: Omit by default. Pass only to override the current project. facility_key: Omit by default. Pass only to override the current project. user_intent: REQUIRED. Pass the user's original question or request verbatim. Used for analytics only, does not affect results. limit: Maximum number of results (default: 10) start_date: Start date filter, YYYY-MM-DD (omit if no date context) end_date: End date filter, YYYY-MM-DD (omit if no date context)
Returns: ToolResult: Image viewer links, 3D coordinates, and capture dates
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| end_date | No | ||
| start_date | No | ||
| team_domain | No | ||
| user_intent | No | ||
| facility_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark readOnlyHint=true, and the description adds relevant behavioral context: it searches visually, returns image viewer links and coordinates, and explains that user_intent is analytics-only. No contradictions. The workflow further clarifies expected behavior when the current project is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but slightly verbose, particularly the workflow section that could be condensed. However, given the complexity (7 parameters, integration with other tools), the length is justified and information is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary aspects: purpose, parameters, return type, workflow with sibling tools, and date handling. It mentions output includes image viewer links, 3D coordinates, and capture dates. The presence of an output schema (though not shown) further supports completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description provides thorough explanations for all 7 parameters, including usage rules (e.g., omit team_domain by default, date format YYYY-MM-DD, user_intent required verbatim). This exceeds what schema alone offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 360° captures by visual content, lists example findings (safety hazards, quality issues), and explicitly contrasts with sibling tools by stating not to use for statistics. This distinguishes it well from 'ask-about-project-data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (searching visual content) and when-not-to-use (statistics), with a detailed workflow for handling current project and date filtering. It also instructs to pass team_domain/facility_key only to override, which guides correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set-focus-projectChoose the project to focus on so answers stay accurate and on topic.ARead-onlyInspect
Save the user's current team and project so subsequent tool calls can omit
the team_domain / facility_key arguments.
Args:
team_domain: Team domain to remember (required unless clear=True).
facility_key: Facility key to remember (required unless clear=True).
clear: If true, delete the stored selection and ignore the other args.
user_intent: REQUIRED. Pass the user's original question or request verbatim. Used for analytics only, does not affect results.
Returns: Human-readable confirmation message.
| Name | Required | Description | Default |
|---|---|---|---|
| clear | No | ||
| team_domain | No | ||
| user_intent | No | ||
| facility_key | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description claims the tool 'saves' context, implying a write operation, but annotations set readOnlyHint=true. This contradiction undermines transparency. No additional behavioral detail beyond the contradictory claim is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses a clear bulleted list for arguments. It is reasonably concise, though the user_intent note could be shortened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's behavior, parameter roles, and return value. Combined with the title, it provides sufficient context for correct usage. The output schema is simple, so no additional detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose and behavior, including the special role of user_intent and the clear flag. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool saves the user's current team and project to allow omitting these arguments in subsequent calls. This verb-resource pair is specific and effectively distinguishes it from sibling tools like list-my-projects or ask-about-project-data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description and title imply usage for setting a focus project, but there is no explicit guidance on when to use this tool versus alternatives like check-current-project or list-my-projects. No exclusions or when-not-to-use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!