What can you do with this server?

@raygister/mcp is a read-only MCP server for the Raygister platform, enabling AI assistants to browse and analyze construction project data through six tools: * list_projects: Browse all projects in your organization with pagination (page, per_page), returning project IDs, names, statuses, and creation dates. * get_project: Fetch full details of a single project by UUID, including counts of associated lots, locations, and specifications, plus organization context. * list_lots: List all lots (work packages) for a given project with pagination, returning lot IDs, types (e.g. plumbing, HVAC), names, and statuses. * get_lot: Fetch a single lot's full details including description, type, instance number, current status, and inline specifications. * list_specifications: List all DPGF (project bid document) line items for a specific lot with pagination, returning IDs, descriptions, quantities, units, and tags. * list_locations: Retrieve all rooms, floors, and zones for a project as a flat (non-paginated) list, including location IDs, names, floor numbers, and parent location IDs for hierarchy. All tools are strictly read-only — no data mutation is supported.

How do I use @raygister/mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@raygister/mcp List my construction projects" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

@raygister/mcp

by raygisterinc

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

@raygister/mcp

Read-only Model Context Protocol server for Raygister, the SaaS for architects to manage construction consultation projects (DPGF, lots, specifications, locations).

npm version license MCP

Features

Six read-only tools wrapping the Raygister public API. The server is strictly read-only in v1: there are no tools that mutate state.

list_projects browse all projects in your organization with pagination
get_project fetch full details of a single project including counts
list_lots list every lot (work package) of a project
get_lot fetch a single lot with its inline specifications
list_specifications list every DPGF line item of a lot
list_locations list rooms, floors, and zones of a project

Related MCP server: OfficeRnD MCP Server

Installation

Add the server to your MCP client. For Claude Desktop, edit your claude_desktop_config.json:

{
  "mcpServers": {
    "raygister": {
      "command": "npx",
      "args": ["-y", "@raygister/mcp"],
      "env": {
        "RAYGISTER_API_KEY": "dk_your_key_here"
      }
    }
  }
}

For Claude Code, the equivalent CLI command is:

claude mcp add raygister -- npx -y @raygister/mcp

then set RAYGISTER_API_KEY in the environment passed to the server.

How to get an API key

Sign in to app.raygister.com.
Open Settings then API keys. (TODO: confirm exact path before publishing.)
Create a new key. It will start with dk_ and is shown only once. Copy it into your MCP client config.

API keys are scoped to a single organization. The Raygister backend enforces tenant isolation, so the MCP only ever sees data from the organization the key belongs to.

Example prompts

Once the server is connected, you can ask your AI assistant things like:

"List my Raygister projects and tell me which one has the most lots."
"For project Hôtel Mercure Lyon, summarise the plumbing lot's specifications."
"Compare the number of locations across all my active projects."
"Show me every specification tagged 'electrical' for the office tower project."
"Give me a high-level breakdown of lots by type for the most recently created project."

Tool reference

Name	Description	Required inputs
`list_projects`	Paginated list of projects in the organization.	none
`get_project`	Single project with counts (lots, specifications, locations) and metadata.	`projectId`
`list_lots`	Paginated list of lots for a project.	`projectId`
`get_lot`	Single lot with full description, type, status, and inline specifications.	`projectId`, `lotId`
`list_specifications`	Paginated list of specifications (DPGF line items) for a lot.	`projectId`, `lotId`
`list_locations`	Flat list of all locations for a project. Not paginated.	`projectId`

Pagination tools also accept page (default 1) and per_page (default 20, max 100).

Configuration

Variable	Required	Default	Description
`RAYGISTER_API_KEY`	yes	none	API key starting with `dk_`. Get one from your Raygister settings.
`RAYGISTER_API_URL`	no	`https://app.raygister.com/api`	Override the API base URL. Useful for staging or local development.
`POSTHOG_API_KEY`	no	none	Enables anonymous tool-call telemetry. Disabled when unset.
`POSTHOG_HOST`	no	`https://eu.posthog.com`	PostHog instance to send events to.

When POSTHOG_API_KEY is unset, the telemetry layer is a strict no-op. When set, it captures only the tool name, success flag, duration, and a hash-derived install identifier. The raw API key is never sent.

Local development

git clone https://github.com/raygisterinc/mcp.git
cd mcp
pnpm install
pnpm build

To iterate, run pnpm dev to rebuild on save.

To test against a local Raygister API:

export RAYGISTER_API_KEY=dk_your_local_key
export RAYGISTER_API_URL=http://localhost:3000/api
node dist/index.js

The MCP server speaks JSON-RPC over stdio. To exercise it without a client, use the smoke script:

