Skip to main content
Glama
sh1rokovs

timetta-mcp

by sh1rokovs
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

timetta-mcp

MCP server exposing the Timetta main OData API to MCP clients (Claude Desktop, Claude Code, Codex, Gemini CLI, etc.) as a universal read-write gateway.

Tools

Generic CRUD

  • list_entities() — list queryable OData entities.

  • get_entity_schema(entity) — fields, types and navigation properties of an entity. Call this first to learn real field names.

  • query_odata(entity, filter?, select?, expand?, orderby?, top?, skip?) — query an entity using OData semantics (without the leading $). top defaults to 50, capped at 200.

  • create_entity(entity, data) — create a record (POST). data is a JSON object of field -> value.

  • update_entity(entity, id, data) — update a record by id (PATCH). data holds only the fields to change.

  • delete_entity(entity, id) — delete a record by id (DELETE).

Composite (reference-data resolved)

  • create_issue(title, description?, type_hint?, project_id?, priority_code?, project_task_id?, project_task_hint?, parent_id?, assignee_id?) — create a Timetta issue in one call. Resolves issue type, priority, and project task from reference catalogs internally.

  • link_issues(source_id, destination_id, link_type_name?) — link two issues, resolving the link type by name.

  • attach_file(issue_key_or_id, file_path, filename?) — attach a local file to an issue, resolving it by key or numeric id.

  • change_issue_status(issue_key, status_code) — change the status of an issue. Resolves the status code against the DirectoryEntries catalog.

Related MCP server: getdot-database-skills

Configuration

Variable

Required

Default

Notes

TIMETTA_API_TOKEN

one of the two

—

Static Token API value (Bearer), TTL 1 year. Takes priority when set.

TIMETTA_CLIENT_ID

for OAuth

external

Public OAuth client id used by timetta-mcp login (password grant).

TIMETTA_AUTH_URL

no

https://auth.timetta.com

OAuth auth server.

TIMETTA_CREDENTIALS_PATH

no

platform default

Where OAuth tokens are stored. Default: %APPDATA%\timetta-mcp\credentials.json (Windows), ~/.config/timetta-mcp/credentials.json (POSIX).

TIMETTA_BASE_URL

no

https://api.timetta.com/odata

OData base URL.

TIMETTA_DEFAULT_PROJECT_ID

no

—

Default project for create_issue.

TIMETTA_DEFAULT_PRIORITY_CODE

no

—

Default priority code for create_issue.

TIMETTA_DEFAULT_ASSIGNEE_ID

no

—

Default assignee for create_issue.

TIMETTA_DEFAULT_PROJECT_TASK_ID

no

—

Default project task for create_issue.

The server can create, update and delete records. Effective permissions are governed entirely by the token — use a read-only Timetta token if write access is not needed.

Authentication

The server picks credentials in this order: TIMETTA_API_TOKEN env var → credentials file written by timetta-mcp login → otherwise an error asking you to log in.

Run a one-time login and choose a method (like the Timetta VS Code extension):

timetta-mcp login

  1. Token API (recommended; works with SSO accounts). Paste a long-lived token generated in Timetta settings (TTL ~1 year). It is saved to TIMETTA_CREDENTIALS_PATH and sent as a Bearer token. No refresh needed.

  2. Email + password (OAuth password grant). Exchanges your Timetta email/password for tokens via grant_type=password (client external) and saves the refresh token. The password is never stored — only the resulting tokens. The server refreshes the access token automatically; re-run timetta-mcp login if the refresh token expires (Timetta refresh tokens last roughly 15 days of inactivity).

These are the only two methods Timetta documents for integrations; it offers no self-service OAuth client registration or browser authorization_code flow.

For CI / automation you can skip login entirely and set TIMETTA_API_TOKEN — it always takes priority.

Tip: run timetta-mcp from this checkout with uv run timetta-mcp … (or uvx --no-cache --from . timetta-mcp …). Plain uvx --from <path> caches the built environment and may run stale code after you edit the source.

Run

Locally from a checkout:

uvx --from . timetta-mcp

From the repository:

uvx --from git+https://github.com/sh1rokovs/timetta-mcp timetta-mcp

Claude Desktop config

{
  "mcpServers": {
    "timetta": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/sh1rokovs/timetta-mcp", "timetta-mcp"],
      "env": { "TIMETTA_API_TOKEN": "YOUR_TOKEN" }
    }
  }
}

Claude Code

CLI command (installs the server straight from GitHub via uvx):

claude mcp add timetta \
  --env TIMETTA_API_TOKEN=YOUR_TOKEN \
  -- uvx --from git+https://github.com/sh1rokovs/timetta-mcp timetta-mcp

Scope is selected with -s: local (default, this project only), user (all projects), or project (writes a committed .mcp.json). To share the server with everyone who clones the repo, add a .mcp.json at the project root:

{
  "mcpServers": {
    "timetta": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/sh1rokovs/timetta-mcp", "timetta-mcp"],
      "env": { "TIMETTA_API_TOKEN": "${TIMETTA_API_TOKEN}" }
    }
  }
}

${TIMETTA_API_TOKEN} is read from the environment, so the token never lands in the repo. Verify with claude mcp list / claude mcp get timetta.

Codex CLI

