FrameOn — Agentic Project Management

get_project_team

Read-onlyIdempotent

Lists the people on this project with their ids: explicit members when the project restricts visibility, otherwise the active users of the workspace (clients excluded) plus anyone already assigned there. Use the returned id as assignee_id in create_task or update_task — it is required there, so call this first. Never guess an id, and never assign work to someone this tool did not return; when it is unclear who should own a task, ask the person. Read-only, one project per call.

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": {
      "project_id": "<project_id>"
    },
    "name": "get_project_team"
  }
}

Input Schema

Name	Required	Description	Default
`project_id`	Yes	Project ID this call refers to. Omit it once to get the list of projects you can access.
`include_email`	No	Include each member's email. Off by default: the member id is what `update_task.assignee_id` needs. Ask for it only to tell people with the same name apart.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 19, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, but the description adds meaningful context beyond that: explicit members versus active workspace users, exclusion of clients, inclusion of anyone already assigned, and the one-project-per-call constraint. These are real behavioral traits that affect how the agent should interpret and use the result.

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

Conciseness5/5

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

The description is compact and front-loaded: it states what the tool returns, then the visibility rule, then the downstream usage constraint, then the safety guidance. Every sentence adds distinct value with no repetition.

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 read-only lookup tool with no output schema and fully documented parameters, the description covers what the agent needs: who will be returned, how visibility affects the result, and why the id matters for subsequent task tools. Nothing essential 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?

Schema coverage is 100%, so both parameters are already fully documented in the schema. The description reinforces the one-project scope and the assignee-id purpose, but it does not add format, edge-case, or syntax details beyond what the schema already provides. Baseline 3 is appropriate.

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 ("Lists the people on this project with their ids") and immediately clarifies the visibility rule that determines membership. This is specific enough that an agent can distinguish it from all sibling tools, none of which list project membership.

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

Usage Guidelines5/5

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

Explicitly says to use the returned id as `assignee_id` in `create_task` or `update_task`, that it is required there, and therefore to call this first. It also adds clear prohibitions: never guess an id, never assign to someone not returned, and ask the person when ownership is unclear.

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

All FrameOn — Agentic Project Management 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.