Skip to main content
Glama
Fibery-inc

Fibery MCP Server

Official
by Fibery-inc

query_database

Execute custom queries on Fibery databases using the low-level API to retrieve, filter, and sort entity data with flexible field selection and parameterized conditions.

Instructions

Run any Fibery API command. This gives tremendous flexibility, but requires a bit of experience with the low-level Fibery API. In case query succeeded, return value contains a list of records with fields you specified in select. If request failed, will return detailed error message. Examples (note, that these databases are non-existent, use databases only from user's schema!): Query: What newly created Features do we have for the past 2 months? Tool use: { "q_from": "Dev/Feature", "q_select": { "Name": ["Dev/Name"], "Public Id": ["fibery/public-id"], "Creation Date": ["fibery/creation-date"] }, "q_where": [">", ["fibery/creation-date"], "$twoMonthsAgo"], "q_order_by": {"fibery/creation-date": "q/desc"}, "q_limit": 100, "q_offset": 0, "q_params": { $twoMonthsAgo: "2025-01-16T00:00:00.000Z" } }

Query: What Admin Tasks for the past week are Approval or Done? Tool use: { "q_from": "Administrative/Admin Task", "q_select": { "Name": ["Administrative/Name"], "Public Id": ["fibery/public-id"], "Creation Date": ["fibery/creation-date"], "State": ["workflow/state", "enum/name"] }, "q_where": [ "q/and", # satisfy time AND states condition [">", ["fibery/creation-date"], "$oneWeekAgo"], [ "q/or", # nested or, since entity can be in either of these states ["=", ["workflow/state", "enum/name"], "$state1"], ["=", ["workflow/state", "enum/name"], "$state2"] ] ], "q_order_by": {"fibery/creation-date": "q/desc"}, "q_limit": 100, "q_offset": 0, "q_params": { # notice that parameters used in "where" are always passed in params! $oneWeekAgo: "2025-03-07T00:00:00.000Z", $state1: "Approval", $state2: "Done" } }

Query: What Admin Tasks for the past week are Approval or Done? Tool use: { "q_from": "Administrative/Admin Task", "q_select": { "State": ["workflow/state", "enum/name"], "Public Id": ["fibery/public-id"], "Creation Date": ["fibery/creation-date"], "Modification Date": ["fibery/modification-date"], "Deadline": ["Administrative/Deadline"], "Group": ["Administrative/Group", "Administrative/name"], "Name": ["Administrative/Name"], "Priority": ["Administrative/Priority_Administrative/Admin Task", "enum/name"] }, "q_where": ["!=", ["workflow/state", "workflow/Final"], "$stateType"], # Administrative/Admin Task is not "Finished" yet "q_order_by": {"fibery/creation-date": "q/desc"}, "q_limit": 100, "q_offset": 0, "q_params: { "$stateType": true } }

Query: Summarize acc contacts with public id 1. Tool use: { "q_from": "Accounting/Acc Contacts", "q_select": { "Name": ["Accounting/Name"], "Public Id": ["fibery/public-id"], "Creation Date": ["fibery/creation-date"], "Description": ["Accounting/Description"] }, "q_where": ["=", ["fibery/public-id"], "$publicId"], "q_limit": 1, "q_params": { $publicId: "1", } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
q_fromYesSpecifies the entity type in "Space/Type" format (e.g., "Product Management/feature", "Product Management/Insight")
q_selectYesDefines what fields to retrieve. Can include: - Primitive fields using format {"AliasName": "FieldName"} (i.e. {"Name": "Product Management/Name"}) - Related entity fields using format {"AliasName": ["Related entity", "related entity field"]} (i.e. {"Secret": ["Product Management/Description", "Collaboration~Documents/secret"]}). Careful, does not work with 1-* connection! To work with 1-* relationships, you can use sub-querying: {"AliasName": {"q/from": "Related type", "q/select": {"AliasName 2": "fibery/id"}, "q/limit": 50}} AliasName can be of any arbitrary value.
q_whereNoFilter conditions in format [operator, [field_path], value] or ["q/and"|"q/or", ...conditions]. Common usages: - Simple comparison: ["=", ["field", "path"], "$param"]. You cannot pass value of $param directly in where clause. Use params object instead. Pay really close attention to it as it is not common practice, but that's how it works in our case! - Logical combinations: ["q/and", ["<", ["field1"], "$param1"], ["=", ["field2"], "$param2"]] - Available operators: =, !=, <, <=, >, >=, q/contains, q/not-contains, q/in, q/not-in
q_order_byNoList of sorting criteria in format {"field1": "q/asc", "field2": "q/desc"}
q_limitNoNumber of results per page (defaults to 50). Maximum allowed value is 1000
q_offsetNoNumber of results to skip. Mainly used in combination with limit and orderBy for pagination.
q_paramsNoDictionary of parameter values referenced in where using "$param" syntax. For example, {$fromDate: "2025-01-01"}
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it returns a list of records on success or detailed error messages on failure, includes examples showing complex query capabilities, and mentions constraints like 'use databases only from user's schema'. However, it doesn't cover rate limits, authentication needs, or pagination details beyond limit/offset.

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

Conciseness2/5

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

The description is overly long and not front-loaded. The first two sentences state the purpose, but then it includes four detailed examples that dominate the text. While examples are helpful, they make the description verbose and could be summarized or moved to documentation. The structure lacks efficiency, with repetitive query patterns.

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

Completeness4/5

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

Given the tool's complexity (7 parameters, nested objects, no output schema) and lack of annotations, the description does a good job of completeness. It explains success/failure outcomes, provides multiple examples covering various use cases, and includes important warnings (e.g., about database usage). However, it could better address error handling or advanced query patterns to be fully comprehensive.

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 all 7 parameters thoroughly. The description adds value through extensive examples that illustrate parameter usage in context (e.g., showing how q_where and q_params interact), but doesn't provide additional semantic meaning beyond what the schema descriptions offer. Baseline 3 is appropriate given high schema 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 tool's purpose: 'Run any Fibery API command.' It specifies the verb ('Run') and resource ('Fibery API command'), and mentions flexibility and required experience. However, it doesn't explicitly differentiate from sibling tools like 'describe_database' or 'list_databases' beyond being a general query tool.

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

Usage Guidelines3/5

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

The description implies usage by stating it 'requires a bit of experience with the low-level Fibery API' and provides examples, but doesn't explicitly say when to use this tool vs. alternatives like 'create_entity' or 'update_entity'. It gives context (e.g., 'use databases only from user's schema!') but lacks clear when/when-not guidance.

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/Fibery-inc/fibery-mcp-server'

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