Generates multi-stage Dockerfiles for containerized deployment of the backend and other services.
Generates an optional Fastify service as part of the backend, with multi-stage Dockerfile and routing.
Generates Figma import plugins and wireframes, and enables syncing design tokens and REST handoff comments.
Integrates Firebase as an alternative backend, generating security rules and configuration.
Generates a complete Flutter application with immersive 3D deep-scroll canvas, theme tokens, and widget tests.
Generates CI workflows for GitHub Actions to automate testing and deployment of the generated project.
Generates a Node.js backend with optional Fastify service, including API contracts and business logic.
Generates Rive animation overlays for interactive HUDs in the Flutter spatial app.
Integrates Stripe for payment processing, generating subscription management and checkout flows in the generated app.
Integrates Supabase as the backend, generating migrations, Row Level Security policies, and storage policies.
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., "@devuniverse-mcp build a Flutter e-commerce app with Supabase backend"
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.
An autonomous virtual software agency, packaged as an MCP server.
Point any MCP client (Claude Code, Claude Desktop, Cursor, …) at devuniverse-mcp,
describe a product, and a bench of 27 senior engineering personas convenes:
they parse your requirements, propose stacks, debate each other, vote, record
dissents, generate a production-grade scaffold — Flutter app with an immersive
3D deep-scroll canvas, Supabase/Firebase/Node backend with Row Level Security,
multi-stage Dockerfiles, CI, Terms of Service and a GDPR/CCPA Privacy Policy —
then cross-examine every generated artifact before presenting it, with the
full meeting transcript on disk.
init_dev_universe(
project_type: "flutter_spatial_app",
description: "A 3D deep-scroll galaxy shop called 'Aurora Atelier' with
glTF product meshes, accounts, offline mode, and Stripe
subscriptions — GDPR matters. Glassmorphism, dark.",
use_omnicinema: true
)
→ projects/aurora-atelier/ (50+ files, 10 debated decisions, transcript, audit)Related MCP server: Gravitas-Core-MCP
flowchart LR
A[init_dev_universe] --> B[Signal parsing<br/>3d · offline · payments · tenants · gdpr…]
B --> C[Roundtable<br/>proposals → objections → mitigations → votes]
C --> D[Rulings + ADRs<br/>dissents recorded]
D --> E[Design synthesis<br/>aesthetic blend → tokens]
E --> F[Scaffold assembly<br/>app · backend · RLS · Docker · CI · legal docs]
F --> G[Cross-examination<br/>RLS/FK/a11y/secrets/legal checks,<br/>auto-fixes recorded]
G --> H[Write to projects/<slug><br/>+ MEETING_TRANSCRIPT.md]
H --> I[Wireframes + Figma plugin]
H --> J[Compliance audit report]
H --> K[Asset watcher armed]Every phase is deterministic: the debate is driven by a stance table (who champions what, when, how strongly, and who objects with which argument), scored against the parsed requirement signals. Same brief in, same rulings out — reproducible, diffable, and covered by tests.
What lands in projects/<slug>/:
Artifact | Contents |
| Full debate: proposals, objections, responses, votes, rulings, dissents, artifact review table |
| One ADR per decision with options, scores, champions, and recorded dissent |
| Flutter app: theme tokens, spatial module (if 3D), widget tests, analysis options |
| Supabase migrations + RLS policies + storage policies, or Firebase rules; optional Fastify service with multi-stage Dockerfile |
|
|
| Privacy Policy, Terms of Service, store checklist, audit report |
| Delivery + secret-routing discipline |
27 codified senior personas across six practices — run get_agency_roster for the full table.
Practice | Personas |
Multi-framework specialists | Principal Systems Architect · Principal Flutter Architect · Flutter Platform Engineer · Supabase/Postgres Architect · Firebase Specialist · Node.js Backend Architect · API Contract Engineer |
UI/UX synthesis | Principal UX Engineer · Design Synthesis Director · Spatial Canvas UI Engineer · 3D Navigation Designer · Accessibility Lead |
Legal & compliance | Privacy & Data Protection Counsel (GDPR/CCPA) · App Store & Licensing Compliance Officer |
3D & animation | 3D Modeler / glTF Pipeline Engineer · Technical Animator (Rive) |
Database | Principal Data Modeler · RLS & Data Security Engineer |
DevSecOps & delivery | Principal DevSecOps Engineer · Container & Isolation Specialist · CI/CD Release Engineer · SRE · QA Architect · Performance Engineer · Red-Team Reviewer · DX Engineer · Delivery Lead (chair) |
They genuinely disagree. A payments brief makes the Node architect win a service
layer over the SRE's objection; the Flutter platform engineer kills three_dart
on maintenance grounds every time; the accessibility lead's sign-off condition
(reduced-motion flat fallback) is enforced by a cross-exam check against the
actual generated Dart.
# The canonical home for this tool and everything it generates:
git clone https://github.com/<you>/devuniverse-mcp.git /Volumes/PortableSSD/devuniverse-mcp
cd /Volumes/PortableSSD/devuniverse-mcp
npm install
npm run build
npm test && npm run smoke # 22 tests + a real stdio round-tripRunning from a different path? Set
DEVUNIVERSE_ROOT— every read and write stays inside that root.
Claude Code
claude mcp add devuniverse -- node /Volumes/PortableSSD/devuniverse-mcp/dist/index.jsClaude Desktop / Cursor (claude_desktop_config.json / mcp.json)
{
"mcpServers": {
"devuniverse": {
"command": "node",
"args": ["/Volumes/PortableSSD/devuniverse-mcp/dist/index.js"],
"env": { "OMNICINEMA_REPO_URL": "https://github.com/<owner>/omnicinema-mcp" }
}
}
}Then, in your client: "Use init_dev_universe to build a 3D portfolio universe with offline mode and a contact form, dark editorial style."
Tool | What it does |
| The unified entry point. |
| The 27 seniors: names, titles, focus, principles. |
| Emit the deep-scroll 3D Flutter module standalone or into an existing project ( |
| Analyze art in the drop zones and re-derive the theme (report + WCAG checks). |
| Start/stop the drop-zone watcher; omit |
| Detect the companion, check loopback IPC health, report CASE A/B/C. |
| CASE C: consent-gated clone → install → build → start IPC → token sync. |
| CASE A: request image/texture/audio/video from the companion; provenance manifest + auto-adaptation. |
| Compile wireframes (SVG), generate the Figma import plugin, optional REST handoff comment ( |
| Pattern-analyze a URL or local video you provide; optional |
| Crawl GitHub/Hugging Face for new MCP servers → |
| (Re)generate Terms/Privacy/store checklist for a project, with overrides ( |
| Static liability scan → |
src/spatial/ is a code-generation skill producing a hand-owned deep-scroll
core — scrolling dollies a camera along the Z axis:
DeepScrollController — maps scroll offset → camera depth with capped travel
velocity and snap-point rooms ("seatbelts for spatial scrolling").
SpatialCamera + ParallaxLayer — Matrix4 perspective transforms
(setEntry(3,2,…)), per-layer parallax factors, depth-fade curves.
StarfieldPainter — seeded CustomPainter behind a RepaintBoundary,
shouldRepaint keyed on camera depth (the performance engineer's 16 ms budget).
SpatialRooms — content stations strung through Z with wayfinding rail.
Accessibility contract: when MediaQuery.disableAnimations is set the
entire Z-axis experience collapses to a flat, semantic, screen-reader-navigable
list. This is checked against the generated Dart, not just promised.
Optional mesh stage: flutter_scene (glTF/Impeller, wrapped behind a
GltfStage seam) or flutter_cube (lightweight OBJ). three_dart is debated
and rejected on maintenance grounds — you'll find the argument in the ADR.
Optional rive HUD overlay driven by a state machine.
Drop any image into app/assets/incoming/ (watched) or call verify_assets:
Verify — format sniffing (PNG/JPEG/GIF/WebP/BMP/SVG), header dimensions, and for PNGs a full dependency-free decode (zlib inflate + unfilter) with palette clustering.
Adapt — deterministic rules re-derive the design tokens: theme brightness
from hero luminance, primary from the most saturated dominant cluster
(contrast-nudged to ≥3:1), secondary from the next distinct hue, padding grid
from hero aspect, radius from saturation. Every rule is written into
docs/ADAPTATION_REPORT.md with WCAG verification.
Apply — design-tokens.json and the marker-delimited block in
app/lib/theme/design_tokens.dart are patched atomically.
src/bridge/omnicinema-connector.ts links the optional local media generator
for cinematic assets. Detection looks at /Volumes/PortableSSD/autonomous-cinema-mcp,
/Volumes/PortableSSD/omnicinema-mcp (override: OMNICINEMA_PATHS).
Case | State | Behavior |
A | Installed & IPC healthy |
|
B | Not found | You get: |
C | Not found + your consent |
|
Security model (see SECURITY.md): provisioning refuses unpinned URLs
(OMNICINEMA_REPO_URL must be a concrete https://github.com/<owner>/<repo>),
consent is explicit and recorded, the bridge follows only same-origin asset
URLs, and every IPC request is logged — a public tool that talks to another
local process should never do so silently.
To Figma. The Figma REST API cannot create or edit design content (it reads
files, writes comments/webhooks). So sync_figma produces what actually lands
an editable draft:
SVG wireframes per screen (screen plan derived from your signals: spatial journey, auth, explore, messages, checkout, settings…) — drag into any file;
a generated Figma development plugin (design/figma-plugin/) that
rebuilds every screen as native auto-layout frames using your tokens — import
via Plugins → Development → Import plugin from manifest, edit freely, then
hand changes back through tokens or the asset drop zone;
an optional REST handoff: token-validated comment on your Figma file
linking the draft materials (FIGMA_TOKEN).
From references. ingest_reference accepts a URL or a local video that
demonstrates an interaction you want:
URLs: single-page read (+ same-origin CSS, size-capped, honest User-Agent) → palette, typography, framework fingerprint (three.js, GSAP/ScrollTrigger, React/Vue/Next, WebGL, Rive/Lottie…), interaction mechanics (scroll-snap, IntersectionObserver, 3D transforms, reduced-motion handling), structure and a11y signals — plus a rebuild plan mapped onto devuniverse modules.
Videos: ffprobe/ffmpeg (when installed) extract metadata + keyframes with
per-scene palettes into references/<slug>/frames/.
apply_theme: true blends the extracted palette into your tokens via the
synthesis engine.
IP stance, stated plainly: reconstruction is pattern-level — interaction
mechanics and structure are re-derived natively; protected artwork, copy, and
trade dress are never copied, and the note ships inside every analysis report.
Likewise, the aesthetic library is curated and license-clean: devuniverse does
not crawl Dribbble/Behance (their ToS prohibit scraping); you steer the
blend with style_preferences and references you have the right to study.
The legal bench generates, per project:
Privacy Policy — GDPR (lawful-basis + retention table per actual data category, Arts. 15–22 rights, 72-hour breach window, transfers/SCCs) and CCPA/CPRA (know/delete/correct/opt-out, "we do not sell or share"), COPPA section when the brief targets children, in-app account deletion per Apple 5.1.1(v) / Play policy.
Terms of Service — license, acceptable use, UGC, IP, subscriptions/IAP language matched to the detected monetization, liability caps, governing law.
Store compliance checklist — Apple privacy labels & IAP rules, Play data safety & billing, web consent banners — only the rows your build triggers.
Active code audit (audit_compliance, also run at init) — committed
credentials, plaintext endpoints, undisclosed tracker SDKs, sensitive
permissions, missing policies → severity-ranked report with remediations.
Cross-exam gates: privacy counsel verifies the docs cover what the signals
imply; the RLS engineer auto-fixes any table created without
enable row level security and records the fix in the transcript.
The honest version of "zero compliance liabilities": generated documents are structured drafts with a mandatory review-by-counsel banner, and the audit reports residual risk. No tool can guarantee legal outcomes — this one refuses to pretend otherwise.
scan_extension_marketplace discovers newly published MCP servers and dev
packages (GitHub search + Hugging Face spaces/models) and logs them to
data/dev-review-queue.json as pending_human_review, with risk flags
(missing-license, low-adoption, suspicious-description,
pipe-to-shell-install, archived). Nothing is ever auto-installed; flip
entries to approved/rejected and your decisions survive re-scans.
Everything lives under one portable root (default
/Volumes/PortableSSD/devuniverse-mcp, override DEVUNIVERSE_ROOT):
devuniverse-mcp/
├── src/ server source (agency · spatial · bridge · compliance · design · marketplace)
├── dist/ build output (gitignored)
├── projects/ generated project environments (gitignored — each becomes its own repo)
├── data/
│ ├── dev-review-queue.json marketplace review queue (committed)
│ ├── omnicinema-link.json companion link record (chmod 600, gitignored)
│ └── logs/ detached-process logs (gitignored)
└── test/ scripts/ docsA storage guard wraps every write: paths must resolve inside the managed root, or the call throws. The only sanctioned writes outside it are the OmniCinema install directory you explicitly consent to.
npm run typecheck # strict TS across src/test/scripts
npm run build # tsc → dist/
npm test # node:test suite (roundtable, scaffold, PNG decode, bridges, crawler, legal)
npm run smoke # boots dist/index.js over real stdio and calls tools
npm run dev # tsx src/index.tsPRs welcome — new personas need a stance (when do they speak, what do they champion or object to, with what score) plus a test proving the debate stays deterministic.
Personas are codified expert heuristics, not 27 live LLMs: stance tables, scoring rules, and critique conditions driven by your requirement signals. That's what makes the debates reproducible, testable, and free to run. The transcript says so in its footer.
The bridge is transparent by design. The original brief for CASE A said "silently query" — this implementation logs every companion request instead, because a published tool talking to another local process must be auditable.
Figma REST can't author designs, so the pipeline generates a plugin + SVGs rather than pretending otherwise.
MIT — see also SECURITY.md.
Static scan of a project for liabilities: committed credentials, plaintext endpoints, undisclosed tracker SDKs, sensitive permissions, missing policy documents. Writes compliance/AUDIT_REPORT.md with severity-ranked findings and remediations.
| Name | Required | Description | Default |
|---|---|---|---|
| project_dir | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a write operation (compliance/AUDIT_REPORT.md) and the nature of findings (severity-ranked, with remediations). It also states it's a 'static scan,' implying no network or destructive side effects.
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 sentences with no wasted words. The first sentence lists what is scanned, the second states the output. Information is front-loaded and each sentence earns its place.
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?
For a tool with one parameter and no output schema, the description explains the scan scope and output file. Missing details about prerequisites, report overwrite behavior, or network requirements, but overall adequate for the simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (project_dir) with 0% schema description coverage. The description mentions 'project' but does not explicitly define the parameter format or semantics (e.g., absolute/relative path). It adds some implicit meaning but not enough for full clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a static scan for security liabilities and writes a report. It lists specific issues checked (committed credentials, plaintext endpoints, etc.), differentiating it from sibling tools like generate_compliance_docs or scan_extension_marketplace.
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?
No explicit guidance on when to use this tool versus alternatives. Among siblings, generate_compliance_docs might be related but no distinction provided. The description implies it's for scanning a project, but lacks exclusions or contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The legal bench drafts a complete Terms of Service, GDPR/CCPA Privacy Policy (lawful bases, retention, data-subject rights), and store compliance checklist from the project's actual data categories. Documents carry a review-by-counsel banner — structured drafts, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| project_dir | Yes | ||
| company_name | No | ||
| contact_email | No | ||
| governing_law | No | e.g. "Ireland" or "Delaware, USA" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that documents are draft-level with a 'review-by-counsel banner' and explicitly states 'structured drafts, not legal advice,' which clarifies limitations. This adds valuable behavioral context beyond a simple 'generates docs'.
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 sentences, front-loaded with clear outputs and a critical disclaimer. No unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool generates complex legal documents but has no output schema and missing parameter descriptions. The description does not explain the response format, success criteria, or how inputs map to outputs. For a tool with no output schema, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only 'governing_law' has a description). The description does not explain key parameters like 'project_dir', 'company_name', or 'contact_email'. It vaguely says 'from the project's actual data categories' but does not connect to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a Terms of Service, Privacy Policy (GDPR/CCPA), and a compliance checklist from project data categories. The verb 'generate' and specific outputs distinguish it clearly from sibling tools like 'audit_compliance' or 'verify_assets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when legal documents are needed based on project data, but it does not explicitly state when to use it or when to use alternatives like 'audit_compliance'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CASE A: request an image/texture/audio/video from the linked OmniCinema loopback API, save it into app/assets/generated/ with a provenance manifest entry, and re-adapt the theme to the new material.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| adapt | No | Re-run theme adaptation after saving (images only). | |
| prompt | Yes | What to generate, e.g. 'nebula background, deep violet, 4k'. | |
| file_name | No | ||
| project_dir | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses file saving, provenance manifest creation, and theme re-adaptation. However, with no annotations, it does not cover error handling, overwrite behavior, or side effects for non-image types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but somewhat convoluted with 'CASE A' and lacks clear separation of steps. It is moderately concise but could be better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description is incomplete. It omits details like file name auto-generation, project directory purpose, and whether the tool is idempotent, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (40%), and the description adds meaning to 'kind' and 'adapt' (e.g., adapt only for images). However, 'file_name' and 'project_dir' remain unexplained, and the description does not fully compensate for the gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool requests media assets (image/texture/audio/video) from an API, saves them to a specific directory with provenance, and re-adapts the theme. However, the 'CASE A' prefix is ambiguous and suggests incomplete context.
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?
No guidance on when to use this tool versus alternatives like generate_spatial_module or omnicinema_status. The description lacks context for appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Emit the spatial canvas code (scroll-driven Z-axis camera, Matrix4 perspective parallax layers, CustomPainter starfield, snap-point rooms, reduced-motion fallback; optional flutter_scene/flutter_cube mesh stage and Rive HUD) into an existing project or a fresh module directory.
| Name | Required | Description | Default |
|---|---|---|---|
| rive | No | Include the Rive HUD overlay seam. | |
| project_dir | No | Existing devuniverse project to write into (files land under app/). Omit to create a standalone module. | |
| depth_layers | No | ||
| project_name | No | Display name used inside the demo journey. | Spatial Canvas |
| mesh_renderer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions optional mesh renderers and Rive HUD, but lacks details on file overwriting, required permissions, error handling, or side effects. The description gives a sense of what is generated but not the behavior during generation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about 45 words, listing many features. While informative, it could be more concise or structured (e.g., bullet points) for easier scanning. The information density is high but the presentation is dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description should provide more comprehensive coverage. It does not explain the depth_layers parameter, the return value or success indicators, nor does it address prerequisites (e.g., Flutter setup). The description leaves significant gaps for an agent to invoke the tool correctly.
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 60% (3 of 5 parameters have descriptions). The tool description adds meaning for mesh_renderer and rive by referring to them as optional, and for project_dir by distinguishing existing project vs. standalone module. However, depth_layers and project_name are not explained beyond their schema defaults, missing an opportunity to clarify their role in the generated output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating an immersive 3D deep-scroll Flutter module. It lists specific features (scroll-driven Z-axis camera, Matrix4 parallax, CustomPainter starfield, etc.) and distinguishes the tool from siblings like audit_compliance or generate_compliance_docs by focusing on code generation for spatial canvas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that the tool can target an existing project or a fresh module directory, providing some usage context. However, it does not explicitly state when not to use the tool or mention alternatives. Given the sibling tools are quite different, the guidance is clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 27 senior personas that debate every project: names, titles, focus areas, and operating principles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description alone must disclose behavior. It fully describes what is returned (names, titles, focus areas, operating principles). It implies a read-only list operation with no side effects. Could mention if authentication is needed or if the roster is static, but the disclosure is good for a simple tool.
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?
Single sentence that is concise, front-loaded, and descriptive without any wasted words.
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?
For a simple list tool with no parameters and no output schema, the description adequately explains the content. It could mention if it returns the current or all personas, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the baseline is 4. No additional parameter information is needed; the description adds value by explaining what the output contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists the 27 senior personas with details like names, titles, focus areas, and operating principles. It uses a specific verb (list, implied) and resource (senior bench). No sibling tool has a similar function, so no need for differentiation.
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?
No explicit guidance on when to use this tool versus alternatives. The sibling tools include various other functions, but the description does not provide context on when to fetch the roster vs. other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reverse-engineer the patterns of a reference the user provides: palette, typography, framework/interaction fingerprint (three.js, GSAP ScrollTrigger, scroll-snap, WebGL…), structure, and an equivalent-rebuild plan mapped onto devuniverse modules. Videos get ffmpeg keyframe + palette analysis when ffmpeg is present. Pattern-level only — protected artwork and trade dress are never copied. apply_theme=true blends the extracted palette into the project tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public page you have the right to study. | |
| video_path | No | Local video file demonstrating the desired interaction. | |
| apply_theme | No | ||
| project_dir | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool only analyzes patterns and never copies protected artwork/trade dress, and mentions ffmpeg keyframe analysis when present. However, it does not describe side effects like file modifications or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, front-loaded with the core purpose. Every sentence adds value, including the caveat about protected works and the apply_theme behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema. The description explains the core function and some param semantics, but does not describe what the tool returns (e.g., a plan text, updated files) or error conditions. Given the lack of annotations, more detail on output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (url and video_path have descriptions). The description adds meaning beyond schema: it explains that apply_theme blends the extracted palette into project tokens and clarifies the purpose of url and video_path as input references. project_dir lacks explanation but is required.
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 uses specific verbs ('reverse-engineer the patterns') and identifies concrete resources (palette, typography, framework/interaction fingerprint). It clearly distinguishes from siblings by focusing on pattern analysis, not compliance, media generation, or other tasks listed in sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user provides a reference URL or video for studying patterns. It mentions ffmpeg analysis for videos and the apply_theme option, but does not explicitly state when to avoid this tool or suggest alternative tools from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convene the 27-senior virtual agency for a new project: parse requirements, debate and vote the stack (Supabase/Firebase/Node, Riverpod/Bloc, spatial 3D core, mesh renderer, offline layer…), synthesize a design language, generate the full scaffold (Flutter app, backend, RLS migrations, Dockerfiles, CI, Terms/Privacy docs), cross-examine every artifact, compile Figma-ready wireframes, run the compliance audit, and start the asset watcher. Everything lands under projects// with the complete meeting transcript.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Plain-language brief. Keywords steer the debate: 3d, offline, chat, payments, multi-tenant, gdpr… | |
| project_type | Yes | Kind of product to build (flutter_spatial_app enables the deep-scroll 3D canvas). | |
| use_omnicinema | No | Route the media pipeline through the OmniCinema companion (detected/linked automatically). | |
| style_preferences | No | Manual design preferences blended by the synthesis engine, e.g. ["glassmorphism", "dark", "luxury"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description thoroughly discloses behavioral traits: parsing, debating, voting, generating scaffold, cross-examining, compiling wireframes, running compliance audit, and starting asset watcher. It also states the output location (projects/<slug>/) and that a meeting transcript is stored. However, it does not mention potential side effects or persistence behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long sentence (over 100 words) summarizing many actions. While it front-loads the core purpose, it is not concise and could benefit from structured bullets or clearer separation of key points. Every sentence earns its place but readability suffers.
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?
No output schema is provided and the description does not explain the return value of the tool (e.g., JSON response, slug, status). It only mentions that artifacts land on disk. Given the tool's high complexity and multiple generated outputs, this omission leaves the agent without essential information about what the tool returns.
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 100%, so baseline is 3. The description adds context beyond the schema by explaining that keywords in 'description' steer the debate and that 'project_type' values like 'flutter_spatial_app' enable specific features. However, it does not systematically enhance each parameter's meaning.
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 uses the specific verb 'Convene the 27-senior virtual agency for a new project' and clearly states the tool initializes a DevUniverse project. It distinguishes itself from sibling tools like audit_compliance or generate_spatial_module by describing an all-encompassing initialization process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for starting new projects but does not explicitly state when to use this tool versus alternatives. There is no guidance on prerequisites, exclusions, or comparison with sibling tools like get_agency_roster or sync_figma. The purpose is implied but not formally clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect the OmniCinema media generator on this machine (well-known SSD paths + overrides), check its loopback IPC health, and report the CASE A/B/C state with next steps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully carries the burden. It transparently states the tool performs detection, health checking, and state reporting, which are read-only operations. It does not disclose potential side effects, but the operations described are inherently non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the main action and provides all necessary context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and is a straightforward status check, the description adequately covers the purpose, inputs, and outputs. It could be improved by specifying the output format, but it mentions 'CASE A/B/C state' which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters (schema coverage 100%), the description adds meaning by detailing what is checked (well-known SSD paths, overrides, IPC health) and the output (CASE A/B/C state), which is not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Detect', 'check', 'report') and clearly identifies the resource ('OmniCinema media generator'). It distinguishes itself from sibling tools like provision_omnicinema and generate_media_asset by focusing on detection and health checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking status, but provides no explicit guidance on when to use versus alternatives (e.g., before provisioning) or when not to use. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CASE C: "Would you like devuniverse-mcp to automatically clone, install dependencies, and link OmniCinema-MCP for 100% free cinematic assets? [y/N]" — with confirm: true this clones the pinned OMNICINEMA_REPO_URL, runs npm install + build, starts the IPC service detached (logged to data/logs/), and syncs the bearer token from data/ipc-token.txt. Refuses unpinned repository URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Explicit consent to clone, install dependencies, and run the companion tool. Must be true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details all major actions (clone, install, build, start service, sync token) and notes that it refuses unpinned URLs. It does not cover prerequisites or potential side effects (e.g., overwriting), but given no annotations, it provides reasonable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the trigger condition, actions, and constraint. It is slightly lengthy but each clause adds necessary detail. The structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema and no output schema, the description covers the main behavior well. Missing details like prerequisites or error handling are acceptable for a tool with clear consent and a specific action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for 'confirm'. The tool description adds value by explaining that confirm must be true to trigger the entire process, reinforcing the schema's requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool auto-provisions OmniCinema by cloning a pinned repo, installing dependencies, building, starting an IPC service, and syncing a bearer token. It distinguishes itself from sibling tools like 'omnicinema_status' by focusing on provisioning rather than querying status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one wants to set up OmniCinema with free assets, requiring explicit consent via confirm=true. It does not explicitly state when not to use it or compare to alternatives, but the context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crawl GitHub and Hugging Face for recently published MCP servers / development packages and log them to data/dev-review-queue.json as pending_human_review (with risk flags: missing license, low adoption, suspicious install patterns). Nothing is ever auto-installed; human decisions survive re-scans.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sources | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the output location, pending human review status, risk flags, and that nothing is auto-installed. Could add details on rate limits or error handling.
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 sentences, front-loaded with core action and outcome. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, and outcome but omits parameter details and potential errors. With no output schema, the description could better explain return format. Adequate for a simple tool but with gaps.
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%. The description mentions the two sources (GitHub, Hugging Face) but does not explain the 'limit' parameter or provide any additional meaning beyond the schema. The parameter semantics are weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (crawl and log), the target sources (GitHub, Hugging Face), the output (MCP servers/dev packages to a specific file with risk flags), and distinguishes from sibling tools like audit_compliance.
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?
States that nothing is auto-installed and human decisions survive re-scans, implying a review workflow. Lacks explicit when-not-to-use or alternatives, but the context is clear enough for a single-purpose scanning tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile the roundtable's screen plan into design artifacts: SVG wireframes (drag into Figma), a generated Figma development plugin that rebuilds the frames natively with auto-layout + tokens, and an optional REST handoff comment on your Figma file (FIGMA_TOKEN). The REST API cannot create designs — the plugin is the editable-draft path, and that constraint is documented in the output.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | plugin | |
| project_dir | Yes | ||
| figma_file_key | No | Figma file key (from its URL) — required for handoff mode. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the REST API cannot create designs and that the plugin is needed for editable drafts. However, it omits important behavioral details such as auth requirements (FIGMA_TOKEN is mentioned but not clarified as required), side effects (e.g., does it modify the Figma file?), and output location (local path or URL?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficiently front-loaded with the purpose and then detailing outputs and constraints. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should explain return values. It names the artifacts but does not specify the tool's response format (e.g., paths, URLs). It also lacks details on error handling or token requirements for handoff. Despite these gaps, it covers the core outputs and constraints reasonably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), so the description must compensate. It adds meaning by linking mode enum values to output types (wireframes, plugin, handoff) and mentioning the token context. But it does not describe project_dir or provide constraints for figma_file_key beyond the schema's description. The compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool compiles a screen plan into three specific design artifacts: SVG wireframes, a Figma plugin, and an optional REST handoff comment. The verb 'compile' and resource 'design artifacts' are specific, and the outputs are distinct from sibling tools, which focus on compliance, media, and spatial generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use each mode (wireframes, plugin, handoff) and explicitly notes that the REST API cannot create designs, so the plugin is the editable-draft path. It also implies that figma_file_key is needed for handoff mode. However, it does not explicitly state when to use this tool versus alternatives, though no close siblings exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze art in the project's asset drop zones (format, dimensions, dominant palette) and re-derive the design tokens — colors, brightness, padding grid, radii — so the app natively adapts. Writes docs/ADAPTATION_REPORT.md with every rule applied and WCAG contrast verification.
| Name | Required | Description | Default |
|---|---|---|---|
| project_dir | Yes | A generated devuniverse project directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses key behaviors: it writes a report at 'docs/ADAPTATION_REPORT.md' and includes WCAG contrast verification. However, it does not disclose whether the tool modifies project files beyond the report, what permissions are needed, or any side effects of re-deriving design tokens. The transparency is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action ('Analyze art... and re-derive the design tokens') and then detailing the output. Every sentence adds meaningful information without repetition or fluff. It is appropriately sized for a moderate-complexity tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the tool returns or how the agent should use the results. It mentions writing a report but does not clarify if the report content is returned or if the tool just signals completion. It also assumes knowledge of 'asset drop zones' without explanation. While the description covers the main actions, it lacks completeness for an agent to fully understand the tool's integration into a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with 100% coverage, providing a clear description: 'A generated devuniverse project directory.' The description does not add new information about the parameter itself; it only contextualizes it as 'project's asset drop zones.' With full schema coverage, the baseline is 3, and the description adds minimal extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing art assets in drop zones (format, dimensions, dominant palette) and re-deriving design tokens (colors, brightness, padding grid, radii) to adapt the theme. It also mentions writing a report. The verb 'analyze' and 're-derive' specify the action and resource. This distinguishes it from siblings like 'watch_assets' which likely only monitors changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used after assets are uploaded to 'asset drop zones' to adapt the theme. It provides context for when to use it but does not explicitly state when not to use it or mention alternatives. With sibling tools, an agent might need guidance on when to choose this over 'audit_compliance' or 'sync_figma', but the description is clear enough for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start/stop the watcher on app/assets/incoming — any image dropped there re-runs verification and theme adaptation automatically. Call without project_dir to list active watchers.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | No | ||
| project_dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes toggling and automatic re-run behavior, but lacks details on side effects, permissions, or process implications.
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 sentences, front-loaded with main action, no wasted words. Efficiently conveys core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool with no output schema and no annotations, description covers main purpose, parameter behavior, and automatic effects. Missing return value or error conditions, but adequately complete given low complexity.
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 has 0% description coverage, but description adds meaning: explains that removing project_dir changes behavior to listing. Adds value beyond schema structure.
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?
Description clearly states the tool starts/stops a watcher on a specific path, and lists active watchers when no project_dir. This distinguishes it from siblings like verify_assets or generate_media_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: start/stop watcher, and listing watchers without project_dir. However, no explicit when-not-to-use or alternatives among siblings.
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.0audit_compliancegenerate_compliance_docsgenerate_media_assetgenerate_spatial_moduleget_agency_rosteringest_referenceinit_dev_universeomnicinema_statusprovision_omnicinemascan_extension_marketplacesync_figmaverify_assetswatch_assetsScored across 13 tools
Tools are mostly distinct, but audit_compliance and generate_compliance_docs both relate to compliance, which could cause confusion. Similarly, verify_assets and watch_assets are related, though the latter extends the former.
All tool names follow a consistent verb_noun pattern with snake_case, e.g., audit_compliance, generate_media_asset, provision_omnicinema. No mixing of conventions.
With 13 tools covering project init, compliance, asset generation, media integration, Figma sync, and more, the count is well-scoped for the domain of a development universe assistant.
The tool surface covers core workflows (init, compliance, asset generation, verification), but lacks tools for updating or deleting projects and generated artifacts, which are minor gaps.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for generating rough-draft project plans from natural-language prompts.
MCP server for AI agent profiles and smart notes. 60+ coding prompt packs with expert personas.
An MCP memory server. One memory your agents share — across models, devices and apps.
