text-to-reality
PYPI · TEXT-TO-REALITY
Turn an idea into a device anyone can build: parts, printed parts, wiring, code and a picture guide.
Available components
Last scanned (3 hours ago)
Scores higher than 78% of PyPI servers
Category IoT and Hardware
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
- 1 of 28 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 29 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability76
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (fair).Partial
- Tool/resource definitions use about 985 tokens (~61/item across 16 items; 13 tools + 3 resources), lean.Pass
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management73
- Stability observed for 22 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 13 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 15 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 5 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 70 to 73. That category is still filling its 30-day observation window: 21 days of observed history at the previous scan, 22 at this one. The score rises as the window fills, whether or not the server changes.
- 3 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.
- 1 Nov 26 +16
- Malware scan: unverified → pass ▲ security
- 31 Oct 26 −15
- Malware scan: pass → unverified ▼ security
- 30 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 50 to 53. That category is still filling its 30-day observation window: 15 days of observed history at the previous scan, 16 at this one. The score rises as the window fills, whether or not the server changes.
- 28 Oct 26 +16
- Malware scan: unverified → pass ▲ security
- 27 Oct 26 −15
- Malware scan: pass → unverified ▼ security
- 26 Oct 26 +15
- Malware scan: unverified → pass ▲ security
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Analysed pypi/text-to-reality@0.1.1
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
| Reason | No attestation published |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 28 packages
| Packages resolved | 28 |
|---|---|
| No linked repository | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
board_headers ~49
Header rows (pins per row) for common boards and modules: XIAO, Pico, ESP32 DevKit, Arduino Nano, SSD1306 OLED and more.
| Name | Type | Req | Description |
|---|---|---|---|
| query | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
build_history ~29
Everything that happened to a build: files recorded, revisions, outcomes.
| Name | Type | Req | Description |
|---|---|---|---|
| project | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
check_package ~73
Check the build is complete and consistent: every stage finished, files unchanged since recorded, bom.json and wiring.json valid, JIG_ connectors in the parts list, an assembly guide present. Returns problems to fix and links to get the JIG_ parts the build uses.
| Name | Type | Req | Description |
|---|---|---|---|
| project | string | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
connector_guidance ~68
Read this before planning header wiring. Returns what JIG_ connectors are (a base that holds each wire's plug in order plus a snap-on cover), which headers they fit, how many to use, how to list them, and the steps to load them and plug them on.
Input schema present but exposes no named parameters.
Structured output declared, but exposes no named fields.
No examples provided.
connectors_for_boards ~139
Which JIG_ wire connectors a build needs: one per header row, sized to the whole row. `boards` is a list of {"board": name, "quantity": n}, or {"board": label, "rows": [pins, ...], "quantity": n} for a board that isn't in the catalog. `size` is small or large, matching the jumper wire plugs. row_checks lists what to confirm on the real board. Custom `headers` take the catalog row fields plus gender, rows, shrouded and preinstalled.
| Name | Type | Req | Description |
|---|---|---|---|
| boards | array | yes | – |
| size | string | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
create_project ~65
Start a build. `brief` is the idea in plain words plus anything known: size, power, budget, parts the person already owns, and how they'll know it works. Creates a folder with brief.md.
| Name | Type | Req | Description |
|---|---|---|---|
| brief | string | yes | – |
| name | string | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
find_jig_parts ~54
Look up JIG_ parts that remove soldering, crimping and breadboards: wire connectors, a XIAO battery adapter, and complete kits. Empty query lists everything.
| Name | Type | Req | Description |
|---|---|---|---|
| query | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
list_projects ~15
List builds in the projects folder.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
log_outcome ~65
Record what happened when the build was tried: worked, partly_worked or failed, with what was learned. Read it back with build_history before designing the next one.
| Name | Type | Req | Description |
|---|---|---|---|
| note | string | yes | – |
| project | string | yes | – |
| result | string | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
new_revision ~39
Start a new revision after a design change. Re-record files you change in it.
| Name | Type | Req | Description |
|---|---|---|---|
| note | string | yes | – |
| project | string | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
project_status ~35
Show each stage, its files, what to do next, and files edited since they were recorded.
| Name | Type | Req | Description |
|---|---|---|---|
| project | string | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
record_files ~69
Record files you've written (paths relative to the project folder) under a stage: requirements, parts, mechanical, electronics, firmware, assembly or testing. Recording fingerprints each file so later edits are caught.
| Name | Type | Req | Description |
|---|---|---|---|
| paths | array | yes | – |
| project | string | yes | – |
| stage | string | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
set_stage ~64
Set a stage to todo, done or not_applicable. not_applicable needs a reason (for example, a printed-only object has no electronics).
| Name | Type | Req | Description |
|---|---|---|---|
| project | string | yes | – |
| reason | – | – | – |
| stage | string | yes | – |
| status | string | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
How do I install the text-to-reality MCP server?
text-to-reality runs locally as a PyPI package, launched with uvx text-to-reality. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · text-to-reality
claude mcp add ai-wes-text-to-reality -- uvx text-to-reality
What is the text-to-reality MCP server?
text-to-reality is an MCP server listed in the public MCP registry as io.github.ai-wes/text-to-reality. Turn an idea into a device anyone can build: parts, printed parts, wiring, code and a picture guide. This page covers its PyPI package (text-to-reality).
Is the text-to-reality MCP server safe to use?
text-to-reality scores 79 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the text-to-reality MCP server expose?
text-to-reality exposes 13 tools: connector_guidance, create_project, list_projects, project_status, record_files, and 8 more. Their descriptions and schemas cost roughly 764 tokens of context every time the server is loaded.
Is the text-to-reality MCP server still maintained?
text-to-reality is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the text-to-reality MCP server under?
text-to-reality declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.