export RAYGISTER_API_KEY=dk_your_key
pnpm smoke

The script calls each tool sequentially and prints success or failure per endpoint.

Contributing

Issues and pull requests welcome at github.com/raygisterinc/mcp. Please open an issue first if you plan a non-trivial change.

License

MIT, see LICENSE.

Available Tools

6 tools

get_lotA

Retrieve a single lot with its full description, type, instance number, current status, and inline specifications. Use list_lots first if the lot ID is unknown.

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	UUID of the parent project
`lotId`	Yes	UUID of the lot

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description implies read-only retrieval without side effects. It adds transparency by listing return fields. However, it does not explicitly state that it is idempotent or what happens on missing lot.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no redundant words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema or annotations, the description sufficiently explains the tool's purpose, return fields, and prerequisite step. It fits well with sibling tools like list_lots.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters with clear descriptions (UUID of parent project and lot). Description adds no further meaning beyond schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Retrieve' and the resource 'single lot', listing specific fields returned (description, type, instance number, status, specs). It is clearly distinguished from sibling 'list_lots' which lists multiple lots.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to use 'list_lots first if the lot ID is unknown,' providing a direct when-to-use vs alternative guidance. No other exclusions needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_projectA

Retrieve full details of a single Raygister project by ID, including counts of lots, locations, and specifications, plus organization context. Use list_projects first if the project ID is unknown.

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	UUID of the Raygister project

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It implies a read-only operation ('Retrieve'), but does not explicitly state that no data is modified, which is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple get with one parameter and no output schema, the description effectively covers what is returned (full details with counts and context) and the precondition (use list_projects if ID unknown).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds minimal extra meaning beyond 'by ID' (already in schema). Baseline 3 is appropriate.

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 retrieves full details of a single Raygister project by ID, including specific data elements (counts, context), distinguishing it from siblings like list_projects and get_lot.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to use list_projects first if project ID is unknown, providing clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_locationsA

List all locations (rooms, floors, zones) of a project. Returns location IDs, names, floor numbers, and parent location IDs for hierarchy. The response is a flat list, not paginated.

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	UUID of the parent project

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden for behavioral disclosure. It notes the response is a flat list and not paginated, but does not mention if the operation is read-only, permissions required, or error behavior. This is adequate but not thorough.

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 two sentences long, front-loaded with the purpose, and every sentence adds value. There is no redundant or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one required parameter and no output schema, the description adequately covers the return fields and response structure (flat, non-paginated). It is complete enough for an agent to understand what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for the single parameter projectId. The description only reiterates 'of a project' from the schema, adding no new semantic context beyond what the schema already provides. Baseline of 3 is appropriate.

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 all locations (rooms, floors, zones) for a project, specifying the returned fields (IDs, names, floor numbers, parent location IDs). This is a specific verb-resource combination that distinguishes it from sibling tools like list_lots and list_specifications.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives. It lacks context about prerequisites, exclusions, or scenarios where another tool would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_lotsA

List all lots (work packages) of a given project. Returns lot IDs, types (e.g. plumbing, HVAC), names, and statuses. Use the lot IDs to fetch specifications or full lot details.

ParametersJSON Schema

Name	Required	Description
`projectId`	Yes	UUID of the parent project
`page`	No	Page number, 1-indexed. Defaults to 1.
`per_page`	No	Items per page, max 100. Defaults to 20.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It mentions returning specific fields (IDs, types, names, statuses) but does not disclose pagination behavior or other potential traits like sorting.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with purpose and a usage hint. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool, full schema coverage, and no output schema, the description adequately covers what the tool does and how to use the results. No missing information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage with descriptions for all parameters. The description adds minimal extra meaning, just 'parent project' for projectId. Baseline 3 is appropriate.

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 (list), resource (lots), and scope (of a given project). It differentiates from siblings like get_lot and list_specifications.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies using lot IDs for further actions like fetching specifications, but does not explicitly state when to use this tool or when not to use it. No exclusions or alternative suggestions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_projectsA

