Tseha

Quick start

Add a .mcp.json file to the root of your repository pointing at the Tseha MCP server:

{
  "mcpServers": {
    "tseha": {
      "url": "https://tseha.io/mcp"
    }
  }
}

That is the whole configuration. The first time your agent connects, it opens an OAuth sign-in (via Auth0) in your browser; approve it once and the agent is connected. From then on, the agent queries Tseha automatically on the tasks it performs. You can find your ready-to-copy snippet on the dashboard under MCP Connection.

Client setup

The same server URL works for any MCP client. Where the config lives depends on the client:

• Claude Code — a .mcp.json file in your project root (shown above), or run claude mcp add --transport http tseha https://tseha.io/mcp.
• Cursor — add the same mcpServers block to .cursor/mcp.json (per project) or ~/.cursor/mcp.json (global).
• Other MCP clients (GitHub Copilot with MCP support and any tool implementing the protocol) — point the client at the server URL https://tseha.io/mcp using the HTTP transport.

Authentication & tokens

• OAuth 2.1 + PKCE. Authentication happens automatically on first connection — for interactive agents there is no API key to paste. Tseha publishes standard discovery documents (/.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource) and supports dynamic client registration, so compliant clients configure themselves.
• Scope. The issued token is scoped to your organization and your role. The MCP server is read-only for every role - writes happen only in the admin panel, where your role (Owner, Admin, Developer can write; User is read-only) applies. Project visibility is enforced on top of that.
• Revocation. Membership and role are re-checked on every request, so removing a member or changing a role takes effect immediately — no token rotation needed. Signing out ends the session. Administrative token actions are recorded in the audit log.
• Machine tokens (Team and above). CI jobs and automation runners have no browser to sign in with. For them an admin can issue a long-lived, read-only API token in the admin panel and pass it as an Authorization: Bearer header. Tokens are scoped to all projects or a chosen set, take an optional expiry, are shown only once, and can be revoked at any time.

Available tools

Tseha exposes granular, read-oriented tools so your agent fetches only what it needs for the current task (lazy loading) rather than a bulky snapshot:

Tool	What it returns
list_projects	Lists the projects in this organization with id, name, and framework. The id is the project_id every other tool requires.
list_packages	Returns all component packages available in this organization and marks which one is active for the given project. Call this to know which npm package to import from when a needed component is not listed in list_components.
list_components	Lists available UI components from the active package.
get_component	Returns component details: props, usage examples, patterns.
search_components	Searches components semantically based on a description. Semantic ranking requires AI features (Team plan and above); other plans fall back to name and import-path matching, which returns a null score.
get_style	Returns style information (design token collection).
get_style_tokens	Returns design tokens by category: color, typography, spacing.
get_standards	Returns developer standards. Without a section it returns an index of available sections; with a section it returns that section's full content.
get_component_updates	Returns component changes relative to a specified version. Requires the Team plan or above.

A typical sequence while writing code: list_components → search_components → get_component → get_style_tokens. Your source code is never sent to Tseha; the server only serves the standards you publish.

Semantic ranking is a Team+ feature. search_components ranks by meaning only when your plan includes AI features (Team and above) and your organization has AI features enabled in settings. Otherwise the tool still answers, but falls back to matching on component name and import path, and every result carries score: null.

Limits & errors

• Rate limit. 1,000 requests per minute per token (sliding window), plus a matching response-volume budget. Exceeding either returns HTTP 429 with a Retry-After header. Custom limits are available on Enterprise agreements.
• Response size. A single tool response is capped (~25,000 tokens). Oversized results are truncated with a hint to use a more specific tool (for example get_component instead of the full list_components payload).

Errors follow JSON-RPC 2.0. The ones you are most likely to see:

• -32001 — unauthorized (missing/invalid session or inaccessible project).
• -31002 — rate limit exceeded (returned with HTTP 429).
• -32602 — invalid params (for example a missing or malformed project_id).

A project with no component package assigned, or components that are not indexed yet, is not a JSON-RPC error: the tool returns a normal result carrying a note or error field (for example "No packages configured") so your agent can react without failing the call.

Troubleshooting

• The agent never prompts to sign in. Confirm the server URL is exactly https://tseha.io/mcp and that your client supports the MCP HTTP transport; restart the client after editing the config.
• 401 / unauthorized. Your session expired or your membership/role changed — sign in again. If you were removed from the organization, access stops immediately by design.
• 429 / rate limited. Back off and respect the Retry-After header.
• Empty component results. The tool returned a note such as "No packages configured": the project has no package assigned, or its components have not been indexed yet — an Admin can assign a package and trigger indexing from the admin panel.
• Still stuck? Email [email protected].