Skip to main content
Glama
Sign In

ChartAnt

by net.chartant
OverviewDiscussionsAdmin

Manage workspace

manage_workspace
Destructive

Team and sharing settings of the connected workspace. operation: list_team; invite_member (args {email}) and remove_member (args {member: user id from list_team}) for the owner only; list_client_pages, create_client_page (args {name, charts: [chart ids]}) and delete_client_page (args {id}) for read-only pages to share with clients; list_domains, add_domain (args {host, page: client page id}), verify_domain and remove_domain (args {host}) for a custom domain (Team or Business owner). remove_member, delete_client_page and remove_domain cannot be undone. Returns the result as JSON. Needs a connection signed in to a free account (connector URL ending in /mcp/account).

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": {
      "operation": "<operation>"
    },
    "name": "manage_workspace"
  }
}

Input Schema

NameRequiredDescriptionDefault
argsNoArguments for the operation, e.g. {"email":"ana@example.com"}; {} for list operations.
operationYesWhat to do; see the description for each operation's args.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and non-idempotent; the description adds real value on top by naming exactly which three operations cannot be undone and by disclosing the auth requirement (a connection signed in to a free account, connector URL ending in /mcp/account). It also states the JSON return shape, though it does not describe response contents.

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?

Dense but front-loaded: the resource is stated first, then operations grouped by theme (team, client pages, domains), then the destructive/auth notes. The middle section is a long semicolon chain rather than a list, which costs some scannability, but no sentence is filler.

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?

Covers all ten enum values with their args, names the destructive subset, states role prerequisites, and notes the connection type — everything needed to pick an operation and call it. Only the return payload remains vague ('Returns the result as JSON'), which matters somewhat since there is no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema's args object is untyped (additionalProperties only), so the description is the sole place where per-operation argument names appear: {email}, {member: user id from list_team}, {name, charts}, {id}, {host, page}. That is meaningful added semantics well beyond the schema, including a cross-operation dependency (member id comes from list_team).

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?

Names the resource (team and sharing settings of the connected workspace) and enumerates all ten operations with their arguments, so the agent knows exactly what surface this tool covers. It does not explicitly contrast with the chart-generation siblings, but the domain is unmistakably different, so confusion risk is low.

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?

Gives per-operation eligibility rules: invite_member/remove_member are 'for the owner only' and domain operations require 'Team or Business owner', which tells the agent when an operation will be rejected. It does not phrase guidance as when-to-use-this-vs-alternatives, but for a single multi-op workspace tool that is a minor gap.

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

All ChartAnt toolsInspect
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