Skip to main content
Glama

Phoenix operational_context unpaid canary

Get operational_context

get_operational_context

Whether that named member-lane business is currently in-scope for a subsequent bounded operational action, using only operator-authoritative non-PII identity, category, status, site, and timestamps.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceNo
grant_tokenYesHMAC-signed unpaid_invited_canary grant
business_slugYesMust match grant tenant
invitee_identityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2/5.0
Behavior2/5

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

No annotations exist, so the description must disclose side effects or read-only nature. It doesn't state whether this is a pure read, what authentication is required beyond the token, or what happens on failure.

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

Conciseness3/5

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

It's a single concise sentence, but the phrasing is convoluted and not well-structured for an agent to parse.

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

Completeness1/5

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

With 4 parameters, no output schema, and no annotations, the description is severely under-specified. It doesn't mention return format, error behavior, or any operational constraints.

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

Parameters2/5

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

Schema descriptions cover only half the parameters; the description adds no meaningful mapping to parameters. Terms like 'identity' and 'category' are not tied to the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is a noun phrase rather than a clear verb+resource statement. It vaguely indicates a check of 'in-scope' status but uses unexplained jargon ('member-lane business', 'bounded operational action') without clarifying what the tool actually returns or does.

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?

No explicit guidance on when to use. It implies a pre-action check but provides no context about alternatives or situations to avoid.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources