Skip to main content
Glama

search

Retrieve sessions, traces, or completions from a Freeplay project using flexible filters to analyze observability data and identify issues.

Instructions

Search observability data in a Freeplay project. This is a read-only operation.

Returns sessions, traces, or completions matching the given filters.

  • Sessions are top-level containers that group related traces and completions, representing a complete user interaction, conversation, or agent run.

  • Traces group related completions and tool calls within a session, representing a functional unit of work such as a single agent run or workflow step.

  • Completions are individual LLM calls with their inputs, outputs, and metadata.

Filter syntax

The filters parameter accepts a JSON string. A single filter has the form: {"field": "", "op": "", "value": }

Operators

eq        Equals
lt        Less than
gt        Greater than
lte       Less than or equal
gte       Greater than or equal
contains  Contains substring
between   Within numeric range

Available fields

Numeric fields (support eq, lt, gt, lte, gte): cost e.g. 0.003 latency e.g. 8 (seconds) start_time e.g. "2024-06-01 00:00:00"

Equality fields (support eq): environment e.g. "staging" prompt_template e.g. "my-prompt" prompt_template_id e.g. "uuid..." completion_id e.g. "uuid..." session_id e.g. "uuid..." model e.g. "gpt-4o" provider e.g. "openai" review_status e.g. "review_complete" agent_name e.g. "support-agent" trace_agent_name e.g. "my-agent" api_key e.g. "production-key" assignee e.g. "user@example.com" insight_name e.g. "Response Quality Issues"

Text search fields (support contains): completion_output e.g. "weather"

Nested JSON fields (field.* syntax, support contains): completion_inputs.* e.g. field="completion_inputs.topic", value="weather" completion_feedback.* e.g. field="completion_feedback.rating", value="positive" session_custom_metadata.* e.g. field="session_custom_metadata.user_type", value="premium" trace_custom_metadata.* e.g. field="trace_custom_metadata.workflow", value="onboarding" trace_input.* e.g. field="trace_input.query", value="weather" trace_output.* e.g. field="trace_output.response", value="sunny" trace_feedback.* e.g. field="trace_feedback.rating", value="positive"

Evaluation result fields (nested JSON, field.* syntax): completion_evaluation_results.* supports eq. e.g. field="completion_evaluation_results.Response Quality", value="4" completion_client_evaluation_results.* supports eq. e.g. field="completion_client_evaluation_results.score", value="85" trace_evaluation_results.* supports eq, gt, lt, gte, lte, contains. e.g. field="trace_evaluation_results.Quality Score", value=5 trace_client_eval_results.* supports eq, contains. e.g. field="trace_client_eval_results.confidence_score", value=0.95

Evaluation notes fields: evaluation_notes.content supports contains. e.g. "needs review" evaluation_notes.author supports eq. e.g. "user@example.com" evaluation_notes.created_at supports gt, lt, gte, lte. e.g. "2024-06-01 00:00:00"

Compound filters

Combine filters with "and", "or", "not" (nestable to any depth): {"and": [, , ...]} All conditions must match {"or": [, , ...]} At least one must match {"not": } Negates a condition

Example - expensive GPT-4o or Claude completions outside production: {"and": [{"field": "cost", "op": "gte", "value": 0.001}, {"or": [{"field": "model", "op": "eq", "value": "gpt-4o"}, {"field": "model", "op": "eq", "value": "claude-3-opus"}]}, {"not": {"field": "environment", "op": "eq", "value": "prod"}}]}

Args: project_id: The Freeplay project ID result_type: What to search for: "sessions", "traces", or "completions" filters: Optional JSON string with filter expression. Examples: Simple: '{"field": "environment", "op": "eq", "value": "production"}' Compound: '{"and": [{"field": "cost", "op": "gte", "value": 0.01}, {"field": "model", "op": "eq", "value": "gpt-4o"}]}' limit: Maximum number of results to return (default: 20) offset: Number of results to skip for pagination (default: 0)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo
filtersNo
project_idYes
result_typeYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Declares read-only operation, explains result types, and details filter syntax comprehensively. With no annotations provided, the description fully discloses behavior: no side effects, authentication implied but not required beyond tool access, and pagination via limit/offset. No contradictions.

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?

Well-structured: summary first, then key concepts, followed by filter syntax documentation, and parameter descriptions. Each section earns its place; no fluff. Front-loaded with core purpose and read-only nature.

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?

Given the complexity (5 parameters, extensive filter system), the description covers all aspects: result types, filter syntax, all available fields with operators, examples, and parameter details. Output schema exists, so return values are not needed. Complete for agent usage.

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 0% but description compensates fully with an 'Args' section explaining each parameter, plus extensive documentation of the 'filters' parameter including syntax, operators, available fields, and compound filter examples. Adds substantial meaning beyond the bare schema.

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?

States verb 'Search' and resource 'observability data in a Freeplay project', specifies read-only, and lists result types (sessions, traces, completions). Clearly distinguishes from sibling tools which focus on prompts, insights, and projects.

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?

Provides clear context for when to use: searching with filters for sessions, traces, or completions. Includes filter syntax and examples. Does not explicitly state when not to use, but sibling tools are sufficiently distinct so no ambiguity arises.

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/freeplayai/freeplay-mcp'

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