cupix-compass

Ask about anything in your projects: properties, BIM and drawing files, annotations, and capture details.

ask-about-project-data

Read-only

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 via set-focus-project). Do NOT call list-my-projects again 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

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`scope`	No
`cursor`	No
`team_domain`	No
`user_intent`	No
`facility_key`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`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.

All cupix-compass tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources

Need Help?