Skip to main content
Glama

The Bridge

by dev.thebridge
OverviewDiscussionsAdmin

Evaluate Feature Flag

evaluate_feature_flag
Read-onlyIdempotent

Dry-run a feature flag against a synthetic context and explain the verdict. Nothing is written and no eval is recorded — this evaluates the live flag config in-process with the exact evaluator the server and the SDKs use, so the answer matches what the app would see. Use it to check targeting you just wrote before shipping code that depends on it. Arguments: key (required), identity (the stable id the rule buckets on — a user id, tenant id or device key), and attributes (a flat map of the values the rule tests, e.g. { "bridge:billing.entitlement.analytics": true, "privileges": ["REPORTS_VIEW"] }; dotted paths and nested objects both resolve, and roles are their KEYS). Returns the resolved value plus an explanation: which branch matched (or that none did), whether a rolloutPct bucket applied, and the bucket number. IMPORTANT: a rule with rolloutPct < 100 requires an identity; called without one the evaluator returns the safe otherwiseValue instead of bucketing, which is reported explicitly rather than looking like a targeting failure. warnings also names settings that cannot mean what they look like: switched on while the onValue is false, or a rule on a plan or role the app does not have. get_flag shows the rule being evaluated; update_feature_flag changes it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appNoId of the Bridge app to act on for this call (see list_apps). Omit to use the current app.
keyYesFlag KEY to evaluate (see list_feature_flags).
identityNoStable per-eval identity used for sticky rollout bucketing. REQUIRED for a meaningful answer whenever the rule has rolloutPct < 100.
attributesNoAttribute values the rule conditions read. Dotted keys ("user.role") and nested objects both work. Values may be strings, numbers, booleans, objects or lists (privileges is a list of privilege keys).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / attributes / additionalProperties / type
      Added value: +[
+  "string",
+  "number",
+  "boolean",
+  "object",
+  "array",
+  "null"
+]
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations: 'Nothing is written and no eval is recorded,' the evaluator is the same one the server/SDKs use so results match production, and it discloses the rolloutPct<100-without-identity fallback to otherwiseValue plus the `warnings` behavior for misleading settings. None of this is derivable from readOnlyHint/idempotentHint.

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?

Front-loaded with the purpose and the write-safety guarantee, then parameters, then the rolloutPct caveat. It is on the long side and somewhat dense, but nearly every clause carries non-redundant information, so little could be cut without losing behavioral detail.

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 still describes the return shape (resolved value, which branch matched, whether a bucket applied, the bucket number, and warnings), and covers the identity-required edge case. An agent has everything needed to call it correctly.

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?

Schema coverage is already 100%, yet the description adds real meaning: identity is the id the rule buckets on (user/tenant/device), attributes is a flat map with a worked example, dotted paths and nested objects both resolve, and roles are referenced by their KEYS. It also flags the identity-required precondition for partial rollouts.

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?

Opens with a specific verb+resource+scope: 'Dry-run a feature flag against a synthetic context.' It explicitly routes away from siblings, noting get_flag shows the rule and update_feature_flag changes it, so an agent can distinguish it without opening any schema.

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?

States the concrete use case ('check targeting you just wrote before shipping code that depends on it') and contrasts the read-only dry-run against get_flag (inspect) and update_feature_flag (mutate). When-to-use is explicit and the alternatives are named.

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

All The Bridge 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