Productive.io API v2 用のMCPサーバー — 1つの組織を対象としたプロジェクト、タスク、タイムトラッキング、リソースプランニング、財務、CRM、レポート。
Productiveは132のリソースに対して約650のオペレーションを公開しています。これらを650のMCPツールに変換すると、クライアントのツールリストが溢れてしまうため、このサーバーは生成されたレジストリによって駆動される12のツールで構成されています。ツールは汎用的で、レジストリが各リソースが実際に受け付ける内容を把握しています。
ディスカバリ — productive_search_capabilities、productive_describe_resource、productive_check_connection、productive_describe_custom_fields
読み取り — productive_list（フィルタ、ソート、インクルード、ページング、およびグループ化を伴う26のレポートエンドポイント）、productive_get
書き込み — productive_create、productive_update、productive_delete、productive_run_action（150の名前付き動詞: archive、restore、approve、close、copy、finalize、send…）、productive_track_time、productive_commit_operation
ユーザーごとの認証（オプトイン） — productive_connect、productive_status、productive_disconnect — 認証を参照
まず productive_search_capabilities から始めてください。Productiveのリソース名は独自のものです。予算は deal、ボードの列は workflow_status、タイムシートの承認は time_entries に存在します。推測はAPI呼び出しのコストがかかります。
Related MCP server: productive-mcp-rb2
src/productive/registry.generated.ts は、Productiveが公開しているOpenAPIドキュメントから scripts/generate-registry.mjs によって生成され、コミットされています。そのためCIはネットワークを必要とせず、仕様の変更はレビュー可能な差分として現れます。このレジストリは、すべてのリソースについて、フィルタフィールド、ソートキー、レポートのグループキー、インクルード可能なリレーションシップ、作成・更新用の書き込み可能な属性（必須のものをマーク付きで）、および各名前付きアクションを記録しています。
これこそが、12のツールが誠実であり続けるための仕組みです。productive_describe_resource は1つのリソースの正確な契約を返し、すべての引数はリクエストを送信する前にその契約と照合されます。
npm run registry:generate で再生成します（ローカルコピーの仕様を使うにはパス引数を追加します）。手書きの分類（リスク階層、外部向けフラグ、ブロックされたオペレーション）が仕様内のどのパスとも一致しなくなった場合、ジェネレータはビルドを失敗させます。これにより、上流でのリネームがガードを静かに失わせることはありません。
ここに記載されている内容はすべて、実際の組織に対して検証済みです。仕様とAPIは、重要な点で食い違うことがあるからです。
時間は分単位。金額は最小通貨単位。 時間エントリの 2 は2分を意味します。レスポンスも同様の単位で返ってきます。
不明なフィルタ、ソート、インクルードは明確に失敗します。 HTTP 400とともに unsupported_filter、sort_param_unsupported、unsupported_include が返ります。したがって、ここでそれらを検証することは、セーフティネットではなく、より良いエラーを返すためのものです。
不明な書き込み属性は静かに失敗します。 スペルミスのある属性での PATCH はHTTP 200を返し、何も変更しません — 成功と区別がつきません。そのため、このサーバーは、リソースが宣言していない属性を拒否し、実際には行われなかった書き込みを報告することを避けます。これはレジストリが行う最も有用なことです。
すべてのフィールドに、ちょうど6つのフィルタ演算子があります: contains、eq、gt、lt、not_contain、not_eq。仕様はフィールドごとに4つを記載しており、実際に動作する gt/lt を省略しています。gte、lte、in、not_in、starts_with、ends_with、blank、present はすべて unsupported_filter_operation で拒否されます。包含的な比較は存在しないため、包含的な範囲を指定するには、リソース独自の after/before または <field>_after/<field>_before フィルタフィールドが必要です。
page[size] は200で上限となり、静かにクランプされます。 500を要求すると、エラーなしで200が返ります。結果には total と nextPage が含まれるため、1ページを全体の回答と誤認することはありません。
PATCHは本当に部分更新です。 省略された属性は値を保持します。レコード全体を再送信する必要はありません。
data.type はチェックされません。 type: "projects" でタスクをパッチすると成功し、変更が適用されます。このサーバーはそれでも正しいタイプを送信します。
組織IDが「指定される必要がある」という403は、欠落ではなく誤りを意味する場合があります。 同じ no_organization_id コードが、ヘッダーの欠落と、トークンが到達できない組織の両方をカバーしています。
存在しない機能は403ではなく404で応答します。 /boards は、それを持たない組織では404を返します。これは壊れたパスのように見えます。
削除は復元できる場合があります。 削除されたタスクは deleted_items に item_type と item_id とともに現れ、そのリソースの restore アクションを通じて復元できます。タスクについてのみ検証済みです — すべてのタイプに当てはまるとは想定しないでください。
GET /users は唯一の呼び出し元スコープのエンドポイントです。 これは正確に1つのレコード — あなた自身 — を返し、このサーバーがトークンの所有者を識別する方法です。/users/me は存在せず、そのパスは404を返します。/organization_memberships に注意してください: これは固定された組織にスコープされておらず、呼び出し元が所属するすべての組織にわたるメンバーシップを一覧表示するため、その行数は人数ではありません。
レート制限ヘッダーはありません。 あるのは x-request-id のみで、このサーバーのエラーはそれを引用します。制限を探るのではなく、429でバックオフしてください。
4つのスイッチがあり、すべてデフォルトでオフです。読み取り専用サーバーが、有用で安全なデフォルトです。
スイッチ | 対象 |
| マスタースイッチ。これがない限り、何も変更されません。 |
| 金銭、価格設定、給与、顧客が受け取る文書: 請求書、ラインアイテム、支払い、請求、経費、発注書、提案書、契約書、価格、レートカード、給与、諸経費、税率、銀行口座、子会社。 |
| アクセスと組織全体の設定: 人、メンバーシップ、権限セット、チーム、招待、カスタムフィールド、ウェブフック、統合、承認およびタイムトラッキングポリシー。 |
| ティアゲートに加えて削除。 |
Productiveにはマスタースイッチ1つでは不十分です。同じAPIがタスクの移動、請求書の発行、権限セットの付与を行い、これらは3つの異なる判断です。プロジェクト作業の実行を信頼されたサーバーが、それによって請求書を送信できるようになってはいけません。
PRODUCTIVE_ALLOWED_RESOURCES / PRODUCTIVE_DENIED_RESOURCES はインスタンスをさらに絞り込み、読み取りにも適用されます — タイムトラッキングにスコープされたインスタンスは、給与も読み取るべきではありません。
スイッチに関係なく、決して公開されません: passwords、sessions、organization_subscriptions、認証不要の public/* 共有リンク、および PATCH /users/{id}/update_password。これらはゲートされるのではなくレジストリに存在しないため、ポリシーのバグによって再び公開されることはありません。
通常のプロジェクト作業 — タスク、時間エントリ、予約、コメント — は1回の呼び出しで書き込まれます。すべての時間エントリにハンドシェイクを要求すると、人々が最も頻繁に行う操作に対してサーバーが使えなくなってしまいます。
影響範囲が広いものはすべてステージングされます: ツールは正確なリクエストとハッシュを返し、何も送信しません。productive_commit_operation は、オペレーションが変更されずに戻ってきた場合にのみ実行します。これには、財務および管理ティア、すべての削除、組織外に出るもの、およびすべての bulk_* アクションが含まれます — これらはフィルタが一致するすべてのレコードに作用するため、明示的なフィルタなしでは実行を拒否します。
6つのオペレーションは、実行された瞬間に組織外の誰かに届くため、outward としてフラグ付けされています: invoices.send、invoices.send_einvoice、people.invite、people.resend、organizations.resend_code、および invitation の作成。
2つのモードがあります。PRODUCTIVE_ORGANIZATION_ID は両方で必須であり、ツールの引数になることはありません。
各人は自分自身の Productiveトークンをリンクするため、Productiveはその人の権限を適用し、その人が行った操作にその人の名前を記録します。
これは、ほとんどのシステムよりもProductiveで重要です。Productiveは作業を人に帰属させます: 時間エントリは person_id に属し、すべての変更はアクティビティログにトークンの所有者として記録されます — これはクライアントへの請求書を裏付ける記録です。共有トークン1つでは、そのログはサービスアカウントがすべてを行ったと記録されます。
PRODUCTIVE_PER_USER_AUTH=true
PRODUCTIVE_TRUST_FORWARDED_USER=true
PRODUCTIVE_ENCRYPTION_KEY=<min 16 chars>
PRODUCTIVE_STORE_PATH=/data/store.json
PRODUCTIVE_PUBLIC_BASE_URL=https://productive.example.com
# PRODUCTIVE_API_TOKEN deliberately unsetフロー:
呼び出し元は productive_connect を実行し、10分間有効な単回使用リンクを取得します。これはその人のアイデンティティに紐付けられています。
そのリンクを開き、Productiveの設定 → API連携で作成したトークンを貼り付けます。トークンはブラウザからサーバーに直接送信されるため、会話のトランスクリプトに入ることはありません — Productiveトークンはアカウント全体と同等のベアラー権限を持ち、後述の測定結果のとおり、通常は複数の組織に到達できます。
保存する前に、サーバーはそのトークンとこの組織のIDを使って GET /users を呼び出します。この1回の呼び出しで3つのことが証明されます: トークンが有効であること、この組織に到達できること、そして誰のものかということ。その後、ページはどのアカウントがリンクされたかを確認します。
トークンはAES-256-GCMで保存時に暗号化され、検証済みのアイデンティティごとに1行ずつ保存されます。
注意すべき点:
アイデンティティはゲートウェイからのみ取得されます。 X-MCP-User は PRODUCTIVE_TRUST_FORWARDED_USER=true の場合にのみ読み取られ、MCPクライアントが制御するものからは決して読み取られません。検証済みトークンからヘッダーを設定し、クライアントが提供したコピーを除去するゲートウェイの背後でのみ有効にしてください — そうしないと、呼び出し元が任意のアイデンティティを名乗ってその人として行動できてしまいます。
フォールバックはありません。 未登録の呼び出し元は NOT_CONNECTED を受け取り、たとえ PRODUCTIVE_API_TOKEN が設定されていても共有トークンは受け取りません。フォールバックがあると、借り物の権限を渡すことになり、このモードが排除するために存在する失敗を招きます。
/productive/enroll はユーザーのブラウザから到達可能である必要があります。MCPゲートウェイを経由せずに — ブラウザはゲートウェイのベアラートークンを保持できないためです。PRODUCTIVE_PUBLIC_BASE_URL 上の /productive/* をコンテナに直接ルーティングしてください。そのセキュリティは、単回使用でアイデンティティに紐付けられたステートトークンです。
PRODUCTIVE_STORE_PATH をボリューム上に永続化し、PRODUCTIVE_ENCRYPTION_KEY を安定に保ってください — 変更すると、保存されているすべてのトークンが復号不可能になります。
トークン自体のProductiveメールが呼び出し元のディレクトリアドレスと異なる場合、それはページと productive_status で明確に報告され、それでも接続されます。代わりに拒否するには PRODUCTIVE_REQUIRE_EMAIL_MATCH=true を設定してください。デフォルトでオフなのは、他人のトークンを貼り付ける人はすでにそれを保持しているため、拒否してもセキュリティ上の利得はほとんどなく、一方で別のアドレスでのProductiveアカウントは十分にあり得るからです。
ユーザーごとの認証は、組織ではなく、権限と帰属を分離します。組織の固定は依然として全員に適用されます。
PRODUCTIVE_API_TOKEN に1つのトークンを設定します。シンプルで、stdioや単一のオペレーターに適しています — ただし、すべての呼び出し元はそのトークンの所有者として、その権限で動作し、Productiveのアクティビティログはすべての変更をその人に帰属させます。
PRODUCTIVE_TRUST_FORWARDED_USER はここでも役立ちます。人物に関連する書き込み（タイムエントリー、予約）は、デフォルトでトークンの所有者ではなく解決された呼び出し元に帰属し、アドレスが誰にも一致しない場合や複数の人物に一致する場合、サーバーは推測することを拒否します。productive_check_connection はどちらの場合でもトークンの所有者を明示するため、帰属先が驚きになることはありません。
1つのインスタンスは正確に1つの組織にのみサービスを提供します。X-Organization-Id は環境から取得され、ツールの引数になることはないため、汎用ツールを含むいかなるコードパスも別のテナントに到達できません。2つ目の組織には2つ目のインスタンスを実行してください。イメージは同じです。
これは理論上の話ではありません。1つのトークンが日常的に複数の組織に到達します。この開発に使用したアカウントでは、GET /organizations は3つの組織を返し、ヘッダーを切り替えるだけで組織間を移動できました（他の2つは「見つからない」ではなく 403 subscription_expired を返しました）。ヘッダーが境界のすべてであり、それが引数として渡されるのではなく固定される理由であり、登録済みのユーザー別トークンが保存前に この 組織に対して検証される理由でもあります。
.env.example を参照してください。必要な変数は2つです。PRODUCTIVE_API_TOKEN（Productive の設定 → API連携。作成ユーザーの権限を継承します）と PRODUCTIVE_ORGANIZATION_ID（Productive URL 内の数値 ID）です。
PRODUCTIVE_AUDIT_LOG を設定すると、ミューテーション試行ごとに1行の JSON が追記されます。ポリシーが拒否した試行も含みます。リクエストボディは意図的に記録されません。それらには給与、レート、個人データが含まれており、ソースシステムと同程度に厳重に保護しなければならない監査証跡は、そもそも読まれない傾向にあるからです。
npm install
npm run dev # stdio
npm run dev:http # streamable HTTP on :3000/mcp (stateless), /healthz open
npm test
npm run smoke:live # reads a real organization; stages one write, commits nothingDocker イメージ: ghcr.io/borgels/mcp-server-productive（main へのプッシュ時に公開）
Apache-2.0.
Verify the token and organization and report what this deployment may do. Also names the person the token belongs to — every change Productive records is credited to them, whoever asked — and the caller identity, when a gateway forwards one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, and the description adds relevant behavioral context: token identity is attributed to every recorded change, and caller identity may be forwarded by a gateway. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the core action first, followed only by consequential detail about attribution and caller identity. There is no fluff or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool, the description conveys the main outputs: deployment capabilities, token owner, and caller identity. It does not specify exact response formatting or failure behavior, but the tool's simplicity and readOnly annotation make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the empty schema fully describes the input surface, so there is nothing for the description to add about parameter semantics. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Verify the token and organization' and states what the tool reports (deployment capabilities, token owner, caller identity). This makes its role distinct from sibling data-operation tools like productive_get or productive_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes the context — validating the Productive token and organization and surfacing what the deployment can do — so an agent knows to call it for connection/auth checks. It does not explicitly name alternatives or when-not conditions, but the absence of parameters and the verification purpose make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a write that a prepare step staged. Pass the operation object back exactly as it was returned: it is hashed, and an altered operation is refused rather than run. Show the change to the person who asked for it before committing.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the minimal readOnlyHint=false annotation, the description discloses two important behaviors: the operation is hashed and altered operations are refused, and the change must be shown to the requester before committing. This is valuable safety-relevant context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, purposeful sentences with no fluff. Purpose, usage constraint, and mandatory approval step are all front-loaded and directly actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what matters most for a commit operation: exact object reuse, hash enforcement, and user approval. It does not describe the success response or explicitly name a prepare tool, but the workflow is sufficiently constrained for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the single nested 'operation' parameter has no field-level documentation. However, the description compensates by instructing the agent to pass the exact object back and explaining the hash invariant, which materially reduces the risk of misuse despite lacking field-by-field semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'Execute a write that a prepare step staged.' This clearly identifies the tool as the commit step for a staged operation, distinguishing it from direct create/update/delete siblings by the staged-operation framing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: use after a prepare step, pass the operation object back exactly as returned, and show the change before committing. It does not explicitly name alternatives or say when not to use it, but the staged-operation workflow is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a record on any writable resource. Required attributes are checked first, and so is every attribute name. On a financial or administrative resource this returns a staged operation to review rather than creating anything — pass it to productive_commit_operation to go through with it.
| Name | Required | Description | Default |
|---|---|---|---|
| resource | Yes | ||
| attributes | No | Attributes to write, by their Productive names. Validated against the resource contract first, because Productive answers 200 and ignores an unknown attribute rather than reporting it. Custom-field values go in a nested `custom_fields` object keyed by field id. | |
| relationships | No | JSON:API relationships, where the resource accepts them. Most links are set through an `_id` attribute instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark readOnlyHint=false, so the description carries the burden of explaining mutation nuance. It discloses the staging behavior, the validation-before-write behavior, and the fact that commit is required on certain resources. This is meaningful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler, with the core action first, then validation, then the exception case. Every sentence adds actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema, it explains the essential invocation path, including when commit is required. It could say more about return shape or failure behavior, but the description and schema together cover the necessary details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes attributes and relationships in detail, covering 2 of 3 parameters. The tool-level description adds no parameter-specific detail; `resource` remains minimally described, though it is self-evident and explained at a high level as 'any writable resource.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what it does: create a record on any writable resource. The explicit mention of productive_commit_operation distinguishes it from update/delete/list/get siblings. No ambiguity about the operation performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the resource-type condition that changes behavior: financial/administrative resources stage an operation rather than creating, and directs the agent to productive_commit_operation to finalize. It doesn't enumerate exclusions versus update/delete, but for a create tool this is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a record. Needs its own switch beyond ordinary writes, and always returns a staged operation first. Many Productive types are meant to be archived rather than deleted — check productive_describe_resource for an archive action before reaching for this.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| resource | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description need not restate that. It adds non-obvious behavioral facts: deletion requires a separate switch and always returns a staged operation first. This goes beyond annotations and meaningfully sets expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with the core purpose first, followed by two high-value caveats. Every sentence earns its place; there is no filler or repetition of schema/annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with two simple parameters and no output schema, the description provides essential behavior: staged operation first, archive exception, and switch requirement. The main gap is parameter semantics, but the operational guidance is strong enough to make the tool safely invocable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not define the `resource` or `id` parameters. 'Delete a record' hints that resource is the record type and id is its identifier, but this is too vague to clarify valid resource types or how the id is used. The description adds minimal value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Delete') and resource ('a record'), making the tool's purpose clear. It also distinguishes the tool from create/update operations and explicitly references the archive alternative, differentiating it from a sibling behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs the agent to check productive_describe_resource for an `archive` action before using delete, giving clear when-to-use-vs-alternative guidance. It also notes the requirement for a special switch beyond ordinary writes, which is a practical precondition for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the organization's custom fields with the id each value is written under, the object it applies to, and its options. Custom-field values are keyed by numeric id, not by display name — a name used as a key is accepted with 200 and stored nowhere.
| Name | Required | Description | Default |
|---|---|---|---|
| appliesTo | No | Narrow to fields on one object, matched against Productive's own wording for it. That wording is not this server's resource key — fields on people report "employees" — so call this without an argument first and pick from appliesToValues. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses a critical behavioral quirk: custom-field values are keyed by numeric id, not display name, and using a name as a key is silently accepted with 200 but stored nowhere. This is exactly the kind of non-obvious behavior that prevents an agent from making a subtle mistake.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the purpose and return fields, then adds the essential behavior warning. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with one optional parameter, the description is complete: it names the resource, lists the output components, and flags the keying gotcha. The absence of an output schema is mitigated by the explicit statement of what is returned, and the readOnlyHint annotation covers safety expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage and already explains appliesTo in detail, including the 'employees' example and the instruction to call without an argument first. The tool description itself adds no additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), names the resource ('organization's custom fields'), and specifies what is returned: id, object, and options. It clearly distinguishes this from siblings like productive_describe_resource, which would describe a resource's schema rather than enumerate custom fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage context clearly: call it to list custom fields and understand how values are keyed. The input schema adds explicit guidance to call without an argument first and then pick from appliesToValues, which is practical usage direction. It does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The exact contract for one resource, derived from Productive's own OpenAPI document: every filter field, the operators any field accepts, sort keys, report group keys, includable relationships, the writable attributes for create and update with the required ones marked, and any named actions. Read this before writing — it is the difference between a write that lands and a 200 that changed nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| resource | Yes | Resource key, e.g. "tasks", "time_entries", "reports/time_reports". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral context: output is derived from Productive's own OpenAPI document and includes specific contract elements, plus a warning about write no-ops that goes beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: one sentence enumerates the full contract contents, and a second short sentence delivers a high-impact usage warning. Every phrase contributes meaning, with no filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only introspection tool, the description fully specifies what output the agent should expect and when to call it. The lack of an output schema is compensated by the detailed enumeration of returned contract components.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the single 'resource' parameter with examples. The description adds no additional syntax, validation, or format details for the parameter, so it stays at the baseline where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb-object relationship: it provides 'the exact contract for one resource' and enumerates the concrete contents such as filter fields, operators, sort keys, and writable attributes. This clearly distinguishes it from siblings like productive_get, productive_list, and productive_describe_custom_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to 'Read this before writing' and contrasts a successful write with 'a 200 that changed nothing,' giving a clear trigger for use. It does not explicitly name alternative tools or when not to use it, but the intended context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one record by id, optionally pulling related records in the same call rather than following relationship stubs one at a time.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| raw | No | ||
| include | No | ||
| resource | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safety, and the description adds meaningful behavior: optional eager-loading of related records in the same call. It does not explain raw mode or default include behavior, but the core read semantics are transparent and align with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and then adds the key optional behavior. There is no redundant or filler language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter descriptions, the description is too sparse to fully support correct invocation. The agent still has to guess what 'resource' values are valid, what 'raw' does, and what the response shape looks like. The relationship-include guidance is helpful but not enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all four parameters. It explains the purpose of 'id' and loosely hints at 'include', but it never clarifies 'resource' or 'raw', which are both undocumented in the schema and the description. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and clear object ('one record by id'), which distinguishes it from sibling tools like productive_list and productive_create. The added phrase about pulling related records also separates it from naive relationship-stub traversal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool: when you need a single record by id and optionally want related records in one call rather than following stubs. It does not explicitly exclude alternatives like productive_list for multiple records, so it stops short of full when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List any Productive resource with server-side filtering, sorting, includes and paging. Also how the 26 report endpoints are read: use resource "reports/time_reports" (and the rest) with group to get aggregated rows instead of records. Results are flattened out of JSON:API — attributes hoisted, included records inlined into their relationship — with total and nextPage so a page is never mistaken for the whole answer.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Return Productive's JSON:API envelope untouched instead of flat records. | |
| page | No | ||
| sort | No | Sort keys; prefix with "-" for descending, e.g. ["-created_at"]. | |
| group | No | Report aggregation key. Only the reports/* resources accept one. | |
| filters | No | Server-side filters. A bare value means equality: {"assignee_id":"5"}. An array is comma-joined: {"id":["1","2"]}. An operator object narrows further: {"created_at":{"gt":"2026-01-01"}} — the ONLY operators Productive accepts are contains, eq, gt, lt, not_contain, not_eq. There is no gte/lte, so for an inclusive date range use the resource's own after/before filter fields instead. Logical groups nest: {"$op":"and","0":{"assignee_id":{"eq":"5"}},"1":{"company_id":{"eq":"7"}}}. Field names are validated against the resource — call productive_describe_resource for the list. | |
| include | No | Relationships to pull in the same call, e.g. ["assignee","project"]. | |
| resource | Yes | One of 132 resource keys; see productive_search_capabilities. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond the readOnlyHint annotation: results are flattened out of JSON:API, attributes are hoisted, included records are inlined, and responses include total and nextPage so the agent understands pagination is partial. It also clarifies that report resources return aggregated rows rather than records. This goes well beyond the minimal safety signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences and front-loads the core purpose. Each sentence provides meaningful information, though the phrase 'Also how the 26 report endpoints are read' is slightly awkward and could be streamlined. Overall it is efficient without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return shape well: flattened records, inlined relationships, total, and nextPage. It also covers the special report behavior and aggregated rows. For a complex 7-parameter listing tool with 132 possible resources, this is sufficiently complete to guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so the input schema already documents most parameters well. The description adds a little context around group for report endpoints, but it mostly summarizes capabilities like filtering and paging rather than meaningfully extending the schema's parameter documentation. Baseline 3 is appropriate because the schema carries the parameter-semantic burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists any Productive resource with filtering, sorting, includes, and paging. It also explicitly handles the special behavior of the 26 report endpoints, distinguishing this from siblings like productive_get and productive_search_capabilities. The verb 'List' and resource scope are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on when to use this tool, including the specific instruction to use resource 'reports/time_reports' with group for aggregated report rows. It provides the main usage context but does not explicitly enumerate exclusions or alternatives such as 'use productive_get for a single record.' The context is clear enough that an agent can choose correctly in most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one of Productive's named verbs: archive, restore, close, open, approve, reject, copy, finalize, send, reposition and the rest. Actions named bulk_* act on every record the filter matches rather than one, and refuse to run without an explicit filter. productive_describe_resource lists the actions a resource has.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Required for actions that act on one record. | |
| action | Yes | Action name, e.g. "archive", "approve", "send". | |
| filters | No | Server-side filters. A bare value means equality: {"assignee_id":"5"}. An array is comma-joined: {"id":["1","2"]}. An operator object narrows further: {"created_at":{"gt":"2026-01-01"}} — the ONLY operators Productive accepts are contains, eq, gt, lt, not_contain, not_eq. There is no gte/lte, so for an inclusive date range use the resource's own after/before filter fields instead. Logical groups nest: {"$op":"and","0":{"assignee_id":{"eq":"5"}},"1":{"company_id":{"eq":"7"}}}. Field names are validated against the resource — call productive_describe_resource for the list. | |
| resource | Yes | ||
| attributes | No | Attributes to write, by their Productive names. Validated against the resource contract first, because Productive answers 200 and ignores an unknown attribute rather than reporting it. Custom-field values go in a nested `custom_fields` object keyed by field id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false, so the description carries the behavioral burden. It discloses two non-obvious behaviors: bulk_* actions operate on every record the filter matches, and they refuse to run without an explicit filter. The schema also surfaces that Productive answers 200 and silently ignores unknown attributes, adding important behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. It front-loads the core purpose, then immediately covers the most dangerous edge cases (bulk scope and filter requirement), and ends with a useful discovery pointer. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 5-parameter tool with nested filter objects and no output schema, the description and schema together cover the essential invocation details: valid action classes, bulk semantics, filter requirements, field validation, and discovery via productive_describe_resource. The only notable gap is the lack of any mention of what the response looks like or error behavior beyond the silent-attribute-ignore note, which is a minor omission for an action-triggering tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is roughly 80%, and the schema already provides rich semantics for filters, attributes, and id. The description adds the bulk-vs-single distinction and the explicit-filter requirement, which complements the filters parameter. Given this high schema coverage, the baseline of 3 is appropriate; the description does not need to re-document each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Run') and a clear resource class ('one of Productive's named verbs'), then lists concrete examples: archive, restore, close, open, approve, reject, copy, finalize, send, reposition. It also distinguishes single-record actions from bulk_* actions, so the tool's purpose is unmistakable and well differentiated from the sibling CRUD tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states that bulk_* actions require an explicit filter and calls out productive_describe_resource as the way to discover which actions a resource supports. It does not, however, give explicit when-not-to-use guidance against siblings like productive_update or productive_delete, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the right resource, tool or guide for a subject. Start here: Productive names its resources its own way (a budget is a deal, a person is a person, a board column is a workflow_status), and guessing wastes calls. Returns matching tools, workflow guides, and resources with the operations each supports.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Subject to search for, e.g. "invoice", "capacity", "custom field", "time". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already in annotations, the description adds useful behavioral context: it returns matching tools, workflow guides, and resources along with the operations they support. It also discloses the important quirk that resource names may not match user expectations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, and every sentence adds value: what it finds, where to start, and what it returns. The naming examples are illustrative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with only two parameters and no output schema, the description covers purpose, scoping context, and return categories well. It does not detail result shape or empty-result behavior, but those are not critical for selecting and invoking this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description reinforces that 'query' is a subject to search for, but the schema already covers that with examples. The 'limit' parameter is not described in the description, and with only 50% schema description coverage, the description does not fully compensate. The parameter is simple enough that the gap is moderate rather than severe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Find') and resource ('resource, tool or guide for a subject') and clearly distinguishes this as the starting point for discovery. It explains the tool's role relative to siblings by highlighting Productive's naming conventions, so an agent knows this is a search/capability lookup, not a data operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Start here' explicitly tells the agent when to use this tool, and the mention of Productive's non-obvious naming ('a budget is a deal') explains why guessing would waste calls. It does not name alternative sibling tools or state when not to use it, but the contextual guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a time entry without looking up what Productive insists on. Time is stored in MINUTES — pass hours and it converts. The service (the budget line the work bills to, not the task) is resolved from the task when not given, and the person is resolved from the authenticated caller, so time lands on the right person even though the server holds one shared token.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date of the work, YYYY-MM-DD. | |
| note | No | ||
| hours | No | Time worked in hours; converted to minutes. | |
| taskId | No | Task worked on. Also used to resolve the service. | |
| minutes | No | Time worked, in minutes. | |
| personId | No | Whose time this is. Defaults to the resolved caller. | |
| serviceId | No | Service (budget line) to bill to; overrides the task lookup. | |
| billableMinutes | No | Billable portion, if it differs from the time worked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=false in annotations, the description carries the full burden of behavioral disclosure. It clearly reveals that hours are converted to minutes, the service is derived from the task when absent, and the person is resolved from the authenticated caller despite a shared server token. This is specific and valuable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the action, the second explains the critical unit conversion, and the third clarifies lookup defaults and authentication behavior. It is dense without being bloated, and the essential action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no output schema, the description covers the core call flow well: what to log, how units are handled, which IDs can be omitted, and how resolution works. It does not describe the return value or what happens when conflicting inputs like hours and minutes are both supplied, but these are minor gaps given how much is already explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 88%, so the schema already documents most parameters. The description adds real value by explaining the hours-to-minutes conversion, the distinction between service and task, and the fallback resolution behavior for serviceId and personId. It does not explain every edge case, such as providing both hours and minutes, but it meaningfully supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Log a time entry.' It goes beyond the title by explaining the key behavior that makes this tool distinct from generic create/list tools: it avoids manual lookups and handles conversions, making the intent unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear practical context: service can be omitted and is resolved from the task, person can be omitted and is resolved from the caller. This tells an agent when it can avoid passing certain parameters, though it does not explicitly name alternatives or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a record. PATCH semantics, verified live: attributes you omit keep their values, so there is no need to resend the whole record. On a financial or administrative resource this returns a staged operation instead of writing.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| resource | Yes | ||
| attributes | No | Attributes to write, by their Productive names. Validated against the resource contract first, because Productive answers 200 and ignores an unknown attribute rather than reporting it. Custom-field values go in a nested `custom_fields` object keyed by field id. | |
| relationships | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=false provided by annotations, the description carries a meaningful behavioral burden and does well: it discloses PATCH semantics, confirms omitted fields are retained, and warns that certain resources return a staged operation instead of writing. It does not cover permissions or reversibility, but it adds real behavioral facts beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the key PATCH behavior. The first sentence duplicates the title, which costs a little, but every other sentence carries useful operational meaning without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core PATCH semantics and the staged-operation caveat, but it does not explain what a staged operation should be followed by, especially given the sibling productive_commit_operation. There is also no output schema and the description does not say what a normal update returns, and relationships remain undocumented. This leaves the agent needing to infer important follow-up behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low at 25%, and the description does add value for the attributes parameter by explaining that omitted attributes keep their values. However, it gives no semantic guidance for resource, id, or relationships, and the custom_fields nesting behavior lives only in the schema, not the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action on a record and immediately clarifies PATCH semantics, which distinguishes it from read-only siblings like productive_get and productive_list. It is slightly repetitive with the title but unambiguous about the operation's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context: partial updates preserve omitted attributes, so no full resend is needed, and financial/admin resources return staged operations instead of writing. However, it does not explicitly say when to choose this over productive_create, productive_delete, or productive_run_action, so usage versus alternatives is mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0productive_check_connectionproductive_commit_operationproductive_createproductive_deleteproductive_describe_custom_fieldsproductive_describe_resourceproductive_getproductive_listproductive_run_actionproductive_search_capabilitiesproductive_track_timeproductive_updateScored across 12 tools
Each tool targets a distinct operation: reading one record, listing, creating, updating, deleting, running a named action, staging/committing writes, tracking time, or performing a meta/introspection task. Even the closer pairs like get/list and describe_resource/describe_custom_fields are clearly separated by resource scope and purpose.
All tools follow the snake_case productive_<verb> pattern, with most using verb_noun (productive_check_connection, productive_run_action) and a few using bare verbs (productive_get, productive_list). This is consistent and predictable, with no style mixing or vague duplicate verbs.
Twelve tools is well within the ideal scope for a broad API integration server. The set covers generic CRUD, named actions, time tracking, staged writes, and meta/discovery tools without ballooning into redundant or overly granular endpoints.
The server provides full lifecycle coverage: read, list, create, update, delete, run actions, and commit staged operations, plus support for custom fields and resource contracts. The meta tools fill the gaps that typically cause agent failures, such as knowing resource-specific filters, writable attributes, and custom-field keying.
Agent-complete, permission-scoped product operations for Priorify workspaces.
Supervised API-write gateway for AI agents with policy, human approval and execution receipts.
Read time entries, projects, clients, tasks and invoices; log and update tracked time.
Read teams, spaces, lists and tasks; create, update and comment on tasks and track time.