Timether MCP uses a secure OAuth-based connection flow so compatible AI tools can access approved workspace data without asking for your password.
This article explains how authorization works, how workspace access is selected, and how Timether protects connected MCP sessions.
Authorization discovery
MCP clients can discover Timether’s authorization details from:
https://api.timether.com/.well-known/oauth-protected-resource/mcp
This discovery endpoint tells compatible clients how to start the authorization process for Timether MCP.
Login and consent
When an MCP client connects to Timether, the login and consent flow is handled in the browser through:
https://app.timether.com
You may be asked to sign in if you are not already logged in.
After signing in, you will choose the workspace you want to connect and approve the requested access.
Workspace selection during consent
During the consent step, you select one eligible workspace.
The MCP connection is then bound to that workspace.
This means the issued access and refresh tokens can only be used for the selected workspace and the Timether MCP resource.
The MCP resource audience is:
https://api.timether.com/mcp
This prevents the same token from being used for unrelated resources.
Supported scopes
Timether MCP supports three OAuth scopes:
timether:read
timether:write
timether:admin
The requested scopes control what the MCP client is allowed to do.
timether:read allows read-style operations, such as viewing workspace data.
timether:write allows supported write operations, such as creating or updating approved records.
timether:admin allows higher-level administrative actions where the connected user and workspace permissions allow it.
The exact tools available still depend on your workspace role, plan, billing state, and current capabilities.
PKCE requirement
Timether MCP requires OAuth authorization-code flow with S256 PKCE.
PKCE adds protection to the authorization flow, especially for public clients that cannot safely store a client secret.
Only S256 PKCE is supported.
This means clients must generate a secure code verifier and send the matching S256 code challenge during authorization.
Public client support
Timether supports public OAuth clients for MCP.
The authorization server supports:
-
Client ID Metadata Documents
-
Dynamic Client Registration
This allows compatible MCP clients to register and connect without requiring a manually issued confidential client secret.
Redirect URI rules
Redirect URIs must use HTTPS.
HTTP redirects are only allowed for loopback redirects used by local native clients.
This allows desktop or local tools to complete secure local authorization flows while keeping browser-based and hosted clients on HTTPS.
Consequential operation confirmations
Some MCP actions can make important changes to workspace data.
For safety, consequential operations use a two-step confirmation flow.
The first call returns a one-time confirmation token.
That token is valid for five minutes.
To complete the action, the MCP client must repeat the same arguments with the confirmation token.
This helps prevent accidental or unintended changes.
Safe retries with idempotency keys
Additive write operations can accept an idempotency_key.
This helps clients safely retry requests without accidentally creating duplicate records.
If a completed result is already cached for the same idempotency key, Timether can return the completed result instead of performing the same operation again.
This is useful for network retries and automation workflows.
Revoking MCP access
You can revoke MCP OAuth connections from:
Account → Integrations
After revocation, the MCP client can no longer use that connection.
Revoking a connection is recommended if:
-
You no longer use the AI tool
-
You connected the wrong workspace
-
A device or client may be compromised
-
You want to reset access
-
You want to reconnect with different permissions
Access checks after connection
Timether continues checking access after a connection is created.
A token may be rejected later if:
-
The token was revoked
-
The user account is disabled
-
The membership becomes inactive
-
The workspace is downgraded
-
The workspace no longer has
public_api_access -
The workspace billing state prevents access
-
The requested action is no longer allowed
This keeps MCP access aligned with the current workspace stat