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., "@@whatic/mcp Find specs for the ATMEGA328P microcontroller"
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.
Local stdio MCP proxy for the whatic.io IC-discovery MCP server.
whatic.io runs a remote MCP server (streamable-http) at
https://whatic.io/mcp exposing IC-discovery tools (find_parts,
get_specs, compare_parts, search, lookup, get, get_image). Many
MCP clients only support launching a local process over stdio. This package
is that local process: it forwards everything to the remote server. It
contains no tool logic of its own.
Once published, add to your MCP client config:
{
"mcpServers": {
"whatic": {
"command": "npx",
"args": ["-y", "@whatic/mcp"]
}
}
}For Claude Code:
claude mcp add whatic -- npx -y @whatic/mcpUntil published to npm, run from a local checkout instead:
git clone https://github.com/pitkonst/whatic-mcp.git
cd whatic-mcp
npm install
npm run build
node dist/index.jsand point your client's command/args at node / ["<path-to-repo>/dist/index.js"].
Related MCP server: jlcpcb-mcp
WHATIC_MCP_URL — override the remote MCP server URL (defaults to
https://whatic.io/mcp). Useful for pointing at a local or staging
what-ic server during development.
npm install
npm run build # compile TypeScript to dist/
npm run smoke # verify the live remote server end-to-endThere is no unit test suite: this package has no business logic beyond
forwarding requests to the remote server, so npm run smoke (a real
round-trip against the live endpoint) is the meaningful check.
Relative price tier, stock posture, and library class for a set of IC part numbers (a ranking from a distributor snapshot, not a live quote).
| Name | Required | Description | Default |
|---|---|---|---|
| parts | Yes | Two or more IC part numbers to rank relatively; needs >=2 priced parts for a verdict. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does disclose the key trait: the result is a relative ranking based on a distributor snapshot, not a live quote. This manages expectations about freshness and absolute accuracy. It does not discuss auth or errors, but for a read-only comparison tool the main caveat is present.
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?
One compact sentence delivers the output dimensions first and the important caveat in a parenthetical. There is no filler or repeated schema content; every word 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 single-parameter tool with a full output schema, the description covers what is compared, what dimensions are returned, and the snapshot/live-quote caveat. It does not explicitly guide selection among siblings like find_parts or get_specs, but the input contract is fully specified in the schema.
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%, and the schema already explains that parts must be two or more IC part numbers with at least two priced for a verdict. The description only restates the concept of a set and adds no syntactic or formatting value, so baseline 3 applies.
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 the input resource (a set of IC part numbers) and the outputs (relative price tier, stock posture, library class), making the tool's function recognizable. It lacks an explicit verb and does not differentiate from siblings like get_specs or lookup, so it stops short of a 5.
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 phrase 'from a distributor snapshot, not a live quote' gives useful context and an implied exclusion, and the schema adds the requirement of at least two priced parts. However, no alternative sibling tools are named and there is no explicit when-to-use statement, so usage guidance is mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shortlist IC part numbers by parametric spec constraints, ranked by how many constraints each part satisfies, then by headroom past those thresholds, and spread across device families. Each constraint is {canonical, op: gte|lte|eq|range, value, unit?}. Returns per-constraint pass/fail/unknown, plus matched (parts that qualified) vs returned (parts in this response) — when they differ this is a ranked page, not the full set. canonical MUST be one of the exact names below (case-sensitive):
abs_max_current, abs_max_voltage, adc_resolution, block_erase_time, breakdown_voltage_ds, channel_count, clamping_voltage, clock_frequency, cmrr, cmti, coil_power, coil_resistance, coil_voltage, collector_emitter_voltage, contact_current, contact_resistance, core_size, cpu_speed, current_rating, dark_current, data_rate, data_retention, dc_resistance, drain_current, driver_count, dropout_voltage, dynamic_range, eeprom_size, emitter_base_voltage, fall_time, forward_current, forward_voltage, gain_bandwidth, gate_charge, impedance, input_bias_current, input_capacitance, input_offset_current, input_offset_current_drift, input_offset_voltage, input_offset_voltage_drift, input_voltage_noise_density, insertion_loss, io_count, isolation_voltage, junction_capacitance, load_capacitance, memory_size, operate_time, operating_frequency, operating_temperature, output_capacitance, output_count, output_current, output_noise_voltage, output_power, output_voltage, output_voltage_high, output_voltage_low, page_program_time, peak_pulse_current, power_dissipation, program_erase_cycles, program_memory_size, propagation_delay, psrr, quiescent_current, ram_size, rds_on, receiver_count, rectified_current, release_time, response_time, reverse_leakage_current, reverse_recovery_time, reverse_transfer_capacitance, reverse_voltage, rise_time, sample_rate, sector_erase_time, sensitivity, settling_time, slew_rate, standby_current, supply_voltage_range, switching_frequency, switching_voltage, vgs_threshold, zener_voltage
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | Maximum number of parts to return, best first. | |
| constraints | Yes | Spec constraints; a part is ranked by how many it satisfies. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it is very transparent: it explains ranking by constraint satisfaction and headroom, the matched vs. returned distinction, per-constraint pass/fail/unknown output, and the case-sensitive canonical-name requirement. It also notes that `unit` is informational only, which prevents a common misuse.
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 prose is tight and front-loaded, with key behavioral details packed into the first two sentences. The long canonical-name list is redundant with the schema's enum but is presented as a direct requirement, so it is justified; still, it makes the description bulkier than necessary.
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 a complex constraint model, the description covers the essential semantics: input shape, canonical names, operator set, ranking behavior, paging nuance, and output semantics. The presence of an output schema means return-value documentation is not required from the description, and nothing critical for calling the tool correctly is 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?
The input schema already covers all parameter details at 100% coverage, so the baseline is 3. The description adds some behavioral context around constraints (ranking, headroom, matched vs. returned) but does not materially add new meaning to the parameters themselves beyond what the schema already states.
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 a specific action ('Shortlist IC part numbers by parametric spec constraints') and a distinctive resource, making the tool's purpose obvious. It does not explicitly name sibling tools or contrast itself with search/lookup, but the parametric-constraint phrasing is enough to separate it from generic search 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 opening sentence gives a clear context for use: when you need to shortlist IC parts based on parametric constraints. However, it does not state when not to use this tool or explicitly point to alternatives such as search, get_specs, or compare_parts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch datasheet figure images (PNG/JPEG) for opaque ref tokens obtained
from search/lookup/get_segments. Returns each image plus its caption/description/page
metadata. Only type='image' segments have image data; a ref that is not one comes
back as an error record whose available_images lists the document's figures nearest
that ref's page and section, closest first.
| Name | Required | Description | Default |
|---|---|---|---|
| refs | Yes | Opaque `ref` tokens (from search/lookup/get_segments) of image segments; non-image segments return an error record. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It states what is returned (image plus caption/description/page metadata), explicitly warns that non-image refs produce an error record, and explains the fallback behavior with `available_images` and closest-first ordering. This is rich edge-case disclosure 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?
Two sentences front-load the core action and then pack in return metadata, the image-segment constraint, and error behavior without fluff. Every clause earns its place, and the structure is easy for an agent to parse.
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 single-parameter tool with no output schema and no annotations, this description is unusually complete: it covers input provenance, valid input type, return contents, and invalid-input behavior. There is no missing information that an agent needs to invoke it 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 100%, and the schema already documents that `refs` are opaque tokens from search/lookup/get_segments of image segments and that non-image segments return an error record. The description largely restates this, adding no meaningful parameter-level meaning beyond 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 opens with a specific verb and resource: 'Fetch datasheet figure images (PNG/JPEG)' for opaque `ref` tokens. It clearly distinguishes this from siblings by scoping it to image segments and by naming the source tools (search/lookup/get_segments) rather than describing general segment retrieval.
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?
It states that refs must come from search/lookup/get_segments and that only `type='image'` segments have image data, giving an explicit when-to-use boundary. It does not name an alternative tool for non-image segments, but the error behavior makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Expand opaque ref tokens (from search/lookup) into full datasheet segment
content.
| Name | Required | Description | Default |
|---|---|---|---|
| refs | Yes | Opaque `ref` tokens from search/lookup hit records, to expand into full segment content. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of explaining behavior. It conveys the expansion/resolution behavior and the source of the refs, but does not explicitly state non-mutation, behavior on invalid refs, ordering, or other operational traits. The 'expand' wording implies a read-type operation, but explicit safety/error details are absent.
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, front-loads the core operation ('Expand'), and provides the essential provenance of the input tokens. Every phrase earns its place, and there is no redundant filler.
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 one required parameter, a fully documented schema, and an output schema present, the description covers the core contract well. It could additionally specify edge cases like invalid ref tokens or batch size limits, but for a straightforward expansion endpoint the current level of detail is nearly 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 already provides a 100% descriptive description for the only parameter, refs. The tool description essentially repeats the same concept without adding new detail about format, limits, or examples, so it adds no meaningful semantic value beyond 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 states a specific verb, 'Expand,' and a specific resource: opaque ref tokens from search/lookup into full datasheet segment content. This clearly differentiates the tool from siblings like get_specs or get_image by tying it directly to expanding search/lookup outputs.
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 strongly implies the usage context: call this when you have opaque ref tokens produced by search/lookup and need the underlying segment content. It does not explicitly enumerate alternatives or exclusion cases, but the context is clear enough for an agent to select this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read canonical extracted specs (min/typ/max, unit, conditions) for known
IC part numbers from a pre-extracted parametric index — not from datasheet text.
This is the cheapest and most precise source for numeric parameters where it has
coverage. Optionally restrict to specific canonical parameter names.
A part absent from results (with a "No specs found" warning) means no index
coverage, not that the datasheet lacks the parameter — fall back to lookup
for that part.
| Name | Required | Description | Default |
|---|---|---|---|
| canonicals | No | Optional: restrict to these canonical parameter names; omit to return all available specs. | |
| part_numbers | Yes | Exact IC part numbers / MPNs, e.g. ['NE5532', 'LM358']. Family fallback is applied (e.g. TL084CDT -> TL084C). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does so thoroughly: it discloses that results come from a pre-extracted index, that absence of a part in `results` means no index coverage rather than absence in the datasheet, and that the tool issues a 'No specs found' warning. It also clarifies it does not read datasheet text, which is a key behavioral limitation.
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 four sentences, each serving a distinct purpose: what it reads, when to prefer it, how to restrict output, and what absence means with fallback. The 'cheapest and most precise' phrasing is mildly promotional, but the overall structure is front-loaded and efficient.
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's moderate complexity, no annotations, and an output schema, the description covers all essential context: data source, content shape, cost/precision trait, optional filtering, missing-coverage semantics, and fallback routing. An agent has enough to correctly invoke it and interpret an empty 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?
Schema description coverage is 100%, so baseline is 3. The description does reinforce meaning by calling out 'canonical parameter names' and 'known IC part numbers,' but it mostly restates what the schema already explains (optional restriction, exact MPNs). It adds no new syntax or format details beyond 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 states a specific verb ('Read') and resource ('canonical extracted specs ... from a pre-extracted parametric index'), which is clearly distinct from the datasheet-text source and from siblings like lookup. It also defines the spec contents (min/typ/max, unit, conditions), giving the agent a precise mental model of the tool's scope.
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 gives explicit when-to-use guidance: 'This is the cheapest and most precise source for numeric parameters where it has coverage,' and explicit when-not-to-use by saying it is 'not from datasheet text.' It names the fallback alternative directly: 'fall back to `lookup` for that part,' so the agent is told exactly what to do when coverage is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot spec/section retrieval: full content of the most relevant datasheet
segments for one or more parts (fuses search+get_segments). Already groups results per
part (via parts), so prefer lookup over search when you know the part(s).
| Name | Required | Description | Default |
|---|---|---|---|
| parts | No | Part numbers to scope and group the retrieval by; results are returned per part. | |
| query | Yes | What to retrieve, e.g. 'supply voltage' or 'absolute maximum ratings'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that this is a combined one-shot operation, returns full content of relevant segments, and groups results per part. It does not discuss side effects or permissions, but for a retrieval tool the disclosed behavior is sufficient.
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 focused sentences: the first defines what the tool does, and the second gives routing guidance. No wasted words, and the most important scoping detail is front-loaded.
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 only two parameters, full schema coverage, an output schema, and the description clarifies its relationship to key siblings. An agent has enough information to invoke it correctly and understand its grouping behavior without ambiguity.
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 the baseline is 3. The description adds little beyond the schema beyond reinforcing the grouping behavior tied to parts, which the schema already states.
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 states a precise action: one-shot retrieval of full datasheet segment content for one or more parts. It also differentiates itself from siblings by noting it fuses search and get_segments and groups results per part.
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 advises preferring lookup over search when the part(s) are known, giving a clear usage condition relative to a sibling. It does not enumerate exclusions or alternative comparisons for all siblings, but the guidance is actionable and specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the datasheet corpus; returns hit records (metadata + snippet, each
with an opaque ref). Pass a ref list to get_segments for full content.
If you already know the part number(s), prefer lookup — it fuses this search
with get_segments in one call and groups full content per part. Use search
when the part is unknown, or to triage snippets before pulling full content.
For part-specific queries, pass scope='device:' (e.g. scope='device:NE5532')
to restrict hits to that part and avoid cross-part contamination.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Maximum number of hit records to return. | |
| q | Yes | Free-text query, e.g. 'input voltage noise density'. | |
| scope | No | Optional filter, e.g. 'device:NE5532', to restrict hits to one part and avoid cross-part matches. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the return shape (hit records with metadata, snippet, opaque ref), the opaque-ref indirection to get_segments, and scope-restriction behavior. It does not mention ordering/pagination/errors, but for a search tool the core behavior is well conveyed.
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 efficient and every sentence earns its place: what it returns, how to chain to get_segments, when to prefer lookup, when to use search, and how to scope. The key purpose and return shape are front-loaded.
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 presence of an output schema, the description does not need to explain return-value details beyond the hit-record/ref/segments flow. It covers purpose, return nature, alternatives, usage conditions, and parameter scoping. An agent has enough context to select and invoke this 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 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining why scope should be used (restrict hits to one part and avoid cross-part contamination) and by giving a concrete syntax example. It does not add much about q or k, but they are already well described 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 opens with a specific verb and resource: "Search the datasheet corpus; returns hit records (metadata + snippet, each with an opaque `ref`)." It clearly states what the tool produces and differentiates it from siblings like lookup and get_segments by describing the hit-record/snippet level of detail.
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 gives explicit routing guidance: prefer lookup when part numbers are known, use search when the part is unknown or for triage before pulling full content. It also explains exactly when to use the scope parameter with a concrete MPN example.
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.1getget_image1 field changedInput schema / properties / refs / descriptionPrevious value: -"Opaque `ref` tokens (from search/lookup/get) of image segments; non-image segments return an error record."New value: +"Opaque `ref` tokens (from search/lookup/get_segments) of image segments; non-image segments return an error record."get_segmentsv0.1.0compare_partsfind_partsgetget_imageget_specslookupsearchScored across 7 tools
find_parts, get_specs, compare_parts, and get_image are clearly distinct, while search, lookup, and get_segments overlap in the retrieval workflow but have explicit descriptions that differentiate triage, fused retrieval, and ref expansion. Minor boundary ambiguity remains between get_specs and lookup, but the descriptions provide enough guidance.
Most tools follow a predictable verb_noun pattern: find_parts, get_specs, compare_parts, get_segments, get_image. The bare-verb names search and lookup are minor deviations that remain readable and do not obscure their purpose.
Seven tools form a well-scoped toolkit for IC parametric discovery and datasheet retrieval. Each tool earns its place by covering a distinct step in the workflow without unnecessary duplication or bloat.
The toolset covers the full read-only datasheet research lifecycle: parametric discovery, normalized spec lookup, distributor comparison, corpus search, full segment retrieval, and figure extraction. There are no obvious dead ends or missing operations for the stated domain.
MCP server for IT hardware parts research: normalize PNs, search listings, get subs/comps.
An MCP server that provides congressional transcripts
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
