Tseha
REMOTE · TSEHA.IO · SCANNED SEP 20
Serves your design system and coding standards to coding agents, so they stop guessing.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security97
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server supports Client ID Metadata Documents, the current MCP client-registration mechanism. View diagnostics → Pass
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability68
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 2502 tokens (~278/item across 9 items; 9 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management93
- Stability observed for 28 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 9 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 10 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
How do I install the Tseha MCP server?
Tseha is a hosted endpoint at https://tseha.io/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · tseha.io
claude mcp add --transport http io-tseha-tseha 'https://tseha.io/mcp'
{
"mcpServers": {
"io-tseha-tseha": {
"url": "https://tseha.io/mcp"
}
}
} {
"servers": {
"io-tseha-tseha": {
"type": "http",
"url": "https://tseha.io/mcp"
}
}
} [mcp_servers.io-tseha-tseha] url = "https://tseha.io/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"io-tseha-tseha": {
"type": "remote",
"url": "https://tseha.io/mcp",
"enabled": true
}
}
} openclaw mcp add io-tseha-tseha --url 'https://tseha.io/mcp' --transport streamable-http
mcp_servers:
io-tseha-tseha:
url: "https://tseha.io/mcp" {
"McpServers": {
"io-tseha-tseha": {
"Transport": "http",
"Url": "https://tseha.io/mcp"
}
}
} assistant mcp add io-tseha-tseha -t streamable-http -u 'https://tseha.io/mcp'
{
"mcpServers": {
"io-tseha-tseha": {
"type": "http",
"url": "https://tseha.io/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
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.
- 19 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.
- 17 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 15 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 73 to 77. That category is still filling its 30-day observation window: 22 days of observed history at the previous scan, 23 at this one. The score rises as the window fills, whether or not the server changes.
- 13 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 67 to 70. That category is still filling its 30-day observation window: 20 days of observed history at the previous scan, 21 at this one. The score rises as the window fills, whether or not the server changes.
- 11 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.
- 9 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.
- 6 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.
- 4 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.
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 20 Sept 2026 · Probed https://tseha.io/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=tseha.io | CN=YE1,O=Let's Encrypt,C=US | 27 Jul 2026 | 25 Oct 2026 | ECDSA 256 | ECDSA-SHA384 | 55499356ed0d2800fee7b2543f1c97c6a89 |
| SANs: *.tseha.io, tseha.io | ||||||
| CN=YE1,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 5ddd70dd31f801c85c186a7a04b80afe |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of tseha.io. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| io. | present | 57355 | 8 | Verified |
| tseha.io. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer realm="Tseha MCP", resource_metadata="https://tseha.io/.well-known/oauth-protected-resource"
Bearer realm="Tseha MCP", resource_metadata="https://tseha.io/.well-known/oauth-protected-resource" | Header | Value |
|---|---|
| strict-transport-security | max-age=0; includeSubDomains; preload |
| content-security-policy | default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://app.termly.io; script-src-elem 'self' 'unsafe-inline' https://www.googletagmanager.com https://app.termly.io; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob: https: https://www.google-analytics.com https://www.googletagmanager.com; font-src 'self' data:; connect-src 'self' https: https://www.google-analytics.com https://analytics.google.com https://www.googletagmanager.com https://region1.google-analytics.com; frame-ancestors 'none'; base-uri 'self'; object-src 'none'; form-action 'self' |
| x-content-type-options | nosniff |
| x-frame-options | DENY |
| referrer-policy | strict-origin-when-cross-origin |
| permissions-policy | camera=(), microphone=(), geolocation=() |
Protected resource metadata
| Document | https://tseha.io/.well-known/oauth-protected-resource |
|---|---|
| Retrieved | Yes |
| Resource | https://tseha.io/mcp |
| Authorisation server | https://tseha.io |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://tseha.io/mcp | Verified | 200 | |
| http (plaintext) | http://tseha.io/mcp | HTTPS enforced | 301 | https://tseha.io/mcp |
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 →
get_component Get component spec ~295
Returns the full specification for one component: import path, props schema, usage example, anti-patterns, when-to-use and when-not-to-use notes, Figma spec, and dependencies. Read-only. Call it before writing code that uses a component, so props and import path come from the design system instead of memory. The name argument must be the exact component name as returned by list_components or search_components (case-sensitive, no package prefix); an unknown name returns a not-found error rather than a near match, so resolve the name first with search_components if you are guessing. The result may carry a provenance warning when the record was LLM-generated and not yet reviewed - treat those fields as unverified. It covers one component at a time; use list_components to enumerate and get_component_updates for version-to-version changes.
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | Exact component name, e.g. "Button" |
| project_id | string | yes | UUID as returned by list_projects - not the project name, title, or slug, and not guessable. Fetch it once and reuse the same id across tools. An id outside the caller's organization returns "Project… |
No output schema declared.
No examples provided.
get_component_updates Get component updates ~302
Returns per-component breaking changes and a migration guide between an installed version of the project's active component package and the latest published version. Read-only: it reports an upgrade, it never performs one. Use it when planning or reviewing a component-library upgrade, or before bumping the package version in a manifest. current_version is the exact semver currently installed, e.g. "1.0.0" - not a range, so no leading "v", "^", or "~"; read it from list_packages when unsure. Passing the latest version returns an empty change set. It is not a per-component changelog and not a current spec - use get_component for one component today, and list_packages for what is installed. Requires update tracking, a Team plan feature; on lower plans it returns an upgrade-required error instead of data.
| Name | Type | Req | Description |
|---|---|---|---|
| current_version | string | yes | The version currently installed, e.g. "1.0.0" |
| project_id | string | yes | UUID as returned by list_projects - not the project name, title, or slug, and not guessable. Fetch it once and reuse the same id across tools. An id outside the caller's organization returns "Project… |
No output schema declared.
No examples provided.
get_standards Get development standards ~313
Returns the organization's development standards: coding conventions, project structure, and framework-specific rules. Read-only. Call it before writing or reviewing code, so the result follows this organization's rules rather than general defaults. Call it first without a section to get an index of available sections, each with a note on what it covers, then call again with one section id copied from that index; inventing a section id returns a not-found error naming that step. Request only the sections a task needs - the full content of one section can be long. The framework argument is deprecated: use section with the "framework:" prefix instead. It returns prose rules, not data - use get_style_tokens for visual values and get_component for component APIs.
| Name | Type | Req | Description |
|---|---|---|---|
| framework | string | – | Deprecated - use section instead. e.g. "react", "nextjs" |
| project_id | string | yes | UUID as returned by list_projects - not the project name, title, or slug, and not guessable. Fetch it once and reuse the same id across tools. An id outside the caller's organization returns "Project… |
| section | string | – | Section identifier from the index, e.g. "global", "project_structure", "framework:react", "cicd". Omit to get the index. |
No output schema declared.
No examples provided.
get_style Get style metadata ~267
Returns metadata for the project's active style: the style name, its Figma file key, when it was last synced, and a token count per available category (such as color, typography, spacing). Read-only and small - it names categories but returns no token values. Use it to inspect the project theme, or to learn which categories are populated before requesting values; call get_style_tokens for the values themselves. project_id is the only argument and it is not a plain filter: a style is assigned per project and there is no organization-level fallback, so sibling projects can report different style names and different populated categories, and a project with no style assigned returns a null style with a note rather than an error.
| Name | Type | Req | Description |
|---|---|---|---|
| project_id | string | yes | UUID as returned by list_projects - not the project name, title, or slug, and not guessable. Fetch it once and reuse the same id across tools. An id outside the caller's organization returns "Project… |
No output schema declared.
No examples provided.
get_style_tokens Get design tokens ~296
Returns the project's design tokens with their names, values, and token paths. Read-only. Use it to source exact visual values for styling instead of inventing hex codes, spacing, or radii. The category argument takes exactly one of: color, typography, spacing, radius, shadow, blur, all; omitting it behaves the same as "all". Pass a single category when you know which one you need - "all" returns the largest response this server produces. Use get_style first if you only need to know which categories exist, and get_standards for coding conventions, which are not tokens. A project with no style configured returns an empty token list with a note, not an error.
| Name | Type | Req | Description |
|---|---|---|---|
| category | string | – | One of: color, typography, spacing, radius, shadow, blur, all |
| project_id | string | yes | UUID as returned by list_projects - not the project name, title, or slug, and not guessable. Fetch it once and reuse the same id across tools. An id outside the caller's organization returns "Project… |
No output schema declared.
No examples provided.
list_components List UI components ~252
Lists every UI component in the project's design system, each with its name, source package, import path, and a short note on its intended use. Read-only and unpaginated: it returns the whole catalog across all packages assigned to the project, so expect a large response on big design systems. Use it to see what exists before building UI, and to get the exact component name other tools need. Do not use it to find a component by need - search_components ranks by description - and do not use it for props, examples, or Figma data, which only get_component returns. project_id is not a display filter: it selects the assigned packages, so two projects in one organization legitimately return different catalogs.
| Name | Type | Req | Description |
|---|---|---|---|
| project_id | string | yes | UUID as returned by list_projects - not the project name, title, or slug, and not guessable. Fetch it once and reuse the same id across tools. An id outside the caller's organization returns "Project… |
No output schema declared.
No examples provided.
list_packages List component packages ~225
Lists the component packages assigned to a project, each with its name, version, and description, and marks which one is active. Read-only. Use it to decide which npm package to import from, or to read the installed version before calling get_component_updates. It lists packages, not their contents - use list_components to enumerate components and get_component for one component API. project_id is the only argument and it does more than filter output: assignment and active-package status are per project, so one organization package can be listed as active here and absent from a sibling project.
| Name | Type | Req | Description |
|---|---|---|---|
| project_id | string | yes | UUID as returned by list_projects - not the project name, title, or slug, and not guessable. Fetch it once and reuse the same id across tools. An id outside the caller's organization returns "Project… |
No output schema declared.
No examples provided.
list_projects List projects ~97
Lists the projects in this organization, each with its id, name, and framework. Read-only, takes no arguments, and returns only the projects the calling credential may see. Call it first in a session: the returned id is the project_id that every other tool in this server requires, and guessing that id fails. It does not return components, packages, or tokens - use list_components, list_packages, or get_style_tokens for those.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
search_components Search components ~317
Searches the components of every package assigned to the project by use case, behavior, or description, and returns up to 10 ranked matches with a relevance score. Read-only. Use it when you can describe what the UI must do but do not know the component name. The query is free-text describing the need, such as "date range picker" or "dismissible inline warning" - not a component name, not a glob, and not a props expression. Do not use it when the exact name is known (get_component is direct and returns the full spec) or when you want the complete catalog (list_components). Semantic ranking needs AI features on the Team plan or above; on other plans it falls back to name and import-path matching and the score is null. No close match returns an empty result list, not an error.
| Name | Type | Req | Description |
|---|---|---|---|
| project_id | string | yes | UUID as returned by list_projects - not the project name, title, or slug, and not guessable. Fetch it once and reuse the same id across tools. An id outside the caller's organization returns "Project… |
| query | string | yes | Free-text description of the need - a use case, behavior, or purpose, e.g. "date range picker". Not a component name and not a glob. |
No output schema declared.
No examples provided.
What is the Tseha MCP server?
Tseha is an MCP server listed in the public MCP registry as io.tseha/tseha. Serves your design system and coding standards to coding agents, so they stop guessing. This page covers its hosted endpoint (https://tseha.io/mcp).
Is the Tseha MCP server safe to use?
Tseha scores 92 out of 100 on VerifyMCP. 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 Tseha MCP server expose?
Tseha exposes 9 tools: list_projects, list_packages, list_components, get_component, search_components, and 4 more. Their descriptions and schemas cost roughly 2,364 tokens of context every time the server is loaded.
Does the Tseha MCP server require authentication?
Yes. Tseha asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the Tseha MCP server still maintained?
Tseha is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.