Skip to main content
Glama

accelo_list_profile_fields

List available Accelo profile fields for a chosen object type, such as contacts, companies, or jobs, to discover and select fields for CRM data operations.

Instructions

List profile fields available for an object type.

Args: object_type: The object type — affiliations, companies, contacts, contracts, invoices, issues, jobs, milestones, prospects, staff fields: Additional fields to return

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldsNo
object_typeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden, and it delivers little beyond the verb 'List' (which weakly implies a safe read). Nothing is said about auth requirements, pagination, rate limits, or what a profile field record contains, and there is no output schema to fall back on.

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?

One sentence of purpose followed by a compact Args block; the key constraint (object_type, with values) is front-loaded and there is no filler. Slightly verbose only because the enum list is inlined.

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

Completeness3/5

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

For a small two-parameter lookup tool with no annotations and no output schema, the description is minimally adequate: it names the operation and the valid object types, but leaves the meaning of 'profile field', the return shape, and the relationship to the profile-value tools unexplained.

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 description coverage is 0%, so the description is the only source of parameter meaning — and it does supply the full object_type enumeration, which the schema lacks entirely. However, 'fields: Additional fields to return' is vague: no format (comma-separated? repeated?), no distinction from the default field set, so the second parameter stays under-specified.

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?

States a specific verb (list) and resource (profile fields) scoped to an object type, and enumerates the valid object types so an agent immediately knows the domain. It is distinguishable from value-oriented siblings like accelo_get_profile_values and accelo_set_profile_value, though the description never explicitly draws that contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no reference to alternatives. An agent must infer on its own that this is a discovery call typically made before get_profile_values/set_profile_value, or that accelo_list_extension_fields is a different kind of metadata lookup.

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