Skip to main content
Glama
ZhipingYang

FFS MCP Server

by ZhipingYang

ffs_check_account

Check feature flag status for RingCentral accounts or extensions by providing a flag ID and account/extension ID. Verify current settings to manage feature access.

Instructions

Check the current status of an AccountId or ExtensionId in a Flag.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
flagIdYesComplete FFS Flag ID
idYesAccountId or ExtensionId to check

Implementation Reference

  • Core implementation of ffs_check_account tool logic. The checkAccountStatus function retrieves flag configuration and searches through all rules and conditions to find if the given AccountId or ExtensionId exists in any condition. Returns AccountStatus with exists, valueId, value, conditionName, and priority fields.
    export async function checkAccountStatus(
      flagId: string,
      id: string
    ): Promise<AccountStatus> {
      const flag = await getFlag(flagId);
    
      for (const rule of flag.rules) {
        for (const cond of rule.conditions) {
          if (cond.dimension === 'AccountId' && cond.argument?.split(',').includes(id)) {
            return {
              exists: true,
              valueId: rule.value.id,
              value: rule.value.value,
              conditionName: cond.description,
              priority: cond.priority,
            };
          }
        }
      }
    
      return {
        exists: false,
        valueId: null,
        value: null,
        conditionName: null,
        priority: null,
      };
    }
  • MCP tool handler for ffs_check_account. Orchestrates the logic by calling checkAccountStatus and getFlagOptions, then formats the response based on whether the ID exists in the flag. Parses JSON values and includes available options in the response.
    async ({ flagId, id }) => {
      try {
        const status = await checkAccountStatus(flagId, id);
        const options = await getFlagOptions(flagId);
    
        if (status.exists) {
          let parsedValue: unknown = status.value;
          try {
            parsedValue = JSON.parse(status.value || '');
          } catch {
            // Keep as string
          }
    
          return {
            content: [
              {
                type: 'text' as const,
                text: JSON.stringify({
                  success: true,
                  flagId,
                  id,
                  exists: true,
                  currentValue: parsedValue,
                  valueId: status.valueId,
                  conditionName: status.conditionName,
                  priority: status.priority,
                  availableOptions: options.map((o) => ({
                    valueId: o.valueId,
                    value: o.parsedValue,
                  })),
                  message: `ID ${id} is configured with value: ${JSON.stringify(parsedValue)}`,
                }, null, 2),
              },
            ],
          };
        } else {
          return {
            content: [
              {
                type: 'text' as const,
                text: JSON.stringify({
                  success: true,
                  flagId,
                  id,
                  exists: false,
                  message: `ID ${id} is not configured in any condition. Will use default value.`,
                  availableOptions: options.map((o) => ({
                    valueId: o.valueId,
                    value: o.parsedValue,
                  })),
                }, null, 2),
              },
            ],
          };
        }
      } catch (error) {
        return {
          content: [
            {
              type: 'text' as const,
              text: JSON.stringify({
                success: false,
                message: error instanceof Error ? error.message : 'Unknown error',
              }, null, 2),
            },
          ],
          isError: true,
        };
      }
    }
  • Zod schema definition for ffs_check_account tool inputs. Defines two string parameters: flagId (complete FFS Flag ID) and id (AccountId or ExtensionId to check), both with descriptive metadata.
    {
      flagId: z.string().describe('Complete FFS Flag ID'),
      id: z.string().describe('AccountId or ExtensionId to check'),
    },
  • TypeScript interface defining the AccountStatus return type for checkAccountStatus function. Contains exists boolean, valueId, value, conditionName, and priority fields (with null for non-existent accounts).
    export interface AccountStatus {
      exists: boolean;
      valueId: string | null;
      value: string | null;
      conditionName: string | null;
      priority: number | null;
    }
  • src/index.ts:165-167 (registration)
    Registration of ffs_check_account tool with MCP server using server.tool() method. Specifies tool name and description explaining it checks the current status of an AccountId or ExtensionId in a Flag.
    server.tool(
      'ffs_check_account',
      'Check the current status of an AccountId or ExtensionId in a Flag.',
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool checks status but doesn't explain what 'status' entails (e.g., enabled/disabled, active/inactive), whether it's a read-only operation, if it requires authentication, or any rate limits. This leaves significant gaps in understanding the tool's behavior beyond the basic action.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly, and every part of the sentence contributes essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters with full schema coverage and no output schema, the description adequately covers the basic purpose. However, it lacks details on what 'status' means in the return value, which is crucial since there's no output schema. For a status-checking tool with no annotations, more context on the expected output or behavioral traits would improve completeness.

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 the schema already documents both parameters ('flagId' and 'id') with clear descriptions. The description adds minimal value by mentioning 'AccountId or ExtensionId' for the 'id' parameter, but doesn't provide additional context like format examples or constraints beyond what the schema states, meeting the baseline for high coverage.

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?

The description clearly states the action ('Check'), the target ('status of an AccountId or ExtensionId'), and the context ('in a Flag'). It specifies what resource is being operated on, though it doesn't explicitly differentiate from sibling tools like 'ffs_get_user_info' or 'ffs_search_flag' which might also retrieve status information.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'ffs_get_user_info' or 'ffs_search_flag'. It lacks context about prerequisites, such as whether the flag must exist or if the ID needs to be valid, and doesn't mention any exclusions or specific scenarios for its use.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ZhipingYang/ffs-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server