Skip to main content
Glama
Sign In
Workvivo MCP

Workvivo MCP

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List your Workvivo team

workvivo_get_my_team
Read-onlyIdempotent

Retrieves your Workvivo team directory — manager, peers, or reports — with each person's name, job title, department, location, and email. Use it to identify teammates and contact details without manual lookup.

Instructions

List the people on your team in Workvivo (as the directory defines it — your manager and peers or your reports): name, job title, department, location and email. Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "workvivo_get_my_team"
  }
}

Input Schema

NameRequiredDescriptionDefault
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact (default) keeps id, name, job title, department, location and email per person; "full" returns Workvivo's record as sent (credential-shaped fields such as meeting passcodes are redacted on every view).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the trailing 'Read-only' is largely redundant. The description does add value beyond annotations by defining team scope and enumerating the per-person fields returned, but it says nothing about result size, pagination, or ordering for what could be a long list.

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 front-loaded sentence carries the purpose, scope definition and return fields, followed by a short safety note. The closing 'Read-only' duplicates the readOnlyHint annotation and could be dropped, but nothing else is wasted.

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 simple zero-required-parameter read tool, the description covers purpose, team-scope semantics, and the returned fields — compensating for the absent output schema. Annotations handle safety, and the schema fully documents the only parameter, so nothing an agent needs to select or call it is missing.

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?

The single 'view' parameter has 100% schema description coverage, including enum meanings and the redaction note, so the schema carries the semantics fully. The description adds no information about the compact/full choice, which is acceptable at this coverage level (baseline 3).

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?

States a specific verb and resource ('List the people on your team in Workvivo') and immediately disambiguates what 'team' means — manager and peers or reports as the directory defines it — then names the returned fields. This clearly separates it from siblings like workvivo_search_people or workvivo_get_person.

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?

It gives clear context for use: this is your own team per the directory, not an arbitrary people lookup, which implicitly points an agent away from workvivo_search_people. It does not explicitly name alternatives or state exclusions (e.g., what to use for a colleague outside your team), leaving that to inference.

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