F
licenseNot graded
qualityB
maintenanceAutomatically routes natural language questions to RAG or Text2SQL paths to answer queries about virtual construction site data, supporting semantic search and structured aggregation.
-
cupix-compass
Server Details
Explore and analyze Cupix construction site data: 360 images, progress, and insights.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
7 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
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| team_domain | No | ||
| user_intent | No | ||
| facility_key | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses that user_intent is analytics-only and does not affect results, that team_domain/facility_key default to the saved project, and that the tool will signal missing current project. These trait disclosures add valuable behavioral context not captured in 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 well-structured with clear sections (overview, workflow, args, returns). Every sentence serves a purpose—explaining behavior, usage, or parameters—and avoids redundancy. The formatting improves readability despite 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?
The description covers the tool's purpose, argument semantics, default behavior, interaction with sibling tools, and return type. Given the existing output schema and annotations, the description is sufficiently complete for an agent to select and invoke the tool correctly without missing critical context.
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 description thoroughly explains each parameter: team_domain and facility_key are optional overrides, user_intent is passed verbatim but only for analytics. However, it calls user_intent 'REQUIRED' while the schema shows a default and does not list it as required, creating a potential contradiction that could mislead an 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 verb (Analyze), the specific resource (Work In Place progress from SiteInsights), and the outputs (completion rates, delays, forecasts, progress report). It distinguishes itself from siblings like ask-about-project-data by emphasizing analytical report generation rather than general project Q&A.
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?
The workflow section provides explicit when-to-use guidance: default to no arguments relying on the saved project, explicitly avoid calling list-my-projects unless the project is missing, and only pass overrides when analyzing a different project. It names sibling tools and exact steps for recovery, which is excellent guidance.
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. scope: Previous ask-about-project-data result identity to search within. limit: Number of rows per page. Values above 200 are capped at 200. cursor: Cursor for the next page of the same search.
Returns: List of TextContent with query results and metadata
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| scope | No | ||
| cursor | No | ||
| team_domain | No | ||
| user_intent | No | ||
| facility_key | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint/openWorldHint annotations by disclosing SQL conversion, server-side current-project resolution, result row caps at 200, cursor-based pagination, and the fact that user_intent is used only for analytics and does not affect results. This gives the agent a clear model of how the tool behaves.
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 longer than average but is well-structured: a crisp purpose sentence, an explicit sibling alternative, a bulleted workflow, an available-tables catalog, and a compact Args section. Every sentence earns its place, and the content is front-loaded with the most important usage guidance.
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 complex 7-parameter tool with no schema descriptions, the description is unusually complete. It covers the full invocation workflow, parameter semantics, available database tables, pagination/limit behavior, and return format, leaving no significant gaps for correct use.
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 description coverage is 0%, the description explains every parameter: query must be passed as-is, team_domain/facility_key default to the saved project, user_intent must be the original verbatim request, scope searches within a previous result, limit caps at 200 rows, and cursor enables paging. This fully compensates for the sparse 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 identifies the tool as a natural-language Text-to-SQL query tool over the project database, listing retrievable data types such as captures, annotations, progress metrics, and schedules. It distinguishes itself from siblings by explicitly directing trade-visibility questions to analyze-progress-and-forecasts.
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?
The description gives explicit usage guidance: use this tool for general project-data queries, and use analyze-progress-and-forecasts instead for trade visibility. It also details a concrete workflow—call with only query by default, avoid redundant list-my-projects calls, recover via list-my-projects → set-focus-project when no project is set, and pass team_domain/facility_key only to override the current project.
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.ARead-onlyInspect
Return the currently saved team_domain and facility_key for this user.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| user_intent | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds useful context by specifying the exact return fields (team_domain and facility_key) and that it is for 'this user'. No contradiction exists, and the behavior is adequately transparent for a simple read operation.
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 a single sentence, starts directly with the verb 'Return', and contains no unnecessary words. It is concise, front-loaded, and appropriately sized for the tool's simplicity.
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 simple read-only getter, the description covers the core functionality and return fields. The output schema exists to detail return structure. However, the unexplained 'user_intent' parameter and lack of mention of behavior when no project is set create minor gaps, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'user_intent' with no description, and schema description coverage is 0%. The tool description does not mention this parameter at all, leaving its purpose and expected values entirely unexplained. Since the description must compensate for low schema coverage, this is a significant gap.
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 the specific verb 'Return' and identifies the exact resources ('currently saved team_domain and facility_key'), clearly stating the tool reads the current project context. This distinguishes it from siblings like set-focus-project (which modifies the project) and list-my-projects (which lists all projects).
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 title 'See which project the conversation is currently focused on' communicates a clear use case, and the description reinforces it by specifying the saved fields. However, it does not explicitly name alternatives or state when not to use this tool, relying on context from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare-site-findingsCompare Compass AI findings between two capture dates.ARead-onlyInspect
Use for QA/QC questions about findings added, resolved, unchanged, moved, or otherwise changed between two dates. Use the prior dates again on a follow-up call and add level or confidence filters. The runtime uses pano camera coverage, so uncertain identity or possible movement is returned as INDETERMINATE instead of guessed ADDED/RESOLVED.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| polygon | No | ||
| statuses | No | ||
| timezone | No | UTC | |
| level_ids | No | ||
| team_domain | No | ||
| user_intent | No | ||
| facility_key | No | ||
| baseline_date | Yes | ||
| min_confidence | No | ||
| comparison_date | Yes | ||
| minimum_level_number | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| project | Yes | |
| summary | Yes | |
| baseline | Yes | |
| findings | Yes | |
| query_id | Yes | |
| returned | Yes | |
| warnings | Yes | |
| comparison | Yes | |
| schema_version | Yes | |
| normalized_request | Yes | |
| classification_policy | Yes |
TDQS
A4.2/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a key behavioral trait beyond annotations: the runtime uses pano camera coverage, causing uncertain cases to be returned as INDETERMINATE rather than guessed. This adds significant transparency about result semantics, going beyond the readOnlyHint annotation and helping the agent set expectations.
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, each earning its place: purpose, follow-up guidance, and behavioral caveat. No fluff or redundancy, perfectly concise and well-structured.
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 provides enough for basic usage but is incomplete for a tool with 13 parameters. It covers the core concept and important caveat, and the output schema exists, but the parameter richness is not fully addressed. The lack of parameter descriptions means the agent may be uncertain about advanced filtering options, reducing overall 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 13 parameters and zero schema descriptions, the description only covers a few: baseline_date and comparison_date (implied by 'two dates'), level_ids and min_confidence ('level or confidence filters'). Many parameters like query, statuses, polygon, timezone, team_domain, facility_key, minimum_level_number, user_intent, and limit are not explained, leaving a significant semantic gap.
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 compares findings between two dates for QA/QC questions, listing specific delta states (added, resolved, unchanged, moved). It distinguishes from siblings like analyze-progress-and-forecasts by focusing on change detection between captures, making the purpose unmistakable.
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 explicit when-to-use context ('Use for QA/QC questions') and actionable advice for follow-up calls (reuse prior dates, add level/confidence filters). It lacks explicit mention of alternatives or when not to use, but the context is clear enough to guide selection.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| team_domain | No | ||
| user_intent | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnlyHint and openWorldHint. The description adds important behavioral details: team_domain fallback behavior, user_intent being analytics-only, and the required multi-step workflow. It also clarifies the return type as a string of accessible facilities, which is beyond the structured fields.
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 with a bold usage rule, a clear numbered workflow, and separate Arg explanations. Every sentence adds practical value; the length is justified by the complex workflow required.
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 description is complete for this tool's context: it explains when to use, prerequisites, workflow steps, parameter behavior, fallback logic, and return value. The presence of an output schema reduces the need but the description still covers the essential context thoroughly.
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 description coverage is 0%, but the description fully documents both parameters. It explains team_domain is optional and what happens if omitted, and that user_intent is REQUIRED and passed verbatim for analytics only—significantly adding meaning beyond the bare schema properties.
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 lists construction projects the user can access within a team. It distinguishes itself from siblings by specifying when to use it ('ONLY when the user wants to switch project or has no saved current project') and by contrasting with check-current-project.
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?
The description gives explicit when-to-use and when-not-to-use guidance, including an alternative: 'If check-current-project returns a saved facility_key, do NOT call this tool — call the analysis tool directly.' It also provides a numbered workflow for presentation, selection, and persistence via set-focus-project.
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) scope: Previous search-site-photos result identity to search within. cursor: Cursor for the next page of the same search.
Returns: ToolResult: Image viewer links, 3D coordinates, and capture dates
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| scope | No | ||
| cursor | No | ||
| end_date | No | ||
| start_date | No | ||
| team_domain | No | ||
| user_intent | No | ||
| facility_key | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable workflow behavior: server auto-resolves project context from the saved project, when to retry with project setup, and that user_intent is analytics-only and does not affect results. It doesn't describe pagination/return semantics in depth, but the output schema covers that, and the behavioral notes exceed what annotations provide.
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 longer than typical but every section earns its place: purpose, workflow, date filtering, and per-argument notes. Markdown structure (WORKFLOW, Date filtering, Args) makes it scannable. Slightly verbose with the Args section duplicating some schema field names, but the behavioral notes justify the length.
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?
This is a complex tool (9 params, nested scope object with pano list, pagination via cursor, cross-tool workflow). The description addresses the multi-step fallback workflow, project context resolution, and date handling comprehensively. The output schema covers the return structure. Minor gap: the cursor pagination interaction could be spelled out more explicitly, but overall completeness is strong for the 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 description coverage is 0%, so the description must compensate for all 9 parameters, and it does: every param gets an inline explanation (query='keywords describing what to find', team_domain/facility_key='omit by default, override current project', user_intent='REQUIRED...does not affect results', limit='default 10', date params='YYYY-MM-DD, omit if no date context', scope='previous result identity', cursor='next page'). This fully compensates for the 0% schema coverage.
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 has a very specific verb+resource ('Search 360° captures by visual content analysis') and clearly distinguishes from siblings by explicitly naming what it does NOT do (capture counts/statistics → ask-about-project-data). It enumerates the exact content types searched (safety hazards, quality issues, work types, objects, equipment, materials, conditions).
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?
Provides an explicit WORKFLOW section detailing default usage (query only), when to override with team_domain/facility_key, when to run list-my-projects → set-focus-project (only when current project is missing), and precise date-filtering guidance (only when user mentions dates, YYYY-MM-DD format). The exclusion of the stats use case with a named alternative is exemplary.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| clear | No | ||
| team_domain | No | ||
| user_intent | No | ||
| facility_key | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.9/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says it will 'Save' and, with clear:true, 'delete the stored selection,' indicating a state-modifying write operation. This directly contradicts the annotation 'readOnlyHint: true,' which classifies the tool as read-only. This is an annotation 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?
The description is well-structured, front-loaded with the core purpose, and then uses a compact Args/Returns format. Every sentence adds meaningful information, such as required conditions and the return value, with no filler.
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 stateful tool with 4 parameters, the description covers all parameter semantics, the clear behavior, and the return value, making it usable without external documentation. It loses one point for not mentioning alternative tools or addressing the annotation contradiction, leaving some contextual gaps.
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?
The schema coverage is 0%, but the description fully compensates by explaining each parameter: team_domain and facility_key are required unless clear=true, clear deletes the stored selection and ignores other args, and user_intent is required for analytics and does not affect results.
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 starts with a precise verb and object: 'Save the user's current team and project,' which clearly states what the tool does. It also differentiates this tool from the sibling 'check-current-project' (which likely only reads) by emphasizing the action of saving for future calls.
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 usage context: it is used so that 'subsequent tool calls can omit the team_domain / facility_key arguments.' However, it does not explicitly state when not to use it or name an alternative like 'check-current-project' for verifying the current focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
- Changed
ask-about-project-data2 fields changed- added
Input schema / properties / cursorAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Cursor" +} - added
Input schema / properties / limitAdded value: +{ + "default": 200, + "title": "Limit", + "type": "integer" +}
- Added
compare-site-findings
1 tool update
- Changed
search-site-photos1 field changed- added
Input schema / properties / cursorAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Cursor" +}
2 tool updates
- Changed
ask-about-project-data2 fields changed- added
Input schema / $defsAdded value: +{ + "ProjectDataSearchScope": { + "additionalProperties": false, + "properties": { + "ids": { + "items": { + "pattern": "^[0-9]+$", + "type": "string" + }, + "maxItems": 200, + "title": "Ids", + "type": "array" + }, + "mode": { + "const": "within_previous_result", + "title": "Mode", + "type": "string" + }, + "source_table": { + "enum": [ + "elements", + "captures", + "records", + "annotations", + "voice_notes", + "facilities", + "users", + "workareas" + ], + "title": "Source Table", + "type": "string" + } + }, + "required": [ + "mode", + "source_table", + "ids" + ], + "title": "ProjectDataSearchScope", + "type": "object" + } +} - added
Input schema / properties / scopeAdded value: +{ + "anyOf": [ + { + "$ref": "#/$defs/ProjectDataSearchScope" + }, + { + "type": "null" + } + ], + "default": null +}
- Changed
search-site-photos2 fields changed- added
Input schema / $defsAdded value: +{ + "PhotoSearchScope": { + "additionalProperties": false, + "properties": { + "mode": { + "const": "within_previous_result", + "title": "Mode", + "type": "string" + }, + "pano_ids": { + "items": { + "pattern": "^[0-9]+$", + "type": "string" + }, + "maxItems": 200, + "title": "Pano Ids", + "type": "array" + } + }, + "required": [ + "mode", + "pano_ids" + ], + "title": "PhotoSearchScope", + "type": "object" + } +} - added
Input schema / properties / scopeAdded value: +{ + "anyOf": [ + { + "$ref": "#/$defs/PhotoSearchScope" + }, + { + "type": "null" + } + ], + "default": null +}
1 tool update
- Changed
ask-about-project-data3 fields changed- added
Output schema / $defsAdded value: +{ + "Annotations": { + "additionalProperties": true, + "properties": { + "audience": { + "anyOf": [ + { + "items": { + "enum": [ + "user", + "assistant" + ], + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Audience" + }, + "priority": { + "anyOf": [ + { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Priority" + } + }, + "title": "Annotations", + "type": "object" + }, + "TextContent": { + "additionalProperties": true, + "description": "Text content for a message.", + "properties": { + "_meta": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Meta" + }, + "annotations": { + "anyOf": [ + { + "$ref": "#/$defs/Annotations" + }, + { + "type": "null" + } + ], + "default": null + }, + "text": { + "title": "Text", + "type": "string" + }, + "type": { + "const": "text", + "title": "Type", + "type": "string" + } + }, + "required": [ + "type", + "text" + ], + "title": "TextContent", + "type": "object" + } +} - added
Output schema / properties / result / itemsAdded value: +{ + "$ref": "#/$defs/TextContent" +} - changed
Output schema / properties / result / typePrevious value: -"string"New value: +"array"
6 tool updates
- Changed
analyze-progress-and-forecasts1 field changed- added
Input schema / properties / user_intentAdded value: +{ + "default": "", + "title": "User Intent", + "type": "string" +}
- Changed
ask-about-project-data1 field changed- added
Input schema / properties / user_intentAdded value: +{ + "default": "", + "title": "User Intent", + "type": "string" +}
- Changed
check-current-project1 field changed- added
Input schema / properties / user_intentAdded value: +{ + "default": "", + "title": "User Intent", + "type": "string" +}
- Changed
list-my-projects1 field changed- added
Input schema / properties / user_intentAdded value: +{ + "default": "", + "title": "User Intent", + "type": "string" +}
- Changed
search-site-photos1 field changed- added
Input schema / properties / user_intentAdded value: +{ + "default": "", + "title": "User Intent", + "type": "string" +}
- Changed
set-focus-project1 field changed- added
Input schema / properties / user_intentAdded value: +{ + "default": "", + "title": "User Intent", + "type": "string" +}
12 tool updates
- Added
analyze-progress-and-forecasts - Added
ask-about-project-data - Added
check-current-project - Removed
compass_analyze_work_in_place - Removed
compass_get_current_project - Removed
compass_list_projects - Removed
compass_query_database - Removed
compass_search_360_captures - Removed
compass_select_project - Added
list-my-projects - Added
search-site-photos - Added
set-focus-project
12 tool updates
- Added
compass_analyze_work_in_place - Added
compass_get_current_project - Added
compass_list_projects - Added
compass_query_database - Added
compass_search_360_captures - Added
compass_select_project - Removed
getActiveContext - Removed
listFacilities - Removed
projectDataExplorer - Removed
setActiveContext - Removed
siteImageExplorer - Removed
siteinsightsAnalyzer
5 tool updates
- Added
getActiveContext - Changed
projectDataExplorer7 fields changed- added
Input schema / properties / facility_key / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / facility_key / defaultAdded value: +null - removed
Input schema / properties / facility_key / typeRemoved value: -"string" - added
Input schema / properties / team_domain / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / team_domain / defaultAdded value: +null - removed
Input schema / properties / team_domain / typeRemoved value: -"string" - changed
Input schema / requiredPrevious value: -[ - "query", - "team_domain", - "facility_key" -]New value: +[ + "query" +]
- Added
setActiveContext - Changed
siteImageExplorer7 fields changed- added
Input schema / properties / facility_key / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / facility_key / defaultAdded value: +null - removed
Input schema / properties / facility_key / typeRemoved value: -"string" - added
Input schema / properties / team_domain / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / team_domain / defaultAdded value: +null - removed
Input schema / properties / team_domain / typeRemoved value: -"string" - changed
Input schema / requiredPrevious value: -[ - "query", - "team_domain", - "facility_key" -]New value: +[ + "query" +]
- Changed
siteinsightsAnalyzer7 fields changed- added
Input schema / properties / facility_key / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / facility_key / defaultAdded value: +null - removed
Input schema / properties / facility_key / typeRemoved value: -"string" - added
Input schema / properties / team_domain / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / team_domain / defaultAdded value: +null - removed
Input schema / properties / team_domain / typeRemoved value: -"string" - removed
Input schema / requiredRemoved value: -[ - "team_domain", - "facility_key" -]
1 tool update
- Changed
listFacilities2 fields changed- added
Input schema / properties / team_domain / defaultAdded value: +null - removed
Input schema / requiredRemoved value: -[ - "team_domain" -]
1 tool update
- Removed
tradeVisibilityAnalyzer
2 tool updates
- Changed
siteinsightsAnalyzer3 fields changed- added
Output schema / $defsAdded value: +{ + "Annotations": { + "additionalProperties": true, + "properties": { + "audience": { + "anyOf": [ + { + "items": { + "enum": [ + "user", + "assistant" + ], + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Audience" + }, + "priority": { + "anyOf": [ + { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Priority" + } + }, + "title": "Annotations", + "type": "object" + }, + "TextContent": { + "additionalProperties": true, + "description": "Text content for a message.", + "properties": { + "_meta": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Meta" + }, + "annotations": { + "anyOf": [ + { + "$ref": "#/$defs/Annotations" + }, + { + "type": "null" + } + ], + "default": null + }, + "text": { + "title": "Text", + "type": "string" + }, + "type": { + "const": "text", + "title": "Type", + "type": "string" + } + }, + "required": [ + "type", + "text" + ], + "title": "TextContent", + "type": "object" + } +} - added
Output schema / properties / result / itemsAdded value: +{ + "$ref": "#/$defs/TextContent" +} - changed
Output schema / properties / result / typePrevious value: -"string"New value: +"array"
- Changed
tradeVisibilityAnalyzer3 fields changed- added
Output schema / $defsAdded value: +{ + "Annotations": { + "additionalProperties": true, + "properties": { + "audience": { + "anyOf": [ + { + "items": { + "enum": [ + "user", + "assistant" + ], + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Audience" + }, + "priority": { + "anyOf": [ + { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Priority" + } + }, + "title": "Annotations", + "type": "object" + }, + "TextContent": { + "additionalProperties": true, + "description": "Text content for a message.", + "properties": { + "_meta": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Meta" + }, + "annotations": { + "anyOf": [ + { + "$ref": "#/$defs/Annotations" + }, + { + "type": "null" + } + ], + "default": null + }, + "text": { + "title": "Text", + "type": "string" + }, + "type": { + "const": "text", + "title": "Type", + "type": "string" + } + }, + "required": [ + "type", + "text" + ], + "title": "TextContent", + "type": "object" + } +} - added
Output schema / properties / result / itemsAdded value: +{ + "$ref": "#/$defs/TextContent" +} - changed
Output schema / properties / result / typePrevious value: -"string"New value: +"array"
1 tool update
- Changed
siteImageExplorer3 fields changed- added
Output schema / $defs / ImageContentAdded value: +{ + "additionalProperties": true, + "description": "Image content for a message.", + "properties": { + "_meta": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Meta" + }, + "annotations": { + "anyOf": [ + { + "$ref": "#/$defs/Annotations" + }, + { + "type": "null" + } + ], + "default": null + }, + "data": { + "title": "Data", + "type": "string" + }, + "mimeType": { + "title": "Mimetype", + "type": "string" + }, + "type": { + "const": "image", + "title": "Type", + "type": "string" + } + }, + "required": [ + "type", + "data", + "mimeType" + ], + "title": "ImageContent", + "type": "object" +} - removed
Output schema / properties / result / items / $refRemoved value: -"#/$defs/TextContent" - added
Output schema / properties / result / items / anyOfAdded value: +[ + { + "$ref": "#/$defs/TextContent" + }, + { + "$ref": "#/$defs/ImageContent" + } +]
1 tool update
- Changed
siteImageExplorer3 fields changed- added
Output schema / $defsAdded value: +{ + "Annotations": { + "additionalProperties": true, + "properties": { + "audience": { + "anyOf": [ + { + "items": { + "enum": [ + "user", + "assistant" + ], + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Audience" + }, + "priority": { + "anyOf": [ + { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Priority" + } + }, + "title": "Annotations", + "type": "object" + }, + "TextContent": { + "additionalProperties": true, + "description": "Text content for a message.", + "properties": { + "_meta": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Meta" + }, + "annotations": { + "anyOf": [ + { + "$ref": "#/$defs/Annotations" + }, + { + "type": "null" + } + ], + "default": null + }, + "text": { + "title": "Text", + "type": "string" + }, + "type": { + "const": "text", + "title": "Type", + "type": "string" + } + }, + "required": [ + "type", + "text" + ], + "title": "TextContent", + "type": "object" + } +} - added
Output schema / properties / result / itemsAdded value: +{ + "$ref": "#/$defs/TextContent" +} - changed
Output schema / properties / result / typePrevious value: -"string"New value: +"array"
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Related MCP Connectors
AI Hub for AEC — 50+ 3D formats, clash detection, ACC integration via Autodesk Platform Services.
- AgineraOAuthai.aginera
Turn construction drawings into takeoffs, measured routes, schedules and estimates.
1 Access and manage CenterPoint Connect data for property management, construction, and service oper…
36 MCP tools for projects, tasks, workers, QR/NFC tags, and AI remediation. Task. Scan. Done.
Related MCP Servers
- AlicenseAqualityBmaintenanceProvides construction-supervision tools for small-to-medium building projects, including stage guidance, inspection checklists, progress tracking, next-stage recommendations, and quotation analysis. It enables local, standards-based MCP interaction over stdio without third-party MCP SDKs.5MIT
- AlicenseNot gradedqualityBmaintenanceEnables construction professionals to query project documents with conflict-aware RAG, detect contradictions, and trace change impacts through any MCP client.2,019MIT
- FlicenseNot gradedqualityCmaintenanceProvides read-only MCP tools to query building construction approval lifecycle data, covering project discovery, bidding, contracts, drawing review, permits, and completion records.1-
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.2/5.0
Disambiguation3/5
Tools generally have distinct purposes, but there is overlap between analyze-progress-and-forecasts and ask-about-project-data for progress metrics, and between search-site-photos and ask-about-project-data for capture data. The descriptions include guidance (e.g., 'use analyze-progress for trade visibility'), but an agent may still be uncertain which tool to choose for a given query.
Naming Consistency4/5
All tool names use a consistent lowercase hyphen-separated format with a verb prefix (e.g., list-my-projects, set-focus-project). Most follow a verb-noun structure, though ask-about-project-data and analyze-progress-and-forecasts include prepositions/conjunctions, making them slightly less uniform.
Tool Count5/5
With 7 tools, the server is well-scoped for its purpose: four analysis tools and three context-management tools. Each tool serves a clear role without unnecessary redundancy, and the count aligns well with typical MCP server conventions.
Completeness4/5
The tool set covers the core needs of project progress analysis, natural language querying, photo search, findings comparison, and project context management. Access to detailed records is available through ask-about-project-data, so no major dead ends. Minor gaps include no dedicated tool for just listing captures or viewing project details, but these are addressable via the query tool.