Skip to main content
Glama
growing-pai-git

MCP Teamleader Focus

by growing-pai-git
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

teamleader_create_project

Create a new project in Teamleader Focus with just a title. Optionally set dates, link deals or quotations, assign owners, and add budgets or billing methods to schedule and manage projects.

Instructions

Create a new project in Teamleader Focus (next-gen projects module). Only 'title' is required; everything else is optional. Set start_date/end_date to schedule the project. The creating user is automatically added as an owner.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
colorNoProject color (hex value from the Teamleader palette)
titleYesProject title
deal_idsNoDeal IDs to link to the project
end_dateNoProject end date (YYYY-MM-DD). Should not be before start_date.
owner_idsNoAdditional owner user IDs (the creator is always an owner)
start_dateNoProject start date (YYYY-MM-DD). Should not be after end_date.
assignee_idNoAssign a user or team: ID (with assignee_type)
customer_idNoLink a customer: ID (with customer_type)
descriptionNoProject description
assignee_typeNoAssign a user or team: type (with assignee_id)
customer_typeNoLink a customer: type (with customer_id)
quotation_idsNoQuotation IDs to link to the project
billing_methodNoBilling method for the project
time_budget_unitNoTime budget unit (with time_budget_value)
company_entity_idNoDepartment / company entity ID
time_budget_valueNoTime budget amount (with time_budget_unit)
fixed_price_amountNoFixed price amount. Only for fixed_price billing method.
fixed_price_currencyNoFixed price currency (currently only EUR supported)
purchase_order_numberNoPurchase order number
external_budget_amountNoExternal budget (aka 'budget') amount. Only for time_and_materials.
internal_budget_amountNoInternal budget (aka 'cost budget') amount
external_budget_currencyNoExternal budget currency (currently only EUR supported)
internal_budget_currencyNoInternal budget currency

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the behavioral burden. It discloses a non-obvious side effect ('The creating user is automatically added as an owner') and notes that all fields except title are optional. However, it does not mention permissions, idempotency, or what the response contains.

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?

Three sentences with no filler, front-loading the action and resource. Each sentence adds useful information: purpose, required/optional fields, scheduling, and a side effect.

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

Completeness3/5

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

For a 23-parameter tool with no output schema, the description covers the core creation context and side effects, but it omits what the tool returns (e.g., created project ID) and any permission requirements. The schema covers parameter semantics, so the main gap is response behavior.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description's parameter hints ('Only title is required', 'Set start_date/end_date to schedule') largely restate schema information, and the owner side effect is already present in the owner_ids schema description. It adds minimal value 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?

The description opens with 'Create a new project in Teamleader Focus (next-gen projects module)', specifying a clear verb and resource. It distinguishes itself from sibling project tools (update, delete, list, get) by being the create operation, and the module qualifier adds specificity.

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 clearly implies use when creating a new project, and it provides parameter usage guidance ('Only title is required', 'Set start_date/end_date to schedule'). It does not explicitly name alternatives or exclusions, but the create verb makes the context unambiguous.

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

Deploy Server

Other Tools