Metadata MCP Connector

List User Accounts

list_user_accounts

Read-only

List accounts the current user has access to, with optional name filtering.

                            USE FOR: "which accounts do I have access to?", "show me my accounts", "what accounts can I manage?", "what is my account ID?", "which account am I logged into?", "what role do I have?", "show me account named X", "do you have an account called X?"

                            AUTH METHODS: JWT tokens (OAuth) | PAT tokens (prefix "pat-")

                            ARGS:
                            - name (optional for regular users, REQUIRED for super users unless `account_id` is given): partial account name to search for. Super users span the whole platform and would otherwise return an unbounded list, so a search term is mandatory for them. If a super user calls this with neither `name` nor `account_id`, the tool returns an error asking for one — re-call with the user's intended search term.
                            - account_id (optional): exact account id to look up. Use this instead of `name` when the search term is a number ("account 4368", "the 12057 account"), since account names are not ids and a numeric name search finds nothing. It satisfies the super-user search requirement on its own; supplying both narrows to accounts matching BOTH.

                            RESPONSE FORMAT (identical for JWT and PAT — the token format does not change the result):
                            Regular users: user_id, email, default_account_id, is_super_user, token_type, accounts[{account_id, name, role}]
                            Super users with neither argument: error response — supply `name` or `account_id` and retry.
                            Super users with name: matching accounts platform-wide (paged at 20).
                            Super users with account_id: the single matching account, or an empty list when no account carries that id.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No	Partial account name to search for. Optional for regular users (acts as a filter); required for super users unless `account_id` is given (acts as the search query against the whole platform).
`account_id`	No	Exact account id to look up. Use instead of `name` when the search term is numeric; it satisfies the super-user search requirement on its own.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses super-user behavior, mandatory search requirements, error responses, paging at 20, and the full response structure for each user type. It also explicitly notes that the token format does not change the result, adding genuine behavioral nuance.

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 description is well-organized into four clearly labeled sections, and each section carries useful information. It is longer than average because it handles two user classes and multiple argument combinations, though the USE FOR list partially repeats the purpose, preventing a perfect score.

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?

With no output schema, the description thoroughly documents response formats for regular users, super users with no arguments, super users with name, and super users with account_id, including error conditions. Nothing needed to invoke and interpret the tool is missing.

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?

Although the schema already describes both parameters, the ARGS section adds vital semantics: super-user requiredness, the numeric-account_id guidance ('account names are not ids'), and the behavior when both parameters are supplied. This is far beyond the schema's basic descriptions.

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?

The opening sentence 'List accounts the current user has access to, with optional name filtering' states a specific verb, resource, and scope. The USE FOR section further grounds the purpose with concrete user queries, distinguishing it from list_* siblings like list_audiences and list_budget_groups that cover different resources.

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?

The USE FOR section provides numerous example phrasings that clearly signal when to invoke the tool. It also gives detailed selection rules for arguments based on user type (regular vs super user), but it does not explicitly name alternative tools or state when not to use this one.

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

All Metadata MCP Connector 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?