Skip to main content
Glama
Zeekeey-jpeg

singleops-mcp-server

by Zeekeey-jpeg

List users current

singleops_read_list_users_current
Read-onlyIdempotent

Fetch current SingleOps users and their account details, including roles and contact info, to support user management, permissions checks, or reporting.

Instructions

List users current. (GET /api/v1/users/current) Inferred from the SingleOps web app's own traffic; confirm results. Returns JSON with keys: id, account_id, name, email, manager_user_id, rate, first_name, last_name, custom_fid, vendor_id, is_sales_rep, office, mobile, route_capacity, color, color_priority, role_id, html_color, text_color, title, operations, sales_reps, operation_id, all_operations, is_super_admin, role, default_dashboard_id.

Input Schema

NameRequiredDescriptionDefault
extra_queryNoAny additional query parameters.
response_formatNoOutput format: "markdown" (default, readable tables) or "json" (full raw response).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds a meaningful caution that results are inferred from web app traffic and should be confirmed, but it does not explain pagination, authentication, filtering behavior, or why 'current' is scoped as it is.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is front-loaded with the endpoint and reliability caveat, but the long inline enumeration of return keys is bulky and not structurally broken out. It is efficient in terms of no filler, yet the field list dominates the description.

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?

Because there is no output schema, the description usefully lists returned JSON keys and discloses the inferred-data caveat. However, it leaves 'current' undefined and does not clarify scope, filtering, pagination, or how results relate to sibling user tools.

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 100%, with both extra_query and response_format fully described in the schema. The description does not mention either parameter, so it adds no parameter semantics beyond what the schema already provides; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource as users via 'List users current' and adds the endpoint GET /api/v1/users/current. However, 'current' is not explained, and the description does not distinguish this tool from siblings such as singleops_read_whoami or singleops_read_list_users_crews, leaving the exact scope ambiguous.

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?

The description provides no guidance on when to use this tool versus alternatives like singleops_read_whoami or singleops_read_list_users_crews. The only procedural note is 'confirm results,' which is a reliability caveat rather than usage guidance.

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