agent-passport-system-mcp

Create Task Brief

create_task_brief

Create a new agent task with defined roles, deliverables, and acceptance criteria to standardize handoffs and verify completion.

Instructions

[OPERATOR] Create a new task with roles, deliverables, and acceptance criteria.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>",
      "description": "<description>",
      "roles": "<roles>",
      "deliverables": "<deliverables>",
      "acceptance_criteria": "<acceptance_criteria>"
    },
    "name": "create_task_brief"
  }
}

Input Schema

Name	Required	Description
`roles`	Yes	Roles needed for this task
`title`	Yes	Task title
`deadline`	No	ISO 8601 deadline
`description`	Yes	What needs to be done
`deliverables`	Yes	Expected outputs
`acceptance_criteria`	Yes	What 'done' looks like

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv4.0.0Aug 1, 2026
- changedInput schema / $schema
```
Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
```
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / deliverables / items / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / roles / items / additionalProperties
```
Removed value: -false
```
Addedv2.8.0May 1, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive write. The description adds only the [OPERATOR] privilege marker, which is useful but thin; it does not explain side effects such as duplicate creation risk from non-idempotency or what state the new task enters.

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

Conciseness4/5

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

A single front-loaded sentence with no filler and the key payload named first. It is efficient, though arguably under-specified for a tool with six parameters and two nested object arrays.

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

Completeness2/5

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

For a mutation tool with required nested role and deliverable objects, no output schema, and no annotations covering side effects, the description is too sparse. It omits what a task brief lifecycle looks like, what is returned, and what happens after creation.

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 nested roles and deliverables structures are already documented. The description names three of six parameters but adds no format or constraint meaning beyond the schema, so baseline 3 applies.

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

Purpose4/5

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

States a specific verb (Create) and resource (task) and enumerates the core payload (roles, deliverables, acceptance criteria), which clearly distinguishes it from list_tasks and get_task_detail. It does not explicitly name a sibling, so it lands at 4 rather than 5.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no routing against related creation/assignment tools (create_intent, assign_agent, accept_assignment). The only implicit signal is the [OPERATOR] tag, which hints at privilege but does not say when to pick this tool.

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

Deploy Server