Skip to main content
Glama
Selerity

accelo-mcp

by Selerity
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

accelo_set_profile_value

Set a profile field value on an object and verify it persisted.

Instructions

Set a profile field value on an object and verify it persisted.

The write goes through Accelo's dedicated profile-value endpoint, POST /{object_type}/{object_id}/profiles/fields/{profile_field_id} ("Set a Profile Field Value"). The older PUT /{object_type}/{object_id} + profile.{id} form is only the create-company shortcut, not a general profile-value write, so it silently no-ops for hyperlink fields — that was the bug behind this tool reporting a false success.

The request body is shaped by the field's field_type, which is resolved first via GET /{object_type}/profiles/fields:

  • integer -> value_int (the string value is coerced to int)

  • date / date_time -> value_date (unix timestamp or ISO8601 string, passed through as given)

  • lookup -> value_id (the object id in value) plus value_type (the lookup object type, e.g. company)

  • everything else, including hyperlink, text, decimal, currency, select, multi_select and structure -> value (a bare string; for a hyperlink that is the plain URL and Accelo stores value_type as null)

After the write, the value is read back via GET /{object_type}/{object_id}/profiles/values (with _fields=_ALL so custom fields are returned) and compared against what was submitted. If no matching row is found, or the persisted value does not match, an error is returned (status verify_failed) rather than a success — the tool can never report a silent no-op as success. Date comparison is deliberately lenient (presence/non-empty) because Accelo may normalise the stored date format.

Values are validated before any write, so a bad input returns a structured error (error true) rather than failing mid-write:

  • invalid_value — an integer field was given a value that is not a valid integer.

  • value_type_required — a lookup field was given no value_type; it is mandatory for lookup writes.

  • field_not_found — the profile_field_id does not exist for the object type.

Args: object_type: The object type (e.g. "companies", "issues") object_id: The object's ID profile_field_id: The profile field's ID value: The value to set, as a string. For hyperlink/text fields this is the raw value; for integer/date fields it is coerced; for a lookup field it is the target object's id. value_type: Required for a lookup field — the lookup object type (e.g. "company"). A lookup write with no value_type returns a value_type_required error. Ignored for other field types.

Input Schema

NameRequiredDescriptionDefault
valueYes
object_idYes
value_typeNo
object_typeYes
profile_field_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • addedInput schema / properties / value_type
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Value Type"
+}
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

No annotations are supplied, so the description carries the full burden. It discloses the exact endpoints, field-type-dependent request body, pre-write validation errors, read-back verification, lenient date comparison, verify_failed status, and the false-success failure mode it prevents, giving unusually complete behavioral context for a mutation.

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?

Long but well structured and front-loaded: purpose and verification come first, followed by endpoint rationale, field-type mapping, verification behavior, and validation errors. The field-type mapping and error semantics justify the length, though there is minor repetition of the value_type requirement between the body and Args.

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?

For a five-parameter mutation with no annotations and no output schema, the description supplies the missing context: write semantics, verification, error codes, and return-status behavior. It also explains field-type-specific body shaping, so an agent can call it correctly without extra documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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

Schema description coverage is 0% and the schema only lists property names, so the Args section is essential. It defines every parameter's meaning, including coercion for integer/date fields, lookup value_id/value_type requirements, and that value_type is ignored for other field types.

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?

Starts with a specific verb and resource ('Set a profile field value') plus scope ('on an object and verify it persisted'), and explicitly rules out the older PUT/profile.{id} form. It makes clear this is the dedicated profile-value write rather than a generic object update, so an agent can distinguish it from update tools and the read-only profile tools.

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?

Explains the intended path for profile-field writes and why the older PUT form is not equivalent, including the silent no-op bug it avoids. It does not explicitly compare against the sibling accelo_set_extension_value, so the profile-vs-extension boundary is left implicit, but usage context and an alternative warning are present.

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