Skip to main content
Glama
soil-dev

capsulemcp

apply_track

Apply a track definition to an opportunity or project, creating a track instance and tasks with due dates calculated from a start date.

Instructions

Apply a track definition to an opportunity or project. Creates a track instance and auto-creates tasks per the track's task definitions; tasks' dueOn is computed from startDate (defaults to today) plus each task's daysAfter offset. Use list_track_definitions to discover available templates. NOT IDEMPOTENT — applying the same trackDefinitionId twice creates two independent track instances and two sets of auto-tasks (no de-duplication). If you want to apply only once, call list_entity_tracks first and check for an existing instance with the same trackDefinition.id (but mind that list_entity_tracks can include auto-applied tracks from board stage rules, not just manual applies).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entityYesWhich entity to apply the track to. Use 'kases' for projects.
entityIdNo
trackDefinitionIdNoThe trackDefinition to apply (from list_track_definitions). Auto-creates task definitions on the target entity per the track's rules.
startDateNoOptional ISO-8601 date (YYYY-MM-DD) the track should start from — drives task due-date calculations (each task's `dueOn` is computed as startDate + the track-definition's `daysAfter` offset). Defaults to today if omitted. Useful for scheduling a renewal-queue track against a future contract end-date, or backfilling tracks for historical projects.
Behavior5/5

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

The description discloses that the tool is NOT idempotent, explains duplicate behavior, and mentions the startDate default. This adds transparency beyond annotations (readOnlyHint: false, destructiveHint: false).

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 yet comprehensive, with no unnecessary words. It is front-loaded with the main purpose and logically flows to details and usage guidance.

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?

For a tool with side effects and no output schema, the description covers all essential aspects: action, mechanism, alternatives, idempotency, and parameter behavior. It is complete and actionable.

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?

Schema coverage is 75% (3 of 4 parameters have descriptions). The description adds extra context for startDate (computation details and use cases) beyond the schema, enhancing understanding.

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 the action ('Apply a track definition') and the target ('to an opportunity or project'), and distinguishes it from sibling tools like list_track_definitions and list_entity_tracks.

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?

It explicitly advises using list_track_definitions to discover templates and warns about non-idempotency, suggesting checking list_entity_tracks first for idempotent application.

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

Install Server

Other Tools

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/soil-dev/capsulemcp'

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