Resources / API and MCP
API and MCP reference is public at the concept level and authenticated at the tenant level.
TwinEdge can describe REST and MCP product concepts publicly, but live API catalogs, tool schemas, test runs, audit feeds, external clients, API keys, tenant graph data, and operational context require authenticated customer access.
Public concepts
Authenticated catalog
Tenant scope
API keys
Read-only tools
Audit feed
API access is governed, tenant-scoped, authenticated, rate-limited, and audited.
Platform in action
Authenticated API/MCP access model
The public page explains what API/MCP products are while making clear that live calls and tenant-specific catalogs are behind authentication.
Workflow
API and MCP access flow
Connect industrial sources, build trusted context, govern recommendations, and turn approved decisions into operational work.
Public reference concepts
Explain REST products, MCP tools, standard profiles, read-only context, rate limits, approval requirements, and audit concepts without publishing tenant endpoints or keys.
Authenticated customer catalog
Authorized users see tenant-specific products, tool schemas, profile options, external clients, audit feeds, test runs, and key-management surfaces.
Governed execution and audit
Tool calls are scoped to tenant and permissions, physical writeback is disabled by default, and every access path is rate-limited and audited.
Capabilities
What the API resource covers
REST and MCP product concepts
Describe how validated DataOps context becomes REST APIs, MCP tools, profiles, catalog entries, and monitored data products.
Authentication boundary
State clearly that live catalogs, API keys, test runs, tool execution, external clients, and tenant data are available only after authentication.
Tenant and organization scope
Every catalog, graph query, recommendation, audit feed, API product, and MCP call is scoped to the authorized customer tenant and role.
Read-only first tools
MCP tools expose operational context and recommendation evidence without physical writeback by default.
Approval and publication model
New products, profile publications, pipeline publications, and external client access follow approval, validation, and audit requirements.
Audit and monitoring
Calls, failures, latency, rate-limit hits, selected tools, profile context, and external client access are visible to authorized reviewers.
Public/private line
Do not turn the public API page into an open developer console
The public resource can explain the contract model, but real API/MCP access belongs behind authentication and customer authorization.
Public
Conceptual API/MCP overview, governance model, access request path, supported product types, and example categories.
Authenticated
Tenant catalogs, exact schemas, API keys, test-run console, external client registry, audit feeds, graph data, and tenant recommendations.
Controlled by customer scope
Products and tools are limited by tenant, organization, role, rate limit, approval status, and deployment boundary.
Engineering controls
Public resources without public tenant access.
TwinEdge explains product value, user guidance, and adoption paths publicly while keeping tenant catalogs, credentials, support bundles, private service endpoints, and customer data behind authenticated access.
Authenticated API surfaces
Live API/MCP catalogs, test runs, external clients, audit feeds, and API keys require an authenticated customer or partner account.
Tenant-scoped data
Operational context, graph objects, telemetry, recommendations, and evidence are scoped by tenant, role, permission, and deployment boundary.
No public secrets
Credentials, source connection details, customer runbooks, and support artifacts are not published on public resource pages.
Governed action
Recommendations remain read-only first and move through validation, approval, audit, and replay before operational execution.
Outcomes
Who uses API/MCP resources
Teams get the context, controls, and execution path needed to move from noisy industrial data to approved operational action.
Application teams
Understand how to consume governed operational context once authenticated access is approved.
AI and agent teams
Use tenant-scoped MCP tools and data products rather than scraping dashboards or requesting broad database access.
IT and platform owners
Review scopes, keys, approval state, rate limits, audit feeds, and external clients before enabling production use.
Connected platform
API access boundaries
API/MCP resources must be explicit that public information is conceptual and live tenant access requires authentication.
Public pages explain product scope, operating options, governance concepts, resource paths, and customer value without exposing tenant implementation details.
Authenticated customer access is used for tenant-specific API catalogs, MCP tools, API keys, implementation runbooks, support bundles, and evidence packages.
DataOps source mappings, graph context, validation results, and operational evidence stay scoped to the customer tenant and authorized roles.
API and MCP access is not an open public console; live calls require authentication, tenant scope, permissions, rate limits, and audit trails.
Implementation planning and customer-specific review can be handled through controlled disclosure and commercial engagement.
Free developer tools can be public utilities, but production connectors, enterprise integration paths, and customer data access remain governed.
Evaluate TwinEdge
Evaluate governed API and MCP access for your environment.
Use this page for public education and access requests. Use authenticated customer portals for live catalogs, keys, tool execution, audit feeds, and tenant operational context.