List all projects in the user's Raygister organization. Supports pagination via page and per_page. Returns project IDs, names, statuses, and creation dates. Use the project ID to fetch lots, locations, or full project details.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No	Page number, 1-indexed. Defaults to 1.
`per_page`	No	Items per page, max 100. Defaults to 20.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should fully disclose behavior. It states a read operation with pagination and returned fields, but omits details like authentication requirements, rate limits, or ordering.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the main purpose, and no redundant information. Every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description mentions pagination and the return fields (IDs, names, statuses, dates), which is helpful given the lack of an output schema. Could be enhanced with default pagination values or ordering details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description adds minimal value ('Supports pagination via page and per_page') beyond what the schema already provides. Baseline 3 is appropriate.

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 action ('List') and resource ('all projects in the user's Raygister organization'). It distinguishes from siblings like get_project (individual project) and list_lots (different resource).

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 context for when to use this tool by mentioning downstream usage ('Use the project ID to fetch lots, locations, or full project details'). Lacks explicit when-not-to-use or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_specificationsA

List all specifications of a given lot. Specifications are the detailed line items of the DPGF (project bid document). Returns IDs, descriptions, quantities, units, and tags.

ParametersJSON Schema

Name	Required	Description
`projectId`	Yes	UUID of the parent project
`lotId`	Yes	UUID of the lot
`page`	No	Page number, 1-indexed. Defaults to 1.
`per_page`	No	Items per page, max 100. Defaults to 20.

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It mentions pagination parameters but does not clarify that results may be paginated or that 'List all' might require multiple requests. The description assumes read-only behavior but doesn't confirm it.

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 two sentences that efficiently convey purpose, domain, and output. No unnecessary words; front-loaded with the action.

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?

Given the tool has 4 parameters and no output schema, the description covers the return format and domain. It omits explicit pagination behavior but schema provides bounds. Almost complete for a straightforward listing tool.

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 descriptions cover all parameters (100% coverage), so baseline is 3. The description adds value by explaining the domain (DPGF line items) and listing return fields, which indirectly reinforces parameter purpose. This extra context merits a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists specifications for a given lot, defines specifications as detailed line items of DPGF, and notes the returned fields. This distinguishes it from siblings like get_lot or list_lots.

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?

While the description makes the tool's function obvious, it does not explicitly state when to use this over alternatives (e.g., get_lot for single lot details). However, the context is clear enough for an AI to infer appropriate use.

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.

6 tool updatesv0.1.0May 4, 2026
- First observedget_lot
- First observedget_project
- First observedlist_locations
- First observedlist_lots
- First observedlist_projects
- First observedlist_specifications

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-05-04 10:10 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: retrieving single items vs listing collections, and each resource type (project, lot, location, specification) has its own dedicated tool, eliminating ambiguity.

Naming Consistency5/5

All tool names consistently use the verb_noun pattern with 'get_' for single-item retrieval and 'list_' for collections, making the naming predictable and easy to follow.

Tool Count5/5

With 6 tools covering the core entities (projects, lots, locations, specifications), the count is well-scoped for a read-only project management server, providing essential operations without bloat.

Completeness3/5

The tool set covers listing and retrieval for all resources, but lacks any create, update, or delete operations, and missing individual retrieval for locations and specifications, leaving notable gaps for full lifecycle management.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
ORANO MCP Server
io.github.infotik
Read-only MCP server exposing a user ORANO library to their own AI agent.
Note Taking Knowledge & Memory Search
1
classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2
The Quiet Protocol Growth Offense MCP A
com.thequietprotocol.www
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Databases Research & Data Finance
292

Related MCP Servers

ClaudeHopper
RAG Systems Vector Databases Developer Tools
Arborist-ai
A
license
Not graded
quality
D
maintenance
AI-powered MCP server that enables Claude and other LLMs to interact directly with construction documents, drawings, and specifications through advanced RAG and hybrid search capabilities.
Updated a year ago (2025-04-22 23:21 UTC)
9
MIT
OfficeRnD MCP Server
Workplace & Productivity Real Estate Project Management
MrBoor
A
license
A
quality
D
maintenance
A read-only MCP server that connects AI assistants to the OfficeRnD coworking and flex-space management platform. It enables natural language queries for community members, space bookings, billing records, and office resources.
Updated 6 months ago (2026-03-27 02:43 UTC)
5
1
MIT
Context Weaver
Project Management Workplace & Productivity
grxkun
A
license
Not graded
quality
D
maintenance
An MCP server that gives LLMs read-only access to Microsoft Project Online (Project for the Web) via the Microsoft Graph API.
Updated 5 months ago (2026-04-06 05:13 UTC)
9 npm
MIT
@rarecloudio/mcp-serverofficial
Cloud Platforms Developer Tools Payments & Billing
RareCloudio
A
license
A
quality
B
maintenance
Read-only MCP server for the RareCloud API, enabling AI agents to list servers, browse the catalog, check billing, and plan deployments.
Updated 10 days ago (2026-09-10 07:05 UTC)
100
8 npm
MIT

@raygister/mcp

Features

Installation

How to get an API key

Example prompts

Tool reference

Configuration

Local development

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

@rarecloudio/mcp-serverofficial