Skip to main content
Glama
Sign In
Capacities MCP Server

Capacities MCP Server

by inconceivablelabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update Capacities Object

update_object

Change selected properties of an existing Capacities object while leaving unnamed fields intact, and optionally append markdown to its body.

Instructions

Replace typed properties of an existing object (PATCH /object). Only the properties you name are changed; unnamed properties are left intact. WARNING: for a named property this REPLACES its value — it does NOT append. Naming a multi-value relation/label drops the prior list and sets exactly what you pass. To ADD to a relation, first read the current values (this tool reports them) and pass the full desired list. The optional body param is a convenience: after the PATCH, it also appends markdown to the object's body (POST /blocks/append) — the same additive write append_to_object performs on its own. Labels and relations are set by NAME and resolved strictly — an unknown name is an error. properties/labels/relations map keys accept a property NAME or id. Pass create_missing_relations: true to auto-create unmatched relation targets.

Input Schema

NameRequiredDescriptionDefault
bodyNoMarkdown body appended to the object after the update. Capacities markdown conventions apply in the body: `() text` creates and links a new Task; `#tag` creates or links a Tag; `[[Name]]` links an EXISTING object by title (renders as plain text if no such object exists — it does NOT create one). Note `() ` and `#` create objects as a side effect.
titleNoNew title for the object
labelsNoLabel props keyed by property NAME or id; value(s) are option NAME(s). REPLACES the named prop.
objectIdYesobjectId of the object to update
relationsNoEntity (relation) props keyed by property NAME or id; value(s) are entity NAME(s). REPLACES the named prop.
propertiesNoScalar props keyed by property NAME or id: text/url/number/boolean/date. REPLACES each named value.
collectionsNoCollection ids to set on the object
create_missing_relationsNoAuto-create relation targets that don't already exist

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.1

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and discloses the PATCH mutation, destructive replacement of named multi-value relations/labels, the body append side effect, strict name resolution errors, and the create_missing_relations side effect. It does not cover permissions, rate limits, or broader error/return behavior, so it is strong but not complete.

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 front-loaded with the action and scope, then moves through the replacement warning, additive-relation guidance, body behavior, strict resolution, and create-missing behavior. It is dense but every sentence carries relevant information, and the warning is placed where it will be seen.

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?

For a complex mutation with nested property maps and no output schema, the description covers replacement semantics, side effects, alternatives, strict name resolution, and relation creation. It leaves out return details and permission/error context, but provides enough 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds useful sequencing and resolution details: body is appended after the PATCH, keys accept property names or ids, labels and relations resolve strictly by name, and create_missing_relations auto-creates unmatched targets. Much of this reinforces the schema, but the added operational context is valuable.

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 states a specific verb and resource: replace typed properties of an existing object via PATCH /object. It clearly distinguishes this update operation from additive sibling behavior by explaining that named properties are replaced rather than appended.

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?

It explains that only named properties change, warns that values are replaced rather than appended, and gives explicit guidance for adding to relations by reading current values and passing the full desired list. It also identifies append_to_object as the standalone alternative for additive body writes.

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

Deploy Server

Other Tools