Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
TP_TOKENYesYour Targetprocess access token. Never logged.
TP_BASE_URLYesYour Targetprocess instance URL, e.g. https://yourcompany.tpondemand.com (no /api/...)
TP_DEFAULT_TEAM_IDNoTeam for new cards when none is given.
TP_DEFAULT_PROJECT_IDNoProject for new cards that have no parent to inherit one from.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
read_cardA

Read any card (user story, task, bug, feature, epic, test plan, ...) by id: type, name, state, project, parent chain, teams with team states, assignments (who is assigned in which role), role efforts, effort totals, release/iteration, custom fields, tags, counts, and the description as plain text.

read_searchA

Find cards by text in the name (or #id; bare digits match the id and the name), type, state, project, assignee ("me" for yourself) and tag. Open cards only unless includeClosed. Names and states are resolved; ambiguous names are listed, never guessed. Newest-modified first.

read_my_workA

Cards assigned to the current user (the token owner), open ones by default, with counts per state.

read_statesA

States available to a card (from its own project's process), or to an entity type in a project. Team sub-workflow states are flagged isTeamWorkflow; for a card, its current state and team states are included.

read_peopleA

Find people by name, login or email (every word must match), fully paged over all users. Without a query, lists everyone active. Use the returned ids when a name is ambiguous.

read_teamsA

List teams (active by default), optionally filtered by name.

read_rolesA

List roles (Developer, Product Owner, ...). hasEffort tells whether a role can carry effort.

read_projectsA

List projects (active by default) with abbreviation and process, optionally filtered by name.

read_releasesA

Releases, newest first, optionally for one project; currentOnly for releases in progress.

read_iterationsA

Team iterations (sprints) for a team, or project iterations for a project; newest first. currentOnly for the running ones. Without team or project: current team iterations of every team.

read_custom_field_optionsB

Custom fields of a card's type (or of an entity type in a project) with their type and, for dropdowns, the allowed values. Pass field to see one field.

read_commentsA

Comments on a card, oldest first, as plain text, with author and reply parent. When capped, the most recent comments are kept.

read_relationsB

Relations of a card in both directions (dependency, blocker, relation, link, duplicate), with the related card.

read_timesA

Time logged on a card, or by a person ("me" for yourself), optionally within dates (YYYY-MM-DD). Returns entries and the total spent. Reads Time entries where the card's process tracks time, and TimeRecord entries where the instance tracks time that way (a story's records include those of its tasks). By person alone, both kinds are returned.

read_attachmentsA

Attachments of a card: name, size, type, owner, date and URL. Downloading needs Basic or cookie auth; with an access token Targetprocess returns an HTML error page instead of the file.

read_test_planB

A test plan with its test cases and their steps (in run order), child test plans, and recent test plan runs.

read_metaA

Describe the Targetprocess resource catalog read from this instance. Without a resource: every resource with its operations. With a resource: its fields (settable/required), references and collections (addable/removable). Use it before read_query/write_create.

read_getA

GET one entity of any resource by id (layer 1). Inner collections in include return up to 1000 items. Prefer read_card for cards.

read_queryA

Query a collection of any resource with where/include/orderBy (layer 1), fully paged. Returns {count, truncated, items}; default limit 500, max 5000. Use include to keep results small.

read_collectionA

GET an inner collection of an entity, e.g. UserStories/{id}/Tasks or Bugs/{id}/Comments (layer 1), fully paged. See read_meta for collection names.

read_v2_queryA

Targetprocess REST v2 query (read-only): select with projections and nested collections, where with ==, !=, and, or, aggregations via result, board filter DSL via filter. Entity is singular (userStory, bug, feature). v2 omits null fields: absence means null. Filters use v2 syntax, e.g. where=(entityState.isFinal==false and project.id==2), select={id,name,tasks.count as tasks}.

read_historyA

Change history of an entity, oldest first (when capped, the most recent entries are kept). Simple history (default) records state, effort, release and iteration changes; full: true returns every change with the changed fields and their new values. resource is resolved from the id for cards; pass it for other entities (e.g. Comment).

read_contextA

Targetprocess Context for entity ids, or for projects and teams: processes and their practices (e.g. IsStoryEffortEqualsSumTasksEffort), terms, custom field definitions, selected projects/teams, logged user, version. Without arguments: the global context.

read_conversionsB

Type conversions of a card (e.g. a bug converted to a user story): the id it has now if it was converted, and the ids it was converted from.

read_deletedA

Deleted projects or users (v2 includeDeleted), with their delete date. Restoring them needs admin_undelete and an administrator token.

read_storageA

RESTful storage, where views, boards and settings live. No group: list groups. Group: its storages (select/where in storage syntax, e.g. select={key,publicData.name} where=(scope == "Public")). Group + key: one storage with publicData and userData.

write_create_cardA

Create any card type (UserStory, Task, Bug, Feature, Epic, TestPlan, Request, ...) with parent, name, description, state, team, assignees, role efforts, tags and custom fields, applying the team rules: the project is inherited from the parent (task ← story, story ← feature, feature ← epic, bug ← its card, test case ← test plan) and the call fails before posting if none resolves; assignments Targetprocess adds by default are removed and reported, then exactly the requested people are assigned; effort is written per role; the parent's state and role efforts before/after are reported. Description: pass format markdown for Markdown; HTML is sent as-is, plain text lines become paragraphs.

write_update_cardA

Update a card: name, description, tags (tags replaces the whole list; addTags/removeTags edit it), release, iteration, team iteration (null clears), parent, or other settable fields. Description: pass format markdown for Markdown. Changes are read back; removed tags are reported. For a test case, parent ADDS it to that test plan (existing plans are kept). For state, people, effort, teams and custom fields use the dedicated write_* tools.

write_set_stateA

Move a card to a state by name or id, resolved against the card's own project workflow. With team, sets that team's state on the card (its team sub-workflow, or the project workflow when the team has none). The state is read back, and the parent card's state before/after is reported: moving a task out of its initial state can advance its user story.

write_assignA

Assign a person to a card in a role (names or ids; "me" for yourself). Adds to existing assignments; with exclusive: true, also removes everyone else in that role (only when explicitly asked). Reports what was removed and reads the assignments back.

write_unassignA

Remove one exact assignment (person + role) from a card. If the person holds several roles on the card, the role is required.

write_set_role_effortA

Set effort for one or more roles on a card. Effort always belongs to a role: this writes the RoleEffort rows, never the card total, which Targetprocess computes from them. A role is required. Task role efforts ROLL UP into the parent user story, overwriting the story's value for that role; the parent's before/after values are reported rather than assuming the story estimate was kept.

write_set_custom_fieldsA

Set custom fields on a card by name, e.g. {"BackEnd":"Done","FrontEnd":"To Do"}. Dropdown values are validated against the field's options (see read_custom_field_options) before anything is sent; null clears a field. Values are read back.

write_teamA

Add teams to or remove teams from a card (names or ids). Adding appends; removing deletes only the named team assignment.

write_commentA

Add a comment to a card. Pass format markdown for Markdown; otherwise plain text lines become paragraphs and HTML is sent as-is. replyTo answers another comment.

write_log_timeA

Log time spent on a card for a person (default: you). date is YYYY-MM-DD (default: today in the server's time zone). Where the card's process tracks time, this is a Time entry and the role defaults to the person's only role on the card (pass role if they have none or several). Where the process has no Time Tracking practice but the instance tracks time in a TimeRecord type, this creates a time record linked to the person and the card (and a task's story); records have no role or remaining time, and Targetprocess names them itself.

write_relateA

Relate two cards: relation Dependency, Blocker, Relation (default), Link or Duplicate (or any type on the instance). outbound (default): id → to (id is the master); inbound: to → id. An existing identical relation is left alone.

write_followA

Follow (or with unfollow: true, stop following) a card, for yourself or another person.

write_test_casesB

Create test cases with ordered steps under a test plan. The project is inherited from the test plan. Each case is read back.

write_test_runA

Record a test run of a test plan: creates a test plan run (Targetprocess adds a "Not run" test case run per case), then sets each given test case's result (Passed, Failed, Blocked, OnHold, NotRun) with an optional comment.

write_createA

Create an entity of any resource that supports create (layer 1), validated against the catalog before sending. Nested children may be included, e.g. {"Name":"Story","Project":{"Id":2},"Tasks":{"Items":[{"Name":"T1"}]}}. Never include Id. Custom fields go in "CustomFields":[{"Name","Value"}]. Prefer write_create_card for cards: it applies the team rules.

write_updateA

Update fields of an existing entity (layer 1), validated against the catalog before sending. The response is read back and any requested value that did not persist is reported. Writing a card Effort here bypasses role efforts; use write_set_role_effort instead.

write_bulkA

Create or update up to 500 entities of one resource in one call (layer 1). Items with "Id" update, items without create. Every item is validated first; nothing is sent if any item is invalid.

write_collection_addA

Add items to an addable collection of an entity (layer 1). Collection posts APPEND to what is there; nothing is replaced. For assignments, teams and role efforts prefer write_assign, write_team and write_set_role_effort.

write_storageA

Create or update a storage entry. MERGE semantics: posted publicData/userData keys are added or overwritten, other keys are kept, a null value deletes that key. A missing group or key is created. Scope and publicData can be changed only by the owner or an administrator.

write_attachmentA

Upload files to a card (UploadFile.ashx). Each file is given as base64 content with a name; pounce never reads local files itself, so the client decides what may be uploaded. Attachments are read back to confirm they arrived.

delete_cardA

Delete a card by id alone (its type is resolved). A card with child cards (a story's tasks and bugs, a feature's stories, an epic's features, a test plan's test cases) is only deleted with withChildren: true, since Targetprocess may delete them with it. Reports what was deleted and the parent card's state and efforts before/after.

delete_relationA

Delete the relation between two cards, in either direction. If they have several relations, pass relation (type name) to pick one.

delete_entityB

Delete one entity of any resource that supports delete (layer 1). Reads it first and reports what was deleted.

delete_bulkA

Delete up to 500 entities of one resource by id (layer 1). Targetprocess bulk delete works by id only.

delete_collection_removeA

Remove items from a removable collection of an entity by child id (layer 1), e.g. unlink test cases from a test plan. To unassign a person prefer write_unassign.

delete_storageA

Delete one storage entry (only its owner or an administrator can).

admin_createA

Create a configuration/administration entity. Administration resources only (Project, Team, User, Process, Workflow, EntityState, Role, CustomField, ...). Requires an administrator token.

admin_updateA

Update a configuration/administration entity. Administration resources only (Project, Team, User, Process, Workflow, EntityState, Role, CustomField, ...). Requires an administrator token.

admin_deleteA

Delete a configuration/administration entity. Administration resources only (Project, Team, User, Process, Workflow, EntityState, Role, CustomField, ...). Requires an administrator token.

admin_collection_addA

Add items to a collection of a configuration/administration entity (e.g. Team TeamMembers). Administration resources only (Project, Team, User, Process, Workflow, EntityState, Role, CustomField, ...). Requires an administrator token.

admin_collection_removeA

Remove items from a collection of a configuration/administration entity. Administration resources only (Project, Team, User, Process, Workflow, EntityState, Role, CustomField, ...). Requires an administrator token.

admin_undeleteA

Restore deleted entities by id and entity type (e.g. UserStory, Project, User). Administrator token required. Comments, milestones and programs cannot be undeleted.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 58 tools

Disambiguation4/5

Most tools have clearly distinct purposes, with detailed descriptions that disambiguate card-specific operations from generic ones (e.g., read_card vs read_get, write_create_card vs write_create). Some potential confusion exists between read_query and read_v2_query, and between write_update_card and write_update, but descriptions explicitly guide selection.

Naming Consistency4/5

All tool names follow a consistent prefix_verb_noun snake_case pattern (read_*, write_*, delete_*, admin_*), making the set predictable. Minor deviations like write_team, write_follow, and write_relate use verbs instead of nouns, but the overall convention is strong.

Tool Count1/5

With 58 tools, the server exceeds the 50+ threshold defined as an extreme mismatch. While tools are organized by operation type and cover a comprehensive API, the sheer number overwhelms agents and raises misselection risk. Generic CRUD and admin tools could be consolidated.

Completeness4/5

The tool surface covers the bulk of Targetprocess card workflows, including create/read/update/delete for cards, relations, custom fields, comments, attachments, and test runs. Notable gaps include no write/delete for releases and iterations, no comment deletion, and no attachment removal, but these are minor relative to the breadth covered.

Maintenance

ActivityMaintained
ResponsivenessNo issues