fynk MCP

Create account team

create-account-team

Create a new team in the current account.

Use this tool when:

The user asks to create a new team
You need a new team to be available before attaching it to documents or templates

The tool requires name. Do not ask the user about an icon — the team will use the default icon. Optionally pass account_user_uuids to add initial members. After creation, don't expose the UUID to the user.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "create-account-team"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	Display name for the new team
`account_user_uuids`	No	Optional list of account user UUIDs to add as initial members of the team

Output Schema

Name	Required	Description
`icon`	No	Icon identifier for the team (e.g. "UserGroupIcon")
`name`	No	Name of the team
`uuid`	No	Identifier for the team. Do not show to the user unless they ask for it
`_entity_type`	No	Only relevant for tooling. Do not show to the user

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare the write/mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false), so the description only needs to add context — and it does: default icon handling ('Do not ask the user about an icon'), optional initial members, and the instruction not to surface the created UUID. It says nothing about permission requirements or failure modes, but those are secondary given the annotation coverage.

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?

The core statement and the usage triggers are front-loaded, and the operational notes (icon default, UUID handling) come last where they belong. The bulleted 'use this tool when' block is slightly heavier than the content requires, but no sentence is wasted.

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 two-parameter create tool with an output schema and full annotation coverage, the description supplies the missing pieces an agent actually needs: the required field, the optional membership list, the icon policy, and post-call UUID discretion. Only the permission/error surface is left unaddressed, which is minor here.

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%, so both name and account_user_uuids are already documented in-schema. The description restates the same facts ('requires name', 'optionally pass account_user_uuids to add initial members') without adding format or constraint detail, so the baseline 3 applies.

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 ('Create a new team') and scopes it to 'the current account'. Against siblings such as update-account-team, delete-account-team and list-account-teams the intent is unambiguous without opening a schema.

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?

An explicit 'Use this tool when' list gives two concrete triggers, including the sequencing case (team must exist before being attached to documents or templates). It does not name a when-not condition or point to update-account-team for modifying an existing team, which keeps it short of a 5.

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

All fynk MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?