Add the server to ~/.codex/config.toml:

[mcp_servers.timetta]
command = "uvx"
args = ["--from", "git+https://github.com/sh1rokovs/timetta-mcp", "timetta-mcp"]
env = { TIMETTA_API_TOKEN = "YOUR_TOKEN" }

Or via the CLI:

codex mcp add timetta \
  --env TIMETTA_API_TOKEN=YOUR_TOKEN \
  -- uvx --from git+https://github.com/sh1rokovs/timetta-mcp timetta-mcp

Gemini CLI

Add the server to ~/.gemini/settings.json (user scope) or .gemini/settings.json in the project root (committed, shared scope):

{
  "mcpServers": {
    "timetta": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/sh1rokovs/timetta-mcp", "timetta-mcp"],
      "env": { "TIMETTA_API_TOKEN": "$TIMETTA_API_TOKEN" }
    }
  }
}

List configured servers with /mcp inside the Gemini CLI.

Development

uv sync
uv run pytest

Example

get_entity_schema("TimeEntries")
query_odata("TimeEntries", filter="Date ge 2024-01-01 and Date le 2024-01-31",
            expand="Project,User", select="Date,Hours,Comment")

Available Tools

3 tools
get_entity_schemaA

Get fields, types and navigation properties for one Timetta entity (e.g. 'Users', 'TimeEntries'). Call this before query_odata to learn real field names.

ParametersJSON Schema
NameRequiredDescriptionDefault
entityYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description clearly indicates a read operation (get schema). Does not mention any destructive behavior, auth, or rate limits, but none expected. Could add 'This is a read-only operation' for extra clarity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first defines purpose, second provides usage guidance. Front-loaded, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has output schema (not shown), so no need to explain return values. Description covers purpose, usage, and parameter semantics fully for a simple 1-param tool with well-known siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% coverage for parameter 'entity', but description explains it is for one entity and gives examples ('Users', 'TimeEntries'), adding essential context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states verb 'Get' and resource 'fields, types and navigation properties' for a Timetta entity, with examples 'Users', 'TimeEntries'. Clearly distinguishes from siblings: list_entities lists entities, query_odata queries data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Call this before query_odata to learn real field names.' Provides clear when-to-use and implied when-not-to (for listing or querying). No exclusions needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_entitiesA

List the queryable Timetta OData entities (EntitySet names).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the burden. It is adequate (read-only listing) but does not explicitly confirm read-only or discuss auth or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no filler, clear and front-loaded. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool is simple with output schema provided. Description fully captures the necessary context for an AI agent to understand the tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, baseline is 4. The description adds no parameter info, which is acceptable since none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the specific verb 'List' and resource 'queryable Timetta OData entities (EntitySet names)', clearly distinguishing it from siblings like get_entity_schema and query_odata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for discovering available entities but does not explicitly state when to use versus alternatives or provide contextual exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_odataA

Query a Timetta OData entity.

Args use OData semantics ($filter, $select, $expand, $orderby, $top, $skip) without the leading '$'. Example: entity='TimeEntries', filter='Date ge 2024-01-01', expand='Project,User', select='Date,Hours'. top defaults to 50 and is capped at 200; use skip to paginate. Returns a JSON array of rows, or 'Error: ...' on failure.

ParametersJSON Schema
NameRequiredDescriptionDefault
entityYes
filterNo
selectNo
expandNo
orderbyNo
topNo
skipNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses return format (JSON array or error), default top (50), cap (200), and pagination via skip, which is sufficient for a query tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (a few sentences) and well-structured, with an example embedded. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (7 parameters, output schema present but not shown), the description covers key aspects: entity, filtering, selection, expansion, ordering, top cap, pagination. It may omit some edge cases but is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description adds substantial value by explaining OData semantics, omitting the '$' prefix, providing an example, and detailing the top default and cap. This compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Query a Timetta OData entity' with a specific verb and resource, and distinguishes from sibling tools (get_entity_schema, list_entities) by focusing on data retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear usage pattern with OData semantics and an example, but does not explicitly state when not to use this tool or mention alternative tools for different scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observedget_entity_schema
    • First observedlist_entities
    • First observedquery_odata
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: listing entities, retrieving schema for a specific entity, and querying data. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case: get_entity_schema, list_entities, query_odata. The pattern is uniform and predictable.

Tool Count4/5

Three tools is minimal but fits the focused scope of exploring and querying Timetta OData. It is not overly sparse for a read-only adapter; could potentially include more but earns its place.

Completeness4/5

The tool set covers the essential read operations: listing available entities, understanding their schema, and querying with rich OData semantics. For a read-only interface, there are no obvious gaps; write operations are likely out of scope.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • getdot-database-skills

    zurferr
    F
    license
    Not graded
    quality
    D
    maintenance
    MCP server providing a single query tool to execute SQL against GetDot Database, enabling schema discovery, data loading, and querying via natural language.
    -

  • odatav4-mcp

    singlebarrel
    F
    license
    Not graded
    quality
    C
    maintenance
    An MCP server for OData v4 endpoints, especially Microsoft Dataverse/Dynamics 365, enabling authentication, schema discovery, querying, CRUD, and more via natural language.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sh1rokovs/timetta-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server