Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@archviz_mcp Find acoustic ceiling references for a high atrium and show photos."
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.
Живые архитектурные референсы через MCP + скилл для концепций и визуализаций по BIM.
Находит проекты онлайн, читает описание и авторство, показывает выбранные фотографии. Не создаёт локальную базу проектов, архив изображений или поисковый индекс. Сейчас реализован и проверен адаптер OfficeNext. API-ключи не нужны.
English: a read-only stdio MCP server for live architectural reference research, with a Russian-language agent skill. OfficeNext is the only implemented source. No persistent content database or image archive.
Инструмент | Результат |
| Поддерживаемые источники, ограничения поиска и хранения |
| Карточки проектов из одной страницы живого поиска OfficeNext |
| Авторство, сведения источника, выдержки и ссылки на галерею |
| Одна фотография в ответе MCP, без создания файла |
Скилл architectural-visualization связывает исследование с проектированием: проверка фото, применимость решения, сохранение геометрии модели, согласованность серии ракурсов и выпуск альбома. Сам сервер не меняет BIM и не генерирует рендеры — для этого агенту нужны соответствующие инструменты.
Related MCP server: Mercury MCP Server
Требуются Python 3.11+ и uv. Вариант из исходников даёт воспроизводимые зависимости из uv.lock:
git clone https://github.com/proovcme/archviz_mcp.git
cd archviz_mcp
uv sync --locked
uv run --locked archviz-mcpСервер ждёт MCP-сообщения в stdin/stdout, это не сайт и не интерактивная консоль. Завершение вручную — Ctrl+C. Диагностика идёт в stderr.
Для разового запуска без клонирования:
uvx --from git+https://github.com/proovcme/archviz_mcp.git archviz-mcpЭтот вариант устанавливает код и зависимости в кэш uv. Требование «без базы» относится к контенту референсов, а не к установленным программам. Для фиксированной версии к Git URL можно добавить @<commit-sha>.
После клонирования замените /absolute/path/archviz_mcp на свой абсолютный путь:
codex mcp add architectural_references --env PYTHONUTF8=1 -- uv --directory /absolute/path/archviz_mcp run --locked archviz-mcpНа Windows путь с пробелами заключите в кавычки. Если uv не находится в окружении приложения, укажите полный путь к нему.
Для других MCP-клиентов используйте эквивалентную конфигурацию (имя верхнего поля зависит от клиента):
{
"mcpServers": {
"architectural_references": {
"command": "uv",
"args": ["--directory", "/absolute/path/archviz_mcp", "run", "--locked", "archviz-mcp"],
"env": {"PYTHONUTF8": "1"}
}
}
}Скопируйте папку skills/architectural-visualization в каталог навыков вашего агента. Для Codex это обычно ~/.codex/skills/ (либо каталог skills внутри настроенного CODEX_HOME). Не перезаписывайте свою изменённую версию без сравнения. Затем откройте новый чат и проверьте наличие четырёх инструментов. Документация Codex MCP.
Пример задания агенту:
Используй $architectural-visualization. Найди примеры акустических потолков для высокого вестибюля. Нужны подвесные скруглённые острова, спокойный характер и выразительный свет. Посмотри фотографии, объясни, что применимо к нашей геометрии. Сохрани только выбранные ссылки и выводы.
Типичная последовательность:
Проверить reference_sources.
Выполнить несколько коротких поисков: «акустика», «потолок», «вестибюль».
Прочитать подходящие карточки; для focus полезны корни «акуст», «потол», «освещ».
Открыть релевантные фотографии через view_reference_image.
Разделить сведения автора, видимое на фото и предложенный перенос в новый проект.
Поисковая выдача не является готовой рекомендацией. Совпадение по слову «акустика» не доказывает наличие нужных потолочных панелей. Бюджет, высота, класс акустики и узлы крепления остаются неизвестными, если источник их не подтверждает.
Никаких фоновых обходов каталога и массового скачивания. Сетевые запросы выполняются по вызову инструмента.
HTML-кэш только в оперативной памяти: до 16 страниц, срок повторного использования 180 секунд. Изображения не кэшируются сервером на диск, выбранное фото передаётся в память клиента с размером до 1600 px.
MCP-хост может сохранять ответы и изображения в истории чата. Сервер не управляет политикой хранения хоста.
Поиск — одна страница нативной смешанной выдачи, из которой отбираются проекты; это не семантический поиск по всем годам. Есть параметр page.
Веб-страницы могут менять разметку, выдачу и доступность. Ошибки возвращаются явно; при проблемах используйте браузер или поиск по домену источника.
В текущем адаптере разрешён только HTTPS OfficeNext; перенаправления проверяются, размеры ответов ограничены, запросы разделены паузой. Произвольные URL и локальные адреса не поддерживаются.
Тексты источников считаются данными, а не инструкциями для агента.
WAF, WAF Interiors, ArchDaily и другие премии пока исследуются инструментами веб-поиска хоста. Их адаптеров в этом сервере нет.
Независимый проект, не официальный продукт OfficeNext. Фотографии и тексты принадлежат правообладателям; лицензия кода не даёт прав на их перепубликацию. Сохраняйте ссылки и авторство, учитывайте условия источника.
uv run --locked python -m unittest -v test_server
uv run --locked python test_server.py --live
uv buildОбычные тесты не обращаются к сети и проверяют парсинг, границы URL и поведение при изменении разметки. Live smoke test запускает реальный MCP-клиент через stdio, ищет три темы, читает карточки и проверяет передачу фото в памяти. Это проверка транспорта и извлечения, не художественная оценка фотографий. Live test зависит от доступности и выдачи OfficeNext, поэтому запускается вручную; CI выполняет автономные тесты на Windows/Linux и Python 3.11/3.13.
Новые источники добавляются отдельными проверенными адаптерами. Для каждого нужны понятная семантика поиска, ссылки и авторство, тесты изменения разметки и явные ограничения. Не добавляйте в репозиторий клиентские модели, изображения проектов, персональные оценки или ключи доступа.
Код и скилл: MIT. Сторонние материалы в репозиторий не включены.
Read a live OfficeNext project: authors, stated dates/materials, relevant text excerpts and all gallery image URLs. focus selects excerpts by keyword. Does not download images or infer visuals.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| focus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: it reads *live* content (network dependence), returns raw textual/excerpt data only, and refuses to infer visuals — meaningful scope limits an agent would otherwise guess wrong about. It stops short of describing failure modes (dead URLs, paywalled pages).
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?
Two tight sentences: the payload of returned fields is front-loaded, then the focus parameter, then the exclusion. No filler and nothing buried.
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?
With no output schema, the description correctly enumerates the return payload, which is the essential gap to fill. For a two-parameter read tool with full annotations, this is nearly complete; only the url validity contract and error behavior are missing.
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 description coverage is 0%, so the description carries the burden. It explains 'focus' well ('selects excerpts by keyword', defaulting to empty), but 'url' is never characterized — no format example, no statement that it must be a live OfficeNext project URL, which matters for an openWorld fetch.
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?
Specific verb (read) plus resource (a live OfficeNext project) and an explicit enumeration of what comes back: authors, stated dates/materials, excerpts, gallery image URLs. It also carves out territory against view_reference_image by saying it does not download images, though it never names that sibling or contrasts with search_references/reference_sources directly.
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 negative guidance is useful ('does not download images or infer visuals'), which steers an agent to view_reference_image for actual image retrieval. But there is no explicit when-to-use statement versus search_references or reference_sources, so the routing decision must be inferred from the tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report supported live sources and storage behavior; does not fetch or crawl.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral constraint (no fetching or crawling), but leaves terms like 'storage behavior' and the shape of the report undefined.
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?
A single compact sentence with the positive scope front-loaded and the exclusion appended. Nothing is wasted or padded.
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?
With no parameters and no output schema, the description is the only place an agent can learn what this returns, and 'supported live sources and storage behavior' does not say what form that information takes. It is adequate to decide whether to call it, but not to anticipate the result.
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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies for a no-argument tool.
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 names a specific action (report supported live sources and storage behavior), which is distinct from the sibling operations search_references, read_reference and view_reference_image. It is clear this is a capability/status reporting tool, though 'report' and 'storage behavior' remain slightly abstract.
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 clause 'does not fetch or crawl' implicitly steers the agent toward the fetch/read siblings, but no alternative tool is named and no explicit when-to-use condition is stated. Usage is inferable rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search OfficeNext live by 1-4 Russian keywords or project name. Returns candidate project links, not verified design matches. Break complex briefs into several short queries. No database/index.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely non-redundant behavior: results are unverified candidate links rather than confirmed design matches, and there is no database or index behind the search, which sets expectations about coverage and reliability.
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?
Three short sentences, all front-loaded with the operation and the query constraint first, then the caveat about result quality, then the decomposition advice. Nothing is repeated or padded.
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?
With no output schema, the description usefully characterizes what comes back (candidate project links, not verified matches), which is the key thing an agent needs to avoid over-trusting results. The only gap is the unaddressed pagination parameters and the absence of explicit sibling routing.
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 description coverage is 0%, so the description carries the burden. It does add real meaning for the required 'query' parameter (1-4 Russian keywords or a project name), but 'page' and 'limit' are never mentioned, leaving two of three parameters explained only by their bare titles and defaults.
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?
States a specific verb (search) and resource (OfficeNext references) plus the query vocabulary (1-4 Russian keywords or project name). It implicitly separates itself from a stored-index tool via 'No database/index', but never names the siblings read_reference or reference_sources, so the agent must infer the boundary.
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?
'Break complex briefs into several short queries' gives concrete query-shaping advice, and 'No database/index' implies a live-search context. However, there is no explicit when-to-use-this-vs-alternatives guidance and no statement of when not to call it (e.g., once a project link is known, use read_reference instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View ONE gallery photo from a verified OfficeNext project in memory, without a local image file. Use indices returned by read_reference. Image is max 1600px for visual review. Preserve attribution. Viewing a photograph does not establish hidden construction, dimensions, cost or acoustic performance.
| Name | Required | Description | Default |
|---|---|---|---|
| image_index | No | ||
| project_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond that: the 1600px size cap, the attribution-preservation obligation, and an explicit epistemic caveat that viewing an image proves nothing about construction, dimensions, cost or acoustics.
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 core capability and its constraint are front-loaded in the first sentence, with supporting caveats after. The final guardrail sentence is slightly tangential to invocation but earns its place as a scope limit on interpretation.
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?
An output schema exists, so return-value explanation is not required. The description covers source, sizing, attribution and interpretation limits; the main remaining gap is the unelaborated project_url requirement and behavior when the project is not verified.
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 description coverage is 0%, so the description must compensate. It partially does: image_index is explained as coming from read_reference. However, project_url — the only required parameter — is never described beyond 'verified OfficeNext project', leaving format and validation requirements undocumented.
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?
States a specific verb and resource ('View ONE gallery photo from a verified OfficeNext project') plus the key modality ('in memory, without a local image file'), which differentiates it from a file-based viewer. It does not explicitly contrast itself with sibling read_reference, but the reference to indices implies the distinction.
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 routes the agent: 'Use indices returned by read_reference' tells it where the required index comes from. There is no statement of when NOT to use it (e.g., use search_references to find a project first), so it falls short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0read_referencereference_sourcessearch_referencesview_reference_imageScored across 4 tools
Each tool has a distinct role: reporting sources, searching candidates, reading project details, and viewing a single gallery image. The search/read/view split is clear, and descriptions explicitly state boundaries such as search returning candidates versus read returning verified project content.
Three tools follow a clear verb_noun pattern: search_references, read_reference, view_reference_image. reference_sources is a noun phrase rather than an action, but it is still readable and semantically appropriate as a metadata/reporting tool.
Four tools are well scoped for a focused workflow around searching, reading, and visually inspecting OfficeNext references. It is slightly thin but each tool earns its place without unnecessary overlap.
The surface covers source discovery, keyword search, project reading, and image viewing, which is a coherent lifecycle for the stated reference-inspection purpose. Minor gaps include no browse/list operation independent of search and no batch image viewing, but these are workable limitations.
Search 2,500+ curated architecture, design, photography and art projects. Free tier, no signup.
Search, organize, generate design guidance from, and reconstruct what you save in Hipppo.
Live web research with related queries, browser-rendered sources, images, and evidence.
Multi-engine scholarly research server for search, traversal, full text, and reading lists.
