Skip to main content
Glama
soil-dev

capsulemcp

apply_track

Create tasks from a track template by applying it to an opportunity or project. Tasks get due dates computed from the start date and template offsets.

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.
entityIdYes
trackDefinitionIdYesThe 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.

Implementation Reference

  • The registerTool helper function that wraps tool handlers into MCP's expected response shape (JSON stringified into text content).
    export function registerTool<Schema extends z.ZodObject<ZodRawShape>>(
      server: McpServer,
      name: string,
      description: string,
      schema: Schema,
      handler: (input: z.infer<Schema>) => Promise<unknown>,
    ): void {
      // Use the SDK config-form registerTool with the full Zod schema. The
      // deprecated shape overload rebuilds z.object(schema.shape), which drops
      // object-level refinements such as superRefine.
      const registerWithSchema = server.registerTool.bind(server) as (
        toolName: string,
        config: { description: string; inputSchema: Schema },
        callback: (input: z.infer<Schema>) => Promise<CallToolResult>,
      ) => void;
    
      registerWithSchema(name, { description, inputSchema: schema }, async (input) => {
        const result = await handler(input);
        return wrapAsText(result);
      });
    }
Behavior5/5

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

Discloses non-idempotent nature explicitly, explains auto-task creation with dueOn computation from startDate, and notes default behavior. No annotation provided, so description carries full burden and does so comprehensively.

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?

Five sentences, front-loaded with purpose, then parameter details, then usage guidance. No filler, each sentence adds unique 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?

Given no output schema, the description explains behavioral outcomes (task creation, dueOn calculation) and usage context (checking for duplicates). Covers all necessary aspects for correct agent use.

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 75% schema coverage, description adds value by explaining the 'kases' alias for projects, source of trackDefinitionId, and optional startDate with examples. However, entityId parameter lacks additional context in both schema and description, preventing a perfect score.

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 explicitly states the action ('apply a track definition') and the target ('an opportunity or project'), with a specific verb+resource that distinguishes 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?

Clearly indicates when to use (to create a track instance and auto-create tasks) and when not to (if you want idempotent behavior, check list_entity_tracks first). Also mentions edge case of auto-applied tracks from board stage rules.

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