Skip to main content
Glama

p6_query_activities

Read-onlyIdempotent

Search activities, one page: {total, offset, returned, next_offset, rows}, ordered by start (actual, else early) then Activity ID. status: TK_NotStart, TK_Active or TK_Complete. Dates as YYYY-MM-DD (finish_before includes that day).

Instructions

Search activities, one page: {total, offset, returned, next_offset, rows}, ordered by start (actual, else early) then Activity ID. status: TK_NotStart, TK_Active or TK_Complete. Dates as YYYY-MM-DD (finish_before includes that day). wbs_name_contains matches the name of the activity's own WBS node only, not its parents: for a whole branch use p6_list_wbs, or an activity code filter. Durations and float in days of each activity's calendar. code_type (activity code type name, e.g. 'Discipline'; the project's own type wins over an EPS or global one) keeps activities with a code of that type; code_value narrows it to a code by path ('CON.MEC'), short name ('MEC': every match) or name, with its child codes unless include_child_codes=False; code_filter tells what was matched. fields= keeps task_code plus the fields named, e.g. ['task_name', 'early_start_date', 'early_end_date', 'total_float_d'], for smaller pages. UDFs (user defined columns, p6_list_udfs): udf_filter = [{udf: label, op, value}], all to hold; op eq (default), ne, lt, le, gt, ge, contains (text), empty, not_empty; a date alone covers the whole day; udf_filter (info) tells what was used. udfs = labels added to each row as udfs {label: value} (None when empty).

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": {
      "project": "<project>"
    },
    "name": "p6_query_activities"
  }
}

Input Schema

NameRequiredDescriptionDefault
udfsNo
limitNoRows per page (max 200).
fieldsNo
offsetNoRows to skip: pass next_offset from the previous page.
statusNo
projectYesProject ID as shown in P6 (p6_list_projects).
code_typeNo
code_valueNo
udf_filterNo
code_prefixNo
start_afterNo
finish_beforeNo
name_containsNo
wbs_name_containsNo
include_child_codesNo
max_total_float_daysNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • addedInput schema / $defs
      Added value: +{
      +  "UdfFilter": {
      +    "description": "Activities whose UDF value matches: op (default eq) against value (not for empty / not_empty).",
      +    "properties": {
      +      "op": {
      +        "enum": [
      +          "eq",
      +          "ne",
      +          "lt",
      +          "le",
      +          "gt",
      +          "ge",
      +          "contains",
      +          "empty",
      +          "not_empty"
      +        ],
      +        "title": "Op",
      +        "type": "string"
      +      },
      +      "udf": {
      +        "title": "Udf",
      +        "type": "string"
      +      },
      +      "value": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "number"
      +          }
      +        ],
      +        "title": "Value"
      +      }
      +    },
      +    "required": [
      +      "udf"
      +    ],
      +    "title": "UdfFilter",
      +    "type": "object"
      +  }
      +}
    • addedInput schema / properties / udf_filter
      Added value: +{
      +  "anyOf": [
      +    {
      +      "description": "UDF conditions, all must hold.",
      +      "items": {
      +        "$ref": "#/$defs/UdfFilter"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Udf Filter"
      +}
    • addedInput schema / properties / udfs
      Added value: +{
      +  "anyOf": [
      +    {
      +      "description": "UDF labels (as in P6 columns) to add to each row under 'udfs'.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Udfs"
      +}
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses the pagination envelope ({total, offset, returned, next_offset, rows}), row ordering, date-bound inclusivity, UDF filter conjunction behavior, and what code_filter/udf_filter report back. That is substantial behavioral context for an agent invoking a complex query tool.

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?

The definition is dense but front-loads the core action, result shape and ordering before moving into filters. For a 16-parameter tool with low schema coverage, most clauses earn their place, though the single-block parenthetical style makes it harder to scan.

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

Completeness4/5

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

It explains the return envelope, paging, ordering, common filters, WBS caveat, code matching and UDF behavior, which is appropriate given no output schema and sparse schema descriptions. Completeness is reduced because a few schema parameters, notably name_contains, code_prefix and max_total_float_days, are not described anywhere.

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 description coverage is only 19%, so the description must carry parameter meaning, and it does for many important filters: status values, date format/inclusivity, wbs_name_contains scope, code_type/code_value matching, include_child_codes, fields projection, and UDF ops/output. It still leaves code_prefix, name_contains, and max_total_float_days unexplained, so it is strong but not complete.

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?

The description opens with a specific verb and resource: 'Search activities, one page', and it defines the result envelope and ordering. It differentiates one sibling path by saying WBS-branch searches should use p6_list_wbs, but it does not explicitly contrast against other siblings such as p6_get_activity or p6_critical_path.

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?

It gives clear usage context for paging, status filtering, date filters, code filters and UDF filters. It also names an explicit alternative for whole-WBS-branch queries ('use p6_list_wbs'), but it does not comprehensively explain when to choose this tool over the broader sibling set.

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