Skip to main content
Glama

mcp

by com.teamwork

twprojects-create_custom_item_record

Create a record (row) on a custom item type. For example, add a Contract on the Contracts type. Pass field values by name; the tool resolves names to the API's internal IDs. Custom items are user-defined entity types — Contracts, Leads, Deals, or anything else a customer has set up on a project. Use these tools when the user refers to an entity that is NOT a built-in Teamwork concept (Task, Tasklist, Project, Milestone, Comment, Notebook, Company, Team, User, Tag). If you don't recognise an entity name in the user's request, assume it is a custom item and call twprojects-list_custom_items on the relevant project to confirm.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name of the record (e.g. "Acme Inc Contract").
section_idNoOptional section ID to place the record in.
field_valuesNoField values to set on the record. Each entry is {field_name, value}. Field names are matched case-insensitively against the custom item type's fields. Values are coerced by field type: dropdown/multiselect accept option labels or option twIds; date/time/datetime accept ISO-8601 strings; checkbox accepts bool or yes/no/true/false; number accepts numeric or numeric string; user accepts a user ID (or array of IDs for multi-user fields). To clear a field, send null.
custom_item_idYesCustom item type ID that will own the new record.
position_after_idNoPlace the record after the given record ID. Null appends to the end.

TDQS

A4.5/5.0
Behavior4/5

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

The description discloses a key behavior beyond annotations: field values are passed by name and the tool resolves them to API internal IDs. It also clarifies the scope of custom items. No annotations are contradicted, and while it doesn't discuss permissions or response format, it provides solid contextual behavior for a create operation.

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 and well-structured: main action first, followed by an example, context definition, and usage guidance. No redundant or filler sentences; every sentence provides 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?

The description fully covers the tool's purpose, usage context, example, and disambiguation strategy. It explains what custom items are, when to use the tool, and what to do if unsure. With no output schema and minimal annotations, this description is sufficiently complete for an agent to invoke the tool correctly.

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 coverage is 100%, and each parameter already has a clear description. The description adds a general note about passing field values by name and resolving IDs, which complements the schema but does not add substantial new semantics beyond what the schema already provides. Therefore, baseline 3 is appropriate.

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: 'Create a record (row) on a custom item type' with a concrete example (add a Contract on the Contracts type). It distinguishes this tool from siblings by specifying it deals with custom item records, not built-in entity types.

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?

Explicitly instructs when to use these tools: when the user refers to an entity that is NOT a built-in Teamwork concept (Task, Tasklist, Project, etc.). It also provides a fallback strategy: if uncertain, call twprojects-list_custom_items to confirm, which is excellent guidance for tool selection.

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

All mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3/5.0
Disambiguation4/5

Tools are organized into clear namespaced subdomains (twchat, twdesk, twprojects, twspaces) with distinct actions per resource. However, the twprojects domain has many tools for custom items that share repetitive descriptions, and a few tools like `twprojects-search` could overlap with list tools, but overall boundaries are clear.

Naming Consistency4/5

Naming follows a consistent `{prefix}-{verb}_{noun}` pattern across all tools, with prefixes indicating the subdomain. The only minor inconsistency is the use of singular and plural in nouns (e.g., `get_company` vs `list_companies`) and some verbs like `link_project_to_workflow` vs `move_tasks`, but the pattern is predictable.

Tool Count3/5

With 200 tools, this server is extremely large, covering multiple Teamwork products (Chat, Desk, Projects, Spaces). While each subdomain is well-scoped individually, the sheer number makes it unwieldy for an agent to navigate, and many tools could be pruned or combined (e.g., many custom item variants). It's on the high end of acceptable.

Completeness4/5

The surface is comprehensive, covering CRUD operations for most entities, specialized queries (search, count, summarize), and cross-entity linking (link_task_to_ticket). Minor gaps include lack of delete tools for most entities and some missing lifecycle operations (e.g., archiving), but core workflows are well-covered.

Resources